8/14/2019 secdrv

1/14

SecureDrive V1.3c Documentation |Edgar Swank |

This is a maintenance release of SecureDrive 1.3a. It mainly fixesreported problems and has minimal new function. See files BUGS13.DOCand BUGS13A.doc.

A prototype SecureDrive Version 1.3b was sent to a few people for

testing. To avoid confusion, I'm skipping 1.3b for "official"releases.

The only visible functional change from 1.3 to 1.3A is the appearanceof msg

Check bytes in Disk x: Boot Sector need updating from 1.3 to1.1/1.3A. Proceed?

which will be issued by both LOGIN and CRYPTDSK when they attempt toverify a passphrase on a hard disk or diskette encrypted by version1.3 CRYPTDSK operating in version 1.1 compatability mode. Thiscorrects the error in computing the check bytes used to verify the

passphrase and updates the check bytes to the correct 1.1 value andWRITES back the boot sector. Note that once this update has takenplace, 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 theSecureDrive 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 and1.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 GNUCopylefted code, and therefore may be freely distributed under the terms ofthe GNU General Public Licence. See file COPYING for legalese.

SecureDrive V1.1 Changes from V1.0

* Two-drives bug fixed. V1.0 would get the drives out of order if you hadtwo physical hard drives. V1.1 fixes this problem.

* One-step passphrase change. Instead of decrypting and re-encrypting, youcan change the passphrase in one step with CRYPTDSK.

* Improved hashing algorithm. V1.0 used a simple MD5 of the passphrase toproduce the encryption key. This allowed an attacker to test possiblepassphrases quickly. V1.1 iterates the hash 2048 times to slow down apassphrase search.

Because of the new passphrase hashing algorithm, V1.1 users willneed to decrypt your disk with V1.0 and re-encrypt with V1.1 toupgrade. The new algorithm produces a different IDEA key for thesame passphrase.

8/14/2019 secdrv

2/14

This may have been unclear in the previous version: V1.0 and V1.1encrypt one hard drive partition at a time. LOGIN /S will notprotect more than one partition. If you log in to a secondpartition, the first one will not be accessible, and will not beprotected from writes.

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 Swisscompany 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 usersmay obtain licensing details from:

Dieter Profos, Ascom Tech AG, Solothurn Lab, Postfach 151, 4502Solothurn, 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 . |

Changes for version 1.2 are highlighted by "|" at the right margin. |Changes for version 1.3 are highlighted by "+" at the right margin. +

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. Encryptionis the most secure means of protection, but is often cumbersome to use. Theuser must decrypt a file, work with it, encrypt it, and then wipe theplaintext. If encryption were easy, many more people would use it.SecureDrive is a step in this direction. SecureDrive automatically storessensitive data on your DOS/Windows system in encrypted form.

SecureDrive V1.3 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 isloaded and the proper passphrase entered. The TSR takes only 2.4K of +RAM, and can be loaded high. Encryption is performed at the sectorlevel and is completely transparent to the application program.

Everything on the disk or partitions except the boot sector isencrypted. Encrypted floppy disks can be freely interchanged withunencrypted ones. Disks and partitions can be decrypted and returnedto normal at any time.

SecureDrive uses the IDEA cipher in CFB mode for maximum datasecurity. The MD5 hash function is used to convert the user'spassphrase into a 128-bit IDEA key. The disk serial number, and trackand sector numbers are used as part of the initialization to make eachsector unique.

8/14/2019 secdrv

3/14

SecureDrive is made up of four program files. SECTSR is the +memory-resident driver. CRYPTDSK is used to encrypt and decryptfloppy disks and hard drive partitions. LOGIN is used to unlockencrypted disks and partitions by loading the passphrase and diskparameters into the resident module. FPART is a utility for finding +starting cylinder & head numbers for partitions.

Getting started instructions:

If you only have one hard drive partition (C:), you will have torepartition your hard drive if you want an encrypted partition. Youcan use encrypted floppies without changing your hard drive. Youshould create a partition(s) large enough to hold all of yoursensitive data. For this example, assume the partition is (D:). PutSECTSR, 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 dataon it, so you would have to back up all your data beforehand. But ifyou only have one partition now, there is a utility

FIPS08.ZIP 84831 07-23-93 Nondestructive hard diskpartition split util.

available from the SIMTEL archive and possibly elsewhere that claimsto be able to split your first partition without data loss.

Put in your AUTOEXEC.BAT, before the loading of any disk cache:

SECTSRLOGIN 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 areencrypted. Reboot the system to make the changes take effect.

You can also use a form of LOGIN +

LOGIN drive cylinder head /S +

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". +

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 is 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 +

8/14/2019 secdrv

4/14

use the same PC and physical hard disk(s). +

The partition can have data on it, or it can be empty. Run CRYPTDSKand select the drive letter. Enter a passphrase. CRYPTDSK will nowencrypt 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 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. +

All versions of LOGIN always verify passphrases for hard diskpartitions.

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 +useing 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 |

8/14/2019 secdrv

