Escolar Documentos
Profissional Documentos
Cultura Documentos
3c Documentation |
Edgar Swank <edgar@spectrx.sbay.org> |
The only visible functional change from 1.3 to 1.3A is the appearance
of msg
which will be issued by both LOGIN and CRYPTDSK when they attempt to
verify a passphrase on a hard disk or diskette encrypted by version
1.3 CRYPTDSK operating in version 1.1 compatability mode. This
corrects the error in computing the check bytes used to verify the
passphrase and updates the check bytes to the correct 1.1 value and
WRITES back the boot sector. Note that once this update has taken
place, this disk cannot be decrypted by release 1.3 anymore.
The major change to 1.3c from 1.3a is the change of location for the
SecureDrive CryptFlag in the boot record and addition of parameters
/UCFO and /RCF.
Releases 1.3 and 1.3c of Secure Drive are based on releases 1.0 and
1.1, mostly written by
The code which we wrote is not copyrighted, but the program contains GNU
Copylefted code, and therefore may be freely distributed under the terms of
the GNU General Public Licence. See file COPYING for legalese.
* Two-drives bug fixed. V1.0 would get the drives out of order if you had
two physical hard drives. V1.1 fixes this problem.
The IDEA(tm) block cipher is covered by a patent held by ETH and a Swiss
company called Ascom-Tech AG. The Swiss patent number is PCT/CH91/00117.
International patents are pending. IDEA(tm) is a trademark of Ascom-Tech AG.
There is no license fee required for noncommercial use. Commercial users
may obtain licensing details from:
Dieter Profos, Ascom Tech AG, Solothurn Lab, Postfach 151, 4502
Solothurn, Switzerland, Tel +41 65 242885, Fax +41 65 235761.
Changes for version 1.2 are highlighted by "|" at the right margin. |
Changes for version 1.3 are highlighted by "+" at the right margin. +
SecureDrive uses the IDEA cipher in CFB mode for maximum data
security. The MD5 hash function is used to convert the user's
passphrase into a 128-bit IDEA key. The disk serial number, and track
and sector numbers are used as part of the initialization to make each
sector unique.
SecureDrive is made up of four program files. SECTSR is the +
memory-resident driver. CRYPTDSK is used to encrypt and decrypt
floppy disks and hard drive partitions. LOGIN is used to unlock
encrypted disks and partitions by loading the passphrase and disk
parameters into the resident module. FPART is a utility for finding +
starting cylinder & head numbers for partitions.
If you only have one hard drive partition (C:), you will have to
repartition your hard drive if you want an encrypted partition. You
can use encrypted floppies without changing your hard drive. You
should create a partition(s) large enough to hold all of your
sensitive data. For this example, assume the partition is (D:). Put
SECTSR, CRYPTDSK, LOGIN, and FPART in a directory which is in your +
PATH. (Not on the soon-to-be encrypted drive, of course!)
Normally re-partitioning a hard drive with FDISK destroys all the data
on it, so you would have to back up all your data beforehand. But if
you only have one partition now, there is a utility
available from the SIMTEL archive and possibly elsewhere that claims
to be able to split your first partition without data loss.
SECTSR
LOGIN D: /S (assuming drive D:)
LOGIN E: /S (and so on for each to-be-encrypted partition, up to four) +
This will load the TSR and put encrypted disk partitions in "safe mode", +
preventing accidental access and damage to the partitions after they are
encrypted. Reboot the system to make the changes take effect.
in cases where LOGIN can't find the partition from the DOS disk +
letter. This can happen in configurations with more than two physical +
disks or where special disk drivers are used. You can use the FPART +
utility to scan physical drive "drive", which are numbers starting +
from zero, and locate the proper numbers for "cylinder" and "head". +
The partition can have data on it, or it can be empty. Run CRYPTDSK
and select the drive letter. Enter a passphrase. CRYPTDSK will now
encrypt the partition. It will skip bad sectors.
Repeat this for each hard disk partition. If different users are +
assigned to different partitions, let each of them run CRYPTDSK and +
enter his own unique passphrase. +
Now type
To use an encrypted floppy, use CRYPTDSK to encrypt the floppy. Then run
LOGIN /F
and enter the passphrase. The encrypted floppy is now accessible. If you
entered the wrong passphrase, access will fail with a drive not ready error.
As of V1.3, LOGIN will ask you to verify your floppy disk passphrase +
by inserting an encrypted floppy disk into either the A: or B: +
drive. You are given the option to bypass the verification. +
As of Version 1.2, you may use an operand /PGP with LOGIN, either |
by itself, or with either operand above. By itself, |
LOGIN /PGP |
will prompt for a passphrase and set the PGPPASS environment variable |
with whatever is entered. As of version 1.3, you can use this form to +
erase PGPPASS by just pressing Enter (entering a null passphrase) at +
the prompt. This accomplishes the same thing as +
LOGIN /C /PGP +
LOGIN D: /PGP |
or |
LOGIN /F /PGP |
will use whatever PGPPASS is set to as the passphrase. For the hard |
disk partition (and optionally for floppies), LOGIN will test the +
PGPPASS passphrase. If it is incorrect, then it will prompt you for |
another passphrase. |
If PGPPASS is NOT set when these forms of LOGIN are used, than a passphrase |
is prompted for AND PGPPASS is set to this passphrase. |
As you read above, to switch to Version 1.1 from 1.0, you have to +
decrypt your hard disk partition and all your encrypted floppies +
(maybe hundreds of them!) with CRYPTDSK 1.0 and then re-encrypt with +
CRYPTDSK 1.1. Also, with Version 1.1, there is a very noticeable +
delay (1 or 2 seconds on my normally quick 386/SX 16) to enter and/or +
verify a passphrase. +
SET SD10CMP=Y | X +
"Y" (Yes) means that CRYPTDSK will always encrypt with Version 1.0, +
but that CRYPTDSK and LOGIN will decrypt disks encrypted with any +
version. Note that for this double-compatibility feature to work with +
diskettes, you have to let LOGIN /F verify the passphrase with the +
encrypted diskette you want to access.
"X" (exclusive) means that CRYPTDSK and LOGIN will ALWAYS encrypt and +
decrypt with version 1.0-compatible passphrases. You will generally +
not be able to access any disks encrypted with Version 1.1 (or Version +
1.3 with compatibility mode off). +
The reason I provided eXclusive mode is so that if you know you will +
be dealing only with version 1.0-compatible disks, you can avoid the +
delay of checking for 1.1-compatible disks when you inadvertantly +
enter an incorrect passphrase. +
Keys taken from SECTSR which are verified by decryption could have +
been generated in either 1.0 or 1.1-compatible mode. The keys +
internal to SECTSR have already been digested from the passphrase. +
These can be used by LOGIN and CRYPTDSK to encrypt and decrypt, but +
the original passphrase itself cannot be recovered and an internal key +
cannot be converted from one compatibility to another. A flag is kept +
in SECTSR indicating which mode was used to convert the passphrase to +
the key, though, and CRYPTDSK will not allow internal keys to be used +
to encrypt in the wrong mode. +
SD10CMP=X +
Also, CRYPTDSK 1.3 will check for and not allow a wasted pass of +
decrypting and re-encrypting to the same -key- (both passphrase and +
compatibility mode the same). +
Version 1.3 has added a lot of user messages to keep you informed of +
which compatibility is being used, where passphrases are coming from, +
etc. +
Detailed instructions:
Insert any DOS-formatted floppy disk. The disk may contain data, or it may
be empty. Run CRYPTDSK. Select the floppy drive, and enter a passphrase. You
will be required to enter the passphrase twice to confirm. CRYPTDSK will now
encrypt the disk.
As of version 1.2, if PGPPASS is set before you run CRYPTDSK, CRYPTDSK will |
ask to use the value of PGPPASS for the passphrase before prompting you. |
Obviously, if you encrypt a lot of diskettes at once, this feature can save |
you a lot of typing. |
Load SECTSR, if it's not already loaded. Run LOGIN /F and enter the
passphrase used to encrypt the disk. The disk is now accessible. You can
swap disks at any time, as long as all of the disks are encrypted with the
same passphrase. You can also access unencrypted disks; SECTSR switches on
and off automatically. If you want to access a disk encrypted with a
different passphrase, type LOGIN /F again and enter the new passphrase. The
same passphrase applies to both floppy drives.
As of version 1.3, LOGIN /F will try (if you let it read an encrypted +
diskette) the currently active hard disk passphrase (if one exists). +
If you bypass the verification step, then you are asked if you want to +
use the hard disk passphrase without verification. +
Run CRYPTDSK. Select the floppy drive. CRYPTDSK will detect that the disk is
encrypted, and will prompt you to decrypt it. Enter your passphrase.
CRYPTDSK will now decrypt the disk.
As of version 1.2, if PGPPASS is set before you run CRYPTDSK, CRYPTDSK will |
try the value of PGPPASS for the passphrase before prompting you. |
As of version 1.3, CRYPTDSK will also try the active hard disk and +
floppy passphrases in SECTSR before prompting you. +
You must have more than one partition, or more than one hard drive. If you
encrypt your C: drive, you will not be able to boot from it! If this
happens, decrypt it again to restore it. You should create a small D:
partition, large enough to store as much sensitive information as you plan
to keep on your hard drive. You can also run applications from the secure
partition, but there will be some speed loss. Back up your hard drive before
installing. Use FDISK to repartition your drive, and set up a small D:
drive, which will become your secure partition. You can copy data to it
before or after encryption. Run CRYPTDSK and select the letter of the
partition you want to encrypt. CRYPTDSK will display the physical drive,
head, and cylinder of the boot sector of this partition. You should verify
these numbers. Then enter a passphrase to encrypt the partition. This will
take a few minutes, depending on the size of the partition and your CPU.
drive,cylinder,head +
in cases where CRYPTDSK can't find the partition from the DOS disk +
letter. This can happen in configurations with more than two physical +
disks or where special disk drivers are used. CRYPTDSK will prompt +
for these parameters if you enter "X" when it prompts you for DOS disk +
letter. You can use the FPART utility to scan physical drive "drive", +
which are numbers starting from zero, and locate the proper numbers +
for "cylinder" and "head". +
Note that commas (",") must be used to separate these parameters for
CRYPTDSK, while blanks are used for LOGIN.
As of version 1.2, if PGPPASS is set before you run CRYPTDSK, CRYPTDSK will |
ask to use the value of PGPPASS for the passphrase before prompting you. |
Load SECTSR. Run LOGIN D: /S to put the drive in safe mode. This should be
done in AUTOEXEC.BAT. Writes will be locked out. A drive not ready error
will occur if you attempt to access the encrypted drive. This will prevent
DOS programs from reading the drive. Windows behaves rather pathologically:
it retries the attempt about a dozen times, and then displays garbage. If
this happens, just close the window, log in, and try again. The drive is
still protected against writes in Windows.
Although V1.3 still only allows you to have one secure partition +
active, up to four may be placed in Safe mode. Each partition may be +
encrypted with a different passphrase, allowing up to four different +
users (or groups) to keep data private from each other. +
As of version 1.2, if PGPPASS is set before you run CRYPTDSK, CRYPTDSK will |
try the value of PGPPASS for the passphrase before prompting you. |
Changing a passphrase:
Versions 1.1 and 1.3 allow you to do this in one step. Select the +
drive with CRYPTDSK and it will prompt you to change the passphrase.
Enter the old and new passphrases as prompted. Decrypt the disk with
the old passphrase, and re-encrypt it with the new passphrase.
Version 1.3 includes the additional testing for PGPPASS and SECTSR +
internal passphrases for decryption and the additional prompting for +
new passphrases discussed above. +
Clearing keys:
Typing LOGIN /C will erase the cryptographic keys from memory and disable
encryption. You may then run LOGIN again to restore access. Note that this
does not erase plaintext from memory; turn the computer off to do this.
As of Version 1.2, typing LOGIN /C /PGP will clear the SecureDrive crypto |
keys from memory AND clear the PGPPASS environment variable. This is done |
in a manner less likely to leave your passphrase in memory than just using |
the DOS SET command. In addition, Version 1.2 clears all the free memory |
it can find, which is likely to include some plaintext. However, if you |
want to be absolutely sure all traces of sensitive data are erased from |
memory then turning off the computer is still recommended. |
You can use a disk cache such as SMARTDRV.EXE or NCACHE to speed up access.
The cache must be loaded after SECTSR is loaded. A .SYS cache will not work,
because it is loaded before the TSR. If the cache is loaded first, it will
cache ciphertext and provide little speedup. If the cache is loaded after
SECTSR, it will cache plaintext and speed up access.
Hazards to avoid:
Forgetting your passphrase. With any lock, there is the hazard of losing the
key. But cryptography is a special case because there are no locksmiths to
save you. If you forget a passphrase, you're out of luck. That data is gone.
Using this program without backups. It accesses disks at the low level of
the BIOS, and a program bug or an unfriendly interaction between the TSR
and an application could scramble your hard drive permanently.
The "author" of versions 1.2 and 1.3, Edgar Swank, says that the +
export ban should not prevent you from placing this program on public |
BBS's and anonymous FTP sites in the US and Canada. If individuals |
outside the US/Canada use the internet or international long distance |
to obtain copies of the program, THEY may be breaking US law. |
Any such foreign individuals should be aware that US law enforcement may |
legally (under US law) apprehend individuals who break US laws even if such |
individuals are not on or even have never been on US soil. Such |
apprehension may remove such individuals directly to US jurisdiction |
without benefit of extradition proceedings in such individuals' home |
country(ies). This has actually happened in at least two cases, Mexico -- |
suspect in murder of US drug agent, Panama -- Noriega -- indicted in |
absencia for drug smuggling. As is well known, after a small war with |
Panama, Noriega was brought to the USA, tried and convicted. He is now a |
guest of the US Government in a Florida prison. |
Data leaks: swapfiles and temporary files. Many application programs create
swapfiles and temporary files all the time. If these files are written to a
non-encrypted disk, they will expose your data. This can be avoided by
putting the swapfiles and temporary files on the encrypted disk, but this is
slow. The best solution is to use a RAM disk or cache the encrypted disk.
There are also programs such as Norton WIPEINFO which will wipe empty space.
Trojans and viruses: someone could replace LOGIN with a hacked version, or
install a specially written Trojan on your system, and capture your
passphrase or key. Since the key remains in memory in the TSR, any program
could potentially swipe it. The only sure way to prevent this is to make
sure that nobody has the opportunity to install such a Trojan.
If you have PGP, you can verify that version 1.3c executable modules +
CRYPTDSK.EXE |
LOGIN.EXE |
SECTSR.COM |
FPART.EXE +
have not been modified since I compiled them by checking them against |
the detached signatures included. First add my (Edgar Swank's) public key |
to your public keyring
The integrity of this check depends upon that my public key is genuine. You |
should satisfy yourself from the signatures on the key. Also my public key |
is available independently on various public keyservers. |
How many passphrases?: The additions to version 1.2 make it easier to use a |
single passphrase both for your PGP secret key and for SecureDrive hard and |
floppy disks. If you do this, it's obviously putting all your eggs in one |
basket. One school of thought says its better to use several baskets, so if |
one breaks you only loose some of your eggs. The other school says it may |
be better to use one basket IF you make it the best damn basket you can and |
put your best efforts into protecting it. |
CheckWord Offset:
Versions of SecureDrive from versions 1.0 to 1.3a have used the 8-byte
SYSTEM ID at offset 3 of boot records of encrypted disks to store a
"CryptFlag". The first four bytes contain "CRYP" to denote an
encrypted disk; the last four characters (offset 7) store a 4-byte
checkword used to verify that the correct passphrase had been entered.
This checkword is an MD5 digest of the IDEA key and (in Version 1.1)
the passphrase. The 128-bit IDEA key is an MD5 digest (iterated in
Version 1.1) of the passphrase. The checkword is calculated and
stored in the boot sector when the disk partition or diskette is first
encrypted. Whevever you enter a passphrase to decrypt or activate the
disk, both the key and the checkword are generated. The checkword is
compared against the one stored in the boot record as a check that the
same passphrase was entered for decryption as for encryption. Note
that the boot sector is never itself encrypted. Also note that since
MD5 is a "cryptographicly strong" one-way digest function, it is not
computationally feasible to find the IDEA key, much less the original
passphrase, from the checkword.
In hindsight, this was not the best choice of a place for this flag.
Apparently, some versions of MSDOS, especially those included with
some laptop PC clones, insist that the SYSTEM ID field of the boot
sector be ASCII characters, which the checkword is not. Also, the
new diskette formatting utility from Spain, 2M/2MF, uses all the
SYSTEM ID field for its own purposes. For this reason, the location
of the CryptFlag has been move from SYSTEM ID (offset 3) to offset
802 of boot records, as of SecureDrive Release 1.3c. Release 1.3c
is upward compatible with previous releases; that is, Release 1.3c can
activate (LOGIN), decrypt, or change passphrases (CRYPTDSK) of disks
encrypted with SecureDrive Releases 1.3a or before; but you cannot use
previous releases of SecureDrive on disks encrypted by 1.3c.
After using some disk repair utility LOGIN and CRYPTDSK may always
say you have entered an incorrect passphrase for your encrypted disk,
even when you're SURE you used the right passphrase. Or LOGIN and
CRYPTDSK may say a disk is unencrypted when it obviously is encrypted.
Mike had a report from a user who used some disk utility that re-wrote
his boot record, overlaying the checkword (but apparently not the
"CRYPT" flag). This is probably a different manifestation of the
problem described above. This disk-fixing utility wants to see an
all-ASCII SYSTEM ID and will set ASCII where it doesn't find it.
You can fix this by using the /RCF [Recover CryptFlag] parameter to
LOGIN. This will allow you to activate a disk even if the "CRYP" flag
has been overwritten or the checkword doesn't match. You will be
asked to enter the passphrase twice. The new checkword will be
written at new standard offset 506 which will hopefully avoid a
repetition of the problem the next time you use that same utility.
Also, if after you enter the checkword, you get garbage when trying
to read the disk, change SD10CMP from Y to N (or vice versa) and try
LOGIN xxx /RCF again.
/RCF also doesn't work if combined with the /S (safe mode) parameter.
Placement of SECTSR: +
If you encounter a problem that CRYPTDSK (and FPART) don't work while +
SECTSR is installed, try re-ordering device drivers & TSR's which +
might effect diskette access. Note that CRYPTDSK/FPART will reach +
below SECTSR to do sector disk I/O, so any TSR's loaded after SECTSR +
will also be bypassed by CRYPTDSK/FPART. +
I have been able to start CRYPTDSK in the DOS window and it ran fine.
But if I switched to another window, it crashed in the middle. I don't
see how this can be anything but a Windows problem. Since crashing
CRYPTDSK in the middle essentially destroys all the data on the disk,
I don't recommend trying to run CRYPTDSK under Windows.
Another program, 2MF, with TSR 2M.COM, has recently been released from
Spain as 2M13.ZIP. This program claims to either provide higher
storage capacities (902 Kilobytes) or improved access times relative
to FDFORMAT. However, 2M recognizes diskettes formatted by 2MF via
the SYSTEM ID field in the diskette's boot record; Before Release
1.3c, SecureDrive also used the SYSTEM ID field to test for an
encrypted diskette and check for a valid passphrase. So 2MF cannot be
used with SecureDrive Releases before 1.3c with encrypted diskettes.
If you want to switch between FDFORMAT and 2M diskettes, you must load
both FDREAD.EXE and 2M.COM -before- SECTSR.COM. Fortunately, FDREAD
and 2M will both load themselves high, and SECTSR can be loaded high
with LOADHI.
SECTSR.ASM is the self-contained source for SECTSR. Use TASM and TLINK /T to
assemble it.
In version 1.2, LOGIN also uses SETENV.OBJ generated from SETENV.ASM. This |
code is used to set/clear the PGPPASS environment variable. This code sets |
the enviornment variable in all copies of the environment it can find, so |
it may work in some situations where the DOS SET command does not. On the |
other hand, in some early versions of DOS, it may not find the master |
environment area. Experiment for yourself. |
Version 1.3 adds the RLDBIOS.ASM module which replaces the C++ library +
subroutine BIOSDISK and allows LOGIN, CRYPTDSK, and FPART to access +
the "real" BIOS without going through SECTSR. +
The programs were compiled with Turbo C++. Compile them large model.
Miscellaneous:
Version 1.3 SECTSR has been modified to align the internal stack and +
some data fields. This may marginally improve performance on 16/32-bit +
PC's. +
Note that Version 1.3c CRYPTDSK, LOGIN and FPART -require- use of +
Version 1.3c SECTSR. Do not mix modules of different versions! +
(But CRYPTDSK and FPART -may- be run without SECTSR loaded at all). +