The decryption key for Apple’s Secure Enclave Processor (SEP) firmware Posted Online by self-described “ARM64 pornstar” [xerub]. SEP is the security co-processor introduced with the iPhone 5s which is when touch ID was introduced. It’s a black box that we’re not supposed to know anything about but [xerub] has now pulled back the curtain on that.
The secure enclave handles the processing of fingerprint data from the touch ID sensor and determines if it is a match or not while it also enables access for purchases for the user. The SEP is a gatekeeper which prevents the main processor from accessing sensitive data. The processor sends data which can only be read by the SEP which is authenticated by a session key generated from the devices shared key. It also runs on its own OS [SEPOS] which has a kernel, services drivers and apps. The SEP performs secure services for the rest of the SOC and much more which you can learn about from the Demystifying the Secure Enclave Processor talk at Blackhat
[xerub] published the decryption keys here. To decrypt the firmware you can use img4lib and xerub’s SEP firmware split tool to process. These tools make it a piece of cake for security researchers to comb through the firmware looking for vulnerabilities.
[Adam Laurie] spent time tearing into the security of the SAM7XC chip produced by Atmel. Even if he hadn’t found some glaring security holes just reading about his methodology is worth it.
The chip is used in a secure RFID system. The chip is added to the mix to do the heavy lifting required when using encryption. [Adam] grabbed a couple of open source libraries to put it to the test. The firmware is locked down pretty tight, but his explorations into the content of the RAM yield a treasure trove of bits. After investigating the sample code for the chip he’s shocked to learn that it uses RAM to store the keys at one point. The rest of his journey has him dumping the data and sifting through it until he gets to the “Master Diversification Key”. That’s the big daddy which will let him decrypt any of the tags used.
He reported his findings to Atmel in September of 2011. Their response is that they have no way of protecting RAM from exploit. [Adam] asserts that the problem is that the sample software wasn’t designed with the vulnerability of RAM in mind. The keys should never be stored there specifically because it is vulnerable to being dumped from a running system.
[Alessandro] sent us a link to his post about a PRU software VGA rasterizer. It’s not the easiest read, but we think it’s worth your time.
The gist of his background information is that back when his company was developing for an ARM9 processor he wanted to test his mettle with the coprocessor chips. The first iteration was to write a character LCD driver that pulled data from the main processor’s memory and displayed it on the screen. This makes for a low-overhead debugger display, it’s also very limited (32 characters over two lines doesn’t tell you much). And thus began his work on a VGA generator for the Programmable Realtime Unit (PRU is what TI calls this coprocessor) that grabs data in memory just like the original version. But with a much larger display area this becomes quite useful for debugging. That resistor mess is the R2R ladder he soldered together to perform the Digital to Analog Conversions. There’s a quick demo clip after the jump.
This work could end up being useful to you. [Alessandro] reports that the BeagleBone has similar hardware. A bit of porting could get his generator working on that board as well.
Continue reading “Offloading VGA generation onto a coprocessor”