5/14

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. |

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. |

Compatability with Previous Versions: +

As you read above, due to use of a more complex hashing algorithm, +passphrases entered in Version 1.1 are not compatible with those +entered in version 1.0 (and 1.2) and vice versa, because the same +passphrases will produce different 128-bit IDEA keys. Mike Ingle made +this change to slow down brute force "dictionary" attacks. +

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. +

I (Edgar Swank) respectfully disagree 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. +

In 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 +

8/14/2019 secdrv

6/14

enter an incorrect passphrase. +

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. +

In 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 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:

Creating an encrypted floppy disk:

Insert any DOS-formatted floppy disk. The disk may contain data, or it maybe empty. Run CRYPTDSK. Select the floppy drive, and enter a passphrase. Youwill be required to enter the passphrase twice to confirm. CRYPTDSK will nowencrypt 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. |

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. +

Accessing an encrypted floppy disk:

Load SECTSR, if it's not already loaded. Run LOGIN /F and enter thepassphrase used to encrypt the disk. The disk is now accessible. You can

8/14/2019 secdrv

7/14

swap disks at any time, as long as all of the disks are encrypted with thesame passphrase. You can also access unencrypted disks; SECTSR switches onand off automatically. If you want to access a disk encrypted with adifferent passphrase, type LOGIN /F again and enter the new passphrase. Thesame 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. +

Decrypting a floppy disk:

Run CRYPTDSK. Select the floppy drive. CRYPTDSK will detect that the disk isencrypted, 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. +

Creating an encrypted hard drive partition:

You must have more than one partition, or more than one hard drive. If youencrypt your C: drive, you will not be able to boot from it! If thishappens, decrypt it again to restore it. You should create a small D:partition, large enough to store as much sensitive information as you planto keep on your hard drive. You can also run applications from the securepartition, but there will be some speed loss. Back up your hard drive beforeinstalling. Use FDISK to repartition your drive, and set up a small D:drive, which will become your secure partition. You can copy data to itbefore 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 verifythese numbers. Then enter a passphrase to encrypt the partition. This willtake 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 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 forCRYPTDSK, 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

8/14/2019 secdrv

8/14

to it withot first logging in:

Load SECTSR. Run LOGIN D: /S to put the drive in safe mode. This should bedone in AUTOEXEC.BAT. Writes will be locked out. A drive not ready errorwill occur if you attempt to access the encrypted drive. This will preventDOS programs from reading the drive. Windows behaves rather pathologically:it retries the attempt about a dozen times, and then displays garbage. Ifthis happens, just close the window, log in, and try again. The drive is

still protected against writes in Windows.

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 isreplaced by the letter of the encrypted partition. Type thepassphrase. Your secure partition is now accessible. Note that onlyone secure partition can be accessible at a time. You can have

encrypted floppies and a secure partition active simultaneously, butyou can't have two secure partitions active at the same time. The TSR +only stores two cryptographic keys: one for a secure partition, andone for encrypted floppies.

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. +

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. |

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 withthe 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. Theintermediate 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. +

Clearing keys:

Typing LOGIN /C will erase the cryptographic keys from memory and disable

8/14/2019 secdrv

9/14

encryption. You may then run LOGIN again to restore access. Note that thisdoes 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 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 willcache ciphertext and provide little speedup. If the cache is loaded afterSECTSR, it will cache plaintext and speed up access.

Hazards to avoid:

Writing to the encrypted partition or encrypted floppies without logging in.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 diskcan be destroyed. This happened to one of the beta testers. Use safe modeand load the TSR in AUTOEXEC to prevent it.

Forgetting your passphrase. With any lock, there is the hazard of losing thekey. But cryptography is a special case because there are no locksmiths tosave 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 ofthe BIOS, and a program bug or an unfriendly interaction between the TSRand 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 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. |

Potential security problems:

Data leaks: swapfiles and temporary files. Many application programs create

8/14/2019 secdrv

10/14

swapfiles and temporary files all the time. If these files are written to anon-encrypted disk, they will expose your data. This can be avoided byputting the swapfiles and temporary files on the encrypted disk, but this isslow. 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, orinstall a specially written Trojan on your system, and capture your

passphrase or key. Since the key remains in memory in the TSR, any programcould potentially swipe it. The only sure way to prevent this is to makesure 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

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. Thishas proven highly effective against Unix login passwords. The bestpassphrase is a phrase of four or more words which does not appear intext or literature.

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. |

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 four or five 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. |

8/14/2019 secdrv

11/14

Backups: must be encrypted. Use encrypted disks, or use an encryptingcompression program such as HPACK and write the encrypted file onto thebackup tape. Do not leave unencrypted disks or printouts lying around.

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 anycompression program other than HPACK.

CheckWord Offset:

Versions of SecureDrive from versions 1.0 to 1.3a have used the 8-byteSYSTEM ID at offset 3 of boot records of encrypted disks to store a"CryptFlag". The first four bytes contain "CRYP" to denote anencrypted disk; the last four characters (offset 7) store a 4-bytecheckword 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 inVersion 1.1) of the passphrase. The checkword is calculated andstored in the boot sector when the disk partition or diskette is first

