|
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: keyprov-bounces at ietf.org [mailto:keyprov-bounces at ietf.org] 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 |