OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [kmip] Split Key proposal


> I don't see any problem adding an optional field for CHECK VALUE, but I do
> have a few questions about the technical details:
> 
> 1. How is the CHECK VALUE used? In a Register? Get?
[<[Bob]>] The check value should be considered a read-only value which is immutable.  It can either be fixed, or calculated on the fly each time it is requested.  My thought is that it can be retrieved via a 'Get Attributes' call.  The type of data could be string as it is generally shown as 6 ASCII characters which is the HEXASCII encoding of the 3 MSB resulting from ECB encrypting a plaintext block of all zeros (e.g. for DES, ECB encrypt 64 bit buffer of all zeros, and return bytes[0-2], then convert to HEXASCII).

> 
> 2. What value is encrypted to obtain the CHECK VALUE? I don't see the point
> unless it's an unpredictable or implicit value
[<[Bob]>] The intent is for the end user to be able to manually verify that the resulting joined key has been reformed correctly.  Basically a final verification of whether or not everyone entered their components correctly.  The standard also allows each component to compute a check value as well, although I'm not aware of many systems which output check values for each component -- but KMIP should support it, I think.

Another thing to keep in mind is that ANSI X9.24 is DES focused (bleh), so that means when generating keys and components which will be used to generate check values, we have to force odd parity PRIOR to calculating the check value.  The implication then is that all components of DES key splits (2DES & 3DES included) will be odd-parity adjusted.

> 
> > 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.
> 
> I see the current benefit of a Split Key operation in the context of KMIP
> aware servers and clients, where the clients who end up using the splits can
> register them with the server, and the creator of the splits can destroy the
> initial copies for auditing purposes. Until KMIP allows an object creator to
> assign ownership to the object (I create a split key and tell the server you're
> the only one who can access it), I don't see a solution to your auditing issue in
> cases where a client who ends up using a split is not KMIP aware and the
> server generates the splits. However, from what I can tell based on the
> information you've given, your clients are capable of generating and
> distributing the splits (the example where PC1 = KS in your other mail), which
> sounds like the best solution for now.
>
[<[Bob]>] Yes, as a generalization in the financial world, there are only two actors -- specifically the two bits of hardware which need to share keys.  One will generate the splits and distribute them securely (either by having separate individuals capture and secure the component values, or by printing 'pin mailers' which conceal the components).  At the other end, they are entered in one-by-one (securely by each individual) into the receiving hardware.  Once 'joined' a check value is output and verified out-of-band using information supplied by the originator.  If it all checks, then the two sides agree to start using the keys for whatever they agreed to exchange.

Of course, this is the lowest common denominator approach when you have devices from different vendors -- many vendors have created more secure ways of performing out-of-band key agreement (e.g. hardware tokens, secure connections, etc.).  But when we talk about key splits like XOR, we are definitely talking about the lowest-common-denominator approach.

Hope this helps,

Bob
 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]