Slashdot Mirror

← Back to Stories (view on slashdot.org)

Judge Tells Apple To Help FBI Access San Bernardino Shooters' iPhone (engadget.com)

Posted by whipslash on from the slippery-slope dept.

An anonymous reader writes: After a couple shot 14 people in San Bernardino, CA before being killed themselves on December 2nd, the authorities recovered a locked iPhone. Since then, the FBI has complained it is unable to break the device's encryption, in a case that it has implied supports its desire for tech companies to make sure it can always have a way in. Today the Associated Press reports that a US magistrate judge has directed Apple to help the FBI find a way in. According to NBC News, the model in question is an iPhone 5c, but Apple has said that at least as of iOS 8 it does not have a way to bypass the passcode on a locked phone.

11 of 610 comments (clear)

  1. I can see it now... by ZorinLynx · · Score: 5, Insightful

    "Judge orders arsonist to unburn-down house"

    Good luck with that.

    1. Re: I can see it now... by Anonymous Coward · · Score: 5, Funny

      They want to make it somewhat realistic ...

    2. Re:I can see it now... by zugmeister · · Score: 5, Informative

      Hardware key storage should wipe itself after so many failed attempts.

      /sigh, RTFA... This is exactly what happens after 10 bad entries. So the gov't wants Apple to write them software to let them bypass the wipe and continue brute forcing the unlock code.

    3. Re:I can see it now... by ShaunC · · Score: 5, Insightful

      Presumably they want info on who they where talking to. If the shooters had accomplices, the FBI wants to know who they are.

      If only we had an agency who is (lawfully or otherwise) intercepting every electronic signal known to mankind, who could be consulted when national security concerns arise...

      --
      Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
    4. Re:I can see it now... by AaronW · · Score: 5, Interesting

      It should be possible to bypass the erase operation with physical access to the device. Most NAND devices have a write protect pin which when pulled low will disable program and erase operations.

      It may also be possible to add a socket and duplicate the encrypted flash chip so that the original is never in the phone. This could be complicated if the flash device supports a unique ID and the encryption platform makes use of it. I could think of several ways to bypass even that though. One way is to use an FPGA to create a flash emulator that can simulate the NAND device. One other advantage of this is that it could guarantee that the data is never erased. The encryption hardware itself must also store the number of authentication attempts in some non-volatile storage. Usually this would be on another chip or die since it's still not very common to mix flash and logic on the same chip.

      Unless the encryption and erase functionality is built into the Toshiba NAND device Apple uses it should be possible to pop the NAND device and use an FPGA and/or other hardware for forensic purposes since the iPhone is not built to FIPS standards (which usually pot the boards in epoxy and provide a number of methods to prevent physical intrusion).

      Even the secure keys that are not known by Apple should be accessible with physical access to the device. It's expensive, but it should be possible to read the blown fuses by digging through the layers if the exact location is known on a chip.

      https://media.blackhat.com/bh-...

      --
      This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
  2. Let's also order the gun manufacturer by Anonymous Coward · · Score: 5, Funny

    to revive the dead people.

  3. Re:Huh? by adamstew · · 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 stora

  4. Re:4 Digit Pin? by Anonymous Coward · · Score: 5, Informative

    No problem. 0000. Nope. 0001. Nope. 0002. Nope...

    0009. Too many invalid password attempts. Full disk encryption key has been erased. Initiating factory reset of device...

  5. Re:Where's my tinfoil hat? by TsuruchiBrian · · Score: 5, Insightful

    Apple has nothing to gain (and everything to lose) by actually having a back door. Apple doesn't make money by spying on people.

  6. Re:The deed is done by spire3661 · · Score: 5, Interesting

    The right to encryption and by extension privacy is more important than any one crime. The State has to accept its limitations, not wail and moan about how its 'not fair' they cant have absolute control over humans. Some things are beyond government's reach, accept it.

    --
    Good-bye
  7. Re:Huh? by wickerprints · · 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.