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.
SecureDrive Version 1.4b replaces version 1.4a, 1.4, 1.3d, and previous versions. Release 1.4b is a maintenance release of 1.4/a. No new function is added.
Only modules SDCOMMON.C, SETENV.ASM and CRYPTDSK.C have non-cosmetic changes, which affect executables LOGIN.EXE and CRYPTDSK.EXE. For that reason, all other executables still self-identify as release 1.4. They are in fact the exact same EXE & COM files as release 1.4.
Well, this should have been the case, but actually modules FPART.EXE and COPYSECT.EXE are not identical with 1.4 and do not even match the PGP signatures included in SECDR14B.ZIP. Here is an explanation that was posted to Usenet in August, 1996.
1.4b fixes problems setting PGPPASS from Windows 95, either inside Win95 from a DOS window, or from the DOS 7.0 environment outside Windows. Unfortunately, LOGIN still cannot activate SecureDrive decryption from inside a Win95 DOS window.
This same fix also, for the first time, enables LOGIN to set PGPPASS (as well as activate SecureDrive) from inside a Windows 3.x DOS window.
CRYPTDSK also contains added warning msgs for 1) attempting to encrypt drive C: and 2) interrupting en/decryption with Ctrl-Break. SecureDrive Version 1.4b replaces version 1.4/a, 1.3d, and previous versions.
There are also some minor changes in SECDRV.DOC.
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.
Releases 1.3, 1.3a, 1.3d and 1.4/a/b of Secure Drive are based on releases 1.0 and 1.1, mostly written by Mike Ingle <mikeingle@delphi.com>, and version 1.2, with significant new code by Edgar W. Swank <EdgarSwank@Juno.com>.
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 the file COPYING for legalese.
The "author" of versions 1.2, 1.3, and 1.4/a/b 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).
In case anyone in the U.S. Justice Dept. is reading this, Steve and I were very careful to do this release without violating US export restrictions. The only things I "exported" to Steve were "diffs" for source changes from 1.4a to 1.4b, which themselves don't contain any code capable of encryption or decryption. Steve combined those with source for 1.4a, already available overseas.
Steve compiled the new source code, and sent the new EXE files to me. I compared the new executables to ones I compiled myself and verified they match, bit for bit. I then sent back to Steve detached signature files for the executables. Steve then put together secdr14b.zip and sent that to me for final inspection. I then compared all files against my "master" files here and verified that they matched. I then shipped the secdr14b.zip that Steve sent me to the USA sites. So the USA release matches bit for bit the offshore release.
Sequence should be Start - Settings - Control Panel - System - Performance Tab - File System Button - Troubleshooting Tab - "Disable all 32bit Protect-Mode Device Drivers"
If you can't find a control panel setting, look for
32BitDiskAccess=On
in SYSTEM.INI and change it to Off.
I've also been told of one instance where CRYPTDSK and/or LOGIN failed to find the correct partition from the DOS drive letter. If this happens, use the physical partition parameters, as explained in the documentation.
A user has reported,
Even if you enter LOGIN /F outside windows (e.g. in AUTOEXEC.BAT), for some unknown reason, diskettes still can't be accessed after you enter Windows (95). Symptom is some kind of disk loop, which can be resolved by removing the diskette & waiting.
Apparently this is caused by trying to use Win95 built-in drivers for the diskette drive(s). You must insure the diskette drives are running in compatibility mode.
Check Settings, Control Panel, System,Performance. Either the text must say "All drives in compatibility mode" or it must list A and B along with C, D, etc. If hard drives are listed but floppies are not, then the floppies are not in compatibility mode and won't work with SECTSR or any overformatting TSR's (e.g. FDREAD, 2M, etc.).
Try the following (one at a time):
Disabling all 32-bit drivers as suggested above should work. It may have undesired side effects.
A and B can be forced into compatibiity mode from the Control Panel, System, Device Manager. Select Device Manager, Standard floppy disk controller, properties. Under "device usage" remove the check mark from "standard configuration." Back at the Device Manager display, standard floppy disk controller will have a big red "X" through it. After re-start, the floppies still work, but now through DiskBIOS. You will also see that A and B are listed as in compatibility mode under "performance."
Remove or "comment out" the following line from IOS.INI
sectsr.exe ; Shareware Virus driver
This may cause presence of SECTSR.COM to disable all 32-bit compatibility drivers. Re-check device manager after a restart.
A user also reported being unable to access his CD-ROM drive while SD was active. I have a CD-ROM drive & access it with no problems. But I have software which came with the drive loaded in CONFIG.SYS and AUTOEXEC.BAT. I didn't (couldn't?) use the install "wizard."
The IDEA(tm) block cipher is covered by a patent held by the Swiss company called Ascom Systec Ltd. The Swiss patent number is PCT/CH91/00117. International patents are pending. IDEA(tm) is a trademark of Ascom Systec Ltd. There is no license fee required for noncommercial use. Commercial users may obtain licensing details from:
Ascom Systec Ltd.
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!
Edgar's PGP public key is available from key servers and his Home page.
Anonymity and privacy on the Internet