[zzzeek]

is the rooted mp2 subsystem responsible for acquiring the tamper state from the hardware that's passed off to the mp1 system? the diagram seems to indicate this is the case. Why not then try to disable the tamper signal and get mp1 to boot up with the device opened?

[stgl]

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.

[qmarchi]

Disc: Former Visa Employee

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

[tomsonj]

Reminds me of "Every 10-ft wall can be defeated with an 11-ft ladder"