Demystifying the Secure Enclave Processor [pdf]
blackhat.com
Demystifying the Secure Enclave Processor [pdf]
1–10 of 34 posts
Re: Demystifying the Secure Enclave Processor [pdf]
#2Is there a video of this?
Re: Demystifying the Secure Enclave Processor [pdf]
#3The best part of working in a digital forensics research lab is that I get to read this kind of presentations without having to say "there goes my productivity for the day". Actually, whenever one of these comes around is when I get to be most productive :)
Re: Demystifying the Secure Enclave Processor [pdf]
#4Is there a video of this?
> Speaker presentations and materials are put online generally two weeks after the event. Audio and video are generally available 6-9 months after the conference.
Re: Demystifying the Secure Enclave Processor [pdf]
#5The paper mentions standard methods of attack, such as glitching voltage and/or clock.
Does anyone want to comment on how feasible it would be to defend against stuff like that in both hardware and software?
E.g. in software, instead of just storing an address in memory, store a tuple. Something like (address, ~address). Validate each tuple on use, i.e. (address ^ ~address) must result in all bits set. That's obviously a naive thing, but there are probably similar relatively low overhead things that can be done.
Same with hardware. It wouldn't be too difficult to store a parity bit to accompany each register byte. Any hardware glitching that flipped register bits would tend to result in parity errors. Parity checks are not very secure when considered individually, but collectively it would be very difficult to glitch the hardware without introducing massive numbers of parity errors.
Re: Demystifying the Secure Enclave Processor [pdf]
#6The paper mentions standard methods of attack, such as glitching voltage and/or clock. Does anyone want to comment on how feasible it would be to defend against stuff like that in both hardware and software? E.g. in software, instead of just storing an address in memory, store a tuple. Something like (address, ~address). Validate each tuple on use, i.e. (address ^ ~address) must result in all bits set. That's obvious…
In software it is very difficult to "protect" against. The goal with glitching is simply two switch a 1 to a 0 somewhere (conditional branch, memory store, etc). No mater how many extra if statements and bits you set, your not going to get all of them. And the attacker can just glitch twice.
Remember, your not causing the memory to go funky, your messing with the processors reads from registers and cache. So if the next instruction says "jump not equal 0" and the attacker wants "jump not equal 1" parity can't really help you in that scenario.
If you add parity, then the attack just needs to glitch that parity check out.
Hardware defenses are the best. In particular it looks like apple is using a "PLL". It has been a while since I worked with all this stuff, but I believe the PLL makes clock glitching impractical.
For voltage glitching, I'm sure they have components that monitor voltage and either smooth it out, or just shut the chip down if it sees something weird.
Re: Demystifying the Secure Enclave Processor [pdf]
#7One day, a blackhat presentation is actually going to be a new PDF attack vector, and we'll all be doomed.
Re: Demystifying the Secure Enclave Processor [pdf]
#8One day, a blackhat presentation is actually going to be a new PDF attack vector, and we'll all be doomed.
Judging by my reaction to it, this one's a DoS...
Re: Demystifying the Secure Enclave Processor [pdf]
#9The paper mentions standard methods of attack, such as glitching voltage and/or clock. Does anyone want to comment on how feasible it would be to defend against stuff like that in both hardware and software? E.g. in software, instead of just storing an address in memory, store a tuple. Something like (address, ~address). Validate each tuple on use, i.e. (address ^ ~address) must result in all bits set. That's obvious…
In software it is very difficult to "protect" against. The goal with glitching is simply two switch a 1 to a 0 somewhere (conditional branch, memory store, etc). No mater how many extra if statements and bits you set, your not going to get all of them. And the attacker can just glitch twice. Remember, your not causing the memory to go funky, your messing with the processors reads from registers and cache. So if the n…
I wonder if any exploits have successfully used voltage or frequency glitching on a modern processor with DVFS (Dynamic Voltage and Frequency Scaling.)
Re: Demystifying the Secure Enclave Processor [pdf]
#10Am I understanding correctly that while they enumerate a list of potentially useful attack vectors, there are no actual attacks (yet)?
Of course, since the Year of Snowden, I now assume that any "theoretical" attack vector has a Team, a Project Manager, and a half-completed Kanban board somewhere deep in the NSA…