3 ms·

This already exists. If EMV specified an X.509 certificate instead of a proprietary one, then we could be doing card-present transactions over the Internet rig

This already exists. If EMV specified an X.509 certificate instead of a proprietary one, then we could be doing card-present transactions over the Internet right now thanks to TLS client certificates.

ajdlinux 9y ago
https://en.wikipedia.org/wiki/Secure_Electronic_Transaction https://en.wikipedia.org/wiki/Secure_Electronic_Transaction was actually a thing once...
dfox 9y ago
The RSA certificates used in EMV are not used to authorize transactions, but only to authenticate card to the terminal (and optionally to encrypt communication between pin pad and the card). Only effect of using full-blown X.509 for that would be that the certificates will be three times larger. Transactions are "signed" with issuer-specific symmetric algorithm (the specification AFAIK recommends CBC-MAC and HMAC), original motivation for this constructions seems to be backward compatibility in the sense that the algorithm can be designed such that it produces 8 digit decimal numbers that can then pass through various backend systems in field originally intended for swipe card online authorization code. And by the way nothing technically prevents the issuers to combine EMV application with some PKCS#11 applet with X.509 certificate on the same physical card. EMV is in fact to some extent explicitly overdesigned to allow not only this but even multiple EMV "cards" on same physical chip. One interesting idea would be to do EMV transaction over the internet by just forwarding the PDUs sent to the card over the internet, but it has lots of subtle usability and security issues to be really practical.
- rkeene2 9y ago
  There is definitely nothing that prevents another applet (JavaCard, not PKCS#11 -- that's just a generic interface) from running on smartcards currently running the EMV applet. Or any other smartcard from running more than one applet -- this is a result of ISO7816 more than EMV. But my point is that if EMV had chosen to use X.509 instead of inventing their own certificate format then we could re-use the existing infrastructure with zero cost. Passing arbitrary APDUs from webpages to your card isn't a great idea and it will be SLOW since it will require multiple round-trips -- it's already slow enough just reading objects from smartcards. This is the mechanism used by Citrix/MS Remote Desktop, which is to forward a PC/SC connection -- this has a disadvantage that the remote side must have drivers and is also real slow, but the advantage that the resource can be used for anything, just like it were local. For what it's worth, I'm the author of some smartcard middleware (CACKey) and have worked with the EMV specification and EMV applets to a lesser degree.

ajdlinux 9y ago

https://en.wikipedia.org/wiki/Secure_Electronic_Transaction https://en.wikipedia.org/wiki/Secure_Electronic_Transaction was actually a thing once...

dfox 9y ago

The RSA certificates used in EMV are not used to authorize transactions, but only to authenticate card to the terminal (and optionally to encrypt communication between pin pad and the card). Only effect of using full-blown X.509 for that would be that the certificates will be three times larger. Transactions are "signed" with issuer-specific symmetric algorithm (the specification AFAIK recommends CBC-MAC and HMAC), original motivation for this constructions seems to be backward compatibility in the sense that the algorithm can be designed such that it produces 8 digit decimal numbers that can then pass through various backend systems in field originally intended for swipe card online authorization code. And by the way nothing technically prevents the issuers to combine EMV application with some PKCS#11 applet with X.509 certificate on the same physical card. EMV is in fact to some extent explicitly overdesigned to allow not only this but even multiple EMV "cards" on same physical chip. One interesting idea would be to do EMV transaction over the internet by just forwarding the PDUs sent to the card over the internet, but it has lots of subtle usability and security issues to be really practical.

rkeene2 9y ago
There is definitely nothing that prevents another applet (JavaCard, not PKCS#11 -- that's just a generic interface) from running on smartcards currently running the EMV applet. Or any other smartcard from running more than one applet -- this is a result of ISO7816 more than EMV. But my point is that if EMV had chosen to use X.509 instead of inventing their own certificate format then we could re-use the existing infrastructure with zero cost. Passing arbitrary APDUs from webpages to your card isn't a great idea and it will be SLOW since it will require multiple round-trips -- it's already slow enough just reading objects from smartcards. This is the mechanism used by Citrix/MS Remote Desktop, which is to forward a PC/SC connection -- this has a disadvantage that the remote side must have drivers and is also real slow, but the advantage that the resource can be used for anything, just like it were local. For what it's worth, I'm the author of some smartcard middleware (CACKey) and have worked with the EMV specification and EMV applets to a lesser degree.