[lelanthran]

> 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.

[cluckindan]

The OP device tried to mount a USB volume and would have started dropbear if it had been found (presumably in PATH). Maybe maybe maybe…

[timewizard]

> 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?

[lelanthran]

> 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).

[dijit]

How does the binary signing work?

I’m not looking to hack anything, but it sounds cool to have signed binaries only on linux!!

[lelanthran]

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.

[_djo_]

Varies from manufacturer to manufacturer. This is Ingenico's approach, for instance: https://ingenico.com/en/products-services/services/security-...

[shakna]

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.

[zoobab]

ah good to know, I wanted that feature back in 2018 :-)

[account42]

> Even in dev mode (which requires the vendor to provide IDs of the developers), these things are very much locked down solidly.

Probably different vendors but this has not been my experience.

[pabs3]

Have you considered using dm-verity instead of signed binaries?

[lelanthran]

> 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.

[pabs3]

Authenticating the block device before it reaches the Linux kernel filesystem code.

[Y_Y]

If I buy a device it sure as shit better give me root.

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.

[account42]

In many cases you are not buying these devices, you are only renting them.

[lelanthran]

> If a payment system is relying on my local privilige on some random-ass device to authenticate a payment

What makes you think it does?

[fragmede]

> If I buy a device it sure as shit better give me root

how's that been working out in practice? change the ring tone on your washing machine, dryer, and microwave already?

[Y_Y]

Those are all mechanical. I could if I fancied, but they're inoffensive and I have more pressing calls for my attention.

[MintPaw]

I didn't even know there were mechanical microwaves.

[wkat4242]

Never seen the ones with a mechanical egg timer as the time control? Those usually even have a mechanical bell.

Of course the microwave generator itself is not mechanical :)