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


Bob,

Before we dive into the more interesting use cases, there are a couple of very trivial use cases we can eliminate from discussion -- these are the cases where both PC1 and PC2 are KMIP aware and there exists a KS for splitting and serving keys (incidentally, PC1 and/or PC2 in this case could implemented as a KS, which falls into the 'Server to Server' use cases Bob L. is working on ATM). I'll assert that this use case is uninteresting in this discussion because key splitting is all about a way of manually and 'securely' transporting a secret key between devices, and if all actors in our scenario are KMIP aware/compatible then we have no problem to solve as manual key distribution is *not* required because we could rely upon KMIP directly to distribute the keys securely. Therefore these combinations of actors are uninteresting from a key splitting use case scenario.

Unfortunately, I think these use cases are all we can address today. Server distribution of keys using KMIP would be done in a non- interoperable way based on server policy/ACLs. Client side distribution of keys (which breaks auditing control) is more the current KMIP flavor it seems.

So let's consider a more interesting use case where both PC1 and PC2 are KMIP ignorant, and an enterprise has a KS where they would like to manage keys from. Furthermore, let's assume that PC2 is owned by a separate enterprise altogether. In this scenario, the enterprise would supposedly rely upon KS to generate a key and split it. It will then manually load the components into PC1 and then have to securely transport the components to PC2 for loading there. So, does this use case demonstrate any of the strengths of KMIP? In this case, KS will generate a split key, and then spit out components (somehow) -- from that point forward, the KS loses visibility, auditability, and manageability of that key -- it will go into PC1 and PC2 and have no other automatic relationship with the rest of the estate of devices. Sure, you could logically manage the state within KS (e.g. retiring a key, etc.), but does that truly add any value for the enterprise if they still have to manually manage the keys in PC1 & PC2? Also, consider the fact that PC1 and PC2 (most likely) have mechanisms for securely generating and splitting keys for sharing; any payments HSM worth their salt must do this, and generally speaking, can do this in such a way that enterprises are comfortable with for managing the split components (e.g. printing out to opaque mailers, spitting out component pieces procedurally, etc.). My initial feeling is that this use case doesn't showcase the power of KMIP, nor does it offer something that is missing from existing manual key distribution schemes. Introducing a bespoke 3rd solution for generating keys in this space only creates complexity without returning on that investment in any tangible way.

If PC1 and PC2 can generate their own splits, then you could use the existing KMIP functionality to register a Split Key object if they were KMIP aware.

A more interesting use-case here would be one where PC1 is acting also as KS such that the enterprise can use KS/PC1 to generate the splits, while maintaining a copy of the source key for usage within PC1 securely. The splits are then distributed securely to PC2 for ingestion such that PC1 & PC2 can now exchange encrypted information. I feel this is a little bit better (although marginally) than the previous use case because the enterprise can now leverage some of the key management and policy information on the key in question, although visibility of the key is still lost in the PC2 state space, but perhaps that's mostly true in today's world as well (I say 'mostly' because the owner of PC1 could still 'retire' their key through deletion so it would not be able to send/ receive data with that entity any more anyway, but I digress...). So do you think this configuration of actors captures the most demonstrative use-case for key splitting? I'm not quite sure, but it seems to be closest.

This sounds like the current best solution for your use cases, and one I certainly hadn't thought of (PC1 = KS).


My other logical concern (which starts to bleed into the technical implementation realm) is about how to manage the splits through KMIP such that a solution is manageable from a PCI and ANSI X9.24 compliance standpoint. Without getting into the letter of the law (because we'd need more text in this email!), the spirit is one which wants to enforce a culture of split key distribution with auditable physical controls and checks/balances. This means that the devices directly support physical controls and audits which enable organizations to support the compliance and security requirements. It is not intuitively obvious how to leverage the key splitting functionality such that the spirit of the law is maintained (e.g. making sure an owner can ensure only one person can get the component value; that no one person has access to the clear keys or more than one split; etc.)? This question is mostly born from my ignorance of the specifics of KMIP ACL constraints, but I'm hoping that the ultimate use case(s) captures the specifics about how a KS owner would go about splitting a key which supports PCI/ ANSI X9.24 requirements for maintaining dual control on key components, etc.

If PC2 is KMIP unaware and owned by a separate enterprise, I think auditing within KMIP will have its limitations regardless of KMIP ACL constraints. I do however think many more use cases will open up if a Split Key creator can tell the server who can access them.

Kelley




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