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 [EMAIL PROTECTED]
