Archive for February 20, 2016

Saturday, February 20, 2016

Priorities in a Time of Plenty

Horace Dediu:

Looking at Apple this way gives the impression that the company has a large number (nearly a billion) of repeat (subscribed to service) customers. These customers can be seen to spend a predictable recurring amount (average selling price) on Apple’s brand. The repetition of these metrics in public commentary suggests that customer acquisition and retention are among Apple’s goals.


Seen this way each centralized resource allocation question can be assumed to be prefaced with “In order to create/preserve customers should we…?”

This leads to answers quite different from questions that start with “In order to sell/profit more should we…?”

For instance, offering education products, retail store experiences, healthcare products, green energy initiatives, accessories, content and services make sense even if they may have poor financial “returns”. These initiatives score highly on customer retention and satisfaction. They may lead to engagement and repeat sales.

What Is the Secure Enclave?

Mike Ash (comments):

Each iOS CPU is built with a 256-bit unique identifier or UID. This UID is burned into the hardware and not stored anywhere else. The UID is not only inaccessible to the outside world, but it’s inaccessible even to the software running at the highest privilege levels on the CPU. Instead, the CPU contains a hardware AES encryption engine, and the only way the UID can be accessed by the hardware is by loading it into the AES engine as a key and using it to encrypt or decrypt data.

Apple uses this hardware to entangle the user’s passcode with the device. By setting the device’s UID as the AES key and then encrypting the passcode, the result is a random-looking bunch of data which can’t be recreated anywhere else, since it depends on both the user’s passcode and the secret, unreadable, device-specific UID.


The Secure Enclave contains its own UID and hardware AES engine. The passcode verification process takes place here, separated from the rest of the system.


The escalating delays for failed passcode attempts are enforced by the Secure Enclave. The main CPU merely submits passcodes and receives the results. The Secure Enclave performs the checks, and if there have been too many failures it will delay performing those checks. The main CPU can’t speed things along.


This would be fairly easy to implement, and shouldn’t affect the usability of the device. Given Apple’s public stance on user privacy, I would find it extremely weird if it the Secure Enclave’s software update mechanism wasn’t implemented in this way. On the other hand, Tim Cook’s public letter implies that all iPhone models are potentially vulnerable, so perhaps they haven’t taken this extra step.

Previously: FBI Asks Apple for Secure Golden Key.