The 5c originally shipped with iOS 7, which apple can get into if they want. It will be interesting to see what happens. Maybe apples claims about being 'locked out' of iOS 8 is bunk. Maybe they didn't password protect their phone. Maybe apple can guess their iCloud password ('12345'?), or access their gmail and reset the password. Once they have the iCloud password, and if there's an online backup, they can restore the backup to another phone. There are plenty of options beside brute forcing that hardware.
You mistake an iPhone's unlock code with the iPhone's encryption key. the iPhones do typically use a 4-6 digit pin as an unlock code. The user also has the ability to create a full alphanumeric password for the unlock code as well. However, that is simply the code that's used to unlock the actual full encryption key that is stored within dedicated crypto hardware. Apple uses a dedicated chip to store and process the encryption. They call this the Secure Enclave. The secure enclave stores a full 256-bit AES encryption key.
Within the secure enclave itself, you have the device's Unique ID (UID) . The only place this information is stored is within the secure enclave. It can't be queried or accessed from any other part of the device or OS. Within the phone's processor you also have the device's Group ID (GID). Both of these numbers combine to create 1/2 of the encryption key. These are numbers that are burned into the silicon, aren't accessible outside of the chips themselves, and aren't recorded anywhere once they are burned into the silicon. Apple doesn't keep records of these numbers. Since these two different pieces of hardware combine together to make 1/2 of the encryption key, you can't separate the secure enclave from it's paired processor.
The second half of the encryption key is generated using a random number generator chip. It creates entropy using the various sensors on the iPhone itself during boot (microphone, accelerometer, camera, etc.) This part of the key is stored within the Secure Enclave as well, where it resides and doesn't leave. This storage is tamper resistant and can't be accessed outside of the encryption system. Even if the UID and GID components of the encryption key are compromised on Apple's end, it still wouldn't be possible to decrypt an iPhone since that's only 1/2 of the key.
The secure enclave is part of an overall hardware based encryption system that completely encrypts all of the user storage. It will only decrypt content if provided with the unlock code. The unlock code itself is entangled with the device's UDID so that all attempts to decrypt the storage must be done on the device itself. You must have all 3 pieces present: The specific secure enclave, the specific processor of the iphone, and the flash memory that you are trying to decrypt. Basically, you can't pull the device apart to attack an individual piece of the encryption or get around parts of the encryption storage process. You can't run the decryption or brute forcing of the unlock code in an emulator. It requires that the actual hardware components are present and can only be done on the specific device itself.
The secure enclave also has hardware enforced time-delays and key-destruction. You can set the phone to wipe the encryption key (and all the data contained on the phone) after 10 failed attempts. If you have the data-wipe turned on, then the secure enclave will nuke the key that it stores after 10 failed attempts, effectively erasing all the data on the device. Whether the device-wipe feature is turned on or not, the secure enclave still has a hardware-enforced delay between attempts at entering the code: Attempts 1-4 have no delay, Attempt 5 has a delay of 1 minute. Attempt 6 has a delay of 5 minutes. Attempts 7 and 8 have a delay of 15 minutes. And attempts 9 or more have a delay of 1 hour. This delay is enforced by the secure enclave and can not be bypassed, even if you completely replace the operating system of the phone itself. If you have a 6-digit pin code, it will take, on average, nearly 6 years to brute-force the code. 4-digit pin will take almost a year. if you have an alpha-numeric password the amount of time required could extend beyond the heat-death of the universe. Key destruction is turned on by default.
Even if you pull the flash storage out of the device, image it, and attempt to get around key destruction that way it won't be successful. The key isn't stored in the flash itself, it's only stored within the secure enclave itself which you can't remove the storage from or image it.
Each boot, the secure enclave creates it's own temporary encryption key, based on it's own UID and random number generator with proper entropy, that it uses to store the full device encryption key in ram. Since the encryption key is also stored in ram encrypted, it can't simply be read out of the system memory by reading the RAM bus.
The only way I can possibly see to potentially unlock the phone without the unlock code is to use an electron microscope to read the encryption key from the secure enclave's own storage. This would take considerable time and expense (likely millions of dollars and several months) to accomplish. This also assumes that the secure enclave chip itself isn't built to be resistant to this kind of attack. The chip could be physically designed such that the very act of exposing the silicon to read it with an electron microscope could itself be destructive.
TLDR: Brute forcing the unlock code isn't at all possible through pretty much any means...reasonable or even unreasonable...maybe...JUST MAYBE...it's possible through absurdly unreasonable means.
Thank you for that post!
I could see Apple saying "OK, we'll give it a go! We are going to bill the FBI though for time/services rendered to complete this job though, Apple-style" That would end up being a $1billion project to crack the device and then charge triple for the proprietary hardware and services provided because they had to think different.
It's not as expensive as you might think, especially if you have the original chip design and layout available. It may be as low as $50-$100K, though it can also become quite a bit higher in some cases. It's amazing what can be done with FIB today.
Basically I think Apple is trying to tell the FBI to actually pull the device apart and risk breaking it.
1) it's pretty much the only way to get any data, especially if a Secure Enclave is used 2) Apple can't create a custom OS image without knowing information that is in the Secure Enclave anyway 3) Using a high-end FIB that can work well against FIB-hardened Security Systems is still probably cheaper than creating the special OS and all that 4) Apple doesn't want to spend its money on a dead end task 5) There
"The backup set is stored in the user’s iCloud account and consists of a copy of the user’s files, and the iCloud Backup keybag. The iCloud Backup keybag is protected by a random key, which is also stored with the backup set. (The user’s iCloud password is not utilized for encryption so that changing the iCloud password won’t invalidate existing backups.)
While the user’s keychain database is backed up to iCloud, it remains protected by a UID-tangled key. This allows the keychain to be restored only to the same device from which it originated, and it means no one else, including Apple, can read the user’s keychain items.
On restore, the backed-up files, iCloud Backup keybag, and the key for the keybag are retrieved from the user’s iCloud account. The iCloud Backup keybag is decrypted using its key, then the per-file keys in the keybag are used to decrypt the files in the backup set, which are written as new files to the file system, thus re-encrypting them as per their Data Protection class."
The relevant sections begin at page 38, in which the paper discusses iCloud, Apple ID, and general Internet Services security. Your misunderstanding stems from the mistaken belief that you can just "restore" the iCloud backup of your phone to a new device. But to do this, you need access to the user's Apple ID password. If two-step verification is turned on, Apple definitely has no way to circumvent this.
I've put this elsewhere in the thread but Apple seems to think they can provide plenty of stuff from icloud to law enforcement. The icloud stuff is encrypted with a passcode known to Apple:
So if it was in icloud, presumably they have it already, because Apple says "we can give you the icloud stuff, because we can access it". The locally encrypted stuff is locally encrypted, however- so presumably they w
From what I understand the Judge specifically instructed Apple to provide the FBI with a custom IPSW image to aid their efforts. Iphones will install any singed IPSW for which apple still providing the keys thru its network. IPhones have no mechanism to disable the installation of signed images. It remains unclear how much the FBI or Apple can tamper with secure enclave from root but having remote root shell access definitely opens up avenues of attack.
I don't think this will help them. The secure enclave utilizes its own secure boot and personalized software update separate from the application processor. Basically, The secure enclave can have it's software updated, but it's firmware update is separate from the main firmware for the device. The secure enclave requires you to enter the unlock code before it will accept new firmware. Anytime you do an iOS update on your phone, it asks for the unlock code...This is why...you need it to put the secure en
The secure enclave does all the crypto itself. It sits between the OS kernel and the flash memory itself. The full key is never in a space where it is accessible to any part of the application processor.
The secure enclave assembles the full crypto key using the 3 pieces... it's own 64-bit Unique Device ID (UID), the application processor's unique 64-bit Group ID (GID), and a 128-bit random number that the secure enclave generates during the initial device setup that is stored within the secure enclave chi
Very nice explanation, thanks. But help me out here... at some point software reads that key and uses the key to create encrypted data. How safe is __that__ code from being used to detect the key. Is the whole crypto library located on the enclave?
"Every iOS device has a dedicated AES 256 crypto engine built into the DMA path
between the flash storage and main system memory, making file encryption highly
efficient.
The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused
(UID) or compiled (GID) into the application processor and Secure Enclave during
manufacturing. No software or firmware can read them directly; they can see only the
results of encryption or decryption operations performed by dedicated AES engines
imp
You mistake an iPhone's unlock code with the iPhone's encryption key. the iPhones do typically use a 4-6 digit pin as an unlock code. The user also has the ability to create a full alphanumeric password for the unlock code as well. However, that is simply the code that's used to unlock the actual full encryption key that is stored within dedicated crypto hardware. Apple uses a dedicated chip to store and process the encryption. They call this the Secure Enclave. The secure enclave stores a full 256-bit AES
It probably is not as expensive as you think to extract the key from the physical chip. Where I work we had a new chip with a critical bug in it that prevented it from working. We were able to use FIB (Focused Ion Beam) in order to correct a number of chips for development. It should be possible to go through the layers on the chip where the various fields are stored and extract them. Once you have all of the information it should be possible to use an FPGA or other setup (or even software) to brute force t
The secure enclave is physically built to resist these kinds of attacks...EM shielding and such. I'm not saying it's not possible, but it is very difficult, time consuming, and requires a lot of special tools. Tools that apple probably doesn't have because it never created them. And the secure enclave storage is still only 1/2 of the key.
Another 1/4 of the key is physically burned in to the application processor, and the remaining 1/4 of the key is physically burned in to another part of the secure encla
I read one estimate that it probably costs $30K per chip, though it might be quite a bit more. It would likely be well within the FBI's budget, however, and probably no more than a few million dollars. Sure, Apple probably never created the tools, but having the design available should not make it all that difficult especially once the keys are extracted from the chips through physical means. Once the keys are extracted and the flash contents are extracted it then just becomes a software problem to brute fo
" The unlock code itself is entangled with the device's UDID so that all attempts to decrypt the storage must be done on the device itself. You must have all 3 pieces present: The specific secure enclave, the specific processor of the iphone, and the flash memory that you are trying to decrypt. Basically, you can't pull the device apart to attack an individual piece of the encryption or get around parts of the encryption storage process. You can't run the decryption or brute forcing of the unlock code in an
You confuse UDID with UID. The UID is unique and burned in to the processor of the phone. The GID is unique to the Secure Enclave and is burned in to the silicon of the secure enclave. Apple does not have any record of any phone's UID or GID. Both of which combine from separate hardware components to create 1/2 of the encryption key.
The other 1/2 of the key is randomly generated during initial device setup by the user and stored in memory that is embedded within the secure enclave itself. It cannot be
My apologies. Rereading my initial post, I realize I made a mistake. I did say "UDID", but I meant "UID".
These are two separate numbers within the phone. The UDID is known to the OS and can be queried. But it is not a part of the encryption key.
The UID is burned in to the silicon and is only known within the encryption system itself. Not even software running at the kernel level can query the UID.
We are not a loved organization, but we are a respected one.
-- John Fisher
Huh? (Score:4, Informative)
There's no word on exactly which model of iPhone was recovered
Huh? The article clearly states a model:
According to NBC News, the model in question is an iPhone 5c
Re: (Score:2)
The 5c originally shipped with iOS 7, which apple can get into if they want. It will be interesting to see what happens. Maybe apples claims about being 'locked out' of iOS 8 is bunk. Maybe they didn't password protect their phone. Maybe apple can guess their iCloud password ('12345'?), or access their gmail and reset the password. Once they have the iCloud password, and if there's an online backup, they can restore the backup to another phone. There are plenty of options beside brute forcing that hardware.
Re: (Score:0)
I don't own one of these devices, so no experience here... but wait. You're saying there are only 10K different possible passwords? How can that be?
I must be mistaken in assuming that is a password to decrypt the encrypted storage?
Re:Huh? (Score:5, Informative)
You mistake an iPhone's unlock code with the iPhone's encryption key. the iPhones do typically use a 4-6 digit pin as an unlock code. The user also has the ability to create a full alphanumeric password for the unlock code as well. However, that is simply the code that's used to unlock the actual full encryption key that is stored within dedicated crypto hardware. Apple uses a dedicated chip to store and process the encryption. They call this the Secure Enclave. The secure enclave stores a full 256-bit AES encryption key.
Within the secure enclave itself, you have the device's Unique ID (UID) . The only place this information is stored is within the secure enclave. It can't be queried or accessed from any other part of the device or OS. Within the phone's processor you also have the device's Group ID (GID). Both of these numbers combine to create 1/2 of the encryption key. These are numbers that are burned into the silicon, aren't accessible outside of the chips themselves, and aren't recorded anywhere once they are burned into the silicon. Apple doesn't keep records of these numbers. Since these two different pieces of hardware combine together to make 1/2 of the encryption key, you can't separate the secure enclave from it's paired processor.
The second half of the encryption key is generated using a random number generator chip. It creates entropy using the various sensors on the iPhone itself during boot (microphone, accelerometer, camera, etc.) This part of the key is stored within the Secure Enclave as well, where it resides and doesn't leave. This storage is tamper resistant and can't be accessed outside of the encryption system. Even if the UID and GID components of the encryption key are compromised on Apple's end, it still wouldn't be possible to decrypt an iPhone since that's only 1/2 of the key.
The secure enclave is part of an overall hardware based encryption system that completely encrypts all of the user storage. It will only decrypt content if provided with the unlock code. The unlock code itself is entangled with the device's UDID so that all attempts to decrypt the storage must be done on the device itself. You must have all 3 pieces present: The specific secure enclave, the specific processor of the iphone, and the flash memory that you are trying to decrypt. Basically, you can't pull the device apart to attack an individual piece of the encryption or get around parts of the encryption storage process. You can't run the decryption or brute forcing of the unlock code in an emulator. It requires that the actual hardware components are present and can only be done on the specific device itself.
The secure enclave also has hardware enforced time-delays and key-destruction. You can set the phone to wipe the encryption key (and all the data contained on the phone) after 10 failed attempts. If you have the data-wipe turned on, then the secure enclave will nuke the key that it stores after 10 failed attempts, effectively erasing all the data on the device. Whether the device-wipe feature is turned on or not, the secure enclave still has a hardware-enforced delay between attempts at entering the code: Attempts 1-4 have no delay, Attempt 5 has a delay of 1 minute. Attempt 6 has a delay of 5 minutes. Attempts 7 and 8 have a delay of 15 minutes. And attempts 9 or more have a delay of 1 hour. This delay is enforced by the secure enclave and can not be bypassed, even if you completely replace the operating system of the phone itself. If you have a 6-digit pin code, it will take, on average, nearly 6 years to brute-force the code. 4-digit pin will take almost a year. if you have an alpha-numeric password the amount of time required could extend beyond the heat-death of the universe. Key destruction is turned on by default.
Even if you pull the flash storage out of the device, image it, and attempt to get around key destruction that way it won't be successful. The key isn't stored in the flash itself, it's only stored within the secure enclave itself which you can't remove the storage from or image it.
Each boot, the secure enclave creates it's own temporary encryption key, based on it's own UID and random number generator with proper entropy, that it uses to store the full device encryption key in ram. Since the encryption key is also stored in ram encrypted, it can't simply be read out of the system memory by reading the RAM bus.
The only way I can possibly see to potentially unlock the phone without the unlock code is to use an electron microscope to read the encryption key from the secure enclave's own storage. This would take considerable time and expense (likely millions of dollars and several months) to accomplish. This also assumes that the secure enclave chip itself isn't built to be resistant to this kind of attack. The chip could be physically designed such that the very act of exposing the silicon to read it with an electron microscope could itself be destructive.
TLDR: Brute forcing the unlock code isn't at all possible through pretty much any means...reasonable or even unreasonable...maybe...JUST MAYBE...it's possible through absurdly unreasonable means.
Source: https://www.apple.com/business... [apple.com]
Re: (Score:1)
Re: (Score:2)
It's not as expensive as you might think, especially if you have the original chip design and layout available. It may be as low as $50-$100K, though it can also become quite a bit higher in some cases. It's amazing what can be done with FIB today.
Re: (Score:1)
Basically I think Apple is trying to tell the FBI to actually pull the device apart and risk breaking it.
1) it's pretty much the only way to get any data, especially if a Secure Enclave is used
2) Apple can't create a custom OS image without knowing information that is in the Secure Enclave anyway
3) Using a high-end FIB that can work well against FIB-hardened Security Systems is still probably cheaper than creating the special OS and all that
4) Apple doesn't want to spend its money on a dead end task
5) There
Re:Huh? (Score:5, Informative)
That isn't correct, according to the white paper:
"The backup set is stored in the user’s iCloud account and consists of a copy of the user’s files, and the iCloud Backup keybag. The iCloud Backup keybag is protected by a random key, which is also stored with the backup set. (The user’s iCloud password is not utilized for encryption so that changing the iCloud password won’t invalidate existing backups.)
While the user’s keychain database is backed up to iCloud, it remains protected by a UID-tangled key. This allows the keychain to be restored only to the same device from which it originated, and it means no one else, including Apple, can read the user’s keychain items.
On restore, the backed-up files, iCloud Backup keybag, and the key for the keybag are retrieved from the user’s iCloud account. The iCloud Backup keybag is decrypted using its key, then the per-file keys in the keybag are used to decrypt the files in the backup set, which are written as new files to the file system, thus re-encrypting them as per their Data Protection class."
The relevant sections begin at page 38, in which the paper discusses iCloud, Apple ID, and general Internet Services security. Your misunderstanding stems from the mistaken belief that you can just "restore" the iCloud backup of your phone to a new device. But to do this, you need access to the user's Apple ID password. If two-step verification is turned on, Apple definitely has no way to circumvent this.
Re: (Score:2)
I've put this elsewhere in the thread but Apple seems to think they can provide plenty of stuff from icloud to law enforcement. The icloud stuff is encrypted with a passcode known to Apple:
http://www.apple.com/privacy/d... [apple.com]
This LEO guide seems to back that up:
http://manhattanda.org/sites/d... [manhattanda.org]
So if it was in icloud, presumably they have it already, because Apple says "we can give you the icloud stuff, because we can access it". The locally encrypted stuff is locally encrypted, however- so presumably they w
Re: (Score:2)
This allows the keychain to be restored only to the same device from which it originated
Sucks if you lose your device. Or it physically breaks.
Two of the main reasons you'd want to keep a backup in the first place.
Re: (Score:2)
Re: (Score:2)
I don't think this will help them. The secure enclave utilizes its own secure boot and personalized software update separate from the application processor. Basically, The secure enclave can have it's software updated, but it's firmware update is separate from the main firmware for the device. The secure enclave requires you to enter the unlock code before it will accept new firmware. Anytime you do an iOS update on your phone, it asks for the unlock code...This is why...you need it to put the secure en
Re: (Score:2)
The secure enclave does all the crypto itself. It sits between the OS kernel and the flash memory itself. The full key is never in a space where it is accessible to any part of the application processor.
The secure enclave assembles the full crypto key using the 3 pieces... it's own 64-bit Unique Device ID (UID), the application processor's unique 64-bit Group ID (GID), and a 128-bit random number that the secure enclave generates during the initial device setup that is stored within the secure enclave chi
Re: (Score:2)
Very nice explanation, thanks. But help me out here... at some point software reads that key and uses the key to create encrypted data. How safe is __that__ code from being used to detect the key. Is the whole crypto library located on the enclave?
"Every iOS device has a dedicated AES 256 crypto engine built into the DMA path between the flash storage and main system memory, making file encryption highly efficient.
The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the application processor and Secure Enclave during manufacturing. No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed by dedicated AES engines imp
Re: (Score:2)
Yes. The random number is generated during the initial device setup process and then stored within the secure enclave itself.
Re: (Score:2)
Re: (Score:2)
It probably is not as expensive as you think to extract the key from the physical chip. Where I work we had a new chip with a critical bug in it that prevented it from working. We were able to use FIB (Focused Ion Beam) in order to correct a number of chips for development. It should be possible to go through the layers on the chip where the various fields are stored and extract them. Once you have all of the information it should be possible to use an FPGA or other setup (or even software) to brute force t
Re: (Score:2)
The secure enclave is physically built to resist these kinds of attacks...EM shielding and such. I'm not saying it's not possible, but it is very difficult, time consuming, and requires a lot of special tools. Tools that apple probably doesn't have because it never created them. And the secure enclave storage is still only 1/2 of the key.
Another 1/4 of the key is physically burned in to the application processor, and the remaining 1/4 of the key is physically burned in to another part of the secure encla
Re: (Score:2)
I read one estimate that it probably costs $30K per chip, though it might be quite a bit more. It would likely be well within the FBI's budget, however, and probably no more than a few million dollars. Sure, Apple probably never created the tools, but having the design available should not make it all that difficult especially once the keys are extracted from the chips through physical means. Once the keys are extracted and the flash contents are extracted it then just becomes a software problem to brute fo
Re: (Score:2)
" The unlock code itself is entangled with the device's UDID so that all attempts to decrypt the storage must be done on the device itself. You must have all 3 pieces present: The specific secure enclave, the specific processor of the iphone, and the flash memory that you are trying to decrypt. Basically, you can't pull the device apart to attack an individual piece of the encryption or get around parts of the encryption storage process. You can't run the decryption or brute forcing of the unlock code in an
Re: (Score:2)
You confuse UDID with UID. The UID is unique and burned in to the processor of the phone. The GID is unique to the Secure Enclave and is burned in to the silicon of the secure enclave. Apple does not have any record of any phone's UID or GID. Both of which combine from separate hardware components to create 1/2 of the encryption key.
The other 1/2 of the key is randomly generated during initial device setup by the user and stored in memory that is embedded within the secure enclave itself. It cannot be
Re: (Score:2)
My apologies. Rereading my initial post, I realize I made a mistake. I did say "UDID", but I meant "UID".
These are two separate numbers within the phone. The UDID is known to the OS and can be queried. But it is not a part of the encryption key.
The UID is burned in to the silicon and is only known within the encryption system itself. Not even software running at the kernel level can query the UID.