3

I am having trouble to completely understand the Prime & Probe attack: My current understanding is this:

  1. Priming phase: The attacker occupies all cache sets with attacker data.

  2. Probe phase: The attacker measures access time to figure out which set of data was accessed by the victim.

But the set is only part of the address. How can an attacker still deduce which address exactly was accessed? I know that this something to do with spatial/temporal locality, but I am struggling to understand how exactly an attacker could abuse this to obtain the full address a victim accessed?

Edit: To add some more context: I am studying for an exam at the moment and after a general explanation of the prime & probe attack, the slide mentions the following:

Question: The set is only a part of the address, why does it still give away important information to the attacker?

A: Because the cache makes use of the temporal & spatial locality properties of computer programs

Where spatial and temporal locality refer to the assumption that in programs, when an address is accessed it is likely to be accessed again in the near future (temporal locality) or an address near to it is likely to be accessed again in the near feature (spatial locality). The slides then conclude that because of temporal & spatial locality:

Data objects with ”close” proximity, i.e. entries of a table, are stored in different sets

(For example, for a two-dimensional table, each table line would be stored in a different set). This is to prevent that those object compete for the cache.

But I still do not understand how this could help us for side-channel attacks?

CryptoThomas
  • 31
  • 1
  • 3
  • In short, they don't, and they don't need to. Look into e.g. ̈Kasper and Schwabe 2009; they explain how cache timing attacks against AES work. In essence, they don't learn everything, they just learn enough to significantly reduce the number of keys they have to try. –  Jul 09 '19 at 16:04
  • Thanks, that already clarifies a lot! I am studying for an exam at the moment and the slides explicitly mention temporal and spatial locality, I edited the question to reflect that context better. – CryptoThomas Jul 09 '19 at 16:39
  • I don't understand what the answer means by "temporal and spatial locality", but I suspect it's a fancy way of referring to the fact that cache lines are 64b, so more than just the one relevant address is loaded at once (everything 'spatially' nearby it in RAM), and if you access a memory location soon after it's been accessed before ('temporal' locality?) it'll be faster the second time. Personally, it sounds like a bad study guide, because that's not actually what causes the vuln... so I'm at a loss here. I hope someone can help you better. –  Jul 09 '19 at 18:51
  • Edited the question again, sorry for not clarifying: Spatial and temporal locality refer to assumptions that cause certain behavior than loading arrays into the cache (namely storing data objects with close proximity in different cache sets. Imagine a 2d table: Each table row is stored in a different cache set). Does this help in any way? – CryptoThomas Jul 09 '19 at 20:50
  • It does, actually. I think I have enough to write up an answer, give me a few minutes. –  Jul 09 '19 at 21:02
  • FWIW, for a real-life example of how cache-related timing helps with side-channel attacks, see this paper showing a real attack against AES. –  Jul 09 '19 at 21:25

1 Answers1

2

Just to reiterate, this is how cache timing attacks work:

  1. Attacker fills up the cache with arbitrary data. The actual values don't matter, so long as the cache is full of data that isn't what's accessed by the algorithm.
  2. Some portion (or all) of the algorithm runs.
  3. Based on how long it took and their knowledge of the relevant algorithm, the attacker can estimate what cache lines were loaded. Note that this does not have to happen locally -- depending on how the encryption is used, it can be done remotely as well, even over a busy network!

See, e.g., this paper for a description of using cache timing attacks against (at the time) common AES implementations. In short, because you know how the algorithm works (Kerckhoff's Principle) and nonces come from the client, you can pick your nonces and messages carefully so that certain nonces will trigger a significantly different timing. The only uncontrolled variable is the secret key, so it must be influencing the timing. Repeat with enough nonces, and you'll be able to determine that a certain timing pattern can only occur with a certain set of nonces if a specific byte of the key is one of 23 options, instead of one in 28.

While it won't give you the exact address used, you don't need that, and in fact it probably wouldn't be very useful without context. What's important is that, because certain data is loaded into the cache and therefore quicker to access, you now have more constraints on the possibilities than you did before, and you can brute-force within those constraints much faster than you could the full, 128-bit key.