Call us at 507.319.5206 or This email address is being protected from spambots. You need JavaScript enabled to view it.
Follow us on LinkedIn and Twitter

Can an Apple a Day Keep the FBI Away?

Lately I’ve found myself wondering…. does the FBI really need Apple’s help to decrypt a bad guy’s iPhone?

Something seems fishy about the dust up between the FBI and Apple over the encrypted iPhone previously used by one of the San Bernardino terrorists, so I amused myself by teasing out the loose threads.

In case you haven’t heard, here’s the gist of the Apple/FBI disagreement. The FBI has an iPhone that was used by one of the San Bernardino terrorists.  The phone could contain information related to the attack in San Bernardino and, if it does, that information might help them thwart a future attack. The terrorist encrypted the data on the iPhone. The FBI wants to force Apple to help them decrypt the data.

According to all of the reports I’ve heard and read, the FBI lawsuit claims that only Apple can help them retrieve the data from the phone; therefore, Apple must be forced to help the FBI do this. Apple’s response is that it would have to create something “new” to provide the help the FBI requires.  While the FBI might be able to legally force Apple to turn over something it already has, it shouldn’t be able to force Apple to create something new to achieve the FBI’s objectives.

What? Wait. Think about that for a bit!

iPhone Encryption

At the heart of the lawsuit is encryption.

Presumably, Apple implemented a strong, well-known and well-vetted encryption algorithm. This means that the only way to decrypt data without having the key used to encrypt it is by mounting a brute force attack. A brute force attack involves trying every possible key combination until one is found that produces unencrypted data.

Fact #1: The more computing power one has, the more quickly a brute force attack can be successfully completed. A successful brute force attack against modern encryption algorithms and key lengths would require thousands or millions of years to complete using processors that are generally available today.  This time can be significantly reduced by using multiple and/or faster processors.

Fact #2: In addition, Apple builds protection against brute force attacks into its iPhones. If you unsuccessfully attempt to decrypt the data on an iPhone 10 times in a row, Apple deletes the data in a way that removes all vestiges of the encrypted data from the phone. Once the encrypted data is gone, it’s buzzer… game over… thanks for playing.

OK. Have you thought any more about the claim in the FBI’s lawsuit and Apple’s response yet? I have. Even with the information from news reports of the lawsuit from multiple different sources, I can’t make any sense of it.

The Hypotheses

The most important goal of the FBI is to get at the unencrypted data as fast as possible. The longer it takes, the less useful the data will be. For the lawsuit to make sense, there has to be a rational scenario that allows the FBI to accomplish this goal faster with Apple’s help than without it.

Can we find a scenario that meets this criterion?

By all accounts, Apple did a great job of implementing encryption on its iPhones. Therefore, the only way to get at the unencrypted data on the terrorist’s iPhone requires that you first bypass the protection against brute force attacks and then mount a brute force attack on the encrypted data. A rational scenario for the FBI’s lawsuit has to show how Apple can be helpful to the FBI in just one, the other, or both of these steps.

Hypothesis #1:  There is some way that Apple can help the FBI conduct a brute force attack more quickly than it can without Apple’s help.

To test this hypothesis, we have to assume that the protection against brute force attacks can be somehow bypassed.

As discussed previously, the time required to mount a successful brute force attack is based on the speed and number of processors used. In the case of the terrorist’s iPhone, the brute force attack must either be executed on the iPhone using its processor or on a separate computer(s).

If the iPhone’s processor is used, it doesn’t matter who executes the brute force attack. It will take the same amount of time for either party, and the time required would be too long for the data to be of use.

The only way to execute the attack in a reasonable amount of time is to use separate computers. But surely the FBI has access to more and (certainly) much faster computers than does Apple.

This rules out the hypothesis that the FBI needs Apple’s help to more quickly execute a brute force attack.

Hypothesis #2: Apple can do something to bypass the protection against brute force decryption on the iPhone.

For this to be true, there must be a way for Apple to change the behavior of the iPhone or to extract the encrypted data from the iPhone for conducting the brute force attack elsewhere.

Presumably the protection against brute force attacks is implemented in hardware, or it would be way too easy for lots of bad actors to bypass this protection.

Changing the behavior of hardware would cost millions of dollars and take months to accomplish. And this assumes that you can change the hardware without impacting the stored encrypted data.

Regardless of whether the protection is implemented in hardware or software, once bypassed, you would still have to use the iPhone’s processor to execute the attack. We’ve already concluded the iPhone processor is probably too slow to accomplish the task in a reasonable amount of time. It doesn’t make sense for the FBI or Apple to spend those kinds of resources to change the behavior of the iPhone.

Hypothesis #3: Apple can do something to help the FBI extract the encrypted data from the phone.

This seems to me to be most technically plausible scenario. There are certainly businesses that help retrieve data from various types of damaged media. The technology to extract data stored on a chip in a board is available. Apple is presumably using commercially-available memory and storage in their phones.

However, it seems more reasonable to me that the FBI already has more expertise and experience to extract the encrypted data from the iPhone than Apple.

Given this thought process, I don’t see how Apple is in a position to help the FBI accomplish its goals more quickly than the FBI can on its own. This leads me to question the whole lawsuit.

At the Core: Unanswered Questions

Here are some non-technical questions I have been asking myself:

  • Why would the FBI go public with a lawsuit? Doing so tells the bad guys they should be storing all of their most secret and damning information encrypted on iPhones – at least unless and until this lawsuit is settled in the FBI’s favor.
  • Why would Apple apparently admit that there is a way for them to help the FBI decrypt data on an iPhone without having the key? This would lead a lot of people to question if their implementation was everything they said it was to begin with.
  • Did Apple do a poor job of implementing the encryption functions in the iPhone?
  • Did Apple purposely design something that would allow them, with some additional amount of resources applied at a later time, to somehow decrypt encrypted data? If so, for what reason?
  • Did Apple cooperate with the FBI during the design of the iPhone encryption mechanisms?

Conspiracy Theory

I have considered one other possible explanation: this lawsuit is a disinformation campaign aimed at making the bad guys believe their data is more strongly protected on iPhones than anything else.

The only thing I really know is that we don’t know everything there is to know about this lawsuit. And it really bugs me!

 

Facebooktwittergoogle_pluspinterestlinkedinmail
This entry was posted in IBM i Security, Security Breach and tagged , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>