You can make fake debit/credit card transactions on a $2 USB card reader. All the specs are here and the protocol is public and documented (IIRC 5000 pages in a lot of PDF, it's a pain in the ass to read).
But to validate those transactions, you must send them to the bank over the internet, and you'll get a visit from the feds/FBI/whatever if you do it.
There is no real protection on card readers (most use Linux with a small shitty password). The protection comes from the contracts and regulations between the shops and the banks.
> There is no real protection on card readers (most use Linux with a small shitty password).
Sure there is: only signed binaries can run, executable filesystem is read-only, data filesystem has noexec bit set, root login is disabled, crippled busybox misses a lot of functionality, keys are loaded from a secure area on bootup, master key injection only available when loading at the factory, bootup itself is more or less secure, tamper detection blanks the chip, etc.
Sure, if you have a cheap non-EMV certified Android terminal imported from Asia it'll probably use a standard Linux, with a rw root filesystem, with root login enabled *and* sudo enabled for the username used to execute applications, tamper-detection is non-existent, screen-casting not locked down, ports are all openable and busybox is more or less complete.
Source: Me. I developed (and still sometimes do) EMV applications for card acquisition for a few years. Even in dev mode (which requires the vendor to provide IDs of the developers), these things are very much locked down solidly.
> Sure there is: only signed binaries can run, executable filesystem is read-only, data filesystem has noexec bit set, root login is disabled, crippled busybox misses a lot of functionality, keys are loaded from a secure area on bootup, master key injection only available when loading at the factory, bootup itself is more or less secure, tamper detection blanks the chip, etc.
Sounds good. Has anyone been hired to attempt to attack the device and find vulnerabilities?
> The protection comes from the contracts and regulations between the shops and the banks.
While the comment is not quite true (see sibling replies), this part is spot on.
This is also why crackpot theories about people walking around with portable card readers and stealing money from contactless cards are false. Yes you can walk around and make those transactions, what comes after (and the setup you had to do before) is the problem. I'm not even sure whether you could get the money out before being caught and shut down. With how many people these days have push notifications for their transactions, I highly doubt that.
I did somehow have two different cards (an Amex and a Visa) compromised at the same time about two months ago, and I do wonder if it was some kind of skimmer setup - if it was just one of them then I'd assume it was just some online store I'd used it at that had been hacked, but I've not used both those cards on the same sites.
I got a notification asking me to confirm a transaction on the Visa and then looked in my app and found they'd actually got another transaction pending at a hotel. I called them up and the hotel said they would "kick out the guests" and refund me. Not sure why they didn't want to call the police on them, because when I called later they said I should report it to the police, but all of the transactions had been refunded so I literally had zero loss and there was nothing really to report... It was them who'd provided the services and suffered the loss, the hotel should have had the police remove them!
Anyway, on the same day the Visa had been used at the hotel, I also had some fraudulent transactions on the Amex, although most of them seemed to be automatically refunded by the vendor themselves (so maybe it was flagged by the vendor's anti-fraud mechanisms and refunded to avoid a chargeback from American Express) before I cancelled the card. They'd tried three times with a similar amount and they'd all refunded.
The other weird thing was that the hotel that the Visa was used at claimed that it had to be a card-present transaction or in a digital wallet, but I didn't get any notification about it being enrolled in a digital wallet and I always had the physical card with me. So not sure if that was mistaken or BS or if they managed to somehow fake the digital wallet.
But yeah it didn't work out for them because I caught the transaction the same day they'd checked in to a hotel with the card and then both were cancelled that day...
Well, the issue is that you need a merchant account to send the money to, and it's quite hard to get one without identifying yourself, and it takes a bit of time after the transaction to actually get the money because of chargebacks and the like. So you can't just pull the money out directly. But that's true of basically any credit card fraud: what you do instead is buy something from someone who takes credit cards. Which is entirely possible with contactless, you can e.g. proxy a connection from a reader to a victim card, it's just that the limits and difficulty of lining up the time of the transaction with someone walking past make it not particularly useful (compared to just stealing or skimming the card details).
Didn't people manage to present a remote card (i.e. in a mark's pocket) to a legitimate terminal through an NFC tunnel of sorts? Limited to no pin required amounts, but still.
I remember when contactless was introduced in France, someone from the CB bank card group (https://en.m.wikipedia.org/wiki/CB_Bank_Card_Group) said that contactless was secure because you are insured. At that time France was already using chip+pin for a while.
At the end of the day the money only goes from one bank account to another, account can be frozen, charge reversed, ... So you just need to secure the POS enough that user feel safe to use it and there is a low number of people that can hack them and are willing to risk prison.
> Yes you can walk around and make those transactions, what comes after (and the setup you had to do before) is the problem
I mean with the amount of stolen card details routinely traded and used successfully (at least for a while) and with how little crime like that is investigated or punished in some jurisdictions, I dunno...
Still it's not quite as simple as "taking the money from your card" like said crackpots think.
Aren't the contracts and regulations holding back the honest people only? But not those who violate contracts and regulations, like the dishonest ones?
> There is no real protection on card readers (most use Linux with a small shitty password). The protection comes from the contracts and regulations between the shops and the banks.
I'm afraid that's not true. Merchant terminals have secure hardware embedded inside to store the bank and interchange keys. If those keys leaked, someone could spoof legitimate transactions.
I'd be more worried about someone compromising a card reader in the field and reading cached/stored real CC details, or installing some kind of intercepting malware. (That does seem to be difficult/impossible in this specific case, but it means research in this area is relevant.)
Aren't credit cards nowadays basically physical private keys? IIRC transactions are one-time payloads signed specifically for that operations, so intercepting that won't help you if I'm not mistaken about how cards work nowadays.
Someone with a root access to a card reader could just make it collect CC details with every transaction, no caches needed. It could also make certain transactions "temporarily fail", while siphoning a certain amount of funds to another, legit-looking, merchant under the hood.
I'd be more worried about someone compromising a card reader in the field and reading cached/stored real CC details, or installing some kind of intercepting malware.
That's happened at least several times already.
I believe breached PoS terminals were what happened in the big Target hack.
You can read a card (stripe) with one of those cheap readers. The magnetic stripe is not encrypted and you can extract the card number (PAN), expiration date, and cardholder name. Some other less important bits too. You cannot extract the CVV this way, but that is not required for transactions.
Most cards are EMV now. That data is encrypted and it's read/write. These keys can leak, putting you back into a similar state as if you'd read the card via magnetic stripe.
But no amount of card reading gives you the ability to submit transactions to the network. For that, you'd need merchant credentials for their gateway or processor, and you'd usually need to have a presence on the merchant's network (to get through the upstream firewall).
These are all achievable things. Doing so gets you the ability to create transactions against the card. These transactions will be submitted to the network and approved or declined. If approved, funds will settle from the issuing bank to the merchant bank, possibly in multiple steps.
I'm oversimplifying a bit, but the essential point is that funds will settle to the merchant's bank account, not yours. You can cause some headaches, but you cannot steal money.
The compromise of a credit card terminal is only interesting because it gives an attacker the ability to steal the card details for all cards that are subsequently used at the compromised terminal. They can be saved and retrieved later, or sent out to a C&C server, etc. Then these card details can be used for all the usual types of credit card fraud.
How exactly are you going to get the diversified IPEK to generate the necessary keys to create the HMAC for the transaction that will be authorized by your merchant acquirer?
The BDK for your merchant acquirer is held by them in an HSM or equivalent. The IPEK is device specific, derived from the BDK based on the terminal ID.
The individual keys for the HMAC are generated for each transaction and are cryptographically linked to a transaction ID and the IPEK, so that the acquirer can determine whether there are missing messages.
Card readers that comply with the latest EMV chip/contactless standards require a secure element that maintains the crypto information and only allows specific requests from the non-secure element and only provides encrypted blobs for transmission between the acquirer backend and the secure element.
The first thing to understand at an even higher level about payment cards is that they have always had two separate and barely related components, Authorisation and Settlement.
Authorisation is concerned with whether this specific transaction has been approved in some sense by a card issuer. Authorization today is relatively high tech, there's somewhat decent cryptography, tamper resistance, uniqueness = they really care - and that's because when Authorization problems occur the banks might lose money, which they hate.
Settlement is "just" moving the money from one customer to another. $123.45 from Jim Smith to Terrible Goose Inc, done. This is very mid-late-20th century technology, we're not talking pieces of paper and scribbly hand writing, but fixed width ASCII fields on magnetic tape is fine - it's the customer's money so the banks don't care more than legally required.
Settlement replays are how you get "accidents" where a big store's customers all get charged twice for a whole day - the associated Authorizations can't be replayed, that's the banks money at risk - but the settlements aren't protected.
Merchants can, and some do, choose not to care about Authorization. In a huge business it could make sense to eat say 2% of sales as undetected fraud (ie you never receive payment) rather than have any transactions fail. If you operate a food truck using a terminal to take $1000 per day on your iPhone the people who supply your terminal may not let you opt out because that's risk they don't want. But if Jeff Bezos or Doug McMillon makes more without Auth he's turning it off.
It's over the Internet, because you're not going to run a dedicated fiber to every card reader. But it's not over the unprotected internet; your card reader will establish a VPN connection of sorts, or at least talk via an encrypted channel (think TLS) is you use e.g. a Square terminal.
Not that a random person can hit these endpoints, unauthenticated, and try to run a transaction.
I mean, maybe they don't have an open API, but they sure do have an API on the internet. Surely the payment terminals are communicating with the issuing bank in someway, perhaps over an interface of some kind.
I believe what this comment is getting at is that making fake transactions is useless without a connection to a bank that will execute them.
>and you'll get a visit from the feds/FBI/whatever if you do it
Is there any proof to this statement or are you just trying to scare people? I think it's possible there are bigger groups that would have their attention and a single fraudulent transaction would just be noise.
In his scenario I don't understand where he'd send the transaction to begin with?
In a typical scenario my understanding is that you get the terminal from your acquirer - this is your broker to the card networks. When the terminal makes a transaction, it does some crypto magic using its own keys (that identify it to the acquirer), sends that to the card which does more crypto magic using its own keys, and finally the result of that is sent to the acquirer.
If you do this flow yourself with fake keys you'd get the card to sign a transaction for your fake terminal's key (assuming you know the card's PIN of course - unless you're happy to forego any CVM), but you have no acquirer that would accept said transaction, so I don't see how you could commit a crime here even if you wanted to? You just got some meaningless bytes back.
And of course, if you have an actually valid terminal key that is trusted by an acquirer and do all this, you've effectively just made a normal payment - if the person was willingly paying you then no crime either, and otherwise it's no different than using a legit terminal to bill someone without their knowledge.
> There is no real protection on card readers (most use Linux with a small shitty password). The protection comes from the contracts and regulations between the shops and the banks.
Wait wait wait... Aren't these EMV cards smart cards using the Java smart card technology? I thought these were heavily using encryption, including PKCS.
They're using challenge/response protected by the PIN no!? If I am not mistaken if you insert a card in a totally compromised reader you cannot clone the card: that alone is already quite an amazing feature compared to where we're coming from with the magnetic stripes ones (and the date to sunset for good magnetic stripes in the EU has already been set IIRC).
A fully compromised reader could trick you in stealing your PIN (so that an accomplice could then later on steal the card physically) and a compromised reader could also trick you into signing a 2 EUR transaction while it's actually wiring 2 000 EUR out of your account but I think that's about it!?
It comes to this: either the card can be cloned from a compromised reader or it cannot. I don't think that someone inserting it's card and getting its PIN intercepted means: "Bad guy can do countless transactions for days on until the account is empty".
If I'm right, that's a very far cry from "protection comes from the contracts and regulations between the shops and the bank".
AIUI a compromised reader can fake one big transaction or maybe a few transaction in quick succession but as soon as the owner pulls its card, they cannot do anything anymore?
Aside from the fact that I wouldn't know what I was looking at, I've been tempted to crack open one of the Stripe M2 readers I have and look inside.
Unfortunately, out of 36 readers that I bought, 7 have "died" (2 won't hold a charge, 1 won't scan NFC, and 4 report "tampered"). That attrition rate is pretty bad on the surface but it doesn't tell the whole story of course, how often were they used? How old are they?
The answer to those questions is much more damning. The devices are 1-3 years old (I bought them over time) and have been used a max of 9 days total [0]. Yes, 9 days _total_ of use and 7 of 36 readers failed in some fashion. Oh, and the readers are all kept in hardshell cases with foam inserts (1 slot per reader) whenever they are moved.
Needless to say, I'm not a huge fan of the M2 readers but they are still the best option for me :/
[0] Some background, my company handles festival payments. We travel to events and handle the in-person payments (most happens on web/app) with iPads+M2 Readers. That's why there are so few "days of use" over 3 years.
I'd be sure to charge them before storing them for the next show. Most batteries don't like being stored for long periods in a low SoC state. And I'm sure the tamper requires a functional battery.
All readers are charged for a day minimum after a festival before I pull the power. I then normally power them up at least a week before the next event so I can update them all and check that no more have randomly died on me. I keep a healthy buffer of devices so that I can replace them without paying for express shipping from Stripe which saved me for the last event I did where I had 6 of them die (before that pre-event check I only had the 1 bad NFC reader from the previous year).
I have to assume that one of the hard-shell cases got thrown around a little too much which caused 4 readers to go into tamper mode. 3 of the tamper mode readers were in the same case but the other was in my nicest case and still had the issue ("nicest" = custom made case vs pick-and-pluck-style).
The tampers I can somewhat understand (still just so odd to have 4 die "at once"), maybe they did get banged up, but the failed NFC and not holding a charge issues are less acceptable to me given the time/use.
It's also possible that the root shell is opened up when the tamper seal is triggered.
Ie. The system is either in secure mode (with all necessary crypto keys for operation), or it is in insecure mode with a root shell open for debugging and failure analysis, but that transition also deleted the critical private keys.
I had the same idea, but no, I tried with a second, untampered one and I also got a working shell. So it does not seem to be dependent on the tamper state.
> Was my guess as well, maybe it's even possible to use it to flash new keys so the device can be used again?
What keys would you flash them with? Anything encrypted with your "new" keys can't be decrypted on the other end of the transaction anyway, so what would be the point?
> the exposed root shell does not seem to be as big of a risk as initially feared. ... I could not find any evidence that sensitive data, such as card details, could become compromised this way
Which is why modern card technologies like chip cards and tap-to-pay don't expose the sensitive numbers at all. The card reader can't steal a number that doesn't exist. Only magnetic stripe cards are so insecure, but the card reader exploited here doesn't even have a magnetic stripe reader.
That having been said, this isn't perfect security. While a chip/tap card is in contact with the reader, it can still be used for fraudulent purposes. And physical access can open the door to other exploits, like trying to break the card's own security or installing a camera to capture images of the card.
If this terminal is anything like the ones I've worked with, the device he had a root shell on was only the "same device" as whatever handles the card details in the sense that it lives in the same housing and on the same PCB. They are otherwise two separate computers.
In my case, the "outer" system was Android, so we could use ADB to control it however we liked--with relatively lax security. The "secure board" only took over for the part where it had to handle payment details. In order to test the payment flows we ended up revamping a bunch of 3D printers to hold a stylus instead because the inbuilt android tools couldn't see or touch anything that secure board was doing except for a relatively narrow set of actions like "start payment flow for $X" and "user canceled" and "payment for $X complete".
If you take a look at the binary that decides whether to boot the secure firmware or the tamper screen, it's probably trivial to patch to get the secure firmware running for more inspection. If the point of the linux system is networking and updates, that implies a method for updating the firmware of the secure portion which isn't ideal. If their check for whether it's tampered or not is in the linux userland, I'd be awfully suspect of their firmware update.
The (compromised) Linux decides whether to load the “compromised mode” code or the mp1 secure system? Sounds like an avenue to explore. It says the bootloader itself is secure, but that doesn’t mean much if it’s being loaded into a compromised environment, depending on where it is actually being executed. I guess the coprocessor could be considered a Secure Enclave of
Sorts, but the fact that Linux could load a separate bootloader and run that (somehow) is of concern.
No, it cannot load a separate bootloader. I tried to tamper with the loadercode (the "secure" bootloader), but it wouldn't boot. So I am guessing there is some third party (boot ROM) that verifies it.
Also, I think Linux always loads loadercode + mp1.img, regardless of the tamper state. The different code paths depending on tamper state are taken within the (integrity protected) loadercode.
Keep in mind that no tamper mode will be set if you use the external debug interface. If Linux is used for networking then maybe you could MITM payments.
If you want to try easy mode, check out those newfangled android-based credit card terminal. I bet they're much more rewarding, especially since you tap your pin on the screen. Juicy.
The touch controller is generally connected to a MUX controlled by the security processor. When entering sensitive data (PIN/PANs), the touch controller output is routed directly to the security processor, bypassing any Android-derived OS responsible for the GUI.
And as a user, I have absolutely no way of distinguishing this from a device that had all secure features removed, and is running a random Android that proxies the NFC or chip data to a real reader, siphoning off what they can, while my PIN gets proxied by a human typing it into the real reader in real time. All I'd notice is a second or so of latency.
That'd get you the PIN quite easily, but if they're designed the same way (with all the important bits being handed off to a secure secondary processor) you still wouldn't be able to do much with the card as modern cards do a whole load of cryptography on-card to prevent stuff like this.
The attack would only work on terminals where every payment option but the magnetic card reader is broken, but those should give off skimmer alert alarm bells before you ever see a PIN prompt.
I'm not sure which type of android terminals you have where you are, but in India they seem to be running Android Oreo (support ended in Jan '21). Yummy!
I love thinking of ways to exploit and circumvent hardware restrictions like the extensive tamper protection here, but it seems I'd assumed that once they were triggered it was game over. Apparently not so - still plenty of interesting bits left over to poke around with. Makes sense that the secure part gets properly disabled though, otherwise I'd lose all confidence in their designers.
That's possibly still true for the hardened processor: As TFA notes, that's not what was compromised here.
> [...] only text strings seem to be passed to a binary (display_tool), that issues some inter-processor messages. The same goes for the key pad or the card reader itself. I could not find any evidence that these peripherals could be accessed directly from Linux.
> Instead, there is an entirely separate processor, refered to as mp1, that seems to handle all the “secure” stuff, like handling the card, getting the pin and showing information on the screen. The “insecure” Linux, running on the second processor, mp2, only handles the networking, the updating, and the business logic.
From the description it sounded like the linux side may play some role in tamper event handling, but hopefully it can just also see it has occurred, otherwise getting a root shell first may lead to an opportunity to prevent the tamper event from clearing security keys.
Reading about all the tamper detection on the device makes me wonder what would be the easiest way to trigger the tamper mode. After all, being able to do that on just a handful of devices would be an efficient denial of service attack on a retail location when the majority - and sometimes all - of payments go through these things.
Readit News
But to validate those transactions, you must send them to the bank over the internet, and you'll get a visit from the feds/FBI/whatever if you do it.
There is no real protection on card readers (most use Linux with a small shitty password). The protection comes from the contracts and regulations between the shops and the banks.
Sure there is: only signed binaries can run, executable filesystem is read-only, data filesystem has noexec bit set, root login is disabled, crippled busybox misses a lot of functionality, keys are loaded from a secure area on bootup, master key injection only available when loading at the factory, bootup itself is more or less secure, tamper detection blanks the chip, etc.
Sure, if you have a cheap non-EMV certified Android terminal imported from Asia it'll probably use a standard Linux, with a rw root filesystem, with root login enabled *and* sudo enabled for the username used to execute applications, tamper-detection is non-existent, screen-casting not locked down, ports are all openable and busybox is more or less complete.
Source: Me. I developed (and still sometimes do) EMV applications for card acquisition for a few years. Even in dev mode (which requires the vendor to provide IDs of the developers), these things are very much locked down solidly.
Sounds good. Has anyone been hired to attempt to attack the device and find vulnerabilities?
Deleted Comment
Probably different vendors but this has not been my experience.
If a payment system is relying on my local privilige on some random-ass device to authenticate a payment it deserves every garbage request it gets.
While the comment is not quite true (see sibling replies), this part is spot on.
This is also why crackpot theories about people walking around with portable card readers and stealing money from contactless cards are false. Yes you can walk around and make those transactions, what comes after (and the setup you had to do before) is the problem. I'm not even sure whether you could get the money out before being caught and shut down. With how many people these days have push notifications for their transactions, I highly doubt that.
I got a notification asking me to confirm a transaction on the Visa and then looked in my app and found they'd actually got another transaction pending at a hotel. I called them up and the hotel said they would "kick out the guests" and refund me. Not sure why they didn't want to call the police on them, because when I called later they said I should report it to the police, but all of the transactions had been refunded so I literally had zero loss and there was nothing really to report... It was them who'd provided the services and suffered the loss, the hotel should have had the police remove them!
Anyway, on the same day the Visa had been used at the hotel, I also had some fraudulent transactions on the Amex, although most of them seemed to be automatically refunded by the vendor themselves (so maybe it was flagged by the vendor's anti-fraud mechanisms and refunded to avoid a chargeback from American Express) before I cancelled the card. They'd tried three times with a similar amount and they'd all refunded.
The other weird thing was that the hotel that the Visa was used at claimed that it had to be a card-present transaction or in a digital wallet, but I didn't get any notification about it being enrolled in a digital wallet and I always had the physical card with me. So not sure if that was mistaken or BS or if they managed to somehow fake the digital wallet.
But yeah it didn't work out for them because I caught the transaction the same day they'd checked in to a hotel with the card and then both were cancelled that day...
At the end of the day the money only goes from one bank account to another, account can be frozen, charge reversed, ... So you just need to secure the POS enough that user feel safe to use it and there is a low number of people that can hack them and are willing to risk prison.
I mean with the amount of stolen card details routinely traded and used successfully (at least for a while) and with how little crime like that is investigated or punished in some jurisdictions, I dunno...
Still it's not quite as simple as "taking the money from your card" like said crackpots think.
I'm afraid that's not true. Merchant terminals have secure hardware embedded inside to store the bank and interchange keys. If those keys leaked, someone could spoof legitimate transactions.
You mean, whenever those keys leak. It's not that hard to do, see e.g. https://media.ccc.de/v/32c3-7368-shopshifting#t=2207
That's happened at least several times already.
I believe breached PoS terminals were what happened in the big Target hack.
https://tech.target.com/blog/cybersecurity-easysweep
https://news.ycombinator.com/item?id=36788831
Not asking "teach me how to do this" but could you explain in a little more detail ?
You can read a card (stripe) with one of those cheap readers. The magnetic stripe is not encrypted and you can extract the card number (PAN), expiration date, and cardholder name. Some other less important bits too. You cannot extract the CVV this way, but that is not required for transactions.
Most cards are EMV now. That data is encrypted and it's read/write. These keys can leak, putting you back into a similar state as if you'd read the card via magnetic stripe.
But no amount of card reading gives you the ability to submit transactions to the network. For that, you'd need merchant credentials for their gateway or processor, and you'd usually need to have a presence on the merchant's network (to get through the upstream firewall).
These are all achievable things. Doing so gets you the ability to create transactions against the card. These transactions will be submitted to the network and approved or declined. If approved, funds will settle from the issuing bank to the merchant bank, possibly in multiple steps.
I'm oversimplifying a bit, but the essential point is that funds will settle to the merchant's bank account, not yours. You can cause some headaches, but you cannot steal money.
The compromise of a credit card terminal is only interesting because it gives an attacker the ability to steal the card details for all cards that are subsequently used at the compromised terminal. They can be saved and retrieved later, or sent out to a C&C server, etc. Then these card details can be used for all the usual types of credit card fraud.
The BDK for your merchant acquirer is held by them in an HSM or equivalent. The IPEK is device specific, derived from the BDK based on the terminal ID.
The individual keys for the HMAC are generated for each transaction and are cryptographically linked to a transaction ID and the IPEK, so that the acquirer can determine whether there are missing messages.
Card readers that comply with the latest EMV chip/contactless standards require a secure element that maintains the crypto information and only allows specific requests from the non-secure element and only provides encrypted blobs for transmission between the acquirer backend and the secure element.
https://en.wikipedia.org/wiki/Derived_unique_key_per_transac...
Not how it works at all, banks don't have some open API on the internet for processing card transactions
The first thing to understand at an even higher level about payment cards is that they have always had two separate and barely related components, Authorisation and Settlement.
Authorisation is concerned with whether this specific transaction has been approved in some sense by a card issuer. Authorization today is relatively high tech, there's somewhat decent cryptography, tamper resistance, uniqueness = they really care - and that's because when Authorization problems occur the banks might lose money, which they hate.
Settlement is "just" moving the money from one customer to another. $123.45 from Jim Smith to Terrible Goose Inc, done. This is very mid-late-20th century technology, we're not talking pieces of paper and scribbly hand writing, but fixed width ASCII fields on magnetic tape is fine - it's the customer's money so the banks don't care more than legally required.
Settlement replays are how you get "accidents" where a big store's customers all get charged twice for a whole day - the associated Authorizations can't be replayed, that's the banks money at risk - but the settlements aren't protected.
Merchants can, and some do, choose not to care about Authorization. In a huge business it could make sense to eat say 2% of sales as undetected fraud (ie you never receive payment) rather than have any transactions fail. If you operate a food truck using a terminal to take $1000 per day on your iPhone the people who supply your terminal may not let you opt out because that's risk they don't want. But if Jeff Bezos or Doug McMillon makes more without Auth he's turning it off.
Not that a random person can hit these endpoints, unauthenticated, and try to run a transaction.
I believe what this comment is getting at is that making fake transactions is useless without a connection to a bank that will execute them.
Is there any proof to this statement or are you just trying to scare people? I think it's possible there are bigger groups that would have their attention and a single fraudulent transaction would just be noise.
In a typical scenario my understanding is that you get the terminal from your acquirer - this is your broker to the card networks. When the terminal makes a transaction, it does some crypto magic using its own keys (that identify it to the acquirer), sends that to the card which does more crypto magic using its own keys, and finally the result of that is sent to the acquirer.
If you do this flow yourself with fake keys you'd get the card to sign a transaction for your fake terminal's key (assuming you know the card's PIN of course - unless you're happy to forego any CVM), but you have no acquirer that would accept said transaction, so I don't see how you could commit a crime here even if you wanted to? You just got some meaningless bytes back.
And of course, if you have an actually valid terminal key that is trusted by an acquirer and do all this, you've effectively just made a normal payment - if the person was willingly paying you then no crime either, and otherwise it's no different than using a legit terminal to bill someone without their knowledge.
I definitely remember making an _offline_ payment with an AMEX card at a restaurant in the UK some 10 years ago.
Also, most airlines that take payments on board also run the terminals in offline mode.
There must be some mapping of BIN codes and whether to allow an offline transaction.
Wait wait wait... Aren't these EMV cards smart cards using the Java smart card technology? I thought these were heavily using encryption, including PKCS.
They're using challenge/response protected by the PIN no!? If I am not mistaken if you insert a card in a totally compromised reader you cannot clone the card: that alone is already quite an amazing feature compared to where we're coming from with the magnetic stripes ones (and the date to sunset for good magnetic stripes in the EU has already been set IIRC).
A fully compromised reader could trick you in stealing your PIN (so that an accomplice could then later on steal the card physically) and a compromised reader could also trick you into signing a 2 EUR transaction while it's actually wiring 2 000 EUR out of your account but I think that's about it!?
It comes to this: either the card can be cloned from a compromised reader or it cannot. I don't think that someone inserting it's card and getting its PIN intercepted means: "Bad guy can do countless transactions for days on until the account is empty".
If I'm right, that's a very far cry from "protection comes from the contracts and regulations between the shops and the bank".
AIUI a compromised reader can fake one big transaction or maybe a few transaction in quick succession but as soon as the owner pulls its card, they cannot do anything anymore?
Unfortunately, out of 36 readers that I bought, 7 have "died" (2 won't hold a charge, 1 won't scan NFC, and 4 report "tampered"). That attrition rate is pretty bad on the surface but it doesn't tell the whole story of course, how often were they used? How old are they?
The answer to those questions is much more damning. The devices are 1-3 years old (I bought them over time) and have been used a max of 9 days total [0]. Yes, 9 days _total_ of use and 7 of 36 readers failed in some fashion. Oh, and the readers are all kept in hardshell cases with foam inserts (1 slot per reader) whenever they are moved.
Needless to say, I'm not a huge fan of the M2 readers but they are still the best option for me :/
[0] Some background, my company handles festival payments. We travel to events and handle the in-person payments (most happens on web/app) with iPads+M2 Readers. That's why there are so few "days of use" over 3 years.
I have to assume that one of the hard-shell cases got thrown around a little too much which caused 4 readers to go into tamper mode. 3 of the tamper mode readers were in the same case but the other was in my nicest case and still had the issue ("nicest" = custom made case vs pick-and-pluck-style).
The tampers I can somewhat understand (still just so odd to have 4 die "at once"), maybe they did get banged up, but the failed NFC and not holding a charge issues are less acceptable to me given the time/use.
Ie. The system is either in secure mode (with all necessary crypto keys for operation), or it is in insecure mode with a root shell open for debugging and failure analysis, but that transition also deleted the critical private keys.
Now I am curious if I can find a terminal myself, if they are actually getting phased out it might not be too difficult to find a used one...
What keys would you flash them with? Anything encrypted with your "new" keys can't be decrypted on the other end of the transaction anyway, so what would be the point?
> the exposed root shell does not seem to be as big of a risk as initially feared. ... I could not find any evidence that sensitive data, such as card details, could become compromised this way
A good read for security designers, though.
In security, physical access and to a lesser extent root access are equivalent to a guaranteed hack.
That having been said, this isn't perfect security. While a chip/tap card is in contact with the reader, it can still be used for fraudulent purposes. And physical access can open the door to other exploits, like trying to break the card's own security or installing a camera to capture images of the card.
In my case, the "outer" system was Android, so we could use ADB to control it however we liked--with relatively lax security. The "secure board" only took over for the part where it had to handle payment details. In order to test the payment flows we ended up revamping a bunch of 3D printers to hold a stylus instead because the inbuilt android tools couldn't see or touch anything that secure board was doing except for a relatively narrow set of actions like "start payment flow for $X" and "user canceled" and "payment for $X complete".
Deleted Comment
Also, I think Linux always loads loadercode + mp1.img, regardless of the tamper state. The different code paths depending on tamper state are taken within the (integrity protected) loadercode.
So the applications in between, that would be accessible in an attack like this, can't view the PIN.
The attack would only work on terminals where every payment option but the magnetic card reader is broken, but those should give off skimmer alert alarm bells before you ever see a PIN prompt.
I love thinking of ways to exploit and circumvent hardware restrictions like the extensive tamper protection here, but it seems I'd assumed that once they were triggered it was game over. Apparently not so - still plenty of interesting bits left over to poke around with. Makes sense that the secure part gets properly disabled though, otherwise I'd lose all confidence in their designers.
> [...] only text strings seem to be passed to a binary (display_tool), that issues some inter-processor messages. The same goes for the key pad or the card reader itself. I could not find any evidence that these peripherals could be accessed directly from Linux.
> Instead, there is an entirely separate processor, refered to as mp1, that seems to handle all the “secure” stuff, like handling the card, getting the pin and showing information on the screen. The “insecure” Linux, running on the second processor, mp2, only handles the networking, the updating, and the business logic.