Strength in Complexity?

[Ben Laurie]

Arshad Noor wrote:
> 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.

Then I would agree that a protocol alone could not achieve all of this, 
though obviously it is possible to design a protocol that makes it 
impossible.

>> 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.

OK, so you still have a PKI problem, in that you have to issue and 
manage client certificates. How is this done?

 > 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.

I'd be very surprised if it were the _only_ logical way to do it. But 
that aside, my point stands: these characteristics are not shared by all 
cryptographic systems. In fact, I'd say that all of them are not shared 
by most cryptographic systems.

>> 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.

I do not believe this is the case. DRM fails because the attacker has 
physical possession of the system he is attacking.

The fact that the attackers is highly motivated because of the 
objectionable nature of DRM does not seem to differ much from your 
system, though in your case the motivator will presumably be profit.

>>> 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.

Are there any even vaguely modern systems that target the network for 
security, or is this a straw man?

 >  As such, it will merely be a tool in the evolution towards
> more secure systems - how people use the tool is up to them.

If it is up to them, then why bother with this verification process? 
This sounds like yet more security theatre to me.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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