>>a "wrong key behavior" can be beyond the scope The issue is rather: can the raw, encrypted data be read from the drive? Maybe, the standard could just say in the introduction that LRW is weak against traffic analysis, therefore, some means are necessary to restrict access to the encrypted data in situations, where an adversary could often gain physical access to the drive.
The consequence is that these unspecified means will be vendor specific. Features, like user authentication, access control, key management, key setup/transfer are more complex than the disk encryption, so the P1619 standard would only deal with a fraction of the issues of securing data at rest. Laszlo > -------- Original Message -------- > Subject: Re: wrong key behaviour > From: james hughes <[EMAIL PROTECTED]> > Date: Thu, December 22, 2005 7:00 pm > To: [EMAIL PROTECTED] > Cc: james hughes <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > > This unlocking becomes hard when there are a lot of partitions with > different keys that the drive does not know about... > > I would suggest that a "wrong key behavior" can be beyond the scope > of the work here. > > JIm > > On Dec 22, 2005, at 1:14 PM, [EMAIL PROTECTED] wrote: > > >>> If you make the data inaccessible unless the correct key is > >>> provided, then why bother with encryption at all? > > Without disk encryption if you change (reset) your password, the disk > > drive should be operational with the new password. You can just read > > the old content off the disk, that is, the disk has to be erased > > before > > reuse, which is a very slow and not full proof operation. > > > >>> It just protects the data in case someone removes the platters from > > the disk. > > If the data is in the clear on the disk, there could be a large number > > of attacks to bypass the access control, like temporarily connect the > > head signal to another controller (after spin-up), insert or remove > > data between the disk controller and the channel chip, force > > diagnostic > > mode or just induce random faults in the controller. If the data is > > encrypted with a key not stored in the drive, these attacks cannot get > > to the data. > > > >>> important to be able to read the data off the drive without > >>> giving the drive the key > > There could be situations, where traffic analysis based attacks are > > thwarted by some other means, like physical protection (a guard with a > > machinegun). Then you could allow unauthenticated data access, but not > > in personal or portable disks. If your application requires the > > ability > > to make backup without providing the encryption key, there is a simple > > solution: setup several authentication passwords. Some would lead to > > the encryption key (for normal use), some password don't (for data > > backup). > > > >>> some communications encryption scheme should be used > > When the wire is not completely inside the computer. Of course, in > > this > > case you need secure communication but there is no requirement there > > for keeping the length of the data. There are more types of attacks, > > but we have a larger arsenal to protect against them. > > > > Traffic analysis can be a threat even if the cable is in the box. As I > > explained several times, colleagues at lunchtime, janitor at night, > > intruder in weekends, etc. If someone can make several snapshots > > undetected, he can locate the changes made in the disk. In some cases > > (database, file system) the leak can be serious. > > > > Laszlo > >> -------- Original Message -------- > >> Subject: RE: wrong key behaviour > >> From: "Elliott, Robert (Server Storage)" <[EMAIL PROTECTED]> > >> Date: Thu, December 22, 2005 12:18 pm > >> To: <[EMAIL PROTECTED]> > >> > >> If you make the data inaccessible unless the correct key is provided, > >> then > >> why bother with encryption at all? It just protects the data in case > >> someone > >> removes the platters from the disk, which is a niche case. The ATA > >> style > >> SECURE LOCK password feature leaves the drive open after reset, but a > >> more > >> secure varient of that could be used (I think TCG is developing > >> something > >> along those lines). > >> > >> I think it's important to be able to read the data off the drive > >> without > >> giving the drive the key. This allows for disk copies and image > >> backups. > >> If the drive is encrypted with a key from the payroll department, > >> the IT > >> department can perform a backup without having to know the payroll > >> key. > >> > >> If concerned about security from the HBA to the drive, then some > >> communications encryption scheme should be used (Jim Hughes always > >> emphasizes the distinction between communications encryption and > >> storage encryption). > >> -- > >> Rob Elliott, [EMAIL PROTECTED] > >> Hewlett-Packard Industry Standard Server Storage Advanced Technology > >> https://ecardfile.com/id/RobElliott > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > >>> Behalf Of [EMAIL PROTECTED] > >>> Sent: Wednesday, December 21, 2005 11:42 AM > >>> To: SISWG > >>> Subject: RE: wrong key behaviour > >>> > >>>>> how does the drive know if the key it is given is wrong? > >>> There are other options, too. For example, a secure hash of the key > >>> could be stored in the drive for each key scope (a contiguous LBA > >>> range). Alternatively, a public key MAC. This later method has the > >>> advantage that an attacker cannot replace it arbitrarily, even if he > >>> rips up the drive. > >>> > >>> It is possible to store a disk key in the drive, which is > >>> hard to hack. > >>> It could be in some nonvolatile memory integrated with the crypto > >>> engine. To get it, you have to get inside of a 65...130 nm > >>> integrated > >>> circuit, use microelectrodes and try not to damage the circuit. A > >>> very > >>> expensive and slow process, which uncovers some secrets for only one > >>> drive. Nevertheless, storing all the keys on disk is not the best > >>> solution. > >>> > >>> Laszlo > >>> > >>>> -------- Original Message -------- > >>>> Subject: RE: wrong key behaviour > >>>> From: "Colin Sinclair" <[EMAIL PROTECTED]> > >>>> Date: Wed, December 21, 2005 12:04 pm > >>>> To: "SISWG" <[EMAIL PROTECTED]> > >>>> > >>>>> the drive must not return any data if the wrong key is given. > >>>> > >>>> Not being funny, but how does the drive know if the key it > >>> is given is wrong? Either > >>>> > >>>> (a) it keeps a copy of the key internally (easy to hack), or > >>>> > >>>> (b) it encrypts a special string and keeps that internally > >>> (in flash or on media), or > >>>> > >>>> (c) it must add a crpytographically safe integrity field > >>> computed over the plaintext on each sector > >>>> to tell if it has been decrypted correctly. This is just > >>> like adding authentication, and will add > >>>> overhead. It's probably not possible to rely on CRC because > >>> that isn't always there (vendor specific > >>>> additional sector information). > >>>> > >>>> I presume the only sensible method is (b)? > >>>> > >>>> Colin. > >>>
