[Liftyee]

Bravo!

I love thinking of ways to exploit and circumvent hardware restrictions like the extensive tamper protection here, but it seems I'd assumed that once they were triggered it was game over. Apparently not so - still plenty of interesting bits left over to poke around with. Makes sense that the secure part gets properly disabled though, otherwise I'd lose all confidence in their designers.

[lxgr]

That's possibly still true for the hardened processor: As TFA notes, that's not what was compromised here.

> [...] only text strings seem to be passed to a binary (display_tool), that issues some inter-processor messages. The same goes for the key pad or the card reader itself. I could not find any evidence that these peripherals could be accessed directly from Linux.

> Instead, there is an entirely separate processor, refered to as mp1, that seems to handle all the “secure” stuff, like handling the card, getting the pin and showing information on the screen. The “insecure” Linux, running on the second processor, mp2, only handles the networking, the updating, and the business logic.

[fredthestair]

From the description it sounded like the linux side may play some role in tamper event handling, but hopefully it can just also see it has occurred, otherwise getting a root shell first may lead to an opportunity to prevent the tamper event from clearing security keys.