the limits of crypto and authentication

[Perry E. Metzger]

Ben Laurie <ben at algroup.co.uk> 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 majordomo at metzdowd.com