Re: massive data theft at MasterCard processor
* Peter Fairbrother: No, it isn't! A handwritten signature is far better, it gives post-facto evidence about who authorised the transaction - it is hard to fake a signature so well that later analysis can't detect the forgery, Apparently, handwritten signatures can be repudiated, at least I've heard of a few cases where this likely was the case (but naturally, graphologists didn't agree if the signature was genuine). You can even use a signature machine to facilitate repudiation at a later date. Also there are several attacks on Chip n' PIN as deployed here in the UK, starting with the fake reader attacks - for instance, a fake reader says you are authorising a payment for $6.99 while in fact the card and PIN are being used to authorise a transaction for $10,000 across the street. In Germany, there's a widely used system based on PIN and a magnetic stripe, and you can buy used reader devices on Ebay. 8-( This makes it rather easy to mount a MITM attack. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: massive data theft at MasterCard processor
Peter Fairbrother wrote: Also there are several attacks on Chip n' PIN as deployed here in the UK, starting with the fake reader attacks - for instance, a fake reader says you are authorising a payment for $6.99 while in fact the card and PIN are being used to authorise a transaction for $10,000 across the street. They get quite complex, there's the double-dip, where the $6.99 transaction is also made, and the delayed double dip, where a reader belonging to a crook makes the $10,000 transaction several days later (the crook has to skip town with the money in this attack - so far. Except of course he never existed in the first place, and maybe ...). the payment infrastructure requires a financial institution taking responsibility for a merchant to connect into the network ... and the settlement into the merchant account nominally flows thru the sponsoring merchant financial institution. for a merchant not to actually exist would require some lapse on the sponsoring financial institution ... i.e. some of the anonomous stored-value specifications tried to simulate direct cash-like transfer between two tokens but the existing payment networks are far from that, requiring a bit more deception on the part of any fraudulent merchant. note that some of the transaction authentication specifications don't necessarily match x9.59 financial standard in also specifying that a PAN in an authenticated transaction can't be used in a non-authenticated transaction. recent post reference http://www.garlic.com/~lynn/aadsm19.htm#38 http://www.garlic.com/~lynn/2005k.html#55 http://www.garlic.com/~lynn/2005k.html#56 i.e. which still leaves open the various harvesting vulnerabilities. the x9.59 financial standard specified that both 1) transactions have to be individually authenticated (account-level authentication with the issuing institution) and 2) the same PAN used in authenticated transactions can't be used in non-authenticated transactions (countermeasure to harvesting vulnerability where crook could utilize information for later fraudulent transactions) misc. x9.59 http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
Ian G [EMAIL PROTECTED] writes: Definitely. Maybe time for a BCP, not just for AES but for general block ciphers? What is a BCP? Best Coding Practices? Block Cipher Protocol? Best Current Practice, a special-case type of RFC. Based on recent experience with this style of collaborative document editing, I've set up a wiki at http://blockcipher.pbwiki.com/, blank username, password 'sbox', for anyone who wants to add their $0.02 about what to do/what not to do to protect block ciphers from side-channel attacks. If it works out, this could turn into a BCP. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: massive data theft at MasterCard processor
Peter Fairbrother [EMAIL PROTECTED] writes: Steven M. Bellovin wrote: Designing a system that deflects this sort of attack is challenging. The right answer is smart cards that can digitally sign transactions No, it isn't! A handwritten signature is far better, it gives post-facto evidence about who authorised the transaction - it is hard to fake a signature so well that later analysis can't detect the forgery, and few people would bother to do it that well anyway, while it is easy enough to enter a PIN with digital reproducibility. Not only that, you can mess up the transaction without even wanting to do it fraudulently. With PIN-based authentication (at least every one I've ever seen), you insert your card, enter your PIN to authorise the transaction, and then it prints your receipt. As you point out, there's no link between the paper trail and the authorisation, and by the time you get to see the paper trail it's too late to do anything about it. Running a two-phase commit to fix this is unworkable (it'd double the number of transactions and require holding state at the acquirer gateway), and even then it doesn't tie the authorisation to the paper trail. Consider a recent example, in which a hotel inadvertently charged me twice for one stay. The first time they ran the transaction on the handheld card terminal the built-in printer ran out of paper, so they reversed the charge and charged me a second time with a new roll of paper in the printer. Since I didn't trust them to get this right, I asked for both printouts, wrote VOID on the first one, and signed the second one. As it turned out, they didn't get it right, and I have a pretty clear paper trail to prove that the first transaction wasn't authorised. If I'd done this with a PIN, both would have been authorised, because I can only take the merchant's word for it that they've cleared up the first transaction for me - the client has to go to some lengths to prove their credentials, but the merchant only has to claim that they've sorted it out. In fact I don't think there's any way for them to prove to a client that they've reversed a transaction short of phoning their bank and getting them to fax out a statement. So I'll stick with printouts and signatures for the foreseeable future. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
Ian G [EMAIL PROTECTED] writes: On Tuesday 21 June 2005 13:45, Peter Gutmann wrote: Best Current Practice, a special-case type of RFC. Based on recent experience with this style of collaborative document editing, I've set up a wiki at http://blockcipher.pbwiki.com/, blank username, password 'sbox', for anyone who wants to add their $0.02 about what to do/what not to do to protect block ciphers from side-channel attacks. If it works out, this could turn into a BCP. That's what I like, action, not words! To celebrate this, I've stuck some words in there which others can act on ;-) Uhh, that wasn't really what I was after, that's pretty much textbook stuff, what I wanted was specifically advice on how to use block ciphers in a way that avoids possibilities for side-channel (and similar) attacks. I have some initial notes that can be summarised as Don't let yourself be used as an oracle that I was planning to add after I've fleshed them out a bit. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
crypto rfcs 4055, 4056, 4101 announce today
4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. J. Schaad, B. Kaliski, R. Housley. June 2005. (Format: TXT=57479 bytes) (Updates RFC3279) (Status: PROPOSED STANDARD) 4056 Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS). J. Schaad. June 2005. (Format: TXT=11514 bytes) (Status: PROPOSED STANDARD) 4107 Guidelines for Cryptographic Key Management. S. Bellovin, R. Housley. June 2005. (Format: TXT=14752 bytes) (Also BCP0107) (Status: BEST CURRENT PRACTICE) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
| Uhh, that wasn't really what I was after, that's pretty much textbook stuff, | what I wanted was specifically advice on how to use block ciphers in a way | that avoids possibilities for side-channel (and similar) attacks. I have some | initial notes that can be summarised as Don't let yourself be used as an | oracle that I was planning to add after I've fleshed them out a bit. It strikes me that block ciphers in *communications*get used in two different contexts: - With a long-lived key. This is in protocols like Kerberos, where the long-lived key is used as part of a mechanism to produce a session key. In most more recent protocols, some combination of D-H or public key plays this role. - With a session key. Usage in first of these may be subject to Bernstein's attack. It's much harder to see how one could attack a session key in a properly implemented system the same way. You would have to inject a message into the ongoing session. However, if the protocol authenticates its messages, you'll never get any response to an injected message. At best, you might be able to observe some kind of reaction to the injected message. But that's a channel that can be made very noisy, since it shouldn't occur often. (BTW, if you use encrypt-then-authenticate, you're completely immune to this attack, since the implementation won't ever decrypt the injected message. Of course, there may be a timing attack against the *authentication*!) By their nature, the first class of uses don't usually require the ultimate in performance. Since they receive and respond to small messages involving the encryption of a small amount of data, the encryption portion of the what they do is rarely the major time cost. If this dicotomy holds up, it leads to a simple recommendation: Use a constant-time implementation in the first role; use the highest-performance implementation in the second role. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
Ian Grigg [EMAIL PROTECTED] writes: Alternatively, if one is in the unfortunate position of being an oracle for a single block encryption then the packet could be augmented with a cleartext random block to be xor'd with the key each request. Moves you from being an encryption oracle to a related-key oracle, and makes the protocol non-idempotent. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
