SecureDrive V1.4a Documentation Edgar W. Swank Release 1.4a is a maintenance release of 1.4. No new function is added. Only module SDCOMMON.C has a non-cosmetic change, which affects executables LOGIN.EXE and CRYPTDSK.EXE. For that reason, all other executables still self-identify as release 1.4. 1.4a fixes a problem decrypting or activating a diskette or disk partition encrypted with both a passphrase and a keyfile. Release 1.4 is a functional and maintenance update of SecureDrive 1.3d. New features include ability to use a keyfile either instead of or in addition to a passphrase, the /ADD function and the option to specify a drive letter, which is remembered, when specifying manual partition parameters to LOGIN. The subroutine which "finds" a physical hard disk partition based on the DOS drive letter has been improved, so hopefully situations where manual partition parameters must be used will be rare. Release 1.4 Secure Drive is based on Release 1.3d, which was in turn based on releases 1.0 and 1.1, mostly written by Mike Ingle and version 1.2, with significant new code by myself. 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. All references to MD5 refer to: RSA Data Security, Inc. MD5 Message-Digest Algorithm (C) 1990, RSA Data Security 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. Ascom IDEA patents: US patent 5,214,703 granted May 25, 1993. EP Patent EP 0 482 154 B1 granted June 30, 1993. JP Patent pending Use this software at your own risk! Send all comments and bug reports to . Many people have sensitive or confidential data on their personal computers. Controlling access to this data can be a problem. PC's, and laptops in particular, are highly vulnerable to theft or unauthorized use. Encryption is the most secure means of protection, but is often cumbersome to use. The user must decrypt a file, work with it, encrypt it, and then wipe the plaintext. If encryption were easy, many more people would use it. SecureDrive is a step in this direction. SecureDrive automatically stores sensitive data on your DOS/Windows system in encrypted form. SecureDrive V1.4 allows you to create up to four encrypted partitions on your hard drive(s). It also allows you to encrypt floppy disks. Encrypted partitions and disks become fully accessible when the TSR is loaded and the proper passphrase entered (and/or Keyfile used). The TSR takes only 2.7K of RAM, and can be loaded high. Encryption is performed at the sector level and is completely transparent to the application program. Everything on the disk or partitions except the boot sector is encrypted. Encrypted floppy disks can be freely interchanged with unencrypted ones. Disks and partitions can be decrypted and returned to normal at any time. 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. If a keyfile is used, the keyfile is XORed with the key derived from the passphrase. Or the keyfile may be used without a passphrase. 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 five 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. COPYSECT is a simple program to save/restore data from the front of the RAWDISK.DAT from the RAWDRVxx device driver. GETTING started instructions: 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 recently a shareware utility was announced that can repartition most hard disks non-destructively: (available by anonymous ftp from the primary mirror site OAK.Oakland.Edu and its mirrors): SimTel/msdos/diskutil/ presz111.zip The Partition Resizer: Safe HD repartitioning Put in your AUTOEXEC.BAT, before the loading of any disk cache: 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. You can also use a form of LOGIN LOGIN drive cylinder head [x] /S in cases where LOGIN can't find the partition from the DOS disk letter. This can happen in configurations with more than one 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". "x" above is an optional DOS disk drive letter which you can specify. You should determine, by trial and error if necessary, which letter DOS assigns to the partition with and use that letter. Subsequent calls to LOGIN need only specify the same drive letter. Actually, before the partitions are encrypted with CRYPTDSK, LOGIN /S will return a warning message that the partitions are not encrypted, but, as of version 1.3, CRYPTDSK uses SECTSR to protect the drive while it is being encrypted and until the next boot. This was a change from previous versions. V1.0 to V1.2 would not operate on hard disk partitions while SECTSR was in memory. One purpose of having multiple encrypted hard disk partitions is so that up to four users (perhaps members of a family) can each have their own encrypted partition with its own unique passphrase. This allows up to four users to have privacy from each other, even if they all use the same PC and physical hard disk(s). 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 LOGIN D: (again, assuming drive D:) and enter your passphrase. Your encrypted drive is now accessible. 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 err 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. But as of V1.4, if you use a keyfile, the verification may not be bypassed. This is because LOGIN has to test the disk to see whether the keyfile and/or passphrase is required. All versions of LOGIN always verify passphrases for hard disk partitions. 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 described below, but -without- clearing the SecureDrive keys in SECTSR. Also, LOGIN /PGP can be run without SECTSR in memory, so it's a good way to set PGPPASS (no echo) even when you're not using encrypted disks. If PGPPASS is already set then 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 a keyfile is present, LOGIN will try PGPPASS both with and without applying the keyfile. 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. The purpose of these changes is to allow you to enter a single passphrase only once per boot IF you choose to use the same passphrase for your PGP secret key, your SecureDrive encrypted hard disk partition, and SecureDrive encrypted floppies. DETAILED instructions: CREATING a keyfile (optional) A keyfile is a 16-byte (128-bit) (or longer) file which may contain any combination of bits. Ideally, the file should be set (once) to cryptographically strong (unpredictable) random data. As it happens, Version 2.6.2 of PGP published by MIT has an undocumented feature to generate just such a random file for use by "other applications." The format is PGP +makerandom=16 C:\SDKEY.BIN Or you could just use a COPY of RANDSEED.BIN (which is longer than 16 bytes, but SecureDrive will just use the first 16 bytes). NOTE: DO NOT use RANDSEED.BIN itself as a keyfile. Use of PGP changes RANDSEED.BIN and the same keyfile contents must be used for encryption and decryption by SecureDrive. You specify the location of a keyfile to SecureDrive by setting an environment variable with the DOS SET command, e.g., SET SDFKEY=C:\SDKEY.BIN Note you must specify a complete drive and path, as shown. Benefits of using a keyfile: Use of a keyfile gives you more flexibility in how you protect your data. 1) Analog of a physical key: You can specify a keyfile on a floppy disk drive, which you can lock up or (at least for 3.5" diskettes) carry on your person. Without the keyfile, a secured disk cannot be activated with any passphrase. 2) Defense against court orders or "rubber hose cryptography": You may be ordered by a court (if given immunity in a criminal case or in a civil case) to divulge your passphrase; or someone may try to intimidate you into revealing it. But if a keyfile is required to activate a disk and the keyfile has been destroyed (either physically in case of a diskette or by overwriting) then no passphrase alone can activate it. This can be demonstrated to a court or anyone either by demonstration or by expert testimony. Backing up your keyfile: If your keyfile is damaged, you will lose access to all your SecureDrive encrypted data which requires it, so it would be prudent to back up the keyfile. But if your backup of the keyfile is found by an adversary, much of your "rubber hose" defense disappears. One possible solution is to use a "secret sharing" protocol such as the Cypherpunk program Secure Split to split your keyfile into N parts any M (M <= N) of which can reconstruct the original file, but any fewer parts than M are useless. You can then send the N parts to N friends on the net, some of whom will be outside your country. Establish some protocol so you can tell your friend if you're acting under duress, in which case he can refuse to return the file, or (better) can return some other file, which will fail to restore the original keyfile. Feining use of a keyfile: Since SecureDrive can encrypt disks using either a passphrase or keyfile or both. One devious defense against "rubber hose" cryptography is to set up a keyfile on your hard disk, but then overwrite and erase it. (But leave the environment variable). Each time you invoke LOGIN or CRYPTDSK, you will get a warning message that the keyfile cannot be opened. So it appears you have just destroyed your keyfile. But in reality your disk(s) can just be encrypted by a (strong) passphrase. But the only way your adversary can prove that a keyfile is not required is to guess the passphrase! CREATING an encrypted floppy disk: 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 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 sa you a lot of typing. As of version 1.3, if CRYPTDSK is run with SECTSR resident, you may be asked if you want to use the hard disk or floppy passwords previously entered and currently in use to encrypt another floppy. If a keyfile is present, you will be asked whether you want it to be used as part of the encryption key. You can use the keyfile alone without a passphrase by just pressing Enter when prompted for a passphrase. ACCESSING an encrypted floppy disk: 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/keyfile combination. 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. Note: The "automatic" detection depends on DOS accessing the boot sector of a diskette whenever it's changed. This can be made more dependable by running DOS CHKDSK against the diskette drive whenever a new diskette is introduced. 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. If you have a keyfile, then the diskette verification is mandatory. LOGIN will also try the keyfile with no passphrase before prompting for a passphrase. DECRYPTING a floppy disk: Run CRYPTDSK. Select the floppy drive. CRYPTDSK will detect that the disk 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. As of version 1.4, if a keyfile is present, CRYPTDSK will try the keyfile both with no passphrase and with PGPPASS. It will also try any passphrase entered both with and without the keyfile. CREATING an encrypted hard drive partition: 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 (or other utilities like FIPS or PRESZ) 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. You can also describe a partition to CRYPTDSK by its 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 one physical disk 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. PREVENTING damage to the secure partition, which could be caused by writing to it withot first logging in: 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. I've also had a report that trying to run FDISK against a drive containing a partition in "safe" mode can cause the PC to "freeze up" with the HD access light on; but encrypted data was not affected. As of version 1.3, you should add LOGIN D: /S statement(s) to AUTOEXEC.BAT and load SECTSR before encrypting your hard disk partition(s). CRYPTDSK will set the partition to Safe mode before beginning to encrypt. (CRYPTDSK itself bypasses SECTSR). ACCESSING an encrypted hard drive partition: Load SECTSR, if it's not already loaded. Run LOGIN D: where D is replaced by the letter of the encrypted partition. Type the passphrase (if prompted). Your secure partition is now accessible. Previous to version 1.4, only one secure partition could be accessible at a time. You could have encrypted floppies and a secure partition active simultaneously, but you couldn't have two secure partitions active at the same time. The TSR only stores two cryptographic keys: one for a secure partition, and one for encrypted floppies. As of Version 1.4, it's now possible to run up to four active partitions at the same time, but they must all have the same key (passphrase/keyfile & compatibility mode). You open one partition with LOGIN as already described. You can then open more by issuing: LOGIN e: /ADD This feature allows you to copy data from one encrypted partition to another without exposing the data in plaintext form or using diskettes. I used it recently after upgrading my hard disk. I temporarily attached my old disk as an extra drive, then I used DOS XCOPY to copy the old encrypted partition to the (larger) new one. It also allows you to cope by temporarily encrypting a larger partition not usually encrypted if you suddenly need to hold more sensitive data than you planned for beforehand. Even if secure partitions all have different passphrases, 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. DECRYPTING a hard drive partition: As of version 1.3, it is no longer necessary or desireable to reboot to clear SECTSR out of memory. Run CRYPTDSK, select the drive letter, and enter the passphrase. CRYPTDSK will decrypt your partition. 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.4, if a keyfile is present, it is tried both with no passphrase and with PGPPASS before a passphrase is prompted for. 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. This is more secure than doing decryption and encryption separately. Decryption and re-encryption is done a track at a time. The intermediate plaintext exists only in memory, never on the disk. Version 1.3+ includes the additional testing for PGPPASS and SECTSR internal passphrases for decryption and the additional prompting for new passphrases discussed above. Version 1.4 will also prompt you if you want to use a keyfile (if present) before prompting for a passphrase. You can use a keyfile without a passphrase by pressing Enter when prompted for a passphrase. 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. Using a disk cache: You can use a disk cache such as SMARTDRV.EXE or NCACHE to speed up acces 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 wil cache ciphertext and provide little speedup. If the cache is loaded after SECTSR, it will cache plaintext and speed up access. Hazards to avoid: Writing to the encrypted partition or encrypted floppies without logging. When you load the TSR and put it in safe mode, writes will be locked out. However, if you access an encrypted disk without loading the TSR, the disk can be easily inadvertantly destroyed. This happened to one of the beta testers. Use safe mode and load the TSR in AUTOEXEC to prevent it. Forgetting your passphrase or loseing your keyfile. 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, or lose a required keyfile 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. Exporting this program. Cryptography is export controlled, and sending this program outside the country may be illegal. Don't do it. The "author" of versions 1.2, 1.3, and 1.4, 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. Potential security problems: Data leaks: swapfiles and temporary files. Many application programs create swapfiles and temporary files all the time. If these files are written to 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 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.4 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 PGP -ka KEY.ASC Then issue commands PGP CRYPTDSK.SIG CRYPTDSK.EXE PGP LOGIN.SIG LOGIN.EXE PGP SECTSR.SIG SECTSR.COM PGP FPART.SIG FPART.COM 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. Passphrase guessing: if your passphrase is weak (a single word, monocase, with no punctuation is very weak) an attacker could try to guess it. This has proven highly effective against Unix login passwords. The best passphrase is a phrase of five or more words which does not appear in text or literature. How many passphrases?: The additions to version 1.2 make it easier to use 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. So if you use a single passphrase for everything, make it the best passphrase you can think of and REMEMBER without writing it down ANYWHERE. A good passphrase should be at least five or six words. The easiest to remember and hardest to guess will be "outrageous" and use words that normally don't go together, e.g. "red grass over yellow sky" (don't use this example). Some use of profanity, foreign words, and creative spelling and punctuation, as long as you can remember it all, will also make the passphrase harder to guess. As of version 1.4, use of a keyfile in addition to or even instead of a passphrase will generally strengthen your security. The 128-bit random keyfile is at least as strong as any passphrase, save only that a passphrase only exists in your head and the keyfile doesn't. So the security of the keyfile is practically the same as the physical security of the keyfile. Use of both a keyfile and a passphrase is obviously the strongest possible security mode. Backups: It will defeat the effect of having an encrypted hard disk partition if you have unencrypted backups. Backups must also be encrypted with the same strength cypher as the hard disk. If you don't have tape backup, you can use SecureDrive encrypted diskettes for backup. Be sure to test your backup program to make sure both backup -and- restore functions work with SecureDrive. PKZIP and some other compression programs work well with SecureDrive and are able to backup to multiple diskettes, backup an entire volume, or only files with the archive flag on, etc. If you have a large amount of encrypted data, and you do have tape backup, it will be a pain to have to use diskettes for the encrypted data. The problem is that existing tape backup programs do not offer strong encryption. (beware of programs that offer "password protection"; this is weak or even non-existant encryption, easily broken) They also work only with DOS files. One solution is to use the device driver RAWDRV11.ZIP 9029 09-29-93 Device Driver maps range of cyls. to virtual file. Useful with tape backups. It's available at ftp://ftp.csn.net/mpj/public/rawdrv11.zip Also at the Colorado Catacombs BBS (303-772-1062) The same program is also available directly from the author at ftp.fb9dv.uni-duisburg.de:/pub/pc/misc/rawdsk11.zip Note the small variation in filename. I have tried it out and it works. It's not terribly user-friendly, so proceed carefully until you're familiar with it. When you're first trying it out, I recommend you have an -independent- backup of your data that you know works until you have tested both backup and restore using this program. The best feature of this method is that since it stores a disk image of the encrypted disk on tape, the encryption is the same as on disk, and so just as secure. As on disk, both filenames and file data are encrypted. The drawbacks are that since you are storing encrypted data you will not get any compression, even if the tape backup program claims to offer compression. Also, unless you VERY CAREFULLY specify an end-cylinder limit to RAWDISK, you will back up the entire encrypted partition, even that part which doesn't contain any files. There is also no way to do an incremental backup (only files with archive flag on) with RAWDISK. Here are some points to using RAWDISK backup/restore. Make up temporary replacements for AUTOEXEC.BAT and CONFIG.SYS. LOGIN will report the parameters you need for the RAWDISK DEVICE= statement, except for "end cylinder" which you must compute by adding the start cylinder to the size of the partition in cylinders minus one. You can't access an encrypted disk set to safe mode through RAWDISK. You must omit the LOGIN /S from your temporary AUTOEXEC.BAT. You can still provide some protection for the encrypted disk using the DOS ASSIGN command. If you activate your encrypted disk partition, RAWDISK will access plaintext data; this can be useful, but DO NOT run your tape backup or restore in this mode. If you don't want to backup a lot of unused space, you can try the following VERY CAREFULLY. With the encrypted disk activated, 1)Used a disk defragmenter like DOGxxx to collect all the free space at the high end of the partition. 2)Use a filldisk utility like Norton FD to overwrite all the free space with a recognizable ASCII string. 3)Compute an approximate end cylinder bound to include only a small amount of the free space. Start with the free space shown by CHKDSK and compute the size of the free space in cylinders (free space in bytes)/(bytes per sector)/(sectors per head)/( heads per cylinder) Discard any fractional cylinders from the above and subtract from the previously computed end cylinder for the whole partition. If there are no fractional cylinders, subtract 1 whole cylinder. Replace the previous end cylinder value in the RAWDISK DEVICE= statement. 4)Re-boot with SECTSR installed and the encrypted disk activated. Then use a disk viewing utility like SHOWFAT on the RAWDISK disk to verify that recognizable free space is at the end of the RAWDISK.DAT file. This is to verify that you really are backing up all the file data. 5)Re-boot again, this time without either activating the encrypted disk or placing it in safe mode. You can still "protect" the encrypted disk with ASSIGN. This ends the optional procedure to minimize backup size. Before calling the tape backup program. Use a file viewing utility to look at the RAWDISK.DAT file on the RAWDISK disk to verify that you are accessing encrypted (random-looking) data. Use your tape backup program to backup the RAWDISK.DAT file to tape. Restore your original "production" AUTOEXEC.BAT and CONFIG.SYS and re-boot. If you want to use this backup method in conjunction with incremental backups to encrypted diskettes, then before changing any files on the encrypted diskette, activate it and turn off all the Archive flags with a utility like ATTR. As I said above, the first time you use this method, you want to test restoring from tape through RAWDISK before you rely on this method, having some independent backup handy, perhaps a (temporary) tape backup of the plaintext files. To restore from RAWDISK, use the same temporary AUTOEXEC.BAT and CONFIG.SYS files you used for backup. Especially the RAWDISK DEVICE= statement must be the same as was used for backup. Again, boot with the encrypted disk neither activated nor in safe mode. Set VERIFY OFF. RAWDISK does not support DOS Verify. Use a utility like ATTR to turn off the Read-only flag. Use your tape restore program to restore file RAWDISK.DAT. Restore your original AUTOEXEC.BAT and CONFIG.SYS and re-boot. If you have any incremental diskette backups done after the tape backup, activate the encrypted disk and restore from those. CAUTION: the RAWDISK.DAT file includes the partition definition records. DO NOT restore from a RAWDISK backup IF you have used FDISK to change the partition size or location since the backup was taken. Obviously this means this method is not suited to temporarily backing up the encrypted partition before changing the partition size!! (When you restore, you will have your old partition size back!) Rather in this case use a temporary plaintext backup. As soon as you don't need the plaintext backup, be sure to use the "Secure Erase" or "Format" function of your tape backup program on the tape so as not to leave any plaintext copies of your encrypted data lying around! As of version 1.4, a COPYSECT utility is provided. This is an experimental method to save a specified number of 512-byte sector images from the front of RAWDISK.DAT -before- you restore a tape to it and then restore -only- those sectors after you restore from the tape. I haven't tried this myself yet, but use of this utility and maybe the PRESZ utility may allow you to restore to a partition that has been moved or resized since the tape was made. EXPERIMENT CAUTIOUSLY! Another possible backup procedure: If you have plenty of unencrypted disk space, you can use a strongly encrypting compression program such as HPACK to make an encrypted archive of data from your encrypted disk and write the resulting encrypted file from your unencrypted disk onto the backup tape. An alternative to HPACK is a combination of any compression program (e.g. PKZIP) and PGP. But DON'T rely on the "built-in" encryption of any compression program other than HPACK. The benefit of this method is you get the benefit of compression and only backing up file data (not free space). It's also well suited to incremental backups if the archive program supports them. The main drawbacks are that preparing the encrypted archive may take a lot of time; during some of that time your data may be exposed in plaintext. Also you may need up to three times the unencrypted disk space as is used by the encrypted files you're backing up. WARNING: PGP sometimes does not give you an error message if it runs out of disk space while encrypting a large file. Always check that the encrypted file is at least as large as the plaintext (e.g. PKZIP ) file. Use the PGP Wipe (-w) function to securely erase any plaintext copies of your confidential data. Compatability with Previous Versions: Version 1.1 of SecureDrive introduced a more complex hashing algorithm. Passphrases entered in Version 1.1 were not compatible with those entered in version 1.0 (and 1.2) and vice versa, because the same passphrases would produce different 128-bit IDEA keys. Mike Ingle made this change to slow down brute force "dictionary" attacks. Originally, to switch to Version 1.1 from 1.0, you had 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 was a very noticeable delay (1 or 2 seconds on my normally quick 386/SX 16) to enter and/or verify a passphrase. I (Edgar Swank) respectfully disagreed with Mike on the value of this "feature." In my opinion (you may disagree) if you have a good passphrase, this change is not necessary; and it is insufficient to protect a poor passphrase. The security "exposure" of version 1.0 (and 1.2) relative to 1.1 can be more than made up for by adding one word (randomly selected from a list of 5000) or two (random upper or lower case) alpha characters to your passphrase. I think there is a greater security exposure from all the plaintext data laying around during conversion. As of version 1.3, I have given you a choice, to convert to 1.1 passphrases, or to stay with 1.0-compatible ones. You make your selection through an environment variable: SET SD10CMP=Y | X where "|" denotes a selection of either Y or 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. The delay is even worse if a keyfile is present, because the passphrase must be checked both with and without application of the keyfile. If SD10CMP is set to anything else, or not set at all, then CRYPTDSK will always encrypt in 1.1-compatible mode. LOGIN and CRYPTDSK will decrypt disks encrypted in either mode. (It takes an insignificant amount of additional time to check for a 1.0 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. After version 1.3, the "(C)hange passphrase" feature can be used to convert disks encrypted in one compatibility to disks encrypted in the other (as specified by SD10CMP). You can even convert from one compatibility to the other and retain the same passphrase (but different keys). Note that you can't convert compatibiities if SD10CMP=X because this will prevent CRYPTDSK from decrypting (first half of converting) 1.1-compatible disks. 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 added a lot of user messages to keep you informed of which compatibility is being used, where passphrases are coming from, etc. 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 502 of boot records, as of SecureDrive Release 1.3d. Release 1.3d is upward compatible with previous releases; that is, Release 1.3d 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 (except 1.3c) on disks encrypted by 1.3d or 1.4. You can convert disks encrypted by previous versions of SecureDrive to the new standard CryptFlag offset by using the /UCFO [Update CryptFlag Offset] function with LOGIN (either for hard disk partitions or diskettes). Note that /UCFO will overlay SYSTEM ID (the old CryptFlag) with "MSDOS ", which means that that disk can no longer be activated or decrypted with previous versions of SecureDrive. /UCFO doesn't work if combined with the /S (safe mode) parameter. Changing a disk's password with CRYPTDSK will also update the CryptFlag offset. ATTENTION: Version 1.3b users. See file BUGS13A.DOC for instructions. Technical details -- Recovering from unexpected problems Reconstructing a CheckWord: 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. You are not allowed to recover the CheckWord if SD10CMP=X, since this setting does now allow LOGIN to compute or check version 1.1 compatible checkwords. 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. Note that extreme caution is required when using this parameter. If you force activation of a disk with the wrong passphrase, it's effectively the same as accessing the disk without SECTSR loaded. Any write to the disk would likely make -all- data on the disk partition or diskette unreadable. 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. In general, TSR's which assist in reading non-standard formatted diskettes, such as FDREAD.EXE and 2M.COM, should be loaded BEFORE SECTSR. CRYPTDSK and FPART may be used without SECTSR loaded if necessary. Running under Windows: I have been able to get LOGIN to activate disks in a Windows DOS window. However LOGIN /PGP and its variants do not set PGPPASS. SET doesn't work either. It's probably better to call LOGIN in your AUTOEXEC for Windows, if possible, and get your disk logged in before loading Windows. 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. Of course, SECTSR must be loaded before Windows. DON'T load SECTSR in a DOS Window. Duncan Frissell, a "heavy user" of SecureDrive under Windows, contributes the following additional comments: Ordinarily, PGPPASS will not be available to DOS programs run under Windows but if you use the Windows virtual device driver EDOS (Extended DOS) PGPPASS will work in DOS windows. EDOS --- Enhanced DOS for Windows Mom's Software Box 449. 391 So. Pacific Street Rockaway, Oregon 97136 503-355-2281 Voice EDOS is Shareware. Note: Windows 3.1 and Windows For Workgroups 3.11 allow you to enable 32-bit disk access in the Virtual Memory/Windows Swapfile menu under the 386 Enhanced section of the Control Panel. In addition, Windows for Workgroups 3.11 allows you to enable 32-bit file access in the same menu. You will be able to read a logged in SecureDrive partition with 32-bit disk access enabled but *not* with 32- bit file access enabled in Windows for Workgroups 3.11. Using SecureDrive with non-standard Diskette Formatting Programs Of course SecureDrive works with diskettes formatted with DOS FORMAT, but many PC users use non-standard formatting programs (and supporting TSR's) to store more data on a diskette than allowed by the standard FORMAT program. One such program, FDFORMAT, with TSR FDREAD.EXE, originated in Germany. The last version (FDFORM18.ZIP) was released in 1991. FDFORMAT allows, for example, storage of up to 820 Kilobytes of data on cheap DSDD diskettes (360 Kilobytes with DOS FORMAT). All Releases of SecureDrive are compatible with FDFORMAT, provided only that SECTSR.COM is loaded -after- FDREAD.EXE. 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. 1.3c still had some problems working with 2MF/2M, so 2MF cannot be used with SecureDrive Releases before 1.3d with encrypted diskettes. Version 1.3d also adds other changes for compatibility with 2M13. 1)Adjust decryption to allow for simulation of FAT2 by reading FAT1. One of the cryptography parameters used by SecureDrive depends on sector address. Using a FAT2 address to decrypt FAT1 data would lead to incorrect decryption. 1.3d adjusts this parameter for FAT2 sectors on 2M-formatted diskettes. 2)2M13 also (incorrectly) moves data to user buffers on a write verify. This would place encrypted data in user buffers. Version 1.3d works around this by treating write verifys the same as writes, encrypting the buffer before the write verify and decrypting after, which apparently provides a solution. 2M13 code which causes this problem also frequently causes requests for write verify not to be performed, which could leave unreadable data undected until a later time. See below for a recommended source change to 2M13. 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. More recently, the author of 2M has released 2MGUI, which uses advanced techniques to strore even more data on a diskette than 2M did, up to 1.2 MB on a 360K diskette. However, 2MGUI uses a device driver architecture which is incompatible with SecureDrive. However, you can use a different Encryption tool called Secure Device, made in the Netherlands, which works fine with 2MGUI. Source code and modifications: SECTSR.ASM is the self-contained source for SECTSR. Use TASM and TLINK /T assemble it. CRYPTDSK uses SDCOMMON and CRYPT2.OBJ generated from CRYPT2.ASM. It also uses MD5.C, which is from the PGP23A source code. LOGIN uses SDCOMMON and MD5.C. 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. In versions 1.2, 1.3d, and 1.4 a MAKEFILE is provided. If you make any interesting modifications or improvements, send us (Edgar and Mike) mail and a copy of the new code. We hope this program will become popular and will be modified and improved by the net. Miscellaneous: Version 1.3+ CRYPTDSK now exits gracefully if an attempt is made to write to a write-protected diskette. 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.4 (or 1.4a) CRYPTDSK, LOGIN and FPART -require- use of Version 1.4 SECTSR. Do not mix modules of different versions! (But CRYPTDSK and FPART -may- be run without SECTSR loaded at all).