94
have various security implications.
For instance, data that is to be encrypted in place may remain
unencrypted in the bad sector. Likewise, data to be erased (for example,
during the process of
creation of a hidden operating system) may remain in the bad sector. Plausible deniability (see
section
Plausible Deniability
) may be adversely affected whenever a sector is reallocated.
Additional examples of possible security implications are listed in the section
Security
Requirements and Precautions
. Please note that this list is not exhaustive (these are just
examples). Also
note that TrueCrypt
cannot
prevent any security issues related to or caused by
reallocated sectors. To find out the number of reallocated sectors on a hard drive, you can use e.g.
a third-party software tool for reading so-called S.M.A.R.T. data.
Defragmenting
When you (or the operating system) defragment the file system in which
a file-hosted TrueCrypt
container is stored, a copy of the TrueCrypt container (or of its fragment) may remain in the free
space on the host volume (in the defragmented file system). This may have various security
implications. For example, if you change the volume password/keyfile(s) afterwards, and an
adversary finds the old copy or fragment (the old header) of
the TrueCrypt volume, he might use it
to mount the volume using an old compromised password (and/or using compromised keyfiles that
were necessary to mount the volume before the volume header was re-encrypted).
To prevent this
and other possible security issues (such as those mentioned in the section
Volume Clones
), do
one of the following:
•
Use a partition/device-hosted TrueCrypt volume instead of file-hosted.
•
Securely
erase free space on the host volume (in the defragmented file system) after
defragmenting.
•
Do not defragment file systems in which you store TrueCrypt volumes.
Dostları ilə paylaş: