4
$\begingroup$

Reading about typical cache timing attacks, they seem to be based on intentional eviction of cache lines and timing how long an operation takes. It seems as if those attacks rely upon these tables being hardcoded constants in read-only sections of an executable, and are therefore subject to sharing memory pages.

If you ensure that your AES tables are on physical pages that are private to your process, is that enough to thwart timing-based attacks? In this situation, an attacker running as a normal-privileged process on the same machine would not be able to perform such tricks as clflushing the cache lines containing the table.

Note that this technique also requires that the contents of the pages are also unique, not just private: some operating systems might notice memory pages with identical contents and coalesce them to a single physical page as copy-on-write.

$\endgroup$
3
$\begingroup$

No

You are misunderstanding how such attacks work. It's not that your page gets shared to some attacker process. Attacker might not even be present on your computer, only measuring time over internet. Such attacks only depend on fact that if you access index 5, then every next access to index 5 will be faster. It doesn't require any method to remove data from cache (it will go away on it's own), but those can make attack faster.

For example here is attack that only used a server that included a cycle-exact time. No attacker program was present on victim machine.

As a side note: When process is attacker running as a normal-privileged process, it has access to all other normal-privileged processes in many OSes (for example Windows), so attacker can simply read key.

$\endgroup$
  • $\begingroup$ Does loading the cache up front - reading from an address in every cache line - before the crypto operation prevent the remote attack? $\endgroup$ – Myria Jan 6 '17 at 23:46
  • $\begingroup$ No. You can't control cache content. Both OS and CPU can decide to wipe your cache due to various reasons. There is technique that RSA uses to prevent cache attacks that relies on interleaving data, so to get all data you have to read whole table. But that reduces performance. Trying to refill cache might make attack harder, but it won't stop it. $\endgroup$ – axapaxa Jan 7 '17 at 1:44
  • $\begingroup$ Cache lines seem to be 64 bytes these days. Would reading all four cache lines of the S-box each time it's accessed and using e.g. cmovxx to select the desired answer among the four work? This is definitely more expensive than the 4-byte lookup table, though. $\endgroup$ – Myria Jan 14 '17 at 2:24
  • $\begingroup$ Well, you have no guarantee that cache line is 64byte (but you can retrieve it from system, afaik). It would work (cmov doesn't cache or predict), but standard practice is to interleave data then (for example first write all first bits of result, then every second bit etc. - then you always read whole buffer). But honestly, that is why AES is so terrible in software. If you can, replace it with for example ChaCha20 (no buffers, quite immune to timing attacks, fast and bigger security margin than AES). $\endgroup$ – axapaxa Jan 14 '17 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.