Strength in Complexity?

Arshad Noor arshad.noor at strongauth.com
Mon Jul 7 13:25:07 EDT 2008


Ben Laurie wrote:
> Arshad Noor wrote:
>>
>> I may be a little naive, but can a protocol itself enforce proper
>> key-management?  I can certainly see it facilitating the required
>> discipline, but I can't see how a protocol alone can enforce it.
> 
> I find the question difficult to understand. Before I could even begin 
> to answer, you'd have to define what "proper key management" actually is.
> 

I consider KM to be the discipline of defining policy and establishing
procedures & infrastructure for the generation, use, escrow, recovery
and destruction of cryptographic keys, in conformance with the defined
policies.

> That said, EKMI (from my brief reading) has a view of key management 
> that is only "proper" in quite constrained circumstances. In particular, 
> keys are available to participants other than those who are 
> communicating, which is general considered to be a very bad idea. 

I'm not sure I'm following your comment here, Ben.  Did some word get
left out?  In EKMI, keys are available only to those who are known to
the central Symmetric Key Services (SKS) server, and who are authorized
to receive keys.  The "knowledge" comes from entries in the SKS server
about the clients and their digital certificates.  The authorization
comes from ACLs and from policies that apply to the client.  So, yes,
EKMIs are designed for constrained environments.

> 
>> The design paradigm we chose for EKMI was to have:
>>
>> 1) the centralized server be the focal point for defining policy;
>> 2) the protocol carry the payload with its corresponding policy;
>> 3) and the client library enforce the policy on client devices;
>>
> 
> Well. You said "centralized server". Many cryptographic systems don't 
> have one of those.
> 

I realizecd that two years ago when I started defining the architecture
for EKMI and the software to implement it.  It was the only logical way
of addressing the business problem of managing encryption keys for five
different platforms/applications that needed to share ciphertext on a
daily basis across hundreds of locations and thousands of POS registers.

> Also, the idea of a client library enforcing policy is DRM all over 
> again. Which, as we all know, will never work.

You make an interesting point here.  While, conceptually, EKMI and DRM
share similar designs, I believe the reasons for DRM's failure has more
to do with philosophy than with technology.  But that's a different
debate.

>> P.S. Companies deploying an EKMI must have an external process in
>> place to ensure their applications are using "verified" libraries
>> on the client devices, so their polices are not subverted.
> 
> 
> Ha ha. Like that's going to work. Even if we assume that libraries are 
> verified (fat chance, IMO), how are you going to stop, for example, 
> cut'n'paste? Employees reading things out over the phone? Bugs? Etc.
> 

EKMI's goals are not to provide bullet-proof security.  It has more
modest ambitions - to provide a management framework for incremental
security, targeted at the right resource: the data, rather than the 
network.  As such, it will merely be a tool in the evolution towards
more secure systems - how people use the tool is up to them.

Arshad Noor
StrongAuth, Inc.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list