massive data theft at MasterCard processor

[Anne & Lynn Wheeler]

Anne & Lynn Wheeler wrote:
> For pure authentication operations ... this model eliminates the whole
> digtital certificate paradigm ... since the model assumes that the
> originator of the authentication request already has the recipient's
> public key recorded someplace.
> http://www.garlic.com/~lynn/subpubkey.html#certless

so the simplified SSL using the domain name on-file public key ... still
has possible replay attack potential against the server (the attacker
doesn't necessarily know what the replay is doing ... but getting the
server do it multiple times might result in something bad).

so in another kind of authenticated connection scenario ... say Kerberos
or RADIUS ... the client has registered their public key in lieu of some
sort of password (for certificateless operation)
http://www.garlic.com/~lynn/subpubkey.html#radius
http://www.galric.com/~lynn/subpubkey.html#kerberos

they contact the server asserting some userid. the server generates a
random key, encrypts a time-stamp plus asserted userid plus more random
data, encrypts the random key with the public key on file for that
userid and responds. the user decrypts the random key with their private
key, and decrypts the response. at this point their is a choice of
possibly having encrypted sessions (with possibly perceived overhead
issues) ... or having the client permute the unencrypted data in some
way, re-encrypt just the permuted data and return it with unencrypted
data. the re-encrypted data demonstrates "something you have"
authentication (i.e. the client has possession and use of the
appropriate private key).

there are MITM vulnerabilities for the client ... since the server
hasn't been authentication.

to eliminate the MITM attacks against the client and replay attacks
against the server ... they would have to authenticate each other ....
w/o resorting to digital signatures (and opening themselves up to
dual-use attack) ... each sending some random data encrypted with the
other's public key .. which then can be decrypted with the appropriate
private key.

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