Re: [kmip] Locate by Value proposal

[Anthony Berglas <anthony.berglas@cryptsoft.com>]

P.S.  The security implications are actually rather small because an attacker with Get access could always iterate over all the keys, Get each one, and compare the key materials.  That would be inefficient, but quite effective unless there were a vast number of keys.

On Wed, Nov 18, 2015 at 12:50 PM, Anthony Berglas <anthony.berglas@cryptsoft.com> wrote:

Hello David and Bruce,

Thank you very much for your prompt feedback. 

I did not mention security policy because currently that is simply not part of the KMIP spec.  However, clearly it should be protected more than just Locate by Attribute, and possibly more than a Get for reasons that you outline.  I will add a note to the slides.

However, given that server policy is properly enforced, I would think that it is useful for appropriately authorized officers to be able to perform searches.  To use your hotel key example, if a key was found lying around (or in the pocket of a thief) then it would be not unreasonable for management to be able to determine to which room it belonged?

The NIST SP800-152 seems to want to treat the key material and attributes in a similar way, which it could be argued is what this proposal does.  I think that different attributes need different security profiles, which is what Chuck was talking about.  The key material is just one of those aspects that need to be properly secured with policy.

And that all becomes grist for the ACL proposal that I had aired in the face to face, but is a much bigger and more difficult issue to deal with.

As to the Group Member on slide 4, that is just referring to the ordinary Group Member KMIP attribute.  In other words the the search on (parts of) an object's value can be combined with ordinary Locate attribute searches.  And that is why I thought to use Locate rather than introducing some new LocateByValue operation.  I will clarify that in the slides.

Likewise, the UUID (Unique Identifier) and wrapping crypto Algorithm  is just he one in the Wrap Data structure, which is not itself wrapped.  It is not in the Key Value.  So it is available without the need to unwrap anything.  I will also clarify that.

I'll upload updated slides shortly.

Anthony

On Wed, Nov 18, 2015 at 3:59 AM, Featherstone, David <David.Featherstone@safenet-inc.com> wrote:

Hi Anthony

 

An interesting idea, but I wonder if that capability would be more useful to a hacker than to a legitimate customer. The risks seem to outweigh the benefits.

 

As a contrived example, suppose you’re at a 5000-room resort hotel and you drop your room key in the lobby. Moments later, a thief finds your lost key, but doesn’t know which room it will open. No problem, because the hotel has a database of its room keys and a corresponding image of every key. The thief takes a photo of the key and pays $20 to his insider friend to run a search on the image. Voila, the thief learns that the key will open Room 3724.

 

Don’t analyze the example too intensely, because I’m sure there are a number of holes, but I think the general concern is valid. If instead of a lost physical key we substitute a lost or stolen password, I think you can imagine how the search capability could be exploited to a hacker’s advantage. You could argue that if the hacker is able to perform the search, then the hacker already has access to the keys, but the critical detail is that the hacker is already in possession of a piece of information but doesn’t know how to use it. The search result tells him. Perhaps this risk could be mitigated by a server policy requiring that Key Blocks be searchable only by clients that are also permitted to Get [i.e. export] the corresponding keys.

 

In one of your examples [4^th slide], you propose that this capability could find a Group Member attribute in the Key Block. Could you clarify why you would search for this attribute in the Key Block? i.e. I understand that the attribute can be packaged within the Key Block – e.g. at time of Register – but why would the server leave this attribute in the Key Block? It must anyway be made accessible by Locate (and Get Attributes, and Get Attribute List) – even now, without the proposed extension.

 

Finally, also on the 4^th slide, could you clarify how this capability would match data within a wrapped Key Value [within a Key Block]? If the Key Value is wrapped, would a search not require that the Key Value be unwrapped? And if the wrapped Key Value can be unwrapped, would not the unwrap have occurred once (and only once) when client first Register’d the key?

 

Cheers,

… Dave

 

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Anthony Berglas
Sent: Tuesday, November 17, 2015 6:36 AM
To: OASIS KMIP Technical Committee
Subject: [kmip] Locate by Value proposal

 

Hello All,

Attached is the proposal for being able to Locate objects by their values in an analogous way that we can locate by attribute. 

I would like to discuss this on this week's call.  However, any initial feedback would be most welcome.

Regards,

Anthony

--

Anthony Berglas Ph.D.
Principal Engineer
Anthony.Berglas@Cryptsoft.com

The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.

--

Anthony Berglas Ph.D.
Principal Engineer
Anthony.Berglas@Cryptsoft.com

--

Anthony Berglas Ph.D.
Principal Engineer
Anthony.Berglas@Cryptsoft.com