home *** CD-ROM | disk | FTP | other *** search
/ Tools en Utilities / CDASS_5.ISO / shell / dos / secdr13d.arj / BUGS13A.DOC < prev    next >
Encoding:
Text File  |  1994-04-25  |  8.8 KB  |  223 lines
  1. SecureDrive Version 1.3d replaces version 1.3a.  A prototype version
  2. 1.3b was sent to a few people for testing. Version 1.3c was
  3. released to distribution but was not really compatible with
  4. 2M13 as it claimed to be.
  5.  
  6. Changes for 1.3d have added minimal new function.  Rather I have
  7. sought to respond to problems brought to my attention.
  8.  
  9. Problem:
  10.  
  11. CRYPTDSK messages indicate incorrect compatibility mode.
  12.  
  13. Solution:
  14.  
  15. This was a simple bug. Fixed in 1.3d.
  16.  
  17.  
  18. Problem:
  19.  
  20. CRYPTDSK & LOGIN can't locate some hard disk partitions, especially in
  21. configurations with more than two physical hard disks, from the DOS
  22. drive letter.
  23.  
  24. Solution:
  25.  
  26. This has been a problem since Version 1.0.  Mike added a fix in
  27. version 1.1 which works for most (but apparently not all)
  28. configurations with two physical disks.
  29.  
  30. We don't have a fix, but we do have a workaround.  Both LOGIN and
  31. CRYPTDSK have since version 1.0 allowed you to specify physical drive,
  32. cylinder and head number -instead of- the DOS drive letter. I have
  33. added a simple FPART utility in 1.3d to assist you in finding the
  34. cylinder and head numbers to use.
  35.  
  36. Note that commas (",") must be used to separate these parameters for
  37. CRYPTDSK, while blanks are used for LOGIN.
  38.  
  39. Problem:
  40.  
  41. After I encrypt my hard disk partition or floppy, MSDOS won't
  42. recognize it as a DOS disk, giving me an "Invalid Media" or similar
  43. message.
  44.  
  45. Solution:
  46.  
  47. Apparently, some versions of MSDOS, especially those included with
  48. some laptop PC clones, insist that the SYSTEM ID field of the boot
  49. sector be ASCII characters. Versions of SecureDrive from versions
  50. 1.0 to 1.3a have used the last four characters of SYSTEM ID to store a
  51. 4-byte checkword used to verify that the correct passphrase had been
  52. entered.  This checkword is an MD5 digest of the IDEA key and (in
  53. Version 1.1) the passphrase.  The 128-bit IDEA key is an MD5 digest
  54. (iterated in Version 1.1) of the passphrase.  The checkword is
  55. calculated and stored in the boot sector when the disk partition or
  56. diskette is first encrypted.  Whevever you enter a passphrase to
  57. decrypt or activate the disk, both the key and the checkword are
  58. generated.  The checkword is compared against the one stored in the
  59. boot record as a check that the same passphrase was entered for
  60. decryption as for encryption.  Note that the boot sector is never
  61. itself encrypted.  Also note that since MD5 is a "cryptographicly
  62. strong" one-way digest function, it is not computationally feasible to
  63. find the IDEA key, much less the original passphrase, from the
  64. checkword.
  65.  
  66. Version 1.3d changes the standard location of the checkword to offset
  67. 506 in the boot record. Also the offset of the "CRYP" flag, which
  68. indicates that a disk is encrypted, has been changed from offset
  69. 3 (the start of SYSTEM ID) to offset 502. All eight bytes from
  70. offset 502-509 is called the "CryptFlag."
  71.  
  72. Version 1.3d will place the CryptFlag at offset 502 for all newly
  73. encrypted partitions and diskettes. It will continue to check
  74. for both the "CRYP" flag and the checkword in the SYSTEM ID so
  75. you can still activate or decrypt partitions or diskettes encrypted
  76. by previous versions of SecureDrive.
  77.  
  78. You can convert disks encrypted by previous versions of SecureDrive to
  79. the new standard CryptFlag offset by using the /UCFO [Update CryptFlag
  80. Offset] function with LOGIN (either for hard disk partitions or
  81. diskettes).  Note that /UCFO will overlay SYSTEM ID (the old
  82. CryptFlag) with "MSDOS   ", which means that that disk can no longer
  83. be activated or decrypted with previous versions of SecureDrive.
  84.  
  85. /UCFO doesn't work if combined with the /S (safe mode) parameter.
  86.  
  87. Changing a disk's password with CRYPTDSK will also update the
  88. CryptFlag offset.
  89.  
  90. ATTENTION: Version 1.3b users.
  91.  
  92. Version 1.3b was distributed to a few people for testing. If you
  93. either SET SDOUTCWO=506 or SDOUTCWO=7 (the default), then Version 1.3d
  94. will be able to activate or decrypt your disks encrypted by Version
  95. 1.3b CRYPTDSK  or processed by Version 1.3b LOGIN /UCWO. This is
  96. because Version 1.3d checks for a split CryptFlag.
  97.  
  98. However, Version 1.3d cannot recognize checkword offsets other than
  99. 7 or 506. So if you set SDOUTCWO to something else, you must convert
  100. all such disks to one of the standard offsets BEFORE switching to
  101. Version 1.3d.
  102.  
  103. You can use Version 1.3b to do this. First
  104.  
  105. SET SDINCWO=whatever current non-standard offset is
  106. SET SDOUTCWO=506.
  107.  
  108. Run Version 1.3b
  109.  
  110. LOGIN  xxx /UCWO
  111.  
  112. on all disk partitions and on all diskettes.
  113.  
  114. Problem:
  115.  
  116. I used the recently released 2M/2MF diskette TSR/Format program from
  117. Spain to format a diskette.  I then encrypted it with CRYPTDSK, which
  118. seemed to run normally, but after that LOGIN /F told me the disk was
  119. unencrypted and all the disk data is garbled.
  120.  
  121. Solution:
  122.  
  123. 2M/2MF sets the SYSTEM ID field in the boot record and won't allow any
  124. other program to change it (if 2M.COM is loaded).  Version 1.3d of
  125. SecureDrive also solves this problem by moving the offset for the
  126. CryptFlag out of SYSTEM ID to offset 502.
  127.  
  128. Version 1.3d also adds other changes for compatibility with 2M13.
  129. 1)Adjust decryption to allow for simulation of FAT2 by reading FAT1.
  130. One of the cryptography parameters used by SecureDrive depends on
  131. sector address. Using a FAT2 address to decrypt FAT1 data would lead
  132. to incorrect decryption. 1.3d adjusts this parameter for FAT2 sectors
  133. on 2M-formatted diskettes.
  134.  
  135. 2M13 also (incorrectly) moves data to user buffers on a write verify.
  136. This would place encrypted data in user buffers. Version 1.3d works
  137. around this by treating write verifys the same as writes. Encrypting
  138. the buffer before the write verify and decrypting after, which
  139. apparently provides a solution.
  140.  
  141. 2M13 code which causes this problem also frequently causes requests
  142. for write verify not to be performed, which could leave unreadable
  143. data undected until a later time.  See SECDRV.DOC for a recommended
  144. source change to 2M13.
  145.  
  146. Problem:
  147.  
  148. After I used [some disk utility] LOGIN and CRYPTDSK always say I have
  149. entered an incorrect passphrase for my encrypted disk.  I'm SURE I
  150. used the right passphrase.
  151.  
  152. Another possible problem might be that SecureDrive says the disk
  153. is not encrypted, but it obviously is encrypted since the DOS "DIR"
  154. command displays garbage.
  155.  
  156. Solution:
  157.  
  158. Mike has a report from a user who used some disk utility that re-wrote
  159. his boot record, overlaying the checkword (but apparently not the
  160. "CRYP" flag).  This is probably a different manifestation of the
  161. problem mentioned above.  This disk-fixing utility wants to see an
  162. all-ASCII SYSTEM ID and will set ASCII where it doesn't find it.
  163.  
  164. As a way to fix this, I've added the /RCF [Recover CryptFlag]
  165. parameter to LOGIN.  This will allow you to activate a disk even if
  166. the checkword doesn't match, or the "CRYP" flag has been destroyed.
  167. You will be asked to enter the passphrase twice.  The new checkword
  168. will be written at new standard offset 506 which will hopefully avoid
  169. a repetition of the problem the next time you use that same utility.
  170.  
  171. You are not allowed to recover the CheckWord if SD10CMP=X, since
  172. this setting does now allow LOGIN to compute or check version 1.1
  173. compatible checkwords.
  174.  
  175. Also, if after you enter the checkword, you get garbage when trying
  176. to read the disk, change SD10CMP from Y to N (or vice versa) and try
  177. LOGIN xxx  /RCF again.
  178.  
  179. /RCF also doesn't work if combined with the /S (safe mode) parameter.
  180.  
  181. Note that extreme caution is required when using this parameter. If
  182. you force activation of a disk with the wrong passphrase, it's
  183. effectively the same as accessing the disk without SECTSR loaded.  Any
  184. write to the disk will likely make -all- data on the disk partition or
  185. diskette unreadable.
  186.  
  187. Problem:
  188.  
  189. CRYPTDSK (and FPART) may not work while SECTSR is installed.
  190.  
  191. Solution:
  192.  
  193. If this occurs, try re-ordering device drivers & TSR's which might
  194. effect diskette access.  Note that CRYPTDSK/FPART will reach below
  195. SECTSR to do sector disk I/O, so any TSR's loaded after SECTSR will
  196. also be bypassed by CRYPTDSK/FPART.
  197.  
  198. CRYPTDSK and FPART may be used without SECTSR loaded if necessary.
  199.  
  200. Problem:
  201.  
  202. CRYPTDSK, FPART and/or LOGIN don't work in a DOS Window of Windows.
  203.  
  204. Discussion:
  205.  
  206. I have been able to get LOGIN to activate disks in a Windows DOS
  207. window. However LOGIN /PGP and its variants do not set PGPPASS. SET
  208. doesn't work either.
  209.  
  210. It's probably better to call LOGIN in your AUTOEXEC for Windows, if
  211. possible, and get your disk logged in before loading Windows.
  212.  
  213. I have been able to start CRYPTDSK in the DOS window and it ran fine.
  214. But if I switched to another window, it crashed in the middle. I don't
  215. see how this can be anything but a Windows problem.  Since crashing
  216. CRYPTDSK in the middle essentially destroys all the data on the disk,
  217. I don't recommend trying to run CRYPTDSK under Windows.
  218.  
  219. Of course, SECTSR must be loaded before Windows. DON'T load SECTSR in
  220. a DOS Window.
  221.  
  222.  
  223.