Does anyone know where the Blackhat 2016 videos will be posted? I've always found them incredibly educational.<p>Okay I'll leave something behind as well. This is my favorite sec-conference video of all time: [HOPE X] Elevator Hacking: From the Pit to the Penthouse <a href="https://www.youtube.com/watch?v=rOzrJjdZDRQ" rel="nofollow">https://www.youtube.com/watch?v=rOzrJjdZDRQ</a>
Closely followed by DEF CON 18 - Joseph McCray - You Spent All That Money and You Still Got Owned... <a href="https://www.youtube.com/watch?v=_SsUeWYoO1Y" rel="nofollow">https://www.youtube.com/watch?v=_SsUeWYoO1Y</a>
The paper mentions standard methods of attack, such as glitching voltage and/or clock.<p>Does anyone want to comment on how feasible it would be to defend against stuff like that in both hardware and software?<p>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.<p>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.
Am I understanding correctly that while they enumerate a list of potentially useful attack vectors, there are no actual attacks (yet)?<p>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…
The military has been building these kinds of secure embedded processors for a long time, they usually include physical / environmental protection packaging.<p>Wonder on the FIPS-140-2 level, where this chip would fit?<p><a href="https://en.wikipedia.org/wiki/FIPS_140" rel="nofollow">https://en.wikipedia.org/wiki/FIPS_140</a>
This seems like a lot of code to be running in a security-critical relatively simple device. Does anyone else have the impression that I would rather this device be much, much simpler.<p>Of course that might raise development costs but that seems like a fair trade off in this case, especially if it causes some "features" not to be implemented because they would be too hard.
How feasible would it be to bombard the enclave with radiation, low enough to avoid any physical damage to the silicon, but high enough to cause random glitches in computation.
If anyone is interested in a less technical, architecture overview of the Secure Enclave, I've written a blog series with the intent of reaching a more relaxed audience who is still concerned about their mobile security. The blog can be found here: <a href="https://woumn.wordpress.com/2016/05/02/security-principles-in-ios-architecture/" rel="nofollow">https://woumn.wordpress.com/2016/05/02/security-principles-i...</a><p>I always welcome feedback! :^)
The 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 :)