encrypted. Whevever you enter a passphrase to decrypt or activate thedisk, both the key and the checkword are generated. The checkword iscompared against the one stored in the boot record as a check that thesame passphrase was entered for decryption as for encryption. Notethat the boot sector is never itself encrypted. Also note that sinceMD5 is a "cryptographicly strong" one-way digest function, it is notcomputationally feasible to find the IDEA key, much less the originalpassphrase, 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 withsome laptop PC clones, insist that the SYSTEM ID field of the bootsector be ASCII characters, which the checkword is not. Also, the

new diskette formatting utility from Spain, 2M/2MF, uses all theSYSTEM ID field for its own purposes. For this reason, the locationof the CryptFlag has been move from SYSTEM ID (offset 3) to offset802 of boot records, as of SecureDrive Release 1.3c. Release 1.3cis upward compatible with previous releases; that is, Release 1.3c canactivate (LOGIN), decrypt, or change passphrases (CRYPTDSK) of disksencrypted with SecureDrive Releases 1.3a or before; but you cannot useprevious releases of SecureDrive on disks encrypted by 1.3c.

You can convert disks encrypted by previous versions of SecureDrive tothe new standard CryptFlag offset by using the /UCFO [Update CryptFlagOffset] function with LOGIN (either for hard disk partitions ordiskettes). Note that /UCFO will overlay SYSTEM ID (the old

CryptFlag) with "MSDOS ", which means that that disk can no longerbe 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 theCryptFlag offset.

ATTENTION: Version 1.3b users.

See file BUGS13A.DOC for instructions.

8/14/2019 secdrv

12/14

Reconstructing a CheckWord:

After using some disk repair utility LOGIN and CRYPTDSK may alwayssay you have entered an incorrect passphrase for your encrypted disk,even when you're SURE you used the right passphrase. Or LOGIN andCRYPTDSK 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-wrotehis boot record, overlaying the checkword (but apparently not the"CRYPT" flag). This is probably a different manifestation of theproblem described above. This disk-fixing utility wants to see anall-ASCII SYSTEM ID and will set ASCII where it doesn't find it.

You can fix this by using the /RCF [Recover CryptFlag] parameter toLOGIN. This will allow you to activate a disk even if the "CRYP" flaghas been overwritten or the checkword doesn't match. You will beasked to enter the passphrase twice. The new checkword will bewritten at new standard offset 506 which will hopefully avoid arepetition of the problem the next time you use that same utility.

You are not allowed to recover the CheckWord if SD10CMP=X, sincethis setting does now allow LOGIN to compute or check version 1.1compatible checkwords.

Also, if after you enter the checkword, you get garbage when tryingto read the disk, change SD10CMP from Y to N (or vice versa) and tryLOGIN 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. Ifyou force activation of a disk with the wrong passphrase, it's

effectively the same as accessing the disk without SECTSR loaded. Anywrite to the disk would likely make -all- data on the disk partitionor 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 BEFORESECTSR.

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 DOSwindow. However LOGIN /PGP and its variants do not set PGPPASS. SETdoesn't work either.

8/14/2019 secdrv

13/14

It's probably better to call LOGIN in your AUTOEXEC for Windows, ifpossible, 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'tsee how this can be anything but a Windows problem. Since crashingCRYPTDSK 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 ina DOS Window.

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 inGermany. The last version (FDFORM18.ZIP) was released in 1991.

FDFORMAT allows, for example, storage of up to 820 Kilobytes of dataon cheap DSDD diskettes (360 Kilobytes with DOS FORMAT). All Releasesof SecureDrive are compatible with FDFORMAT, provided only thatSECTSR.COM is loaded -after- FDREAD.EXE.

Another program, 2MF, with TSR 2M.COM, has recently been released fromSpain as 2M13.ZIP. This program claims to either provide higherstorage capacities (902 Kilobytes) or improved access times relativeto FDFORMAT. However, 2M recognizes diskettes formatted by 2MF viathe SYSTEM ID field in the diskette's boot record; Before Release1.3c, SecureDrive also used the SYSTEM ID field to test for anencrypted diskette and check for a valid passphrase. So 2MF cannot beused with SecureDrive Releases before 1.3c with encrypted diskettes.

If you want to switch between FDFORMAT and 2M diskettes, you must loadboth FDREAD.EXE and 2M.COM -before- SECTSR.COM. Fortunately, FDREADand 2M will both load themselves high, and SECTSR can be loaded highwith LOADHI.

Source code and modifications:

SECTSR.ASM is the self-contained source for SECTSR. Use TASM and TLINK /T toassemble it.

CRYPTDSK uses SDCOMMON and CRYPT2.OBJ generated from CRYPT2.ASM. It alsouses 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 +

8/14/2019 secdrv

14/14

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 and 1.3b 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 thisprogram will become popular and will be modified and improved by thenet.

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.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). +