CWE-1255 describes comparison logic whose power consumption differs depending on whether a guess is right. An attacker who can measure the power a device uses while it checks a security token can work out the reference value. It affects smart cards, secure elements, embedded authentication and any hardware that checks a PIN, password or MAC.
How it happens
The power a device consumes can be monitored in real time. If the algorithm that evaluates a security token does not account for that kind of measurement, the power drawn can vary with the result of each comparison against the reference value.
Add unlimited retries and the picture gets worse. The power difference between a good entry and a bad entry can be observed over many attempts, which lets the attacker decide whether each part of their entry is correct, and so compute the reference value.
MITRE's example is a hardware module that checks a user-provided password or PIN against a stored value byte by byte. In the C code, a matching byte sets a flag one way and a non-matching byte sets it another way. Because the algorithm uses a different number of 1s and 0s for good and bad bytes, a different amount of power is drawn for a good comparison than for a bad one. By stopping the evaluation before it completes and repeating, an attacker can guess the right value for each byte.
The record also lists CVE-2020-12788, a CMAC verification that is vulnerable to timing and power attacks. See its Gold page.
What an attacker gains
The record's consequences are wide: confidentiality, integrity, availability, access control, authentication and authorization, including reading and modifying memory and files, executing unauthorized code or commands, gaining privileges or assuming identity, and bypassing protection mechanisms. Recovering a reference token usually means the attacker can pass the check and everything it guards.
How to find it
The record lists no detection methods. Consider these checks:
- List every place where hardware compares a user-supplied value against a stored secret.
- Check whether the comparison runs the same operations for good and bad input.
- Check whether the number of retries is limited, and whether the counter is updated before the check.
- If you can, measure power during good and bad entries on a test device.
How to fix it
MITRE lists several mitigations, and none is free.
- Design for it. Consider each security token check and the power used for a good token compared with a bad one. An alternative is an all at once check where a retry counter is incremented before the check.
- Parallelize shifting of secret data. The wider the bus, the more effective this is.
- Add random data. Add random data to each crypto operation and subtract it afterwards. This is highly effective but costs performance, area and power, and it needs a random number generator.
- Filter. If the architecture cannot prevent the attack, filtering components may reduce the ability to carry it out. Consider whether the filter elements can be physically removed.
- Rotate secrets. During integration, avoid using a single secret for a long time, for example with frequent key updates. It limits the data compromised but adds complexity.
The entry's improved C example works by obscuring consumption with opposing bit flips. MITRE adds a caution that the initial change of bit values could still show power indications on some hardware, and the result needs to be measured.
Quick check
Why do unlimited retries make this worse?
They let an attacker repeat the measurement as often as needed, so small power differences between good and bad entries add up to a usable signal.
What is the retry counter advice?
Use an all at once check with the retry counter incremented before the check, so stopping the check early does not give the attacker a free attempt.
Does masking guarantee safety?
No. MITRE says the result must be measured on the real hardware, since initial bit changes could still indicate power use.
