News 'METIOR' Provided Defense Blueprint Against Side-Channel Vulnerabilities

[Admin]

A research team with MIT has put forward a side-channel attack mitigation framework that aims to objectively and quantitatively measure the impact of certain known and unknown side-channel attacks. 'METIOR' aims to bring cybersecurity closer to the chip design space.

'METIOR' Provided Defense Blueprint Against Side-Channel Vulnerabilities : Read more

 

[digitalgriffin]

If process per thread encryption of next gen hardware becomes a reality, and done properly with the decryption happening in channels far apart, this will stop 99.9% attacks.

 

[InvalidError]

If process per thread encryption of next gen hardware becomes a reality, and done properly with the decryption happening in channels far apart, this will stop 99.9% attacks.

The cache flush, power and other side-channel attacks don't care about the raw data, only about externally observable memory, cache, power, etc. patterns from which they can infer what data the target code is processing. Encrypting the process' memory space wouldn't affect that in any way, the processing behaviour and externally observable effects would remain the same.

If you want to secure your data against side-channel leaks, you have to change your algorithms to whiten any externally observable noise they may generate. Things like re-arranging your code to take constant time, constant power, constant reads/writes/flushes with constant timing regardless of data. One way to maintain near-constant-everything would be state machines where all code for every state gets executed on every iteration of a loop and ends with a jump table to select the desired result. While horribly inefficient, I bet most solutions for side-channel attacks will require such sacrifices.

 

[bit_user]

Side-channel attacks are a particularly superstitious type: through them, attackers don't even need access to any specific application logic to steal information from it, they can simply observe how it operates.

I think you do need to know the specific build of whatever library or application code is handling the data you want to extract. Otherwise, you cannot model it. It should also be noted that the observations are indirect, therefore requiring no special privileges.

I remain somewhat skeptical of how many such attacks have been successfully performed, in the real world. Even if we're talking about stealing encryption keys, the spying thread is going to have to continually hammer the CPU and just hope that it gets scheduled alongside something handling those keys. Then, there's the whole challenge of trying to figure out what and who you just spied on, because you normally have no visibility or control over what are the other tenants.

You can imagine how hard and expensive it is to mask something like someone's heartbeat, and that's part of the difficulty with protecting from side-channel attacks.

Not really. If you can't touch me, you can't feel my pulse. It's not a perfect analogy, but it does apply. In a hosted environment, someone doing something secure can spend extra money to rent out an entire instance, so it's shared with no other tenants.

Another thing you can do is restrict foreign threads from sharing your core. Google integrated a feature into the Linux kernel called core-scheduling. I assume Hypervisors have a similar control for that, at the VM level. This only helps with SMT-based exploits, but that's how the strongest side-channel attacks work.

 

[InvalidError]

I remain somewhat skeptical of how many such attacks have been successfully performed, in the real world. Even if we're talking about stealing encryption keys, the spying thread is going to have to continually hammer the CPU and just hope that it gets scheduled alongside something handling those keys.

AFAIK, most of these have only been demonstrated in lab environments where the researchers basically control every variable. In a real-world environment on a somewhat busy server, you have 100+k APIC events/sec and all of the other kernel/context-switching noise those may generate screwing up any timing, scheduling and power measurements. That is on top of all of the uncertainty regarding which account keys are being processed at any given time adding to the amount of noise spy algorithms would need to somehow sort out.

Then you have the constant power drain and CPU load by some unknown process likely to get the spy process flagged as a suspicious CPU hog in relatively short order if the operators are doing any sort of power and performance monitoring.

Most of these threats are purely theoretical. The attack code would need to run uninterrupted for so long before producing a first successful attack, only systems that are left completely neglected would be likely to leak information. I'd expect most servers hosting information sensitive enough to worry about this are being monitored closely enough that such spyware would be short-lived.

 

[digitalgriffin]

The cache flush, power and other side-channel attacks don't care about the raw data, only about externally observable memory, cache, power, etc. patterns from which they can infer what data the target code is processing. Encrypting the process' memory space wouldn't affect that in any way, the processing behaviour and externally observable effects would remain the same.

If you want to secure your data against side-channel leaks, you have to change your algorithms to whiten any externally observable noise they may generate. Things like re-arranging your code to take constant time, constant power, constant reads/writes/flushes with constant timing regardless of data. One way to maintain near-constant-everything would be state machines where all code for every state gets executed on every iteration of a loop and ends with a jump table to select the desired result. While horribly inefficient, I bet most solutions for side-channel attacks will require such sacrifices.

The constant read/writes/flushes are to overwhelm the circuits with physics similar to row hammer. Then reading and injection can occur. But if each channel is running a unique encryption, injection of malicious data instructions will mess up the encryption and at worst, cause a crash.

You can install internal profilers for instructions to see if there's an excess number of flush ops/read/write ops and intentionally throttle them.