home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 17 / CD_ASCQ_17_101194.iso / vrac / sfs110.zip / SFS3.DOC < prev    next >
Text File  |  1994-08-01  |  67KB  |  1,432 lines

  1. SFS Disk Volume Layout
  2. ----------------------
  3.  
  4. An SFS volume is broken up into two parts, the boot sector which is used to
  5. identify the volume and store assorted status information, and the encrypted
  6. volume itself.  If a program tries to read the boot sector, the SFS driver will
  7. assemble a pseudo-boot sector in memory and return that instead.  If a program
  8. tries to write to the boot sector, the SFS driver will skip the boot sector
  9. while still writing any other sectors which may be requested.
  10.  
  11. All data on the boot sector, both plaintext and encrypted, is stored in
  12. big-endian format following the convention used by international cryptographic
  13. standards.  Care should to taken to ensure that the proper endianness is
  14. maintained when reading and writing the boot sector on little-endian systems
  15. (the performance of the current implementation was tested against the RS6000
  16. version to confirm that endianness conversion was being done correctly).
  17.  
  18. In the following discussion a BYTE is an 8-bit quantity, a WORD is a big-
  19. endian 16-bit quantity, and a LONG is a big-endian 32-bit quantity.  There are
  20. no alignment restrictions for the data as stored on disk.  All data is
  21. close-packed with no need for byte-padding for word or longword boundaries.
  22.  
  23.  
  24. The SFS Volume Header Record
  25.  
  26. The boot record is the first sector in a disk volume, and is usually used to
  27. load a bootstrap code block which loads more code which eventually loads DOS or
  28. an operating system.  In the case of SFS there is no bootstrap code as SFS
  29. partitions are not bootable.  Instead, the boot record contains a volume header
  30. record holding identification information which SFS uses when mounting the
  31. volume, and encryption information to allow SFS to decrypt the volume.  The
  32. information is stored as a series of variable-length data packets with fields
  33. in big-endian order.  Although it might be desirable to store the data as
  34. DER-encoded ASN.1 (ISO 8824, ISO 8825), the amount of code necessary to decode
  35. this information is considerable, leading to excessively complicated loaders
  36. for the encrypted volume.  In particular, it would make the use of automatic
  37. volume mounts for the SFS device driver virtually impossible.
  38.  
  39. The SFS volume header may contain multiple data packets, currently up to six
  40. types are implemented (there is an additional seventh pseudo-packet type which
  41. is a null data packet).  One packet identifies the volume, one contains
  42. encryption information needed to en/decrypt the volume, and one contains
  43. filesystem-specific information needed to access the volume.  These packets
  44. are mandatory.  Finally, a number of optional packets may be used to hold data
  45. such as information for volumes accessible by multiple users, information
  46. needed by the high-speed direct disk access routines in SFS, and information to
  47. control the conditions under which SFS volumes are unmounted.  Each packet
  48. consists of a packet type identifier followed by the length of the data in the
  49. packet, and then by the packet data itself.
  50.  
  51. The volume header is laid out as follows:
  52.  
  53.     Offset  Size    Type        Description
  54.  
  55.        0      4     BYTE[ 4 ]   'SFS1' identification string
  56.        4      2     WORD        Information packet 1 ID
  57.        6      2     WORD        Information packet 1 data length
  58.        8     ??     ????        Information packet 1 data
  59.        n      2     WORD        Information packet 2 ID
  60.      n+2      2     WORD        Information packet 2 data length
  61.      n+4     ??     ????        Information packet 2 data
  62.                       ..........
  63.        m      2     WORD        Information packet n ID
  64.      m+2      2     WORD        Information packet n data length
  65.      m+4     ??     ????        Information packet n data
  66.  
  67. It is recommended that the order of the information packets be as follows
  68.  
  69.     1.  Volume information
  70.     2.  Encryption information
  71.     3.  Filesystem information
  72.     4.  Other information (such as multiuser access data, direct disk access
  73.         information, and information to control the conditions under which SFS
  74.         volumes are unmounted)
  75.  
  76. although this is not essential.  However some volume mount software which must
  77. run with severely limited resources may run into problems if the order of the
  78. data packets is not as expected.  The remainder of the sector is filled with
  79. zeroes.  Currently defined packet types are:
  80.  
  81.     Name                    Value       Information type
  82.  
  83.     SFS_PACKET_NONE           0         Null packet
  84.     SFS_PACKET_VOLUMEINFO     1         Volume information
  85.     SFS_PACKET_ENCRINFO       2         Encryption information
  86.     SFS_PACKET_DISK_BPB       3         Filesystem information
  87.     SFS_PACKET_MULTIUSER      4         Multiuser access information
  88.     SFS_PACKET_FASTACCESS     5         Direct disk access information
  89.     SFS_PACKET_UNMOUNT        6         Volume unmount information
  90.  
  91.  
  92. Packet 0 - Null Packet
  93.  
  94. This packet contains no information and is never explicitly set in an SFS
  95. volume header.  However since the remainder of the header after the actual data
  96. is padded out with zeroes, it can be viewed as containing a succession of null
  97. packets.
  98.  
  99.  
  100. Packet 1 - Volume Information Packet
  101.  
  102. The volume information packet contains the volume name, the volume creation
  103. time, and the volume serial number.  The packet layout is as follows:
  104.  
  105.     Offset  Size    Type        Description
  106.  
  107.        0      2     WORD        Volume information packet ID = 1
  108.        2      2     WORD        Volume information packet data length
  109.        4      2     WORD        Volume name character set identifier
  110.        6      2     WORD        Volume name length
  111.        8     ??     BYTE[]      Volume name
  112.        n      4     LONG        Volume date, stored as seconds since 1970 GMT
  113.      n+4      4     LONG        Volume serial number
  114.  
  115. The character set identifier is one of the following:
  116.  
  117.     Value   Type
  118.  
  119.       0     ISO 646 character set
  120.       1     ISO 8859-1 character set
  121.       2     ISO 8859-2 charcater set
  122.       3     ISO 8859-3 character set
  123.       4     ISO 8859-4 character set
  124.       5     ISO 8859-5 character set
  125.       6     ISO 8859-6 character set
  126.       7     ISO 8859-7 character set
  127.       8     ISO 8859-8 character set
  128.       9     ISO 8859-9 character set
  129.      ??     Reserved for future use
  130.  
  131. The volume name is stored as an octet string immediately following the
  132. character set and length values.  The recommended maximum length for the volume
  133. name field is 100 octets, in order to allow room for the remainder of the
  134. volume header.
  135.  
  136. The volume creation data is stored as a count of seconds since midnight on 1st
  137. January 1970.  Times are stored relative to GMT, although some operating
  138. systems may have trouble with time zones.
  139.  
  140. The volume serial number is used mainly for identification purposes and has no
  141. special characteristics, but should be unique across volumes.
  142.  
  143.  
  144. Packet 2 - Encryption Information Packet
  145.  
  146. The encryption information packet contains the algorithm identifier of the
  147. encryption algorithm being used, the iteration count used when setting up the
  148. keying information, the initialisation vector (IV) for the disk key, the
  149. encrypted disk key for the volume, and a key check value which may be used to
  150. verify that the correct decryption key has been given. The packet layout is as
  151. follows:
  152.  
  153.     Offset  Size    Type        Description
  154.  
  155.        0      2     WORD        Encryption packet ID = 2
  156.        2      2     WORD        Encryption packet data length
  157.        4      2     WORD        Encryption algorithm identifier
  158.        6      2     WORD        Encryption key setup iteration count
  159.        8     ??     BYTE[]      Disk key IV
  160.        n    128     BYTE[]      Encrypted disk key
  161.    n+128      2     WORD        Key check value
  162.  
  163. The encryption algorithm identifier is one of the following:
  164.  
  165.     Value   Type
  166.       0     MDC/SHS
  167.      ??     Reserved for future use
  168.  
  169. The MDC/SHS algorithm uses the Secure Hash Standard as the block transformation
  170. in the MDC encryption algorithm.
  171.  
  172. The size of the disk key IV depends on the encryption algorithm, and is equal
  173. to the block size of the encryption algorithm being used.  In the case of
  174. MDC/SHS this is 160 bits or 20 bytes.
  175.  
  176. The encrypted disk key contains 128 bytes of cryptographically strong random
  177. information whose derivation is given in the section "Generating Random
  178. Numbers" above.  This data may be utilized as required by the encryption
  179. algorithm used for the particular disk volume.  In the case of MDC/SHS the
  180. first 160 bits are used as the master disk IV from which individual sector IV's
  181. are generated as described in the section "The Use of an Initialization
  182. Vector", the next 512 bits are used as the en/decryption key, and the remaining
  183. 352 bits are ignored.  Other algorithms with larger or smaller key spaces may
  184. use this data differently.
  185.  
  186. The key check value is provided to give some warning about an incorrect
  187. password, and should be derived from the encryption key in some nontrivial
  188. manner which makes using the key check in an attack no easier than a standard
  189. known plaintext attack.  In the case of MDC/SHS it is the last two octets in
  190. the key data buffer after the key setup operation has been performed (this
  191. value is never used as part of the encryption key, and is the product of 200
  192. iterations of MDC/SHS over the user key).
  193.  
  194.  
  195. Packet 3 - Filesystem Information Packet
  196.  
  197. The filesystem information packet contains identification information for the
  198. filesystem contained on the encrypted volume followed by encrypted
  199. filesystem-specific information needed to handle the volume.  This information
  200. is highly system-specific.  The packet layout is as follows:
  201.  
  202.     Offset  Size    Type        Description
  203.  
  204.        0      2     WORD        Filesystem information packet ID = 3
  205.        2      2     WORD        Filesystem information packet data length
  206.        4      2     WORD        Filesystem type identifier
  207.        6     ??     BYTE[]      Encrypted filesystem information
  208.  
  209. The filesystem type identifier is one of the following:
  210.  
  211.     Value   Type
  212.  
  213.       0     MSDOS FAT filesystem - BPB data
  214.      ??     Reserved for future use
  215.  
  216. The encrypted MSDOS BPB data record corresponds directly to a standard BIOS
  217. parameter block and is laid out as follows:
  218.  
  219.     Offset  Size    Type        Description
  220.  
  221.        0      2     WORD        Sector size in bytes
  222.        2      1     BYTE        Sectors per cluster
  223.        3      2     WORD        Number of boot sectors
  224.        5      1     BYTE        Number of FAT copies
  225.        6      2     WORD        Number of entries in root directory
  226.        8      2     WORD        16-bit number of sectors on disk
  227.       10      1     BYTE        Media descriptor byte
  228.       11      2     WORD        Number of sectors per FAT
  229.       13      2     WORD        Number of sectors per track
  230.       15      2     WORD        Number of heads
  231.       17      4     LONG        Number of hidden sectors
  232.       21      4     LONG        32-bit number of sectors on disk
  233.  
  234.  
  235. Packet 4 - Multiuser Access Information
  236.  
  237. The multiuser access information packet contains an identification number for
  238. the multiuser access data file needed to access the volume.  This value is
  239. checked against an equivalent one in the access data file to ensure that the
  240. data file corresponds to the volume in question.  In addition the presence of
  241. this packet signals to the user software that the volume has multiuser access
  242. enabled.  The packet layout is as follows:
  243.  
  244.     Offset  Size    Type        Description
  245.  
  246.        0      2     WORD        Multiuser access information packet ID = 4
  247.        2      2     WORD        Multiuser access information packet data length
  248.        4      4     LONG        Multiuser access data file ID
  249.  
  250.  
  251. Packet 5 - Direct Disk Access Information
  252.  
  253. The direct disk access information packet contains information needed by the
  254. disk access routines in SFS to bypass the normal BIOS disk access methods and
  255. interface directly with the drive.  This leads to a significant speed
  256. improvement with disk types which support this access mode, since SFS can
  257. perform en/decryption operations while waiting for disk I/O to complete.  The
  258. packet layout is as follows:
  259.  
  260.     Offset  Size    Type        Description
  261.  
  262.        0      2     WORD        Direct access information packet ID = 5
  263.        2      2     WORD        Direct access information packet data length
  264.        4      2     WORD        Direct access method
  265.        6     ??     ??          Extra information needed for direct access
  266.  
  267. The direct access method is one of the following:
  268.  
  269.     Value   Type
  270.  
  271.       0     BIOS disk access (default)
  272.       1     IDE single-sector programmed I/O access
  273.       2     SCSI device access via ASPI interface
  274.      ??     Reserved for future use
  275.  
  276. Some of the high-speed access modes are not used automatically since it is
  277. unsafe to assume that all hardware will support them.  Therefore if the direct
  278. disk access information packet is absent and if BIOS access to the drive is
  279. possible, slower BIOS accesses are used by default.  If it has been determined
  280. by external software that a fast access mode is possible, the software should
  281. write (or update) a direct disk access information packet to reflect this.  If
  282. no access to the drive other than with a fast direct access mode is possible,
  283. then the fast access mode will always be used.
  284.  
  285.  
  286. Packet 6 - Volume Unmount Information
  287.  
  288. The volume unmount information packet contains information on conditions under
  289. which SFS volumes are unmounted by the SFS driver.  These may be in response to
  290. external stimuli, or due to internal conditions monitored by the driver.  In
  291. the absence of this packet, the settings used for volume unmounts are the
  292. defaults set by the driver, although these can generally be overridden under
  293. user control.
  294.  
  295. Currently only one parameter, the auto-unmount timeout value, is defined.  This
  296. contains the default setting for the auto- unmount timer for this volume.  If
  297. no disk access takes place in the specified time, the volume is automatically
  298. unmounted.  A value of 0 in this field indicates that no auto-unmount timer is
  299. to be set (although this is better accomplished by simply deleting the volume
  300. unmount information packet).
  301.  
  302. The packet layout is as follows:
  303.  
  304.     Offset  Size    Type        Description
  305.  
  306.        0      2     WORD        Volume unmount information packet ID = 6
  307.        2      2     WORD        Volume unmount information packet data length
  308.        4      2     WORD        Auto-unmount timeout in minutes, 0 = none set
  309.  
  310.  
  311. SFS Multiuser Access File Layout
  312. --------------------------------
  313.  
  314. [The following information is preliminary and is bound to change at a moments
  315.  notice]
  316.  
  317. Associated with each SFS volume which has multiuser access enabled are one or
  318. more database files containing information on each user who has access to that
  319. volume.  This consists of identification information for each user (in the case
  320. of a named database), access control information, and keying information needed
  321. to access the actual volume.
  322.  
  323. The file is laid out as a simple flat database, which is adequate for its
  324. intended use since a user record is only retrieved once per database access,
  325. and generally the databases will be quite small.
  326.  
  327. On a system with proper access control this file will be read-only for everyone
  328. but the volume administrator, but unfortunately under some operating systems
  329. and also DOS there is little access control and anyone with access to a sector
  330. editor can change their access rights.  However at this level they can also
  331. change the SFS volume header and the behaviour of mountsfs and the SFS driver,
  332. so little is gained by attempting to plug this hole.  In any case, the basic
  333. access to the volume is cryptographically controlled, and bypassing this goes
  334. beyond simply editing a file.
  335.  
  336. In the future it may be worthwhile implementing more heavy-duty controls, such
  337. as using public-key signed access permission tokens from the volume
  338. administrator to grant access for networked use.
  339.  
  340. All data in the multiuser access database is stored in big-endian format
  341. following the convention used by international cryptographic standards.  Care
  342. should to taken to ensure that the proper endianness is maintained when reading
  343. and writing the boot sector on little-endian systems (the performance of the
  344. current implementation was tested against the RS6000 version to confirm that
  345. endianness conversion was being done correctly).
  346.  
  347. In the following discussion a BYTE is an 8-bit quantity, a WORD is a big-
  348. endian 16-bit quantity, and a LONG is a big-endian 32-bit quantity.  There are
  349. no alignment restrictions for the data as stored in the database.  All data is
  350. close-packed with no need for byte-padding for word or longword boundaries.
  351.  
  352. An access database is broken up into two sections, a header record containing
  353. details on the database as a whole, and one or more individual user records.
  354.  
  355.  
  356. Database Header
  357.  
  358. The database header is laid out as follows:
  359.  
  360.     Offset  Size    Type        Description
  361.  
  362.        0      4     BYTE[4]     'SFS1' identification string
  363.        4      2     WORD        Database type identifier
  364.        6      4     LONG        Encrypted volume serial number
  365.       10      2     WORD        Number of user records in database
  366.       12      2     WORD        Database name character set identifier
  367.       14      2     WORD        Database name length
  368.       16     ??     BYTE[]      Database name
  369.  
  370. The identification string and database type identifier serve to identify the
  371. general database format.  The type identifier is one of the following:
  372.  
  373.     Value   Type
  374.  
  375.       0     Anonymous database containing date, access, keyinfo records
  376.       1     Named database containing user name, date, access, keyinfo records
  377.      ??     Reserved for future use
  378.  
  379. An anonymous database contains no identification for any of the user records.
  380. Each keyinfo record is decrypted in turn until a valid record is found, and
  381. this keying information is then used to access the encrypted volume.
  382.  
  383. A named database contains an idetifier for each user record.  Lookup of the
  384. database is performed directly by user name, and then access proceeds as for
  385. the anonymous database.
  386.  
  387. The encrypted volume serial number is the serial number of the volume this
  388. database is used to access.
  389.  
  390. [Problem: Should be able to set to zero to keep corresponding volume anonymous]
  391. [Problem: Can lead to trouble if chsfs is used to change volume serial number.
  392.           Perhaps change chsfs to disallow serial number change without also
  393.           changing database serial number]
  394.  
  395. The database name is the collective name for the database and the users in it.
  396. Example database names might be "Ancient Illuminated Seers of Bavaria" or
  397. "Trilateral Commission".  The name is optional, and may be omitted by
  398. specifying a name with a length of 0 characters.
  399.  
  400.  
  401. Database Records
  402.  
  403. Each record in the database is laid out as follows:
  404.  
  405.     Offset  Size    Type        Description
  406.  
  407.        0      2     WORD        Record type identifier
  408.        2      2     WORD        User name character set identifier
  409.        4      2     WORD        User name length
  410.        6     ??     BYTE[]      User name
  411.        n      4     LONG        Access valid from date
  412.      n+4      4     LONG        Access valid to date
  413.      n+8      4     LONG        Access rights bitstring
  414.     n+12     ??     BYTE[]      Keying information
  415.  
  416. The record type identifier is one of the following:
  417.  
  418.     Value   Type
  419.  
  420.       0     Anonymous record containing date, access, and keyinfo
  421.       1     Named record containing user name, date, access, and keyinfo
  422.      ??     Reserved for future use
  423.  
  424. The user name is the name of the user entitled to access the SFS volume the
  425. database corresponds to.  Under multiuser operating systems this will simply
  426. correspond to the userID which the user is known to the operating system under.
  427. Otherwise, the userID can be the user's name or some similar identifying method
  428. capable of distinguishing users.  If the record type is an anonymous record,
  429. the user name fields will not be present.
  430.  
  431. [Problem: One user with many accounts.  Allow multiple userID's per record?
  432.           This could encourage password sharing though]
  433.  
  434. The access valid date pair contains the date after which access to the SFS
  435. volume is permitted, and the date at which access rights to the volume expire.
  436. These are stored in the Unix seconds-since-1970 format.
  437.  
  438. The access rights bitstring contains the access rights the user has to the SFS
  439. volume.
  440.  
  441. [Problem: How?  Use RWXRWXRWX?  Or ASN.1-type strings with complex FTAM-type
  442.           rights?  ACL's?]
  443.  
  444. The keying information is [what?  Same as single-user keying information]
  445.  
  446.  
  447. Interfacing with SFS
  448. --------------------
  449.  
  450. The SFS device driver has a sophisticated control interface which allows
  451. complete configurability through the standard DOS IOCTL read and write calls,
  452. which are used to transfer data to and from the control channel of a device.
  453. It is recommended that you consult a system programming guide or your compilers
  454. documentation for more information on making DOS IOCTL calls.  Many compilers
  455. provide standard routines for making these calls.
  456.  
  457. In the following discussion a BYTE is an 8-bit quantity, a WORD is a little-
  458. endian 16-bit quantity, and a LONG is a little-endian 32-bit quantity.  These
  459. values will need endianness conversion after being read from the SFS volume
  460. header.
  461.  
  462.  
  463. How SFS Identifies Drives
  464.  
  465. For floppy disk drives, a value of 0 usually corresponds to drive A: and a
  466. value of 1 usually corresponds to drive B:.  For fixed disk drives accessible
  467. through the system BIOS, a value of 0 with the high bit set (giving an actual
  468. value of 0x80) usually corresponds to the first physical drive and a value of 1
  469. with the high bit set (giving an actual value of 0x81) usually corresponds to
  470. the second physical drive.  These values correspond to physical drives as
  471. accessed through the BIOS, and not logical volumes (SFS can also access drives
  472. not normally accessible through the BIOS).  A single physical drive may contain
  473. a number of logical volumes. Since the SFS driver runs below the level at which
  474. most operating systems operate, it will ignore the DOS drive mappings (in fact
  475. DOS can't even see the encrypted disk volume) and access the drive directly.
  476. Thus if there are more than the DOS standard of two floppy drives and two
  477. physical hard drives connected to the system it should still be able to access
  478. the drives and present them to the operating system as normal disk volumes.
  479.  
  480. If the physical drive contains more than one logical volume, the offset of the
  481. start of the logical volume from the start of the physical drive is specified
  482. as a sector or disk block count.  If the physical drive contains only one
  483. logical volume, this value is set to zero.  Finding the start of the logical
  484. volume will usually entail parsing the partition table of the physical drive.
  485. Floppy drives have only one logical volume which is equivalent in size to the
  486. physical drive, fixed disks have one or more logical volumes on each physical
  487. volume.  These logical volumes can contain different filesystems and operating
  488. systems, and not all may be accessible or visible to DOS.  For more information
  489. on disk organization, refer to a good technical reference which covers disk
  490. drives, and then spend several days figuring out all the DOS quirks never
  491. mentioned in any reference.
  492.  
  493. In the following text the term `drive number' is used to refer to a value which
  494. identifies a particular drive (which depends on the drive type, since BIOS, IDE
  495. and SCSI drive access identifies drives in different ways), the term `physical
  496. volume' is used to refer to the physical drive being accessed and the term
  497. `logical volume' is used to refer to the drive as DOS sees it.
  498.  
  499.  
  500. Reading from the SFS Driver:
  501.  
  502. The SFS driver processes both control channel read and control channel write
  503. requests.  Initially, the drive number of the logical volume being used by the
  504. SFS driver must be found.  This can be done by checking each possible logical
  505. drive as follows:
  506.  
  507.     for( driveNumber = 0; driveNumber <= 'Z' - 'A'; driveNumber++ )
  508.         {
  509.         /* Try and read data from the device's control channel */
  510.         data <- ioctlRead( driveNumber );
  511.  
  512.         /* Check for the SFS identification string */
  513.         if( first 4 bytes of data = 'SFS1' )
  514.             exit loop;
  515.         }
  516.  
  517. If, at the end of the loop's execution, the driveNumber is greater than the
  518. total number of drives in the system, the SFS driver has not been found,
  519. probably because it isn't present in the system.  Otherwise, driveNumber
  520. contains the drive number of the logical volume which the SFS driver is making
  521. available, and the data packet contains assorted status information about the
  522. SFS volume corresponding to the driveNumber.
  523.  
  524. The data packet returned by the SFS driver is as follows:
  525.  
  526.     Offset  Size    Type        Description
  527.  
  528.        0      4     BYTE[ 4 ]   'SFS1' identification string
  529.        4      2     WORD        SFS unit number, starting from 0
  530.        6      2     WORD        Drive the SFS volume is mounted on.
  531.                                 Interpretation of this value depends on the
  532.                                 disk access mode.
  533.        8      4     LONG        Sector or disk block offset of logical volume
  534.                                 from start of physical volume, or 0 if logical
  535.                                 volume corresponds to physical volume
  536.       12      2     WORD        0 = no disk mounted, 1 = disk mounted, 2 = disk
  537.                                 mounted in non-removable mode
  538.       14      2     WORD        0 = disk is read/write, 1 = disk is read-only
  539.       16      2     WORD        Quick-unmount hotkey value (high byte = shift
  540.                                 value, low byte = optional keyboard scan code)
  541.       18      2     WORD        Auto-unmount time.  -1 = no unmount timer set,
  542.                                 0 = timer set but expired, any other value =
  543.                                 total unmount time in minutes
  544.       20      2     WORD        Auto-unmount timeout actual minutes remaining
  545.                                 before the unmount takes place
  546.       22      2     WORD        Internal driver check code.  0 = no error, 1 =
  547.                                 driver consistency check failed, 2 = individual
  548.                                 unit consistency check failed.
  549.       24      4     DWORD       Last I/O error status.
  550.  
  551. The unit number is used by SFS to handle multiple encrypted drives.  This value
  552. starts at zero for the first unit, and identifies the volume being accessed.
  553.  
  554. The last I/O error status value provides more details on the last read or write
  555. error encountered by the SFS driver for the drive in question.  This value is
  556. divided into 4 bytes, of which the first contains the access mode in use when
  557. the error occurred, the the remaining three contain error information.  The
  558. possible values are as follows:
  559.  
  560.     First byte  Access mode     Remaining bytes
  561.  
  562.         0          BIOS         Byte 1 = 0
  563.                                 Byte 2 = 0
  564.                                 Byte 3 = BIOS error code
  565.         1          IDE          Byte 1 = 0
  566.                                 Byte 2 = controller status
  567.                                 Byte 3 = controller error code
  568.         2          SCSI         Byte 1 = sense key
  569.                                 Byte 2 = auxiliary sense key
  570.                                 Byte 3 = auxiliary sense key qualifier
  571.        ??        Reserved       Reserved for future use
  572.  
  573. In all cases a value of all ones in bytes 2 and 3 indicate a controller or host
  574. device timeout.
  575.  
  576. If queried via an IOCTL call on the volume's removability, the SFS driver will
  577. always indicate that the media is removable, even if the volume is on a fixed
  578. disk.  This is because some disk cacheing software won't invalidate a drive's
  579. data, even if the driver signals that the media has changed, unless the volume
  580. is marked as being removable.
  581.  
  582. This status information can be returned to the user in the form of a status
  583. message or an information dialog if desired (the drive and offset information
  584. can be used to read the volume name, date, and serial number from the encrypted
  585. volume).
  586.  
  587.  
  588. Writing to the SFS Driver
  589.  
  590. Once the driver has been found, several types of data packet can be sent to the
  591. driver to control its operation.  Each control packet begins with a WORD
  592. containing the magic value 'C0' which the SFS driver checks to ensure the
  593. packet is meant for it, and a WORD identifying the data packet type.  The data
  594. packet types are:
  595.  
  596.     Name                    Value       Information type
  597.  
  598.     PACKET_SET_DISKINFO       0         Disk parameters
  599.     PACKET_SET_KEYINFO        1         Keying information
  600.     PACKET_SET_READONLY       2         Set disk read-only status
  601.     PACKET_SET_DRIVENO        3         Drive number to mount
  602.     PACKET_SET_MOUNTSTATUS    4         Set mount status
  603.     PACKET_SET_UNMOUNT        5         Set/clear quick-unmount hotkey value
  604.     PACKET_SET_TIMEOUT        6         Set/clear timed unmount value
  605.  
  606. These packets are explained in more detail below.  All other values are
  607. reserved for future use.
  608.  
  609.  
  610. Packet 0 - Disk Parameters:
  611.  
  612. This packet type is used to convey to the SFS driver various pieces of
  613. information about the physical characteristics of the disk drive, including the
  614. sector size, number of heads, total number of sectors, and so on.  The packet
  615. layout is as follows:
  616.  
  617.     Offset  Size    Type        Description
  618.  
  619.        0      2     WORD        Magic value 'C0'
  620.        2      2     WORD        Packet type 0
  621.        4      2     WORD        Sector size in bytes
  622.        6      1     BYTE        Sectors per cluster
  623.        7      2     WORD        Number of boot sectors
  624.        9      1     BYTE        Number of FAT copies
  625.       10      2     WORD        Number of entries in root dir
  626.       12      2     WORD        Number of sectors on disk
  627.       14      1     BYTE        Media descriptor byte
  628.       15      2     WORD        Number of sectors per FAT
  629.       17      2     WORD        Number of sectors per track
  630.       19      2     WORD        Number of heads
  631.       21      4     LONG        Number of hidden sectors
  632.       25      4     LONG        Number of sectors per disk, 32-bit
  633.  
  634. Sending this data packet to the driver automatically unmounts the encrypted
  635. volume.
  636.  
  637.  
  638. Packet 1 - Keying information
  639.  
  640. This packet type sets up the encryption information in the driver.  It contains
  641. the en/decryption key, and the master IV for the encrypted volume.  The packet
  642. layout is as follows:
  643.  
  644.     Offset  Size    Type        Description
  645.  
  646.        0      2     WORD        Magic value 'C0'
  647.        2      2     WORD        Packet type 1
  648.        4     20     BYTE[ 20 ]  Master IV for encrypted volume
  649.       24     64     BYTE[ 64 ]  MDC/SHS keying information
  650.  
  651. Sending this data packet to the driver automatically unmounts the encrypted
  652. volume.
  653.  
  654.  
  655. Packet 2 - Set disk Read-only Status
  656.  
  657. This packet type sets the read-only status of the disk.  Sending a value of 0
  658. makes the disk read-only.  Sending a value of 1 makes the disk read/write.  The
  659. packet layout is as follows:
  660.  
  661.     Offset  Size    Type        Description
  662.  
  663.        0      2     WORD        Magic value 'C0'
  664.        2      2     WORD        Packet type 2
  665.        4      2     WORD        Read-only status: 0 = read-only, 1 = read/write
  666.  
  667. Sending this packet type has no effect on the mount status of the volume.
  668.  
  669.  
  670. Packet 3 - Drive Number to Mount
  671.  
  672. This packet type sets the drive number and the offset of the logical volume on
  673. the physical drive, which the driver will en/decrypt.  The packet layout is as
  674. follows:
  675.  
  676.     Offset  Size    Type        Description
  677.  
  678.        0      2     WORD        Magic value 'C0'
  679.        2      2     WORD        Packet type 3
  680.        4      2     WORD        Drive number.  Interpretation of this value
  681.                                 depends on the disk access mode.
  682.        6      4     LONG        Sector or disk block offset of logical volume
  683.                                 from start of physical volume, or 0 if logical
  684.                                 volume corresponds to physical volume
  685.  
  686. The drive number contains information allowing the driver to locate the
  687. physical drive on which the SFS volume is located.  The drive access mode and
  688. drive identifying information are encoded into a 16-bit word as follows:
  689.  
  690.     Bits 15-12: Disk access mode
  691.     Bits 11-0 : Drive identifying information
  692.  
  693. The drive identifying information is laid out as follows:
  694.  
  695.     Access mode     Drive identifying informtion
  696.  
  697.          0          Bits 11-8: 0
  698.                     Bits 7-0 : BIOS drive number
  699.          1          Bits 11-8: 0
  700.                     Bits 7-0 : IDE drive number
  701.          2          Bits 11-8: SCSI host number
  702.                     Bits 7-4 : SCSI target ID
  703.                     Bits 3-0 : SCSI logical unit number
  704.  
  705. Sending this data packet to the driver automatically unmounts the encrypted
  706. volume.
  707.  
  708.  
  709. Packet 4 - Set mount Status
  710.  
  711. This packet type sets the mount status of the drive.  A value of 0 unmounts the
  712. drive, a value of 1 mounts the drive.  The packet layout is as follows:
  713.  
  714.     Offset  Size    Type        Description
  715.  
  716.        0      2     WORD        Magic value 'C0'
  717.        2      2     WORD        Packet type 4
  718.        4      2     WORD        Mount status (0 = unmount, 1 = mount)
  719.  
  720. Unmounting the drive using this packet type also destroys the encryption
  721. information held by the driver and forces all data still held in cache and disk
  722. buffers to be flushed to disk.  This is the only sure way to erase all the
  723. encryption information, as it wipes not only the actual keying information but
  724. also most of the data area used by the driver and any data in cache and disk
  725. buffers.  Merely sending an empty keying information packet will not perform
  726. this task.
  727.  
  728.  
  729. Packet 5 - Set/clear Quick-Unmount Hotkey Value
  730.  
  731. This packet is used to set the hotkey value which the SFS driver checks for to
  732. quickly unmount an SFS volume, or to clear the hotkey handling.  The packet
  733. layout is as follows:
  734.  
  735.     Offset  Size    Type        Description
  736.  
  737.        0      2     WORD        Magic value 'C0'
  738.        2      2     WORD        Packet type 5
  739.        4      2     WORD        Hotkey value (see below)
  740.  
  741. The hotkey which the driver checks for can be any combination of the alt key,
  742. control key, left shift, and right shift (referred to as the shift code), and
  743. an arbitrary keyboard scan code.  The recommended default value is a
  744. combination of the left and right shift keys.  This information is encoded in
  745. the hotkey WORD as follows:
  746.  
  747.   The high 8 bits contain the shift code.  This contains a set of bitflags
  748.   which specify the shift keys the driver checks for, possibly in addition to
  749.   an optional character code.  The values are:
  750.  
  751.         Shift key       Value (binary)      Value (hex)
  752.  
  753.            Alt             00001000             08
  754.          Control           00000100             04
  755.        Left Shift          00000010             02
  756.       Right Shift          00000001             01
  757.  
  758.   The encoding for the shift code portion of the default left+right shift
  759.   hotkey is therefore 00000011 binary or 03 hex.
  760.  
  761.   The low 8 bits contain an optional keyboard scan code which the driver will
  762.   check for in addition to the shift code.  This value is used in combination
  763.   with the shift code to specify a key combination to the driver, so that for
  764.   example Alt-Z would be used as the quick-unmount hotkey, although care should
  765.   be taken to ensure that none of a large number of existing special key
  766.   combinations is reused for this.
  767.  
  768.   If the low 8 bits contain zeroes, the driver does not check for a keyboard
  769.   scan code in addition to a shift code.  The encoding for the keyboard scan
  770.   code portion of the default left+right shift hotkey is therefore 00000000
  771.   binary or 00 hex.
  772.  
  773.   The overall value is the combination of the shift code and keyboard scan
  774.   code, or 0300 hex for the default hotkey.
  775.  
  776. Specifying a value of 0 in this word will disable hotkey checking in the
  777. driver.
  778.  
  779. The hotkey quick-unmount is handled by hooking the int 9h keyboard interrupt.
  780. The interrupt handler which performs this task is installed either when the
  781. driver is loaded (if there is a volume to be mounted or a hotkey code is
  782. specified), or when mountsfs is run (which transmits a quick-unmount control
  783. packet to the driver).  The interrupt handler checks for the programmed hotkey
  784. and unmounts the volume if it is detected.  Subsequent quick-unmount control
  785. packets can be sent to the driver to change the actual hotkey value.  Sending a
  786. value of 0 will disable hotkey checking and deinstall the keyboard interrupt
  787. handler.
  788.  
  789.  
  790. Packet 6 - Set/clear Timed Unmount Value
  791.  
  792. This packet is used to set the unmount time after which an SFS volume is
  793. unmounted if no accesses are made to it.  The packet layout is as follows:
  794.  
  795.     Offset  Size    Type        Description
  796.  
  797.        0      2     WORD        Magic value 'C0'
  798.        2      2     WORD        Packet type 5
  799.        4      2     WORD        Timeout value in minutes before unmount
  800.                                 takes place
  801.  
  802. Specifying a value of 0 as the timeout value will disable the timed unmount
  803. feature in the driver.
  804.  
  805. The timed unmount is handled by hooking the int 1Ch timer interrupt.  The
  806. interrupt handler which performs this task is installed either when the driver
  807. is loaded (if a timeout value is specified at this time), or when mountsfs is
  808. run and a timeout value is specified (which transmits a timed unmount control
  809. packet to the driver).  The interrupt handler decrements the timer and unmounts
  810. the volume if it expires.  The timer is reset every time a media check packet
  811. is received by the driver, which allows normal DOS accesses to be detected but
  812. doesn't cause false triggering due to device driver control functions.
  813. Subsequent timed unmount control packets can be sent to the driver to change
  814. the actual timeout value for a volume.  Sending a value of 0 will disable the
  815. timer and, if no more volumes have timers set, deinstall the timer interrupt
  816. handler.
  817.  
  818.  
  819. Controlling the Driver
  820.  
  821. The SFS driver is initialized by sending it a series of control packets giving
  822. the disk information, the keying information, the drive number and logical
  823. volume offset to access, the read/write status, and finally the mount command.
  824. The sequence of operations for mounting a volume is as follows:
  825.  
  826.     driveNumber <- find SFS drive number as outlined above;
  827.     ioctlWrite( driveNumber, PACKET_SET_DISKINFO, \
  828.                 disk information - packet type 0 );
  829.     ioctlWrite( driveNumber, PACKET_SET_KEYINFO, \
  830.                 keying information - packet type 1 );
  831.     ioctlWrite( driveNumber, PACKET_SET_READONLY, \
  832.                 read-only status - packet type 2 );
  833.     ioctlWrite( driveNumber, PACKET_SET_DRIVENO, \
  834.                 drive to mount and vol.offs - packet type 3 );
  835.     ioctlWrite( driveNumber, PACKET_SET_MOUNTSTATUS, \
  836.                 mount status TRUE - packet type 4 );
  837.  
  838. To mount a new volume on the same drive:
  839.  
  840.     driveNumber <- find SFS drive number as outlined above;
  841.     ioctlWrite( driveNumber, PACKET_SET_KEYINFO, \
  842.                 keying information - packet type 1 );
  843.     ioctlWrite( driveNumber, PACKET_SET_MOUNTSTATUS, \
  844.                 mount status TRUE - packet type 4 );
  845.  
  846. To unmount a volume, erasing the keying information held by the device driver:
  847.  
  848.     driveNumber <- find SFS drive number as outlined above;
  849.     ioctlWrite( driverNumber, PACKET_SET_MOUNTSTATUS, \
  850.                 mount status FALSE - packet type 4 );
  851.  
  852.  
  853. Interfacing with mountsfs
  854. -------------------------
  855.  
  856. In order to facilitate the use of SFS with other software such as graphical
  857. front-ends, mountsfs can be run in batch mode in which it accepts abbreviated
  858. forms of the usual commands and outputs more complex results to fixed-record
  859. data files instead of the screen.
  860.  
  861.  
  862. Controlling mountsfs in Batch Mode
  863.  
  864. In order to enable these features, the first option given to mountsfs must be
  865. the keyword `batch'.  This allows it to recognise alternative single-letter
  866. forms of the normal commands.  These single-letter options and their equivalent
  867. commands are as follows:
  868.  
  869.     Letter      Full command
  870.  
  871.       f         user file
  872.       h         hotkey
  873.       i         info or informaion
  874.       n         user name
  875.       p         password entry
  876.       s         status
  877.       t         timeout
  878.       u         unmount
  879.       v         volume name
  880.  
  881. The volume name, hotkey, timeout, user name, and user file options must be
  882. followed by the appropriate extra information in the usual format.  The
  883. password entry option should be followed by the password for the encrypted
  884. volume.  For example to mount the volume "Test" with a quick-unmount hotkey of
  885. Ctrl-Alt-Z, an auto-unmount timeout of 10 minutes, and a password of "secret
  886. data" the command would be:
  887.  
  888.     mountsfs batch vTest hCtrlAltZ t10 "psecret data"
  889.  
  890. which is equivalent to the usual:
  891.  
  892.     mountsfs vol=test hotkey=ctrlAltZ timeout=10
  893.  
  894.  
  895. mountsfs Output in Batch Mode
  896.  
  897. During normal operation mountsfs may print several lines of information to the
  898. screen giving details on the status of the operation being performed and
  899. details on currently mounted and unmounted SFS volumes.  When mountsfs is run
  900. in batch mode, this information is written to a fixed-record data file named
  901. "sfs.tmp" instead of to the screen.  The location of the file is given by the
  902. "TMP" environment variable; if this variable does not exist, the file is
  903. written to the root directory of the C: drive.  If the TMP environment variable
  904. points to a drive without a path, the file is written to the root directory of
  905. that drive.  Thus if the TMP environment variable were set as:
  906.  
  907.     set tmp=e:\data\
  908.  
  909. then mountsfs would output the results of the status or info/information
  910. command to the file "e:\data\sfs.tmp".  If the variable were set as:
  911.  
  912.     set tmp=a:
  913.  
  914. then mountsfs would output its data to the file "a:\sfs.tmp".
  915.  
  916. The mountsfs output is written to the file as a series of fixed records.  Each
  917. record is in ASCII text format with individual fields beginning on new lines,
  918. making parsing by external software a simple task.  All control fields are in
  919. uppercase text.  The exact record format is determined by the record type which
  920. is specified in the first line.  In most cases the only record written will be
  921. the result from the mountsfs execution, although the status and
  922. info/information commands produce one or more extra output records which are
  923. detailed in the section "The Status and Info Commands in Batch Mode" below.
  924.  
  925. The mountsfs result record is laid out as follows:
  926.  
  927.     Field               Field contents
  928.  
  929.     Record type         "RESULT"
  930.     Success status      "TRUE" or "FALSE"
  931.     Error message       <string : error message, or empty string>
  932.  
  933. The record type field identifies the following record as being a mountsfs
  934. result record.
  935.  
  936. The success status field gives the success status of the mountsfs command.  A
  937. value of "TRUE" indicates the command succeeded, a value of "FALSE" indicates
  938. the command failed.
  939.  
  940. The error message field gives the error message generated by mountsfs if the
  941. success status field is set to FALSE, or an empty string if the success status
  942. field is set to TRUE.
  943.  
  944. A successful mountsfs command result record would be as follows:
  945.  
  946.     Field                   Field data
  947.  
  948.     Record type             RESULT
  949.     Success status          TRUE
  950.     Error message
  951.  
  952. A failed mountsfs command result record might be as follows:
  953.  
  954.     Field                   Field data
  955.  
  956.     Record type             RESULT
  957.     Success status          FALSE
  958.     Error message           Cannot find SFS driver
  959.  
  960.  
  961. The Status and Info Commands in Batch Mode
  962.  
  963. Apart from the result record, mountsfs produces two other types of output
  964. records, the output from a status command and the output from an info/
  965. information command.  As with the RESULT record, each record is in ASCII text
  966. format with individual fields beginning on new lines, making parsing by
  967. external software a simple task.  All control fields are in uppercase text.
  968. The exact record format is determined by the record type which is specified in
  969. the first line.  This is either "STATUS" for the output from a status command,
  970. or "INFORMATION" for the output from an info/information command.
  971.  
  972. The status command output record is laid out as follows:
  973.  
  974.     Field               Field contents
  975.  
  976.     Record type         "STATUS"
  977.     Unit number         <number : drive unit number>
  978.     Mount status        "TRUE" or "FALSE"
  979.     Volume name         <string : volume name, or empty string>
  980.     R/W access allowed  "TRUE" or "FALSE"
  981.     Drive letter        <character : uppercase driver letter>
  982.     Hotkey              <Ctrl, Alt, LeftShift, RightShift = 'c', 'a', 'l', 'r'>
  983.                         <Letter = uppercase letter. Example: Ctrl-Alt-Z = "caZ">
  984.                         <or "FALSE">
  985.     Timeout total time  <number : time in minutes, or "FALSE">
  986.     Timeout time left   <number : time in minutes, or "FALSE">
  987.  
  988. The record type field identifies the following record as being from the output
  989. of the status command.
  990.  
  991. The unit number field is the drive unit number used by the SFS driver.
  992.  
  993. The mount status field contains "TRUE" if there is a volume mounted, or "FALSE"
  994. if there are no volumes mounted.  If this field contains the value "FALSE" then
  995. the following fields will contain null values (either the value "FALSE" or
  996. blank fields as appropriate).
  997.  
  998. The volume name field contains the name of the volume.  This may contain any
  999. type of character, or may be an empty string if no volume name is present.
  1000.  
  1001. The R/W access allowed field contains "TRUE" if read/write access to the volume
  1002. is allowed, or "FALSE" if write access is disabled and the volume is mounted
  1003. read-only.
  1004.  
  1005. The drive letter field contains the uppercase drive letter which the mounted
  1006. SFS volume corresponds to.
  1007.  
  1008. The hotkey field contains the quick-unmount hotkey value or "FALSE" if none is
  1009. set.  The shift keys (if any) are given in lowercase and the ASCII key value
  1010. (if any) is given in uppercase.  The shift key codes are Ctrl = 'c', Alt = 'a',
  1011. leftShift = 'l', rightShift = 'r'.  These are followed by the ASCII key value,
  1012. if there is one.  Thus the code for the default quick-unmount hotkey
  1013. combination leftShift-rightShift would be "lr", and the code for the hotkey
  1014. combaination Ctrl-Alt-Z would be "caZ".
  1015.  
  1016. The timeout total time and timeout time left fields contain either the
  1017. auto-unmount total time in minutes and the time left before the unmount takes
  1018. place in minutes, or the control string "FALSE" if no timeout is set.
  1019.  
  1020. A typical status command output record might be as follows:
  1021.  
  1022.     Field                   Field data
  1023.  
  1024.     Record type             STATUS
  1025.     Unit number             0
  1026.     Mount status            TRUE
  1027.     Volume name             Encrypted data
  1028.     R/W access allowed      TRUE
  1029.     Drive letter            G
  1030.     Hotkey                  lr
  1031.     Timeout total time      15
  1032.     Timeout time left       4
  1033.  
  1034. This would then usually be followed by a RESULT record.
  1035.  
  1036. The information command output record is laid out as follows:
  1037.  
  1038.     Field               Field contents
  1039.  
  1040.     Record type         "INFORMATION"
  1041.     Volume name charset <string : character set name, or "FALSE">
  1042.     Volume name         <string : volume name, or empty string>
  1043.     Volume date         <string : date in YYMMDDHHMMSS format>
  1044.     Volume ID           <number : volume serial number>
  1045.     Volume size         <number : volume size in kilobytes, or "FALSE">
  1046.     Filesystem type     <string : filesystem type, or "FALSE">
  1047.     Mount ID            <string[8] : mount ID, or "FALSE">
  1048.     Multiuser access    "TRUE" or "FALSE"
  1049.     Mount status        <character : uppercase driver letter, or "FALSE">
  1050.     Fast access mode    <number : access mode, or "FALSE">
  1051.     Current access mode <number : access mode, or "FALSE">
  1052.     Timeout             <number : timeout in minutes, or "FALSE">
  1053.  
  1054. The record type field identifies the following record as being from the output
  1055. of the info/information command.
  1056.  
  1057. The volume name character set field contains the name of the character set used
  1058. in the volume name.  This is either "ISO 646", "ISO 8859-1", "ISO 8859-2", "ISO
  1059. 8859-3", "ISO 8859-4", "ISO 8859-5", "ISO 8859-6", "ISO 8859-7", "ISO 8859-8",
  1060. "ISO 8859-9", or "FALSE" if the character set is unknown.
  1061.  
  1062. The volume name field contains the name of the volume.  This may contain any
  1063. character from the character set given in the Volume name character set field,
  1064. or may be an empty string if no volume name is present.
  1065.  
  1066. The volume date field contains the volume date in YYMMDDHHMMSS (two-digit year,
  1067. month, day, hour, minute, second) format.
  1068.  
  1069. The volume ID field contains the volume serial number.
  1070.  
  1071. The volume size field contains the volume size in kilobytes, or "FALSE" if the
  1072. volume is removable media.
  1073.  
  1074. The filesystem type field contains the name of the filesystem the volume
  1075. contains.  This is either "DOS", or "FALSE" if the filesystem is unknown.
  1076.  
  1077. The mount identifier field contains the 8-character mount identifier for the
  1078. volume if the volume is on a fixed disk, or "FALSE" if the volume is on a
  1079. removable disk and no mount at system startup is possible.
  1080.  
  1081. The multiuser access field contains "TRUE" if multiuser access to the volume is
  1082. possible or "FALSE" if only single-user access is possible.
  1083.  
  1084. The mount status field contains the uppercase drive letter which the mounted
  1085. SFS volume corresponds to if the volume is mounted, or "FALSE" if it is
  1086. unmounted.
  1087.  
  1088. The fast access mode field contains the fast disk access mode which SFS will
  1089. use if possible when accessing this volume, or "FALSE" if the default (slower)
  1090. access mode will be used.  The current access mode contains the actual access
  1091. mode being used to access the volume, or "FALSE" if the default (slower) access
  1092. mode is being used.
  1093.  
  1094. The timeout field contains the default time in minutes before a volume is
  1095. auto-unmounted.  This value may be overridden by mountsfs or the SFS driver.
  1096.  
  1097. The information command output records corresponding to the volumes given in
  1098. the section "Mounting an SFS Volume" above would be as follows:
  1099.  
  1100.     Field                   Field data
  1101.  
  1102.     Record type             INFORMATION
  1103.     Volume name charset     ISO 646
  1104.     Volume name             Data backup
  1105.     Volume date             931101101301
  1106.     Volume ID               1234
  1107.     Volume size             FALSE
  1108.     Filesystem type         DOS
  1109.     Mount ID                FALSE
  1110.     Multiuser access        FALSE
  1111.     Mount status            FALSE
  1112.     Fast access mode        FALSE
  1113.     Current access mode     FALSE
  1114.     Timeout                 FALSE
  1115.     Record type             INFORMATION
  1116.     Volume name charset     ISO 646
  1117.     Volume name             Personal financial records
  1118.     Volume date             930906112219
  1119.     Volume ID               177545
  1120.     Volume size             10000
  1121.     Filesystem type         DOS
  1122.     Mount ID                03A12F7B
  1123.     Multiuser access        FALSE
  1124.     Mount status            E
  1125.     Fast access mode        FALSE
  1126.     Current access mode     FALSE
  1127.     Timeout                 30
  1128.     Record type             INFORMATION
  1129.     Volume name charset     ISO 646
  1130.     Volume name             Encrypted data disk
  1131.     Volume date             930412221700
  1132.     Volume ID               69231461
  1133.     Volume size             42456
  1134.     Filesystem type         DOS
  1135.     Mount ID                42DD2536
  1136.     Multiuser access        TRUE
  1137.     Mount status            FALSE
  1138.     Access mode             1
  1139.     Current access mode     1
  1140.     Timeout                 10
  1141.  
  1142. This would then usually be followed by a RESULT record.
  1143.  
  1144. In order to make use of these records, the controlling program should invoke
  1145. mountsfs in batch mode with either the `s' status or `i' information command.
  1146. mountsfs will run and, if no errors are encountered, write its output to the
  1147. output file.  The controlling program can then read the data from the file,
  1148. delete the file, and handle the information as appropriate.
  1149.  
  1150.  
  1151. Selected Source Code
  1152. --------------------
  1153.  
  1154. This section contains a walkthrough of selected portions of the source code
  1155. (mainly the encryption-related parts) to allow the verification of its
  1156. correctness and to help people wishing to write SFS-compatible software.
  1157.  
  1158. [!!!! Not in the early releases to save space and because I haven't had
  1159.       time to add it yet, should be in a later version !!!!]
  1160.  
  1161.  
  1162. Future Work
  1163. -----------
  1164.  
  1165. The following ideas may be incorporated into future versions of SFS if
  1166. requested by users.  In addition reasonable requests for other improvements may
  1167. also find their way into SFS.
  1168.  
  1169.  - Improve error recovery for the encryption process.  This is somewhat
  1170.    difficult, and will probably involve keeping a copy of status information
  1171.    and the track currently being encrypted on a local volume to allow a restart
  1172.    in the case of a power failure.  There are problems inherent in this as it
  1173.    involves storing sensitive data in a disk file, and will slow down the
  1174.    processing considerably due to the need to write each track to two
  1175.    physically separate disk volumes instead of one continuous one.  A partial
  1176.    solution is to keep the status information (simply an index of the disk
  1177.    section currently being encrypted) in the volume header while mksfs is
  1178.    running and provide some sort of restart option if power is lost, although
  1179.    what happens if power dies halfway through writing a track is uncertain.
  1180.  
  1181.  - A plug-in card which contains a BIOS extension which hooks int 13h and
  1182.    encrypts and entire physical disk (not just one disk volume), from the
  1183.    master boot record at the start to the very last sector at the end.  This
  1184.    means all disk I/O must be done via int 13h and won't work on all systems.
  1185.    Cost for the card is estimated to be about $80-$100 for the basic version an
  1186.    up to $200 for the full hardware version whose throughput it significantly
  1187.    higher than the basic version.
  1188.  
  1189.  
  1190. Recommended Reading
  1191. -------------------
  1192.  
  1193. In recent years a large number of books and articles on crytography have
  1194. appeared.  Many of these are beyond the level of anyone with a casual interest
  1195. in the subject, but a good overview is given by Dorothy Dennings (now somewhat
  1196. dated) "Cryptography and Data Security", published by Addison-Wesley in 1982
  1197. (ISBN 0-201-10150-5).  Bruce Schneier's much more recent "Applied
  1198. Cryptography", published by John Wiley and Sons in 1993 (ISBN 0-471-59756-2),
  1199. is probably the best single text on cryptography currently available, and is
  1200. recommended reading for anyone wanting more information on the principles
  1201. behind SFS.  This book also contains a large list of references to more
  1202. information on all manner of encryption algorithms, protocols, and technology.
  1203. Voydock and Kent's tutorial "Security Mechanisms in High-Level Network
  1204. Procotols", published in the ACM Computing Surveys Vol.15, No.2 (June 1983)
  1205. provides a good overview of design considerations for encryption systems.
  1206.  
  1207. The algorithms and techniques used in SFS are laid down in the following
  1208. national and international standards:
  1209.  
  1210.     ANSI X3.106, "American National Standard for Information Systems - Data
  1211.         Encryption Algorithm - Modes of Operation"
  1212.  
  1213.     ANSI X9.30 Part 2, "The Secure Hash Algorithm (SHA)"
  1214.  
  1215.     Australian Standard AS 2805.5.2, "Electronic Funds Transfer - Requirements
  1216.         for Interface", Part 5.2, "Ciphers - Modes of operation for an n-bit
  1217.         block cipher algorithm"
  1218.  
  1219.     ISO 10116:1991, "Information technology - Modes of operation for an n-bit
  1220.         block cipher algorithm"[1]
  1221.  
  1222.     ISO 10126-2:1991, "Banking - Procedures for message encipherment
  1223.         (wholesale) - DEA Algorithm"[1]
  1224.  
  1225.     NBS FIPS pub. 81, "DES Modes of Operation", 1980[2]
  1226.  
  1227.     NIST FIPS pub. 180, "Secure Hash Standard", 1993[2]
  1228.  
  1229. Information on the weaknesses of some cryptosystems are published in a variety
  1230. of places.  The largest publicly available sources of information are the
  1231. cryptography conference proceedings which are part of the Springer-Verlag
  1232. "Lecture Notes in Computer Science" series.  Eli Biham and Adi Shamir's
  1233. "Differential Cryptanalysis of the Data Encryption Standard", also published by
  1234. Springer-Verlag (ISBN 0-387-97930-1), gives information on the resistance to
  1235. attack of a number of block ciphers.
  1236.  
  1237. Charles Pfleegers book "Security in Computing", published by Prentice Hall in
  1238. 1989 (ISBN 0-13-798943-1) provides a thorough overview of computer security
  1239. techniques, including coverage of more obscure areas such as ethical issues.
  1240.  
  1241. A good technical coverage of smart cards can be found in "Smart Card 2000: The
  1242. Future of IC Cards", published by North-Holland in 1988 (ISBN 0-444-70545-7).
  1243. The physical and interface characteristics of smart cards are covered in the
  1244. following international standard:
  1245.  
  1246.     ISO 7816:1991, "Identification cards - Integrated circuit card with
  1247.         contacts"[1]
  1248.  
  1249. Finally, James Bamford's "The Puzzle Palace", published by Houghton-Mifflin in
  1250. 1982, is a good source of information on the operation of the NSA, albeit
  1251. slightly dated (it predates the widespread availability of encryption for
  1252. personal computers, for example).
  1253.  
  1254. This list only scratches the surface of the full range of cryptographic and
  1255. security literature available - a very detailed bibliography can be found in
  1256. the "Applied Cryptography" book.
  1257.  
  1258. Footnote [1]: These publications are available for a horribly high price from
  1259.               ISO-affiliated national standards bodies in most countries.
  1260.  
  1261. Footnote [2]: These publications are available from the National Technical
  1262.               Information Service, Springfield, Virginia 22161.  NTIS will take
  1263.               telephone orders on +1 (703) 487-4650 (8:30 AM to 5:30 PM Eastern
  1264.               Time), fax +1 (703) 321-8547.  For assistance, call +1 (703)
  1265.               487-4679.
  1266.  
  1267.  
  1268.  
  1269. Using SFS
  1270. ---------
  1271.  
  1272. In general SFS is free for personal (private) use.  However if you find SFS of
  1273. use then in order to allow continued development of and enhancements to SFS, in
  1274. particular the creation of more user-friendly versions of mksfs and mountsfs,
  1275. of versions for other systems, of a low-cost plug-in card containing whole-disk
  1276. encryption firmware, and the replacement of the drive I fried testing SFS, a
  1277. donation of $25 would be appreciated.  Alternatively, the donation can be used
  1278. to cover the legal costs of those people involved in the current US government
  1279. investigation of the PGP encryption program.
  1280.  
  1281. Use of SFS in a commercial, government, or institutional environment or for
  1282. business purposes is allowed for free for 30 days to allow it to be evaluated.
  1283. After this period it should be registered for further use.  The registration
  1284. fee covers use of SFS on any one machine at any one time (so you could, for
  1285. example, use SFS on a machine at work and keep a copy on your notebook PC for
  1286. use while travelling).
  1287.  
  1288. If you decide to send a donation or registration, please specify whether you'd
  1289. like it to be used for further SFS development work or if it is to go into the
  1290. PGP legal fund.  Cheques or money orders can be sent to:
  1291.  
  1292.         Peter Gutmann
  1293.         24 Durness Pl.
  1294.         Orewa
  1295.         Auckland
  1296.         New Zealand
  1297.  
  1298. I can also be contacted through email at (among others) the following
  1299. addresses:
  1300.  
  1301.         pgut1@cs.aukuni.ac.nz
  1302.         p.gutmann@cs.auckland.ac.nz
  1303.         peterg@kcbbs.gen.nz
  1304.  
  1305. with the first address being the preferred one.  Finally, the fastest way to
  1306. contact me is by phone between about 10am and 1am at the following number
  1307. (remembering that NZ local time is GMT+13, so we're usually about 18-20 hours
  1308. ahead of the US and about 12 hours ahead of Europe):
  1309.  
  1310.         +64 9 426-5097
  1311.  
  1312.  
  1313. Testimony from one of our satisfied customers:
  1314.  
  1315.  "I hear this crash and I find a rock, wrapped in paper, next to my living room
  1316.   window.  I open up the note and it says `You want it in writing? You got it.
  1317.   Next time, use a *real* encryption program.  SFS.  We know where you live'".
  1318.  
  1319.   So why aren't *you* using SFS?
  1320.  
  1321. Here's what reviewers have been saying about SFS:
  1322.  
  1323.  "Version 1.1 has several of the advanced features recommended in version 1.0,
  1324.   but not all of the ones I'd like to see in version 1.2.  So, it's pretty good
  1325.   except when it's not.  Three stars.
  1326.  
  1327.   You probably won't use half the features anyway.  I'm a little ticked off
  1328.   that it clashes with my most exotic memory-resident programs, but otherwise
  1329.   the software runs just fine on my Turbo Rambuster 586.  It will probably run
  1330.   like molasses on your 386SX.
  1331.  
  1332.   It's great value at $25, and I recommend you register it, although that's
  1333.   easy for me to say because reviewers get freebies".
  1334.  
  1335.  
  1336. Credits
  1337. -------
  1338.  
  1339. Thanks to the readers of comp.os.msdos.programmer and comp.os.linux.development
  1340. and in particular Jouni Kosonen, for their valuable advice with low-level DOS
  1341. disk handling and organization, and the users of the Enigma BBS, in particular
  1342. Arne Rohde, for helping test-run several early versions of the low-level disk
  1343. handling code on various drive configurations and for providing useful advice
  1344. on the vagaries of the PC's disk handling.   Thanks also to Steven Altchuler
  1345. for performing all sorts of dangerous tests on SFS volumes and for his heroic
  1346. efforts in finding the obscure mountsfs bug, and to Vadim Vlasov for help with
  1347. various thorny problems with low-level disk and device driver programming.
  1348.  
  1349. Matthias Bruestle (the greatest chemist of all time and space) provided
  1350. valuable feedback on assorted problems in mksfs and mountsfs, and risked his
  1351. disk drives testing the SFS driver and other SFS software.  At the behest of
  1352. the author he also risked imprisonment for Datenvergewaltigung by letting mksfs
  1353. near his Linux partition.
  1354.  
  1355. Colin Plumb made noises about various problems with CFB-mode encryption,
  1356. corrected me when I tried to explain the need for encrypted IV's in email at
  1357. 3am, and provided much useful feedback on SFS's operation in general, including
  1358. the very elegant solution to the CFB-mode encryption problem and help with the
  1359. disk overwriting method.
  1360.  
  1361. Vesselin Bontchev sent in long lists of suggested improvements to SFS, and
  1362. provided an ongoing commentary on features and ideas for the software (it seems
  1363. half the functionality provided by SFS is due to his suggestions).  Ralf
  1364. Brown's interrupt list provided help with the haze of obscure interrupts used
  1365. by mksfs in its quest for random information.
  1366.  
  1367. Thanks to John Huttley for the loan of a SCSI controller, Peter Shields for the
  1368. loan of a SCSI cable, Stuart Woolford for the loan of a SCSI drive which didn't
  1369. work, and John Huttley for the loan of a SCSI drive which did, in order to get
  1370. the SCSI interface code for SFS going.
  1371.  
  1372. Peter Conrad typset the entire set of SFS docs into LaTeX format.
  1373.  
  1374. The Beerdigungsinstitut Utzmann (erstes Erlanger Beerdigungsunternehmen) helped
  1375. clean up the casualties from the SFS beta-testing.  Finally, Tony, Geezer,
  1376. Bill, Ozzy, Ron, and Grandos helped me stay awake during many long nights of
  1377. debugging low-level disk access code and encryption routines.
  1378.  
  1379. Various other people have at various times offered help and suggestions on
  1380. getting SFS going.  My thanks go to them also.
  1381.  
  1382.  
  1383. Warranty
  1384. --------
  1385.  
  1386. 1. Customer Obligations
  1387.  
  1388. 1.1. Customer assumes full responsibility that this program meets the
  1389.      specifications, capacity, capabilities, and other requirements of said
  1390.      customer, and agrees not to bother the author if the program does not
  1391.      perform as expected, or performs other than expected, or does not perform
  1392.      at all.
  1393.  
  1394. 1.2. Customer assumes full responsibility for any deaths or injuries that may
  1395.      result from the normal or abnormal operation of this program.  In the
  1396.      event of casualties exceeding 1000 persons or property damage in excess of
  1397.      $10 million, customer agrees that he or she has stolen the program and we
  1398.      didn't even know he or she had it.
  1399.  
  1400. 1.3. Customer agrees not to say bad things about the program or the author to
  1401.      anyone claiming to be from "60 Minutes".
  1402.  
  1403.  
  1404. 2. Very Limited Warranty and Conditions of Sale
  1405.  
  1406. 2.1. For a period of 90 minutes, commencing from the time you first thought
  1407.      about getting this program, we warrant that this program may or may not be
  1408.      free of any manufacturing defects.  It will be replaced during the
  1409.      warranty period upon payment of an amount equal to the original purchase
  1410.      price plus $10.00 for handling.  This warranty is void if the program has
  1411.      been examined or run by the user, or if the manual has been read.
  1412.  
  1413. 2.2. This program is sold on an AS WAS basis.  The author makes no warranty
  1414.      that it is, in fact, what we say it is in our propaganda, or that it will
  1415.      perform any useful function.  We have no obligation whatsoever other than
  1416.      to provide you with this fine disclaimer.
  1417.  
  1418. 2.3. Some countries do not allow limitations as to how long an implied warranty
  1419.      lasts, so we refuse to imply anything.
  1420.  
  1421. 2.4. There is an extremely small but nonzero chance that, through a process
  1422.      known as "tunnelling", this program may spontaneously disappear from its
  1423.      present location and reappear at any random place in the universe,
  1424.      including your neighbours computer system.  The author will not be
  1425.      responsible for any damages or inconvenience that may result.
  1426.  
  1427.  
  1428. 3. Limitation of Liability
  1429.  
  1430. 3.1. We have no liability or responsibility to the customer, the customers
  1431.      agents, our creditors, your creditors, or anyone else.
  1432.