Monday, September 15, 2014

Pay Technology: The Secure Enclave Processor

This is part of a continuing series of articles focussing on discrete technologies developed by Apple in support of its products.  The first article examined Apple's patent relating to tokenization and extrapolated from this how Pay appears to work.

This time we'll look at the Secure Enclave, basing the analysis on Apple's U.S. Patent No. 8,832,465 invented by, among others, my former colleague Manu Gulati.
In my continuing series of articles explaining why Apple will eventually move its Mac products over to ARM (Part I, Part II), I note that one important reason for doing so is to allow Apple to include unique features in its microprocessors that permit it to differentiate its products.  One example I gave was the Secure Enclave found in Apple's A7 and (as we now know) A8 processors.

The Secure Enclave permits Apple's devices to store sensitive information, such as cryptographically hashed biometric or identification information, in a manner secure from rogue apps, external attacks, or even physical probing of the device.  In particular, with iPhone 5S, Apple stores a cryptographically modified version of your fingerprint data in the Secure Enclave.  The fingerprint is modified in such a way that it is impossible (or at least very very very hard) to recreate your actual fingerprint image from this data.  And by storing it in the Secure Enclave, it's impossible for rogue apps to access even this essentially useless data.

With the iPhone 6, 6P, and possibly Watch, it is believed that the Secure Enclave (or something very much like it) also holds a "tokenized" version of the account information associated with each credit card you "load" onto the phone.  Again, the token is, by itself, useless. And, again, even this useless information is hidden from any rogue apps.

U.S. Patent No. 8,832,465 gives us some insight into how this is likely works.

Fig. 1 from the patent illustrates one particular way that the invention described in the patent might be used.  Fig. 1 is a "block diagram" showing how a system on chip (an SoC) incorporating a Secure Enclave may work.  A SoC is a chip that incorporates multiple semi-independent blocks that can communicate with each other over a common bus (here called "Communication Fabric" and labeled 27).

