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