RE: [kmip] Split Key proposal

["Burns, Robert" <Robert.Burns@thalesesec.com>]

Kelley,

Now, onto some of the technical thoughts I had with respect to performing key splits for payments use cases.

First, some observations -- although PCI supports key splits using Shamir, the reality is that the market has to fall to the lowest common denominator so the use-case should probably focus on the simple XOR case.  And speaking of lowest-common denominator, 2DES key is probably relevant to most of the industry at the moment. (Ugg....).

Next, something easy -- most standards require check values for the end key, and support optional check values for each component.  Based on that, might it be prudent to modify the current specification to support an optional 'CHECK VALUE' field on a key split object, and the subsequent splits?  I would guess this is relatively straight forward to affect from a spec standpoint -- we could support an optional check value type during creation/import such that it was clear how the check was performed.  In the current ANSI/PCI world, a 3 byte (6 hex digit) truncated encryption result using the key is prevalent, although NIST are asserting larger minimum sizes for truncated authentication data which may impact us in the future as the industry (HOPEFULLY) moves to stronger crypto primitives.  So being crypto-agile here is probably prudent by supporting a user supplied check value 'type' attribute -- so perhaps the CHECK VALUE is a struct?

Finally, the hard bit -- one thing that is not clear to me from KMIP is specifically how one might apply ACLs to the derived split objects?  It is not an explicit technical requirement, per-se, but I am just trying to think about how to solve the problem associated with satisfying the "spirit of the law" with respect to having a defensible story for limiting access to the split components.  Do we have any current use cases describing how a key split would work?  Either from entering the components separately, or by having the KS generate the split itself.  Your proposal is fairly clear, but I'm having trouble connecting the dots in a KMIP sense.

Generally speaking, we need to give our customers a defensible story when it comes to external controls for each component; they need to be able to pass an audit which shows how they limit exposure of the individual key components and provide confidence that no one person had access to more than one component.

Other than those two points, I think the technical proposal hits the major points necessary for a payments world.

Thoughts?

Thanks,

Bob

Robert Burns
Security Principal
THALES Information Systems Security 
Phone: 954.888.6215
robert.burns@thalesesec.com


> -----Original Message-----
> From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On
> Behalf Of Kelley Burgin
> Sent: Thursday, April 04, 2013 9:43 AM
> To: kmip@lists.oasis-open.org
> Subject: [kmip] Split Key proposal
> 
> Here is the latest on split keys for discussion today: I'd like to get an idea of
> whether it's worth proceeding with the following. It seems to be the most
> reasonable approach until we have ACLs in KMIP. The benefit of Create Split
> Key is pushing the algorithmic complexity of key splitting to the server. The
> benefit of Join Split Key is the ability for a client to combine and use a key
> without the key being exposed to the client.
> 
> Create Split Key: returns the UUIDs of the splits. Client side distribution of
> splits. No ACLs. Links can be discussed.
> 
> Join Split Keys: takes as input a list of UUIDs corresponding to splits and
> returns a new UUID for the key created by combining the splits. This is a new
> operation to be considered with or separate from Create Split Key.
> 
> Kelley
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php