In Fig. 1, the "SEP" block, labeled with 16 and colored yellow, is the Secure Enclave.  It is separate from the CPU ("CPU Complex 14 at the bottom left) and can communicate with the CPU only over the shared bus (Communication Fabric).

The Secure Enclave is not simply a dumb memory that holds secret information.  It is a relatively complicated structure that has multiple sub-blocks as shown in Fig. 1.  Another figure in the patent, Fig. 3, shows  more  details of what might be found inside a Secure Enclave.

One should think of Fig. 3 as replacing SEP 16 in Fig. 1.  In other words, Fig. 3 is a more detailed view of what's inside SEP 16.

One key to the operation of the Secure Enclave is that it is isolated from the CPU on which apps run. In fact, the patent describes a possible way to do this involving a mailbox.  When an app running on the CPU wants to get or put information into the Secure Enclave, it writes a message and puts it into the mailbox.  Later, the Secure Enclave can read the mailbox to receive the message.  The CPU thus has no direct access to the Secure Enclave.  This reminiscent of a spy craft "dead drop," allowing different parts of the SoC to communicate with the Secure Enclave without exposing the internals of the Secure Enclave to any other part of the chip.

Update: Apple now acknowledges that it uses the mailbox technique.

Perhaps a better analogy is a quarantine.  If the main CPU gets "infected," it can't infect the Secure Enclave because it never gets to have direct contact with the Secure Enclave.

Since the Secure Enclave includes its own processor ("Processor 32"), the patent also describes some methods for keeping it secure.  For example, the SEP may be in control of its own boot process so that it can't be compromised by the injection of bogus boot code.  The code that the Secure Enclave processor runs may be stored in its own Secure Rom (labeled 34 in Fig. 3).  If code is run directly from ROM - which is unmodifiable "Read Only Memory," the processor cannot be tricked into performing actions that would compromise security.  The Secure Enclave may also control its own power management. This is important because one method of attacking cryptographic processors is to manipulate the power rails used to supply power to the processor in the hopes of triggering a bug which allows a point of attack.  Finally, the Secure Enclave may have access to its very own external memory, where it can store encrypted secure information without fear that it could be read or modified by other parts of the chip.

The "mailbox" technique is illustrated in Fig. 4 of the patent.

The inbox and outbox are separate, so that it isn't possible for, say, one app to monkey with something that another app sent to the Secure Enclave.

The CPU may send messages to the Secure Enclave by writing into the "Inbox."   The processor in the Secure Enclave (SEP Processor 32) is notified that there's something to read (by the "Int" signal) and may "read' the contents of the Inbox.

Just how broad is this patent? That is, how free should Apple's competitor's feel they are to copy this technology?  The short answer is that the patent claims, which determine exactly what Apple's competitors are not permitted to without a license from Apple, appear to have fairly broad coverage.  For example, Claim 1:

1. An integrated circuit comprising, all integrated on a single semiconductor substrate: 
Integrating multiple blocks onto a single integrated circuit is the most efficient way to do things, so Apple's competitors probably don't want to try and avoid infringement by pushing some of the blocks onto separate die.

one or more application processors, wherein each application processor comprises hardware configured to execute instructions; 
Interpreting patent claims is fraught with difficulty as there are very specific and extensive rules for determining what each of the words in the claims means.  I haven't followed those rules here, so at best I can offer only an educated guess, but the above language seems to require little more than what we've been referring to as the "CPU Complex" or "CPU."  It goes without saying that Apple's competitors will have semiconductors containing processors that can execute instructions.  Unless "application processor" has some special meaning as used in the patent, this seems like an item that will be difficult for Apple's competitors to avoid.

a memory controller coupled to the one or more application processors; 
Memory controllers are also very commonly located on the same semiconductor as the application processor in SoC's.

a security circuit including at least one additional processor and one or more security peripherals, 
This is the essence of the Secure Enclave. It's a smart circuit with its own processing capabilities.  

wherein the one or more security peripherals comprise an encryption peripheral configured to perform encryption and decryption operations, 
"Security peripherals" may have a special meaning as used in the patent.  But it looks like what is required is some sort of circuit for performing encryption and decryption. Obviously, cryptographic operations like encryption and decryption would be critical functions for any "secure enclave"-like solution proposed by Apple's competitors.

wherein the additional processor comprises hardware configured to execute instructions, 
One way to avoid infringement might be to use a simple hardcoded state machine, rather than a processor which executes potentially modifiable instructions, as the "processor" in the secure enclave.  This would seem to be possible, but would certainly require a lot of design effort. 

and the additional processor is separate from the one or more application processors, and 
Apple's competitors could decide to use the normal processor, for example an ARM core, as the processor for the "secure enclave," thus it wouldn't be "separate" from the "one or more application processors" (again, assuming a very general interpretation of these terms).  But that wouldn't be a very compelling product, seemingly, as it would render the processor subject to easy attack by rogue or malfunctioning apps that also run on these processors.  

wherein the security circuit, including the encryption peripheral, is isolated from access by the application processors and other components of the integrated circuit except through a secure mailbox mechanism implemented in the security circuit, 
This claim is directed to the idea of the "mailbox" mechanism previously described.  Defining "mailbox" seems like it would be a critical determination in any future patent lawsuit, as it's not clear to me that it has a generally understood meaning in the art of CPU design.  The question would be, I think, how far one must stray from Fig. 4 before being free from risk of infringement.  One interesting note, however, is that Claim 14 does not recite the term "mailbox" but instead refers to an "inbox" and "outbox," which perhaps implies that "mailbox" does not require that specific configuration (by a legal principle known as "claim differentiation.")  Again, it's not clear, as a thorough analysis not just of the patent specification, but of the correspondence between the patent examiner and the inventors, would be required in order to reach an informed guess as to what the term really means.

and wherein the one or more application processors are configured to write a message to the secure mailbox mechanism to request operation of the security circuit, and wherein the additional processor is configured to read the secure mailbox mechanism, determine whether or not the operation is permitted, and perform the operation responsive to determining that the operation is permitted. 
There's also a bit of fuzziness here.  "Determine whether or not the operation is permitted" could have various meanings, and a detailed analysis would have to be undertaken to determine what it means within the contexts of this patent.

What is clear, however, is that Apple is working hard to protect, by patents, those features which it feels provide the most differentiation from its competitors.  Apple is uniquely situated in that it makes most of its money selling hardware, and thus it has no need to try to monetize the infrastructures it provides for things like payments.  As Tim Cook noted at the keynote, Apple has no motivation to  collect data on its customers, and thus there is little holding it back from introducing consumer-friendly and privacy-friendly features like the Secure Enclave.  And, thanks to its patent portfolio, Apple's competitors will at least have to think a little harder before replicating some of these features.

No comments:

Post a Comment