M | T | W | T | F | S | S |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
Apple’s new, relaxed NDA rules appear to allow me to talk about the iOS 8 betas. I will hold off on the deep technical details until the final release, as I see that Apple is striving to make a number of improvements to the overall security of their product. What I will say is that so far, things look quite promising. Shortly after my talk at HOPE/X, citing my paper, “Identifying Backdoors, Attack Points, and Surveillance Mechanisms in iOS Devices”, along with a proof of concept, Apple released Beta 5, and a number of the “high value forensic services” I’d outlined in my paper have now been disabled wirelessly, including the packet sniffer service that got many upset (note: we’ve known about the packet sniffer for years, but it was never disclosed to consumers that it was active outside of developer mode). Apple’s fixes are clearly still a work in progress, and not all of my security concerns have been addressed yet, but it does show that Apple does care about the security of their product, and likely wants to prevent their APIs from being abused by both malicious hackers and government. Given that a number of my threat models involved government spying, it feels good to know that Apple has taken my research seriously enough to address these concerns. Keep in mind, the threat model we’re dealing with also includes foreign governments, many of which have long histories of spying on our country’s diplomats. I’ve instructed a number of counter-forensics classes to diplomatic infosec personnel, and the threats of spying on data are very real for these people, to the degree that a lot of cloak-and-dagger goes into play on both sides, especially when visiting technologically hostile countries.
If Apple does, in fact, disable tapping into all of these services wirelessly – which they appear to be on their way to doing – it will fix the significant security threat and concern of persistent, wireless surveillance… but it will not fix the entire problem. Many of these services are being used by a number of commercial forensics tools as a “backdoor” to circumvent deeper layers of security on the device by seizing the subject’s mobile and desktop devices, either on arrest, or perhaps even while being detained at an airport. Given the advanced capabilities of these tools to exploit iOS in this way (and are available to anyone, even if you’re not law enforcement), Apple would be wise to add additional protections to ensure that sensitive data is protected in cases involving data at rest and physical security. This, too, is achievable with a small amount of effort, and will ensure that Apple is the only entity capable of extracting sensitive, encrypted data from the device. To do this, Apple’s file_relay service, which they claim is for “diagnostics purposes” would need to be closed off, or at least fixed so that it doesn’t bypass the user’s backup password and the encryption it is tied to. Additionally, the house_arrest service would need to be patched so that it doesn’t allow sandbox access while the device is locked, or some other creative approach.
Of course, most of us don’t feel comfortable having an operating system designed in such a way that Apple themselves could unlock it, and in fact Apple could re-engineer their disk-based encryption differently so that this was not possible. This is a much longer discussion, however, and most likely a political one. The good news, however, is that Apple appears to be working (and quickly) to resolve these security issues for their next major release of iOS.
At any rate, Apple deserves some credit for attempting to fix these issues promptly. While there is still much work to be done, this does hold some promise for a full fix by the time iOS 8 is released.
M | T | W | T | F | S | S |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |