Plaintext: Hacking, Infosec and Cryptography Explained
Sunday, July 31, 2016
Historiographical Shift in Hacker Studies
Interesting historiographical note about hacker studies is the way in which free software & system design is the focal subject of the 60s and 70s by writers in the 80s, but as we move into the 90s and 00s writers shift to a focus on information security and now in the 10s we're seeing a sort of hybrid model that includes both subjects, but also includes other techno-social activities like maker culture.
Monday, February 29, 2016
Apple v. FBI - Part 1: The Basics
Context:
On February 16th, 2016 most of us found out about the dispute between Apple and the U.S. government over the access to data on an iPhone that belonged to Syed Rizwan Farook. Public consciousness of this dispute was largely due in part to a public letter which Apple CEO Tim Cook posted on Apple's website entitled: "A Message to Our Customers."
Farook, who was killed by police in a shootout, is one of the two terrorists which the Federal Bureau of Investigation's (FBI) counter-terrorism investigation has indicated was responsible for murdering 14 people and injuring 22 in mass shooting that took place in San Bernadino California on December 2nd, 2015.
As of writing on February 29th, 2016, the FBI's investigation into the San Bernadino shooting is still underway. As part of this investigation, the FBI has recovered the cellphone owned by the county of San Bernadino's Department of Public Health, but belonged to its former employee, the shooter, Syed Farook. The phone itself is an iPhone 5C and its operating system, the software used to run the phone, is Apple's iOS 9. On February 9th, 2016 the FBI announced that it was unable to access data on Farook's phone due to its security features and requested Apple's support in bypassing the phone's security.
The Security:
![]() |
| An iPhone Lockscreen |
You might be wondering why the FBI can't just download all the data on the phone by copying it onto a computer, or just read the data stored in its memory from a computer, a technique known as mobile device forensics. This is where the second security feature on the iPhone has prevented the FBI from accessing the data. If the FBI simply tried to download all of the data on the phone, the files and data would appear scrambled. This is because the data on the iPhone is 'encrypted,' which is to say the data is written in a secret key. The secret key was created by combining the user's passcode with a hidden number known only to that EXACT phone handset; this number is known as a universal identifier, or UID. What's interesting about the UID is that the phone's software doesn't even know what that number is. To create the key, the phone's hardware passes the phone's passcode to its "encryption engine" a set of instructions on a chip which creates a math equation. If the math equation gives the engine the right solution then, and only then will the phone unlock. Think of it like the "two man rule" for launching a nuclear missile you've seen in movies: both codes combine to create a key which is needed to unlock, or "decrypt" the phone. One code by itself is useless.
This encryption system is an important part of the security puzzle on the iPhone 5C because you can't unscramble all the data without giving the engine your passcode and you can't ask the engine for its UID because it doesn't even know the key itself, it just creates the key based on instructions provided by the hardware on the phone. This means that to unscramble the phone you need both parts: the lockscreen passcode AND the phone which contains the UID.
If you took the data out of the phone without the UID you couldn't unscramble it in a practical amount of time. This means that you could ask a computer to unscramble the code used by guessing. This kind of guessing technique is called a brute force attack. However, the technique used code the secret key, called AES-256, is highly resistant to this kind of guessing. By some estimations it would take millions of the best computers from now until after all human life on earth dies to figure out how to crack AES-256.
Edit: 1/3/16:
There is some speculation that it is possible to read the phone's UID, it's secret number, by taking apart the phone and physically removing the phone's computer chip. Using certain techniques to 'trick' the encryption engine, it might be possible to get the hardware into giving you the UID.
A method similar to this one was proposed by Congressman Darrell Issa in a hearing over the case between Apple and the FBI before the U.S. House Judiciary Committee. Issa proposed that the FBI could clone copies of the phone's software and test passcodes on these copies, discarding the copy every time they got the code wrong.
In his defense Director Comey has denied that the FBI had considered this option. It is worth mentioning that both of the aformentioned methods would be time and resource intensive and potentially carry a degree of risk. We'll explore this option more in a later post to consider why it probably hasn't been tabled by the FBI.
The FBI's problem:
Based on our understanding of the phone's security, we can appreciate that the FBI has three problems. First, investigators can't repeatedly guess the phone's passcode, because that might cause the phone to erase all its data. Second, the FBI can't take the data off the phone because it can't be decoded without the phone.Third, even if the FBI did try to take the data off the phone, it wouldn't be practical to try and decode the data because its is encrypted.
In the next post:
In the next post I'm going to talk about the arguments made by the FBI on how they want Apple to help and the arguments made by technical experts in favor of decrypting the phone and how that would work.
I'd love hear your feedback on the post - did you find this post useful? Was something not explained properly? Did I miss something important? Was something too confusing to understand?
Leave me a message and let me know.
If you took the data out of the phone without the UID you couldn't unscramble it in a practical amount of time. This means that you could ask a computer to unscramble the code used by guessing. This kind of guessing technique is called a brute force attack. However, the technique used code the secret key, called AES-256, is highly resistant to this kind of guessing. By some estimations it would take millions of the best computers from now until after all human life on earth dies to figure out how to crack AES-256.
Edit: 1/3/16:
There is some speculation that it is possible to read the phone's UID, it's secret number, by taking apart the phone and physically removing the phone's computer chip. Using certain techniques to 'trick' the encryption engine, it might be possible to get the hardware into giving you the UID.
A method similar to this one was proposed by Congressman Darrell Issa in a hearing over the case between Apple and the FBI before the U.S. House Judiciary Committee. Issa proposed that the FBI could clone copies of the phone's software and test passcodes on these copies, discarding the copy every time they got the code wrong.
In his defense Director Comey has denied that the FBI had considered this option. It is worth mentioning that both of the aformentioned methods would be time and resource intensive and potentially carry a degree of risk. We'll explore this option more in a later post to consider why it probably hasn't been tabled by the FBI.
The FBI's problem:
Based on our understanding of the phone's security, we can appreciate that the FBI has three problems. First, investigators can't repeatedly guess the phone's passcode, because that might cause the phone to erase all its data. Second, the FBI can't take the data off the phone because it can't be decoded without the phone.Third, even if the FBI did try to take the data off the phone, it wouldn't be practical to try and decode the data because its is encrypted.
In the next post:
In the next post I'm going to talk about the arguments made by the FBI on how they want Apple to help and the arguments made by technical experts in favor of decrypting the phone and how that would work.
I'd love hear your feedback on the post - did you find this post useful? Was something not explained properly? Did I miss something important? Was something too confusing to understand?
Leave me a message and let me know.
Subscribe to:
Posts (Atom)
