A not-too-testing crossword clue I spotted in the current edition of The Week: Italian city's good for English code-breaker (6).

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.

The BBC reported this week that Dell computers have not only been shipped installed with a Certificate Authority public key issued by Dell with name (CN=) eDellRoot – but bizarrely also with matching private key. The problem has been observed in computers sold as long ago at least as July.

The key is marked as “non-exportable” in the Windows Certificates snap-in certmgr.msc (as is the default for keys created with makecert or openssl), but Kevin Hicks reports using the tool Jailbreak to allow export anyway, and posted the full key. The private key is password protected, but code, such as crackpkcs12, is readily available to perform a brute-force search for the password. This turns out to be “dell”.

Of course this compromises security of affected machines in at least 2 ways:

1. The computers are open to man-in-the-middle attacks, since a MITM can create a certificate for any website the target Dell computer visits which will be accepted as valid by the Dell machine.
2. A malicious party could compromise Microsoft’s Authenticode code-signing mechanism to install software onto a Dell machine: e.g. ActiveX controls from a website it controls which the DELL machine visits (or via a MITM attack). It seems that kernel mode software couldn’t be installed using this certificate, because there’s not a certificate chain leading to the “Microsoft Code Verification Root” certificate issued by Microsoft.

Dell has now acknowledged the problem, and posted instructions for removing the certificate. It’s not clear how they could have been so misguided as to make such a mistake. Their response says that “it was intended to provide the system service tag to Dell online support allowing us to quickly identify the computer model”. My guess is that online support, as client, would access the Dell machine, as a server, using TLS to protect the connection, and this key pair was for use by the server in this scenario. The mistake then was to have generated this key pair as a CA certificate.

As a slight diversion, the openssl command

openssl pkcs12 -in eDellRoot.pfx -nocerts -nodes -out eDellRoot.pri

can be used to extract the private key, and then

openssl rsa -text -noout <eDellRoot.pri

can be used to see the private key parameters, each given with most significant byte first. In this case we have parameters for a 2048 bit RSA key. Values are given for modulus, publicExponent, privateExponent, prime1, prime2, exponent1, exponent2 and coefficient, which are respectively \(n=pq\), \(e\), \(d=e−1 \bmod (p−1)(q−1)\), \(p\), \(q\), \(d \bmod(p−1)\), \(d \bmod (q−1)\), and \(q−1 \bmod p\) where \(p\) and \(q\) are the RSA primes. Vidar Holen has a nice blog entry describing how to perform RSA calculations using the command line calculator bc.