Ben Laurie <[EMAIL PROTECTED]> writes: >> That could be fixed. I think the right design for such a device has >> it only respond to signed and encrypted requests from the issuing >> bank directed at the specific device, and only make signed and >> encrypted replies directed only at the specific issuing bank. If >> anything in between can tamper with the communications channel you >> don't have the properties you want out of this. > > Not entirely clear what you mean by the "issuing bank" here, but I'm > hoping you don't mean that the bank issues the device - that would be > very tedious.
Tedium is something that computers do very well. They don't care about how much work they have to do. The only issue is whether we induce too many serialized public key operations, and thus too much delay. > I also find "directed only at the specific issuing bank" unclear - I > presume you mean encrypted s.t. only the issuing bank can read it? Yup. I want that for a variety of reasons. > In which case, you're adding complexity - a relying party has to let > the issuing bank come between it and you to get anywhere. That's the case already. Only the issuing bank knows if the account has any credit left in it, after all. > This would preclude, for example, offline transactions. We used to live in an era where offline transactions were important. Now that you can get online literally anywhere, and now that merchants pretty much are required to check card validity and funds availability online anyway, that's no longer an interesting concern. I can't think of the last time I was involved in an offline transaction -- even folks at street fairs can now afford GPRS and similar communications for their veriphone (and similar) units. > As I've said before, I totally agree that the only way to go is to > have signatures made on such a device, but I do think its very > important to design the thing right - and the above isn't sounding > right to me. It sounds right to me, because it puts the trust relationships in all the right places. The merchant trusts the accepting bank that it will be paid. The accepting bank trusts the card network, the card network trusts the issuing bank. The issuing bank and cardholder have a bilateral relationship, too. If we keep the cryptographic exchanges purely in correspondence with the trust relationships, and we get rid of reliance on third party certification of public keys entirely, we also fix most of the trouble in the system. By the way, I note as an aside that this also means (in my opinion) that certificates are no longer an interesting technology for payments protocols, because in a purely online environment, you never need a third party x.509 certificate in the course of the payments protocol itself when there are no offline components of the protocol and all relationships are bilateral. The overwhelming disadvantage is deployment complexity, but given deployment (ha, what an assumption on my part!) the system would work very cleanly indeed. The user would not have to worry about his PC being infected or his merchant deploying a dishonest terminal (though theft of a token + beating the PIN out of the user would still be an issue). By not responding to requests that do not come from the issuing bank specifically encrypted for the token, you reduce (though of course not eliminate) the possibility of side channel attacks or inducing buffer overflows and such in the token, as well as depriving intermediate entities of privacy damaging information. The issuing bank would not have worry about the origin of the token's signature -- it could be reasonably assured that, short of physical attacks on the tokens (which would happen but be infrequent), the signature came from the token, and no information that would permit independent payment authorizations has been left with the merchant or card processor. Overall, I think such things are a win. Perry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]