Posted
by
Soulskillon Saturday May 11, 2013 @11:11PM
from the atf-struggles-with-slide-to-unlock dept.

New submitter ukemike points out an article at CNET reporting on a how there's a "waiting list" for Apple to decypt iPhones seized by various law enforcement agencies. This suggests two important issues: first, that Apple is apparently both capable of and willing to help with these requests, and second, that there are too many of them for the company to process as they come in. From the article:
"Court documents show that federal agents were so stymied by the encrypted iPhone 4S of a Kentucky man accused of distributing crack cocaine that they turned to Apple for decryption help last year.
An agent at the ATF, the federal Bureau of Alcohol, Tobacco, Firearms and Explosives, 'contacted Apple to obtain assistance in unlocking the device,' U.S. District Judge Karen Caldwell wrote in a recent opinion. But, she wrote, the ATF was 'placed on a waiting list by the company.' A search warrant affidavit prepared by ATF agent Rob Maynard says that, for nearly three months last summer, he "attempted to locate a local, state, or federal law enforcement agency with the forensic capabilities to unlock' an iPhone 4S. But after each police agency responded by saying they 'did not have the forensic capability,' Maynard resorted to asking Cupertino. Because the waiting list had grown so long, there would be at least a 7-week delay, Maynard says he was told by Joann Chang, a legal specialist in Apple's litigation group. It's unclear how long the process took, but it appears to have been at least four months."

Maybe the backdoor isn't so much the crypto format itself - it's in the password to decrypt. After all - these companies have a thing for you sharing information 'in the cloud', right? What's to stop them from simply posting your password somewhere central - for recovery purposes on your (and apparently, other people's) behalf? I reckon 90% of users would find it super-convenient!

Apple does not have a backdoor per se. But Apple does have the device signing key and can thus completely compromise the chain of trust. The only thing stopping you from compromising a phone with a 4 digit passcode in seconds by brute forcing it is the fact that software rate limits attempts, and the option to have it delete its intermediary keys after 10 bad attempts. If you have the ability to load an arbitrary kernel it is trivial to bypass both of these, but only Apple has that capability, at least on devices without jailbreaks that can be executed them while locked.

Would you have preferred if I had written "Apple does not actually need a backdoor per se in order toto perform the actions mentioned in the article?" My point was that what law enforcement is asking does not require a backdoor, since a lot of posters seem to think it implies there must be one. Furthermore, security researchers can and do look and see how all the signing keys etc are structured on running systems even without source code access. Is there a chance there is still something hidden, sure, but there is also a chance someone snuck a root exploit into an innocuous looking commit in an important open source project. Source code access generally does lead to more trustworthy code, but it isn't so black and white as you claim. In the end we depend on people to validate what we use, and just having the source available is not in and of itself validation.

As for the rest of the your comments, you simply don't know what you are talking about, but you would if you had actually read the PDF I linked. First off, rewriting the bootloader via JTAG is not an option on a lot of SoC's and embedded devices once they have had some of their internal fuses blown. From the PDF:

"When an iOS device is turned on, its application processor immediately executes code from read-only memory known as the Boot ROM. This immutable code is laid down during chip fabrication, and is implicitly trusted. The Boot ROM code contains the Apple Root CA public key, which is used to verify that the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load."

So the stuff in flash might be rewritable, but it won't be executed unless it is signed. Reading the raw flash is also completely useless, because all data written to it is AES encrypted via a DMA engine in the SoC that uses various different keys, but all of them are tied to or derived from values fused into the processor and not readable via software or JTAG (they are routed directly to the DMA block and never exposed). That means the brute force needs to be attempted on the SoC in that particular iPhone, or you need to drastically increase the search space. A suitably advanced attacker code probably also obtain the SoC keys by decapping the chip, dying it, and looking at the fuses with a scanning electron microscope, but I generally don't worry about an attacker with sorts of resources; they would probably just beat my PIN out of me...

Is it a user's password or is it Apple's? Is there a back door in the algorithm? Is it an inherently weak algorihm, but the police don't know what it is so they can't launch an attack?

Inquiring minds want to know!

Apparently you encrypt an iOS device when you enable the pass code option. The default pass code is numerical and is only 4 digits, which is very weak. You can activate a 'pass phrase' option that gives more security but the pass phrase should be at least 12 characters long. An 8 char password can, for example apparently be cracked (brute forced presumably) in under 2 hours. Since the iPhone defaults to a 4 digit numerical code I don't suppose cracking 98% of these devices will be terribly hard. However, as always, it appeals far more to the Apple haters here to jump to the conclusion that iOS devices phone home to Apple and send them your encryption keys and pass phrases in clear-text. I am not so sure about that myself, I know of a criminal case where a FileVault image was sent to Apple for decryption but they returned after a while saying that their people had failed to crack it.