A recent news story has been the decision on Tuesday last week of a US attorney judge, after a hearing brought by the FBI, to place an order on Apple Inc. to assist in the recovery of data from an iPhone relating to the investigation into the shooting by Syed Rizwan Farook and Tashfeen Malik in San Bernardino last December in which 14 people were killed. The order requires Apple to

• bypass the iPhone feature in which keys necessary for decryption are deleted after 10 unsuccessful attempts to enter a passcode
• allow the FBI to repeatedly test passcodes for the device via some suitable interface, with the minimum possible delay between trials.

Apple immediately published an online response stating that, in order to do this, they are being asked to cross a digital Rubicon. They are being asked to create software that will compromise the encryption of this iPhone. In order that the software can be loaded, it must be digitally signed by them, but then there’s no technical measure, they argue, that prevents the software being loaded onto any other iPhone and compromising that too. Presumably in fact there is, since the software could be made specific to this phone; but I think Apple is concerned with the principle that they should not be expected to compromise the security of their equipment whenever subject to such a legal case.

The security features built into recent iPhone models are described in various versions, since May 2012, of Apple’s iOS Security white paper. The particular model involved in this case is an iPhone 5C, which uses an A6 processor and has no TouchID hardware.

The architecture for file protection is given in Apple’s papers:

Every file in flash memory on an iOS device is encrypted with a 256-bit per-file key. The encryption algorithm (prior to hardware with the A8 processor) is AES in CBC mode, with an IV for encrypting a block of the file obtained by AES-encrypting the offset number of the block with a key taken from a SHA-1 hash of the per-file key.

The per-file key is then stored, encrypted, along with other meta-data for the file, including the file’s protection class. The per-file key is wrapped as per RFC 3394, protected under the class key corresponding to its protection class – one of NSFileProtectionComplete, NSFileProtectionCompleteUnlessOpen, NSFileProtectionCompleteUntilFirstUserAuthentication, NSFileProtectionNone. The protection and handling of the class keys define the protection on the corresponding files.

For NSFileProtectionComplete and NSFileProtectionCompleteUntilFirstUserAuthentication, the class key is protected under a combination of the user’s keypad password and the phone’s Unique ID (UID), which was fuse-programmed into the processor prior to A7 hardware and programmed into the Secure Enclave coprocessor in more recent phones. The combining function is PBKDF2, with PRF taken to be AES keyed with the UID, and a count designed to make the process take 80ms to compute on the phone. For NSFileProtectionComplete, the clear class key is deleted when the phone is locked, while for NSFileProtectionCompleteUntilFirstUserAuthentication the clear class key is deleted at power down or reboot.

Since the UID is well protected, the FBI are asking for a mechanism to search passcodes on the device. One software feature that makes such searches difficult is an increasing time delay after failed passcode attempts: after 6 failed attempts a delay of 1 min. is introduced; after the 7th, 5 mins; after the 8th, 15 mins; and after the 9th or subsequent, an extra 1 hour’s delay is added. Another FBI request was to disable the option to have the Effacable Storage area, where the class keys are stored, wiped on the 11th incorrect passcode attempt.

Another option for the FBI might have been to make use of a computer that had previously connected to the phone. If the phone had not restarted since a passcode was last entered, then that computer can gain access to data on the PC via its copy of an escrow keybag, containing a copy of all the class keys encrypted under a key protected with NSFileProtectionCompleteUntilFirstUserAuthentication class on the phone, so still be accessible. Presumably we can conclude from this that the phone had run out of power or rebooted when discovered.

We await further developments in this case with interest.