> 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?
> Sounds good. Has anyone been hired to attempt to attack the device and find vulnerabilities?
In the company I work with, yup. I'm not sure about the rest of the industry, but the security in place ensures that even the developers of the EMV applications are treated as hostile actors.
The certification process itself does do a little bit of malicious attempts too (try to get the terminal to do something out of spec, like during pin-entry, etc).
Varies from vendor to vendor; signed-binaries-only is part of the certification process but the exact mechanism itself is not (or maybe that has changed, not sure).
The way it worked in 2003 (when I first wrote EMV applications) was, when we have a binary that we are ready to deploy, we ship that binary to the manufacturer (Schlumbeger(sp?), at that time), if it passes cert-testing, they sign it and ship it back and that's what we would program the terminals with.
The way it works now is pretty much the same - we build an APK bundle, send it to the manufacturer (Verifone, Pax, etc) and after signing they make it available on their appstore which their terminal can access.
Whilst I'm sure they use something else, Linux does have an experimental extension, "Integrity Measurement Architecture" extension that allows you to sign and verify RSA keys against every binary.
> Have you considered using dm-verity instead of signed binaries?
Why? I don't see any benefits.
In any case, the developers don't get a say in what is used to secure the terminal. The manufacturer decides that, then they get the hardware+firmware certified.
The terminals the developers get are already certified and locked down.
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.