A More Secure Architecture for Mobile

mobile secure architacture

What do the latest Apple iPhone and many Samsung Galaxy Android phones have in common?  Each runs two separate operating systems on a single phone.  The application OS is the familiar iOS or Android OS.  Users download their apps and run them in this OS.  The second OS is a small, secure OS that handles keychains, cryptographic functions, and similar high security functions.

Apple’s secure OS for is described in their security white paper.  According to that paper,

The Secure Enclave is a coprocessor fabricated in the Apple A7 or later A-series processor. It utilizes its own secure boot and personalized software update separate from the application processor

The Secure Enclave runs an L4 microkernel, which has been modified by Apples.  The Secure enclave uses encrypted memory.  It communicates with the application processor via a single mailbox and some (unencrypted) shared memory.  It is impossible for the application processor to even access the main memory for the Secure Enclave.  Some devices, like the Touch ID sensor, communicate directly with the Secure Enclave over an encrypted channel.  The application processor can’t read the encrypted data sent to the Secure Enclave.

Many of the Samsung Galaxy phones are compatible with their Knox mobile security and management solution.  The Knox phones use Samsung’s Trust-Zone-based Integrity Measurement Architecture (TIMA) to verify the integrity of the Android OS. TrustZone-based keystores strengthen the key storage.

Mobile devices are increasingly used by consumers for digital wallets and payments.  Merchants use mobile devices and tablets to accept payments.  These use cases require high levels of security, and the design pattern used by Apple and Samsung can dramatically boost security.

The key concept here is to have two operating systems in a single device.  A small, secure OS runs in a trusted environment.  Its memory cannot be read by the application OS, and its memory can even be encrypted.  The application OS cannot disable or interfere with the secure OS.

Because the secure OS is small, its attack surface is also small.  Microkernels work well here since they can be verified.  In contrast, the feature rich Linux kernel has over 15 million lines of code, so reviewing its security in depth would be problematic to say the least.

The secure OS can also have encrypted communications to devices.  In Apple’s implementation, this means that fingerprints can only be read by the secure OS, and the application OS can’t even unencrypt them.  This same approach could be used to securely communicate between a credit card reader and the secure OS.  For POS terminals, this means that a credit card reader could talk to the secure OS without unencrypted credit card data ever passing through the application OS.  Carefully, done, this would make the POS almost immune to memory scrapers that steal credit card data.  (The scapers could only access the application OS memory, not the secure OS memory.)  This could also reduce the PCI compliance effort since the applications running in the application OS would never see credit card data.  For these apps, the system would resemble a P2P solution.

The application OS is the large feature rich and far more insecure environment where mobile apps are downloaded and run.  It has to be present, because consumers want it.  It lets them tap into the rich ecosystem of apps in the iTunes store or Google Play.  It also gives development organizations access to the many developers who are familiar with the iTunes and Android interfaces.

Using the two OSes in a single phone gives consumers the power and flexibility of iOS or Android apps, while significantly improving security.  Custom built devices POS can also reduce PCI compliance effort, and potentially defeat credit card memory scrapers.