Tamper-resistance
Tamper resistance refers to the ability of a system to resist attacks against its physical incarnation when in the hands of an attacker. From the perspective of the threat model, a key point is that we assume an adversary has gained physical access to the gadget. Duration of access and final condition of the device may vary depending on attack scenario:
- Temporary vs. permanent. In the first case, the user may have temporarily left their device unattended in a hotel room, giving the attacker an opportunity to extract cryptographic keys or implant a backdoor. But the time allotted for accomplishing that task is limited. The adversary must ultimately return the device– or its functional clone– to avoid raising suspicion. In the second case, the device may have been lost or otherwise captured with no intention of being returned to its rightful owner, granting the attacker unlimited time to work.
- Destructive vs. stealthy: This is mainly a concern for attackers who want to avoid detection, when returning the device in a completely mangled or damaged state will not do. This may either limit the range of attacks possible or it may require an elaborate substitution scheme following a successful attack. For example, if the goal is extracting secret keys from a smart-card, it may be acceptable to destroy the card in the process, as long as an identical-looking card can be created to behave functionally when it is provisioned with same secret keys extracted out of the original. The user will not be any wiser.
Lasers and spectrometers
Attacks are commonly grouped into three categories, using the terminology from Tunstall et al:
- Non-invasive. These approaches attempt to extract information without modifying the card. For example simply measuring the time taken to complete various operations with a high-precision timer or introducing faults by varying the power-supply (without frying the chip) do not cause permanent damage to the card but may result in disclosure of information that was supposed to be contained in the card.
- Semi-invasive. Moving one step closer to the hardware, in this category are attacks that require the surface of the chip to be exposed. This includes passively monitoring electro-magnetic emanations from the chip as well as introducing temporary glitches, for example using precisely aimed laser pulses.
- Invasive. In the final group are attacks directly targeting the internal architecture of the chip, using sophisticated lab equipment. For example it may involve placing probes to monitor bus lines or even creating new wiring that alters the logic.
Comparison to off-the-shelf mobile hardware
Standard mobile device architecture does not even attempt at resisting physical attacks. For example reading any secrets in storage is as easy as removing the flash and using a standard connector to mount the same disk from another device. (Incidentally, disk encryption does little to hinder data recovery: Android disk encryption keys are derived from a user-chosen secret subject to brute-forcing.**) By contrast extracting data stored in the EEPROM or flash storage of a modern secure element– while not impossible by any means– requires significantly more work and dedicated laboratory equipment.
Similarly there is no attempt to reduce side-channel emissions on a standard ARM CPU such as shielding to reduce emanations or hide power consumption patterns. As simple experiments demonstrate, there is no reason to zap anything with lasers or carry out elaborate attacks to reverse engineer the circuitry: an ARM processor radiates so much in the way of EF radiation that meaningful signals can be picked up without even opening the case to reveal information about cryptographic operations. By contrast resistance to physical attacks are core part of the Common Criteria (CC) and FIPS 140-2 verification standards around cryptographic hardware. For example the SmartMX embedded secure element present in most NFC-enabled Android devices is part of a family of processors with EAL5+ level assurance according to CC.
Bottom line: for the purposes of resisting hardware attacks when the device lands in the hands of an attacker, there is no contest between an application implemented storing secrets on the main Android systems– such as a payment application using HCE– versus one implemented on dedicated cryptographic hardware such as the embedded secure element.
CP
** Android made matters worse with a design blunder: it forces the disk-encryption secret to be identical to the screen-unlock one. In other words that pattern/PIN/passphrase used to unlock the screen is the only secret input to a “slow” key-generation scheme that outputs the disk encryption key. Because unlocking the screen is a very common operation, this all but guarantees that a low-entropy, easily brute-forced secret will be used. This may have been a usability trade-off based on the assumption that asking users to juggle two different secrets– one only entered during boot and one used frequently for screen unlock– is too much.
Random Oracle 