Subject: Re: [KEYPROV] Security Flaw

From: "Philip Hoyer" <[email-masked]>
Date: Wed, 1 Apr 2009 19:06:38 +0200

Anders,

This is why a client should have the public key of the server embedded
and the server should send a signed nonce that the client can verify.

Matter of fact it is good practice to only speak to valid servers in the
first place.

Philip

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anders Rundgren
Sent: Friday, March 27, 2009 7:20 AM
To: KEYPROV
Subject: [KEYPROV] Security Flaw

I have discovered a security flaw in certain KEYPROV setups as well as
in KeyGen2.  I'm currently researching a countermeasure that may resolve
the problem.  Here is a write-up of the security flaw:

An established way to perform a secure download is that the client sends
a public key (or public key certificate) to the server which is then
used by the server to wrap either the secret data itself, or a freshly
generated symmetric key which is used for bulk encryption of the secret
payload. The client uses its corresponding private key to unwrap the
encrypted data. To verify the integrity of downloaded data, MACs
(Message Authenticate Codes) are usually added as well.

Although the above "works" in the sense that a provider that recognizes
the public key does not have to worry about sending sensitive or secret
data to the wrong party, unfortunately nothing prevents a MITM (Man In
The Middle) from replacing the original encrypted data with something
else including generating proper MACs, since the whole scheme relies on
a single more or less public key, which thus makes the attack go "under
the radar"!

Is this a serious limitation? For authentication keys this is probably a
minor snag since a bad key presumably doesn't give you access anywhere,
while fake PINs and PUKs are slightly more worrying. In addition to
imagined or real threats, there is also an "acceptance" problem with
systems having unresolved security issues. Replaced encryption keys
could in fact be disastrous since they typically would reveal secret
data to the attacker while hiding it from the true recipient!

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 1 Apr 2009 21:01:08 +0200

Philip,

Well, this topic is a little bit more complicated IMHO.

To limit severs' ability to talk to SEs (Security Elements) is an option that has proven security advantages.

Since I [FWIW], strongly believe that on-line provisioning standards that primarily target the enterprise will likely fail on the market, I have personally stayed away from introducing limitations like the one you are mentioning.  In fact, I think there are enough hurdles already :-( :-(

What the referred solution is addressing is a specific configuration where SEs are equipped with "device certificates" which are used in a potentially novel way, albeit very SE-oriented.

It comes to little surprise that no "standard" APIs currently support this scheme.  OTOH, I don't regard for example PKCS #11 as particularly useful for advanced SE-provisioning.  As an SE "key-consumer" API it is though perfectly OK.

A write-up is currently in limited circulation for evaluation.  I would publish it directly if it wasn't for the fact that the core concept already has hundreds, maybe even thousands of (mostly quite stupid), "predecessors" which have been granted patent status by the USPTO.

Anders
PS an SE-oriented API:
http://keycenter.webpki.org/javadoc/keystore/org/webpki/jce/crypto/VirtualSE.html
see: generateAttestedRSAKeyPair
DS
----- Original Message ----- 
From: Philip Hoyer 
To: Anders Rundgren ; KEYPROV 
Sent: Wednesday, April 01, 2009 19:06
Subject: RE: [KEYPROV] Security Flaw

Anders,
This is why a client should have the public key of the server embedded and the server should send a signed nonce that the client can verify.
 
Matter of fact it is good practice to only speak to valid servers in the first place.
 
Philip

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anders Rundgren
Sent: Friday, March 27, 2009 7:20 AM
To: KEYPROV
Subject: [KEYPROV] Security Flaw
 
I have discovered a security flaw in certain KEYPROV setups as well as in KeyGen2.  I'm currently researching a countermeasure that may resolve the problem.  Here is a write-up of the security flaw:
An established way to perform a secure download is that the client sends a public key (or public key certificate) to the server which is then used by the server to wrap either the secret data itself, or a freshly generated symmetric key which is used for bulk encryption of the secret payload. The client uses its corresponding private key to unwrap the encrypted data. To verify the integrity of downloaded data, MACs (Message Authenticate Codes) are usually added as well.
Although the above "works" in the sense that a provider that recognizes the public key does not have to worry about sending sensitive or secret data to the wrong party, unfortunately nothing prevents a MITM (Man In The Middle) from replacing the original encrypted data with something else including generating proper MACs, since the whole scheme relies on a single more or less public key, which thus makes the attack go "under the radar"!
Is this a serious limitation? For authentication keys this is probably a minor snag since a bad key presumably doesn't give you access anywhere, while fake PINs and PUKs are slightly more worrying. In addition to imagined or real threats, there is also an "acceptance" problem with systems having unresolved security issues. Replaced encryption keys could in fact be disastrous since they typically would reveal secret data to the attacker while hiding it from the true recipient!
Anders