Csep-564-Lec-9

Side Channels

What are they?

• Conceptual design will never match implementation completely, there are side effects.
• As we've seen, these effects can be exploited to leak unintended information. This is a side channel.
• A covert channel is an intential usage of side effects to have information flow from one place to another.

Why do we care?

• It's important to note that most compromises happen via simple, straight-forward attacks.
• Embedded systems do see side-channel attacks.
• High security systems (e.g. Intel SGX) do see side-channel attacks.
  • E.g. the Secret Network blockchain company that relied entirely on SGX security is basically defunct due to a new side-channel attack against SGX.

Timing side channels

When attacking cryptography, any leakage is bad, even 1 bit.

• RSA: tons of examples here from timing key-dependent modular exponentiations
• Block ciphers: leverage key-dependent cache hits/misses
• Floating point arithmetic: variable time instructions

Power side channels

The amount of power used by a computer is related to what it is doing. E.g.

• GPU vs CPU op
• 0 + 0 vs 0xffffffff + 0xffffffff

Cache side-channels

The cache's current state implies something about prior memory accesses.
E.g.

• Prime+Probe:
  1. Time cached vs uncached values.
  2. Derive an "eviction set", which is a set of memory addresses that all go to the same cache set.
  3. Prime this eviction set by filling it up completely.
  4. If victim accesses something in the target set, it will evict one of the attacker's.
  5. Refill the cache set, and see if one value takes way longer. If so, then they know the victim accessed memory in the eviction set. If the memory address is dependent on the key, this is quite bad.
• Flush+Reload: requires shared memory amongst attacker and victim; much simpler:
  1. Kick line L out of cache
  2. Let victim run
  3. Time access to L; victim accessed it $\iff$ access was fast.

If there's a shared crypto lib among processes, and if that crypto has an if branch if (keybit) a() else b(), then memory address of a vs. b being in the cache lets you know the keybit!

Esoterica

1. Spectre class: exploits speculative execution.
   • These are probably here to stay, and we need to write software and compilers that avoid them better.
2. Meltdown (L1TF): read illegal (e.g. kernel) address, leak it before the fault occurs.
   • These are largely classified as hardware bugs and will hopefully go away.
   • Intel specific
3. Hertzbleed frequency attack.
   • If you draw more power, your CPU frequency has to be lower.
   • The power and frequency can vary based on varying data, under the same processing.
   • Thus execution time can vary on secrets even if the number of CPU cycles is constant!
   • How?
     • Power depends on secrets
     • Heat depends on power
     • Processor frequency depends on heat & power
     • Execution time depends on frequency
     • Therefore: execution time depends on secrets

Mitigations

1. Remove the leakage source in code
   • E.g. no secret dependent memory accesses
   • KAISER/KPTI defense, disallow kernel/user memory sharing
   • Constant cycle style coding (no branching)
2. Fix the problem in hardware
   • E.g. additional instructions to disallow speculation
3. Mask the leakage to make it more difficult
   • E.g. randomized cache placement, timing, etc.
4. Isolation
   • Partition the cache into discrete parts and don't share them

Takeaways

Side channels aren't going anywhere. Don't build systems that rely on trusted hardware! These are hot targets for side channels exploits.