> 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.
It does look like the EMV contact standard allows for falling back to SDA operation, which involves the card just handing over the static application data, which doesn't ever change and can be cloned fairly easily onto a fake card. I don't know if it's the same data as is encoded in the magnetic stripe, but it's not much better. A hacked card reader might be able to exploit this by pretending to only support SDA. On the other hand, cards can mitigate this by not supporting SDA.
Banks can mitigate most of the effect of this by putting all risk on the merchant if they accept SDA transactions, and then letting the merchant make the choice.
Someone gets their static data skimmed and the card misused? The issuer profits from the chargeback fees...
I've seen stores still have a magnetic readers on their machines, but it's used for vouchers, loyalty cards etc or to scan card numbers to issue refunds. But not for payments.
I've never seen vouchers or loyalty cards handled on payment terminals here in the Netherlands, they always just have a regular bar code that the cashier scans (or that you scan yourself, at a self-checkout).
Your bank holds the public key of the "a certain credit card".
Your thing in the shape of a credit card is a HSM that holds the private key of the "a certain credit card".
A public key (your bank) can verify if a given digital signature generated by a private key (yor card) is valid or not.
The "CC Terminal" is a device that given the inputs (timestamp+value_of_transaction+password), asks the "CC HSM" to generate the signature of said values. "CC HSM" is smart and will ON PURPOSE refuse to generate valid signatures if you're being funny and inputing wrong passwords. Bank can further check if the signature makes sense or not.
Merchant doesn't need to know the public key, the private key, or your password.
> The "CC Terminal" is a device that given the inputs (timestamp+value_of_transaction+password), asks the "CC HSM" to generate the signature of said values.
Which makes a hacked terminal problematic since it can display $1.00 as the amount and actually request the CC HSM to sign a $500 transaction.
In a more safe world, the CC HSM would have it's own display and pin entry, to avoid this exact issue. You really can't validate if the terminal is honest.
Because as you rightly pointed out, who said the evil merchant or MitM thief are either MitM'ing the display system, or even have total control of the display system?
Importantly, though, the credit card system is based around more than just the cryptography involved. By removing the ability to obtain portable payment credentials, the scammer is forced to perform the transaction right then and there. This allows the network to pinpoint the source of the compromise.
A scummy merchant can be banned, a hacked terminal can be removed and examined, etc. And, unlike say a blockchain, a fraudulent transaction can be reversed.
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.
If the integrity protection is like any of the TPM implementations I've seen, it often doesn't apply once the thing is already in memory, just that when it first loads that it (and everything before it) was attested. This matters a lot once you get into the userland, esp with an older system, since any random off the shelf exploit can be chained into modifying kernel memory with the intention of modifying the binfmt loader for loadercode (or anything else). Of course, if the loadercode is just a thin shim to prod the secure firmware and that's what has the tamper mode rather than being two separate firmwares for controlling the display, you probably can't progress very far.
I'm essentially skeptical that if you have the ability to control the linux root filesystem for a very old linux distro that any other security measures for the linux binaries themselves matter.
Linux does not handle any secure binaries. It only shares a filesystem where the signed and encrypted secure images are.
The loadercode verification is not done in Linux, rather the insecure bootloader will read it from the filesystem load it to some memory address, that's it. From there, it is integrity-checked (?) and then executes on the second, secure core. This will then verify and chainload the secure image.
That depends on how they're set up. There is no real protocol difference between MasterCard and Visa debit vs credit. Delhaize in Belgium also uses them and you can definitely use all types of credit cards with them (at least Visa/MC and even AmEx).
> 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.