New causes of side channel

Question

Until recently, my list of what can cause side channels exfiltrating secret data (including data depending on secrets) from code running in a computer was limited to:

1. Hardware emissions: power (e.g. SPA), electromagnetic (e.g. DEMA, Tx/Rx LEDs, [update] other hardware snooping…), sound (e.g. from power supply)
2. Rogue access to memory/media: e.g. by kernel code, buffer overflow, side effect of memory management, JTAG interface, DMA, cold boot, microprobing, or more generally bypassing access restrictions. I put exfiltration by any communication interface in this category.
3. Instruction with data-dependent timing which can cause leak by timing variation: e.g. multiplication, see this.
4. Code branching according to secret (if, switch..) which can cause leak by timing variation or other mean like shared branch prediction logic. I put in this category conditional execution according to a condition code without branching, when it causes a leak.
5. Memory read or write to secret-dependent memory location (e.g. table read at key-dependent address), which can cause leak by timing variation or other mean like shared cache.

Now we must reportedly add Data Memory-dependent Prefetcher in some (Apple) CPUs:

DMP activates (and attempts to dereference) data loaded from memory that "looks like" a pointer.

So now the value of data read in memory can cause a leak by timing or other means like shared cache (other than hardware emissions)!! For details see Boru Chen, Yingchen Wang, Pradyumna Shome, Christopher W. Fletcher, David Kohlbrenner, Riccardo Paccagnella and Daniel Genkin: GoFetch: Breaking Constant-Time Cryptographic Implementations Using Data Memory-Dependent Prefetchers

Question: Can the value of data written to memory also cause a leak in some common CPUs? I'm in particular thinking of suppression of memory writes when some gizmo in the memory subsystem notices that the value being written is the same as the last value read at that location.

Are there other known causes of side channels on common computer gear often doing cryptography (desktop, server, mainframe, portable, mobile, embedded CPUs, GPU…) that I did not discuss?

Answer 1

Question: Can the value of data written to memory also cause a leak in some common CPUs? I'm in particular thinking of suppression of memory writes when some gizmo in the memory subsystem notices that the value being written is the same at the last value read at that location.

Yes. As of a few years ago, Intel CPUs have implemented zero-on-zero redundant store elimination, which has a measurable performance impact in some cases, i.e., is a side channel leak. See, for example:

• Travis Downs, "Hardware Store Elimination", Performance Matters blog, 2020-05-13 (archive)
• Travis Downs, "Ice Lake Store Elimination", Performance Matters blog, 2020-05-18 (archive)

Intel appears to have disabled it in microcode updates, but it's hard to know if that's reliable:

• Travis Downs, "Your CPU May Have Slowed Down on Wednesday", Performance Matters blog, 2021-06-17 (archive)

Answer 2

So now the value of data read in memory can cause a leak

That's not a new thing. It's also how many transient execution vulnerabilities, which rose to popular consciousness with Spectre and Meltdown are vulnerabilities. The basic principle of a transient execution vulnerability is to have code that would use a sensitive value in a leaky way, but that code is guarded by a false condition. The attacker tries to arrange for the code to be executed speculatively, for example by priming a branch predictor. Since the condition is false, the sensitive value is not actually used in a directly observable way. But the execution leaks information through a side channel.

For example, consider the following pseudocode, where secret is a variable whose value is sensitive, and false_condition() is false by construction of the software:

if false_condition():
    f(array[secret])

The processor doesn't know that false_condition() is false, so it might speculatively fetch array[secret], which causes a cache load that leaks the value of secret.

Microarchitectural data sampling is another way speculative execution might read something it shouldn't. Hyperthreading on x86 processors has weaknesses where one processor thread might speculatively start to process value that actually belongs to another thread. A few cycles later, the processor notices that the threads are mingling and cancels the speculative execution, but this might have had an observable side channel. This fits the pattern above, except that here, false_condition() is not software but a check inside the processor that could be symbolically written as thread_of_instruction == thread_of_value.

Can the value of data written to memory also cause a leak in some common CPUs?

It can, at least through software. Linux supports page deduplication. This feature is intended for hypervisors that run many partitions with mostly the same software. When this feature is enabled, the hypervisor scans the memory for identical pages. When it finds two physical pages P1 and P2 with identical content, the MMU tables pointing to P2 are updated to point to P1, and P2 is freed. This allows an attacker to conduct an oracle attack: given a victim page with mostly known content, the attacker populates a page with the possible content, waits for the deduplicator. Based on the timing of a subsequent modification, the attacker figures out whether the page got deduplicated, i.e. whether it was identical to the victim page.

---

What these attacks have in common is that unlike “classical” timing attacks on cryptographic implementations, they do not directly involve cryptographic code. What determines whether your cryptographic secrets leak is not the code that manipulates them, but other code in the operating system.

Answer 3

Assuming that I have physical access to a system, ie: I can get near it, there are two things that I have noticed that "leak" information, and they are both related to EMI.

1. SRAM snooping

SRAM transmission lines are terminated for "noise"; however, if you decided to excite the board with a fundamental frequency of the SRAM frequency, you'll can see data changing the emission spectrum on a network vector analyzer. I've never tried to actually extract data, but this something that I'm sure you can do as our VAs are 60GHz. We've noticed this in the labs as RF pollution so we just move things around until you don't see it. I can describe how an attack would work in detail, but the summary is that you have transmission lines that are specially designed not cause emissions; however, you can "rattle" them electrically into emission because of the laws of E&M.

2. Everything Snooping

Quantum magnetometers allow me to see the magnetic perturbations in a magnetic field. The fact that you can detect a submarine at 10,000m is very similar to detecting changes in magnetic field of an IC due to charge at 0.1m. I took some data with Quspin magnetometer to look at circuit noise; however, I never did a dive into correlating the data with anything except for figuring out where to put the sensors.

Both of these could easily be explored with a collaboration between a cryptographer/RF group and cryptography/quantum sensor group. In the cryptographer/RF case, I'm confident that you'd be able to extraction something because the "noise" that you see is not random, which means it's like correlated to something.