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.
"17 apr 2004 — GPL testing in court by the Netfilter/Iptables team, due to refuse to give source code of the Sitecom WL-122 (isl3893 based!). In the same time, some source code has appeared on the webserver of Sitecom."
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.
Well, I felt like I first had to get a feeling for what I am working with. Hardware, what SoC, interfaces, flash etc... Otherwise I am too much in the dark. But sure, in hindsight I could've just tapped the debug connector and could have been done with it.
No, I got a shell on second, untampered one, as well.
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.
The card details and payment are encrypted and then signed by the firmware running in the secure/trusted zone, using public keys provided by the acquirer.
I cannot tell for sure. I didn't have time to really look at the Linux applications and what they do exactly. My guess is that most of the sensitive stuff is done on mp1 (reading the card, verifying the pin etc.) and the Linux just acts as untrusted relay to the network. Denial of service should be possible in the sense that it could just put the system in a boot loop.
That's sounds like an overcomplicatedengineer solution.
The 10x engineer uses a hammer to deny service.
Aside: I'm an artist-engineer. I like the performance art of using an oversized hammer to solve a problem that isn't obviously solved using a hammer - and I love the discovery process when my aims fail.
No, I don't think so. I think the tamper logic is implemented in hardware and cannot be easily fooled. It seems like both mp1 and mp2 access memory-mapped registers of the tamper subsystem to check its status (and other hardware system stuff like reset reason etc.)
However, I am assuming that there is a way to gain write access to the hardware registers from Linux. After all, the manufacturer has the ability to "un-tamper" devices and there is this nor_update tool in Linux that might be able to do it. But my guess would be that first a key has to be loaded through some authenticated interface in order to unlock that functionality.
Generally, these devices will use the mp1 to do all of the cryptographic operations around the devices.
The biggest part of this is the keys defined between the terminal and the acceptance gateway (something like CyberSource or Authorize.net).
When the temper protection is tripped the keys that are used are immediately dropped from RAM and you can't recover them, they have to manually be input into the device again to reset the tamper protection.
(Side Note: keys are specific to a merchant. If you're able to extract them, it limits the blowback.)
