Hi Jim, I just asked our SCSI T10 guy about the possibility of T10 enforcing key uniqueness, and here's his response.
In general, it's really not easy to require the host to behave by rules that the device (i.e. tape drive) cannot enforce. For this reason, we would do well to add something to the P1619.1 standard that would account for this possibility. -Matt -----Original Message----- From: Paul Entzel Sent: Thursday, January 05, 2006 9:22 AM To: Matt Ball Cc: Paul Suhler Subject: RE: p1619.1 document (tape), draft version 0.4 T10 is a technical committee that produces information technology standards, not a police force. In the T10 standards we strive to whenever possible place requirements on the device server (the entity in the disk drive or tape drive) and not directly place requirements on the application client (the entity in the host computer). However, by placing requirements on the device server to "only accept commands like this" or to reject a command that sends parameter data that "doesn't look like that" we are indirectly placing requirements on the application client. If we were to try to add enforcement of the type you are asking it obviously can not be in the device server, since a device server in one device has no idea what any other device server in a different device is doing. We would have to place a direct requirement onto the application client. We can do that, it's just not common. However, I don't think that's good enough. The application client could only comply if it had sole knowledge of the encryption key. More than likely, this will not be the case. I expect that in many cases the encryption keys will be managed by a third entity and will be retrieved from this entity by the application client and then sent to the drive for use. In this environment, the key management entity, whatever that is, is the only thing that can enforce your rule. And this thing is not something being defined or even referenced in the T10 standards. Paul -----Original Message----- From: Matt Ball Sent: Thursday, January 05, 2006 8:50 AM To: Paul Entzel Cc: Paul Suhler Subject: FW: p1619.1 document (tape), draft version 0.4 Hi Paul, What are your thoughts about T10 enforcing a policy of making sure that an application never sends the same key to two different devices? I'm assuming that there's really no good way to enforce this. -Matt -----Original Message----- From: james hughes [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 04, 2006 8:27 PM To: Matt Ball Cc: james hughes; Shai Halevi; SISWG Subject: Re: p1619.1 document (tape), draft version 0.4 This is indeed a very important issue. In the case of a T10 compliant application pushing a key down to an arbitrary drive which the application knows nothing about the vendor (that is using a proprietary nonce). We need to make sure that vendor A and B have a 0 chance of a collision. I would suggest there are two solutions. 1) we do nothing and tell T10 that they must make sure this never happens and emails like this need to occur in that working group. this abdicates the nonce collision to them. 2) since we allow the nonce to be vendor independent, we describe and endorse something like the following. I want to discuss this issue openly in the group and then decide. Based on that decision, we can then discuss methods. (especially since SHA-1 is under a significant amount of scrutiny and we can do better). Jim On Jan 4, 2006, at 9:01 PM, Matt Ball wrote: > Thanks Shai and Glen for getting this updated! > > I think the only big outstanding issue is that we need to find a > way to solve the problem of unique IVs across different vendors. > Jim, have you had a chance to looks at some of the options? I'd > like to get some discussion started before our next meeting in > February, so here are some comments (most coming from Fabio's > meetings of the December meeting): > > > Does anyone have a link to the NIST key derivation algorithm > draft? This could be a good candidate if it's somewhat useable. > If nothing else, it would provide a good starting point. > > > Just brainstorming here -- How about if we did something like this: > > NewKey = SHA-256(UserKey || 3-byte IEEE OUI || Vendor unique > information) > > That is, we concatenate the provided user key with the unique 3- > byte IEEE vendor ID, along with anything else that would be useful > for a vendor to include (product name, serial number, media ID, > etc). Of course, using a hashing function like this would reduce > the entropy of the 256-bit key by roughly 2/3 of a bit, but it > seems to me that 255.3 bits would still be enough security (anyone > think we need to keep the whole 256-bits of entropy?). By using a > hashing function we shouldn't need to worry about possible weak > keys (not that AES has any...). > > > Other ideas? The minutes mentioned that we could try using NIST > key wrap. Does anyone have a link to this as well? > > > Also, I've discovered that it may not be easy to guarantee a unique > nonce in all cases. For example, with some technologies it is > difficult to create a unique media ID because the tapes may have no > preformatting whatsoever (thus no way to store a unique media ID). > It is then up to the first drive that writes a tape to create a > media ID for that tape. The most promising approach so far is to > create a 64-bit random number and use that within the nonce. > Realistically speaking, a 64-bit random number would not reach its > birthday limit until somewhere around 4 billion tapes. This seems > to me like adequate protection for someone who has already lowered > their security standards by using the same key on multiple tapes. > > Would it be okay if we relaxed the 1619.1 specification to say that > the IV must only be unique for a given tape, and otherwise have a > high probability of being unique across different tapes? This > would make for a much more practical solution for the different > technologies. We could additionally add an advisory that the user > should generally not use the same key on multiple tapes. Thoughts? > > > Thanks, > -Matt > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Shai Halevi > Sent: Friday, December 23, 2005 6:55 PM > To: SISWG > Subject: p1619.1 document (tape), draft version 0.4 > > > Attached is another version the p1619.1 draft, modified by Glen and > myself. > > Following the discussion in the last meeting, we modified it to be > very permissive > in terms of what is written to tape and in what format. Also we > added a section > about authentication-only mode to reflect a request to put it > there. We need to > discuss, however, whether or not we really want it there (I > personally do not). > > Some editorial changes: the draft now talks about variable-length > block storage > rather than tape. Also, we tried to be consistent about using bytes > vs. bits to > specify length (we chose bytes). > > -- Shai
