Download
1 / 15
150 likes | 293 Vues
This proposal outlines enhancements to the Key Management Interoperability Protocol (KMIP) by introducing a new "Random" object type. Key features include minimal modifications to existing KMIP structure, support for single-chunk and streaming random operations, and the ability to share random data among multiple clients. The proposal ensures consistent operation with other cryptographic functions (encryption, signing, etc.) and allows for a flexible object model that supports both mutable and immutable operations, facilitating easier client-server communication and efficient cryptographic processes.
E N D
Get Random Proposal John Leiseboer 11 October 2012
Desirable Features • Minimal changes to KMIP • Supports single “chunk”, and streaming random • Can share same random amongst several clients • Server can push random to clients • Same model of operation as other proposed crypto operations (encrypt, sign, MAC, etc.)
Object or Operation? • Cryptographic Operations Objects… • Objects that perform cryptographic operations • Random, Encipher, Decipher, Sign, SignVerify, MAC, MACVerify, Hash • Consistent with OO programming • Data fields: KMIP attributes • Methods: KMIP operations
Random Object • Object Type • Random • Attributes • UID, Name, RNGAlgorithm, EntropyQuality, Offset, Length, others TBD • Operations • Create, Locate, Get, Destroy, Notify, Put
Usage • Client requests server to Create a Random Object • UID returned • Name attributes can be assigned to Random Object • Placeholder ID works for batch operations • Client locates Random Object by Name • Client gets Random Object bytes specifying Offset and Length • Get operation can be called more than once to read a stream of random bytes from the Random Object • Client destroys Random Object • Multiple clients can get (share) the same random stream
Test Case Outline • Create (Random) • In: objectType=Random, attributes={Name={NameValue=’RNDStream1’,NameType=X}, RNGAlgorithm=X, EntropyQuality=X} • Out: objectType=Random, UID • Locate (Random) • In: attributes={objectType=Random, Name={NameValue=’RNDStream1’,NameType=X}} • Out: UID • Get (Random) • In: UID, attributes={Offset=X, Length=X} • Out: objectType=Random, UID, Random • Destroy (Random) • In: UID
Simple, Single Chunk Operation • For simple, single chunk operations • Client can send a batched request • Create • Get • Destroy
Streaming Operation • For streaming operation • The client can issue individual requests • Create • Get • Get • ... • Destroy
Sharing a Stream • Clients (out of band) communicate information that identifies the shared stream • UID • Name, or other attributes that work with Locate • Each client sends its own Get requests • Only one client should Create and Destroy • Others can only Get
Discussion – KMIP Object Model • What is "the model" for KMIP objects? • Recent mutability discussion is relevant • This proposal clearly models objects as mutable • Also introduces the notion of Objects performing operations • Standard does specify an Object model • Several different, incompatible interpretations are possible • One interpretation is that all objects are static and immutable • Another interpretation is that objects can be mutable and can perform operations • Like OO programming models of objects
Discussion – Simple to Share • Simple means to share Random/Key streams • Each random stream can be identified by a UID, or a name • Very easy for cooperating clients to access the same stream • The UID, or Name can be shared out of band by clients • No new object type, or new attribute needed to enable sharing of Random/Key material
Discussion – Easy to Stream • Streaming operations easily supported • The alternative proposal is limited to single chunk operation • Does not support streaming operations (init, update, update, ..., final), as supported in almost all crypto products and libraries • Streaming mode of operation works very naturally with this proposal • Create functions as "init"; Get functions as "update"; and Destroy can function as "final"
Discussion – Easy Single Chunk • Single chunk, one-off operation supported using batch • Falls out very naturally from the current KMIP standard • If only a single chunk crypto operation is to be performed, it can be done as a sequence of Create/Get/Destroy in a single batched set of requests
Discussion – Push to Client • Notify and Put • Possibly some more thought needed, but… • Notify and Put should work with very little change with this model • Notify Example • As new Random is generated, Notify messages can be sent by the server to registered clients to indicate that the Random Object's attribute(s) have changed • A simple Get by the client in response to a Notify will return the next Offset/Length chunk of random • Put Example • As new random is produced, the server can send a Put message to registered clients • The Put object would retain the UID of the Random Object • Consider a new attribute called "update" rather than either of the current attributes (“new” and “replace”)
Summary • Easily allows sharing of random/key streams (and sharing of cipher streams) using UID or Name • Supports the mutability side of the Template debate • Can stop the debate with a compelling reason for selecting one side over the other • Supports encipher, decipher, sign, etc. stream operations • Works with Notify (no change) and Put (with addition of Update attribute) • Is compatible with almost all OO paradigms • And matches usage models of currently deployed cryptographic products • Requires little change to the existing KMIP specification • Where changes (mostly additions) are made, they fit in very naturally with the current standard • Reuses existing features of the standard wherever possible; e.g. Templates, Create, Get, Locate, Destroy, Notify and Put operations, batched operations using Placeholder ID, etc.
