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


Kelley,

Apologies first for the lengthy email -- Of course these sorts of discussions are better in front of a white board, but not an option in the near term -- so sorry in advance for the email diatribe!

Based on your email below and the follow up from Bob L. about payments networks use cases, I spent a couple of cycles this past weekend considering your proposal in more detail, specifically the use cases within the payments network framework.  Out of that, I came up with a couple of streams of thought, with each one being slightly different in focus; one logical in nature, and the other technical in nature -- but in the interest of keeping all the email responses to a manageable noise level, I will use this response to discuss just the logical considerations and I'll use a separate email thread for the technical ones.  My intent is to generate some dialog from the group on these subjects in hopes that (a) I better understand how this integrates into KMIP, and (b) it improves the use-cases for inclusion in the spec.  Anyway, here goes.

Firstly, let me state that I'm only talking here about the payments network use case and I don't think that it applies universally to your split key proposal; I think key splitting is useful and valuable -- my considerations here are just my stream-of-consciousness thoughts about applicability specifically in the payments space -- at least the one's I'm familiar with, so take these comments with a grain of salt.  Now, onto the meat of the matter!

When considering key splitting (and specifically within KMIP) in the payments network use case, I think it's easiest if we frame our discussion around three different logical 'actors' in the system; firstly there are two parties who wish to share a secret key for the exchange of information securely; let's call them payments clients (PC1 or PC2 for brevity) -- these can be terminals, other payments HSMs, etc., (note we will consider scenarios where each or both of these might be KMIP aware as well).  For the third actor, let's consider the addition of a KMIP Server (call it KS), because without a server we don't really have a use case, now do we?

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.

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.

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.

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.

Well, I think that's probably enough stuff to talk about, so I'll end there and look forward to everyone's discussion on the above topics.

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



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