Este sitio web fue traducido automáticamente. Para obtener más información, por favor haz clic aquí.
Updated

The following article was contributed by Will Strafach, a mobile security expert who made a name for himself as one of the most widely known and respected iOS hackers in the world. Strafach is now the CEO of Sudo Security Group, a mobile security firm specializing in enterprise mobile protection and app security evaluation.

I spent years working alongside a team of enthusiasts hacking each release of iOS to gain full control and package together user-friendly jailbreaking tools that were used by millions of people around the world. I have reversed engineered major bits of the iOS code base in the midst of vulnerability hunting in the past, and have run different security stress tests on different bits of the iOS system, including viability and timing passcode cracking.

Since Apple's war with the FBI has taken center stage in the media following a federal judge's ruling that Apple must help the FBI break into an iPhone belonging to one of the San Bernardino shooters, I wanted to share some thoughts on the subject. After all, the FBI has laid a clever trap for Apple.

Here are five key things that need to be clarified.

1. Many have been misinterpreting the portions of Apple's public response letter with regards to the technique that might help break into the iPhone 5c being usable with other devices (if such a tool was created for other devices). This is not describing a technical issue, but is instead directly related to the later-mentioned issue of setting a precedent.

On a technical level, Apple could carry out the order by creating a RAM disk signed by the company's production certificate for the specific ECID of the suspect's iPhone. This solution would allow Apple to use existing technologies in the firmware file format to grant access to the phone ensuring that there is no possible way the same solution would work on another device.

The aspect that would actually affect the public is the fact that by doing this, Apple will show that breaking into an iPhone is "possible," and allow the FBI to use this case in the future as leverage.

This is only possible on a technical level in very specific circumstances, but if Apple assists in this instance, then it paves the way for more unreasonable and technically difficult requests to be made. In those scenarios, it will be on Apple to try to explain why it cannot accommodate the new requests. The company will have to show definitively why it is different from the "last time" it assisted in a similar case, though there is no way to speculate on how exactly this might be leveraged.

2. Apple has been doing very well in many international markets, especially China, where the company has faced criticism with regards to security concerns. If Apple does not try to fight this court order vigorously, it will not look good to buyers around the world.

A comparison which comes to mind is the disappointment from a decent amount of BlackBerry users in the United States who admired the company for staying strong with regards to security and encryption, but then "gave in" when the Indian government demanded access to BlackBerry users' private data.

3. Although the passcode attempt counter on the iPhone 5c can be handled without much work, the FBI request to allow it to electronically make passcode attempts is a considerable issue. This would specifically require Apple to modify the source code of SpringBoard (which powers the lock screen) to specifically add code that enables this capability, and sign it with the company's production certificate so that the device will run the code. The reason Apple stresses that this is a "backdoor" in its statement is because the order is specifically requesting that Apple make a modification that serves no purpose other than to weaken iOS security by allowing brute force attempts. As touched upon in point #2, this will look horrible for Apple if it complies.

4. Here's something pretty vital that no one has mentioned yet: The custom signed RAM disk that the FBI is requesting will not be possible to boot using the regular TSS restore servers, which check the validity of firmware files that are being loaded during each restore.

To allow restoration to a custom firmware, Apple would need to either: (a) make changes to the way its restore server works for this specific case, potentially causing major security concerns if any sort of mistake is made (which could make this an unreasonable / burdensome request, or (b) bring the device onto its internal network and load the firmware using the restore server used internally, since it can be assumed that such an in-house server exists for the purpose of restoring to unreleased firmware versions.

Apple can of course easily point out the absurdity of this scenario to a layperson: Apple is likely not very comfortable with what could potentially happen on its internal network if it was forced to let in a phone that belonged to a known terrorist, as there is no telling what it might attempt to do, seeing as the FBI is claiming that there is data they need on the device.

There is no way to say whether these valid arguments or any similar arguments will be able to sway the court, but the important takeaway here is that there are a few avenues Apple can take with regard to technical arguments against being forced to carry out this order. IN other words, Apple's objections can go well beyond the moral arguments the company has posted publicly.

5. Another PR-related reason that Apple is opposing this order so vehemently is that it is aware of the fact that, if it complies, the FBI will be able to crack the passcode very quickly. From my own testing, a 4-digit passcode can be cracked in under an hour and a 6-digit passcode can be cracked in less than a day. Therefore, to the layperson, it won't be easy to dispute any claim that Apple has decrypted the device for the FBI. While it wouldn't technically be true, all that would likely matter is Apple taking actions that allowed the FBI to gain access to an iPhone's once-encrypted data.