I could not explain my concerns clearly enough about small block encryption (~LRW) outside of the disk drive, so here I try it again. (Because of protests, we did not discuss this in the last P1619 meeting.)
The purpose of the standard is to provide reasonable security for data at rest. In case of a disk drive doing LRW internally, we know of no other threat of comparable severity than theft of the disk drive, assuming that the drive locks up if the right key or password is not provided. Otherwise, there would be another severe threat: traffic analysis. An attacker, who temporarily gains control of the drive (night guard, intruder, colleague during lunch break, bribed technician) can make snapshots of the drive content, and can find the extent of the changes and their place with very good locality (16 bytes). If the drive does not lock up, when it receives the wrong key, but provides data decrypted with the wrong key, the attacker could re-encrypt the data with the key he provided to the drive, and gets the raw data, which is encrypted with the original key. If he does that often, he can perform traffic analysis. LRW is weak against it. If the drive denies access when a wrong key is provided, the attacker sees nothing. The drive remains locked, the LBA's hidden from the attacker. If he puts the magnetic platters on a spin stand, with expensive equipment he can get a snapshot, but it costs time and money, and the attack gets discovered. When the disk encryption keys are legitimately changed, the new key owner can read the old raw content of the disk (re-encrypting it in SW with his new keys), but the old content does not change any more, so there is no traffic to be analyzed. These mean that an encrypting disk drive needs two new feature sets: data encryption and access control. Both are complicated and both require new disk commands, new disk electronics, firmware, manufacturing tests, infrastructure, documentation, etc. If LRW is done in the controller (the other end of the wire) or even in SW, after temporarily connecting the drive to another computer, the raw data can be accessed and a traffic analysis performed, unless the disk drive still provides access control. In this case, half of the changes are still needed in the disk design and the password/key information has to be provided to both the encryptor and the disk drive. (The current ATA security is not sufficient, because the password is customarily stored in the drive, there are issues with sleep mode of the host PC, diagnostic/debug modes of the drive, the BIOS needs to cooperate, etc.) It is questionable if any disk manufacturer would provide disk drives with secure access control but no data encryption. Without it LRW in the controller or in SW is susceptible to traffic analysis, and so less secure than internal disk encryption. The picture would change somewhat with wide block encryption. If 4KB blocks are encrypted together, the locality of a change on disk can only be determined 256 times less accurately. In this view, reasonable security is only achieved in practice, if the encryption is done internally in the disk drive. There is no interoperability. In theory, the disk manufacturers could employ proprietary solutions, users won't be able to tell the difference. The key export part of the standard is for key archiving. You only want to use the key on one particular drive (to avoid comparison attacks), and you have to provide the key at its power up time in a short, simple manner (not with XML). In case the user forgets his password (and the master password, and the enterprise password, etc.), he might need to write it down and store it in a safe. Instead of a physical safe, a secure XML file can be used, and only the XML encryption key is stored in a physical safe. There is also the US export control problem. If a disk drive can encrypt data and provide it in raw, encrypted format, it can be used as an encryption device. These need export control clearance. If the encrypted data is not accessible, there are no problems with export. It is also an issue with encryption in the controller. The encrypted data can easily be diverted, and so the controller can be used as an encryption device. The value of the standard is: - Saves the disk manufacturers the work of designing a good encryption scheme themselves - Disk designers don't need to repeat the security analysis the IEEE standard went through - Assures users that high level of security is provided, improves trust - Assures users that there are no back doors left to their confidential information - Provides a uniform way of archiving disk keys or passwords Laszlo
