4 ms·

> Too me this always seemed to subvert the "super secure" chip & PIN authentication. Chip and Pin usually implies offline PIN. The terminal supplies the PIN, a

by Nursie 4y ago

> Too me this always seemed to subvert the "super secure" chip & PIN authentication. Chip and Pin usually implies offline PIN. The terminal supplies the PIN, after a one-way transform of some sort IIRC* to the chip on the card, which then verifies it locally against a stored version of that same hash or whatever. With contactless you're doing online PIN. The terminal applies a transform and some sort of asymmetric key encryption to the PIN, and this gets sent to your bank. There's nothing any less secure here. (* I wrote an EMV 'kernel' a long, long time ago, in about 2002, and some more PIN block processing code about 8 years back. So it's been a while!)

rswail 4y ago
Chip + PIN is basically the EMV standard for cards with chips on them (and the small set of connectors for when the card is inserted in a reader). There is very little difference in the process when using NFC, except that the power to the chip in the card is via the NFC field. There are some changes to the business rules around processing contactless payments. Although the same floor limits for asking for the PIN for contact and contactless are pretty much the same these days.
- Nursie 4y ago
  > Chip + PIN is basically the EMV standard for cards with chips on them Worse than that, it's a marketing name :) Or it was in the UK. Strictly speaking the cards contain a customer verification method list that gives the terminal the info about whether and in what priority order it should process PIN offline, online, signature or other methods. This method allows american cards to function elsewhere in the world, depending on the terminal risk profile, and euro cards which usually would require a PIN to function in PIN-less US terminals. > There is very little difference in the process when using NFC, except that the power to the chip in the card is via the NFC field. Sure, but in contactless EMV there is no user interaction part of the process, so 'offline PIN' is not a possibility. This is because the transaction process would have to halt while the user entered their PIN and continue afterwards. So I'm pretty sure that for contactless transactions there is no offline PIN CVM. The process is also going to be slightly different in that the card/phone doesn't stick around for any post-transaction issuer scripts, and IIRC from the short time I worked on a contactless product, there is only a single application-cryptogram generation phase compared to the two in a chip transaction, though I can't remember the significance of that now! Or can I ... the second Gen AC phase is where the card signs off on the bank's authorisation of a transaction, if the transaction has gone online. Strictly your chip card can still decline a transaction even if the bank says it's OK. This is missing in contactless flow because, again, it would require the transaction to pause and take longer than a quick wave.
  - rswail 4y ago
    Not entirely true. I've done a contactless payment that was interrupted at the reader and my PIN requested before the transaction was processed. I didn't need to re-present the card to the reader. It processed the rest of the transaction after the PIN was entered.
    - Nursie 4y ago
      > I didn't need to re-present the card to the reader. It processed the rest of the transaction after the PIN was entered. Yeah that's an online PIN, it's sent to your bank for verification, not the card (which has already done its part of the transaction). (If you want to be pedantic, yes, you're quite right! The EMV transaction process is still going on at that point, between the terminal and the bank, and it has indeed paused to allow the user to enter a PIN. The process between the terminal and the card has completed though, so offline PIN can't be done, because in the offline PIN process the card performs the verification.
      - rswail 4y ago
        Very true, and if there's one thing about EMV, it is pedantic and convoluted and confusing, primarily because it has evolved and is not particularly subject to "intelligent design". :)
connordoner 4y ago
Out of curiosity, what sort of language would such a kernel be written in?
- Nursie 4y ago
  So the 'kernel' I wrote was not the one running on the card. 'In the Industry' (which sounds so pretentious!) the core of the EMV logic that runs on a terminal is often referred to as the kernel. It's not much like a real OS kernel! The kernel I wrote in about 2002/3 was in C and allowed a PC using a dumb reader (with secure PIN pad) to run the transaction, on Windows, Linux or (shudder) Unixware at the time. Years later in 2014 when I worked on a terminal product the company had bought in a third party kernel, also written in C to run on an embedded MIPs board. There was a platform SDK and a custom gcc variant to build bare-metal executables. You bootstrapped the kernel by passing it a malloc implementation and a couple of hooks to other things like accelerated crypto functions etc, and it provided an API to run the transaction. I also worked briefly on a contactless terminal product in 2012, which IIRC was C and C++ (old-skool C-like C++) on a proprietary OS of some sort, and they were moving to embedded linux on ARM at the time. (edit - See also rswall's parallel answer, it's very good. I wrote an EMV L2 kernel in that parlance, and interacted with another.)
- rswail 4y ago
  Whatever the card reader supports. What EMV call a "kernel" is not what a Linux person would call a "kernel". EMV don't really care, what they care about is that the protocols are followed and that the CHD (Card Holder Data) is protected and that the transactions are properly encrypted at rest and in transit. So you could write it in Visual Basic if you wanted, but your PCI auditor might have a problem with that. :) As far as I understand it EMV has L1 and L2 "kernels", then there is an "L3" that is acquirer specific. When a device is "PCI-PADSS" certified, the L1/L2 kernels are what are tested. When a merchant is PCI-DSS audited, it is a combination of the PCI-PADSS certification for the device, as well as the L3 layer and other business processing rules around handling the CHD (Card Holder Data). The L3 is supplied by the merchant's acquirer (often with the terminal itself) and the acquirer has had the device validated as part of their PCI audit. EMV L1 Kernel: The "app" that understands the EMV protocol and data exchanges ("APDUs") between the reader and the card. The equivalent of the PHY chip and ethernet frame handler in ethernet. EMV L2 Kernel: The "app" that understands the EMV business rules and processing of transaction. The equivalent would be the IP layer in networking land. EMV L3 Kernel: The specific "acquirer" rules, eg, there is a BIN (Bank Identification Number) accept/deny list that an acquirer will accept. It also has other rules about limits etc that the acquirer imposes. The equivalent would be IPTables in Linux.
CaptainZapp 4y ago
Thanks to both of you for the comprehensive and interesting answers to my potentially "dumb" question. It's this what makes HN still an outstanding resource and community. Thanks!

by Nursie 4y ago

rswail 4y ago

Chip + PIN is basically the EMV standard for cards with chips on them (and the small set of connectors for when the card is inserted in a reader). There is very little difference in the process when using NFC, except that the power to the chip in the card is via the NFC field. There are some changes to the business rules around processing contactless payments. Although the same floor limits for asking for the PIN for contact and contactless are pretty much the same these days.

Nursie 4y ago
> Chip + PIN is basically the EMV standard for cards with chips on them Worse than that, it's a marketing name :) Or it was in the UK. Strictly speaking the cards contain a customer verification method list that gives the terminal the info about whether and in what priority order it should process PIN offline, online, signature or other methods. This method allows american cards to function elsewhere in the world, depending on the terminal risk profile, and euro cards which usually would require a PIN to function in PIN-less US terminals. > There is very little difference in the process when using NFC, except that the power to the chip in the card is via the NFC field. Sure, but in contactless EMV there is no user interaction part of the process, so 'offline PIN' is not a possibility. This is because the transaction process would have to halt while the user entered their PIN and continue afterwards. So I'm pretty sure that for contactless transactions there is no offline PIN CVM. The process is also going to be slightly different in that the card/phone doesn't stick around for any post-transaction issuer scripts, and IIRC from the short time I worked on a contactless product, there is only a single application-cryptogram generation phase compared to the two in a chip transaction, though I can't remember the significance of that now! Or can I ... the second Gen AC phase is where the card signs off on the bank's authorisation of a transaction, if the transaction has gone online. Strictly your chip card can still decline a transaction even if the bank says it's OK. This is missing in contactless flow because, again, it would require the transaction to pause and take longer than a quick wave.
- rswail 4y ago
  Not entirely true. I've done a contactless payment that was interrupted at the reader and my PIN requested before the transaction was processed. I didn't need to re-present the card to the reader. It processed the rest of the transaction after the PIN was entered.
  - Nursie 4y ago
    > I didn't need to re-present the card to the reader. It processed the rest of the transaction after the PIN was entered. Yeah that's an online PIN, it's sent to your bank for verification, not the card (which has already done its part of the transaction). (If you want to be pedantic, yes, you're quite right! The EMV transaction process is still going on at that point, between the terminal and the bank, and it has indeed paused to allow the user to enter a PIN. The process between the terminal and the card has completed though, so offline PIN can't be done, because in the offline PIN process the card performs the verification.
    - rswail 4y ago
      Very true, and if there's one thing about EMV, it is pedantic and convoluted and confusing, primarily because it has evolved and is not particularly subject to "intelligent design". :)

connordoner 4y ago

Out of curiosity, what sort of language would such a kernel be written in?

Nursie 4y ago
So the 'kernel' I wrote was not the one running on the card. 'In the Industry' (which sounds so pretentious!) the core of the EMV logic that runs on a terminal is often referred to as the kernel. It's not much like a real OS kernel! The kernel I wrote in about 2002/3 was in C and allowed a PC using a dumb reader (with secure PIN pad) to run the transaction, on Windows, Linux or (shudder) Unixware at the time. Years later in 2014 when I worked on a terminal product the company had bought in a third party kernel, also written in C to run on an embedded MIPs board. There was a platform SDK and a custom gcc variant to build bare-metal executables. You bootstrapped the kernel by passing it a malloc implementation and a couple of hooks to other things like accelerated crypto functions etc, and it provided an API to run the transaction. I also worked briefly on a contactless terminal product in 2012, which IIRC was C and C++ (old-skool C-like C++) on a proprietary OS of some sort, and they were moving to embedded linux on ARM at the time. (edit - See also rswall's parallel answer, it's very good. I wrote an EMV L2 kernel in that parlance, and interacted with another.)
rswail 4y ago
Whatever the card reader supports. What EMV call a "kernel" is not what a Linux person would call a "kernel". EMV don't really care, what they care about is that the protocols are followed and that the CHD (Card Holder Data) is protected and that the transactions are properly encrypted at rest and in transit. So you could write it in Visual Basic if you wanted, but your PCI auditor might have a problem with that. :) As far as I understand it EMV has L1 and L2 "kernels", then there is an "L3" that is acquirer specific. When a device is "PCI-PADSS" certified, the L1/L2 kernels are what are tested. When a merchant is PCI-DSS audited, it is a combination of the PCI-PADSS certification for the device, as well as the L3 layer and other business processing rules around handling the CHD (Card Holder Data). The L3 is supplied by the merchant's acquirer (often with the terminal itself) and the acquirer has had the device validated as part of their PCI audit. EMV L1 Kernel: The "app" that understands the EMV protocol and data exchanges ("APDUs") between the reader and the card. The equivalent of the PHY chip and ethernet frame handler in ethernet. EMV L2 Kernel: The "app" that understands the EMV business rules and processing of transaction. The equivalent would be the IP layer in networking land. EMV L3 Kernel: The specific "acquirer" rules, eg, there is a BIN (Bank Identification Number) accept/deny list that an acquirer will accept. It also has other rules about limits etc that the acquirer imposes. The equivalent would be IPTables in Linux.

CaptainZapp 4y ago

Thanks to both of you for the comprehensive and interesting answers to my potentially "dumb" question. It's this what makes HN still an outstanding resource and community. Thanks!