4 ms·

> 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

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

pabs3 1y ago
Have you considered using dm-verity instead of signed binaries?
- lelanthran 1y ago
  > 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 1y ago
    Authenticating the block device before it reaches the Linux kernel filesystem code.
timewizard 1y ago
> 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 1y ago
  > 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 1y ago
    How does the binary signing work? I’m not looking to hack anything, but it sounds cool to have signed binaries only on linux!!
    - _djo_ 1y ago
      Varies from manufacturer to manufacturer. This is Ingenico's approach, for instance: https://ingenico.com/en/products-services/services/security-solutions/e-sign https://ingenico.com/en/products-services/services/security-...
    - shakna 1y ago
      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 1y ago
        ah good to know, I wanted that feature back in 2018 :-)
    - lelanthran 1y ago
      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.
deleted 1y ago
[deleted]
cluckindan 1y ago
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…
Y_Y 1y ago
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.
- fragmede 1y ago
  > 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 1y ago
    Those are all mechanical. I could if I fancied, but they're inoffensive and I have more pressing calls for my attention.
    - MintPaw 1y ago
      I didn't even know there were mechanical microwaves.
      - wkat4242 1y ago
        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 :)
- lelanthran 1y ago
  > 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?
- account42 1y ago
  In many cases you are not buying these devices, you are only renting them.
account42 1y ago
> 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 1y ago

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

lelanthran 1y ago
> 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 1y ago
  Authenticating the block device before it reaches the Linux kernel filesystem code.

timewizard 1y ago

> 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 1y ago
> 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 1y ago
  How does the binary signing work? I’m not looking to hack anything, but it sounds cool to have signed binaries only on linux!!
  - _djo_ 1y ago
    Varies from manufacturer to manufacturer. This is Ingenico's approach, for instance: https://ingenico.com/en/products-services/services/security-solutions/e-sign https://ingenico.com/en/products-services/services/security-...
  - shakna 1y ago
    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 1y ago
      ah good to know, I wanted that feature back in 2018 :-)
  - lelanthran 1y ago
    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.

deleted 1y ago

[deleted]

cluckindan 1y ago

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…

Y_Y 1y ago

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.

fragmede 1y ago
> 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 1y ago
  Those are all mechanical. I could if I fancied, but they're inoffensive and I have more pressing calls for my attention.
  - MintPaw 1y ago
    I didn't even know there were mechanical microwaves.
    - wkat4242 1y ago
      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 :)
lelanthran 1y ago
> 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?
account42 1y ago
In many cases you are not buying these devices, you are only renting them.

account42 1y ago

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