“This time is different.”
Associated with speculative bubbles and market irrationality, that phrase also comes to mind occasionally in the field of information security. Completely ignoring history, a vendor enthusiastically pitches a solution that failed spectacularly under nearly very similar circumstances in the past. Latest addition to that venerable trend: trusted-execution environments (TEE) and TrustZone specifically being positioned as the silver bullet for trusted input on mobile devices.
Establishing trusted paths between a user and application running on general purpose computer is an ancient security conundrum. It was part of the motivation for the three finger-salute in Windows: pressing control, alt and delete keys simultaneously to bring up the system desktop. The problem can be phrased a deceptively simple question: how does the user verify that the user interface they are interacting with on-screen indeed belongs to the application they have in mind? This would be easy, except that a standard PC may have dozens of applications installed and at any given time any one could have full control over drawing the screen. Meanwhile getting it wrong can be quite problematic. Consider Windows logon. It is critical that the password is only entered into a genuine UI from the operating system, as opposed to a malicious application trying to capture that password by creating a look-alike dialog. Such differentiation can’t be accomplished using predictable features in the UI itself. Trying to distinguish the “real” logon screen by using a special logo or border color does not work. By assumption, even untrusted applications have full leeway to take over the entire desktop and paint anything on it. That same collection of pixels could just as well have been rendered malicious application operating in full-screen mode. This is where the CTRL+ALT+DEL key combination comes in. It is special-cased by Windows: that sequence is directly intercepted by the OS. User applications can not trap and handle this on their own, nor can they prevent the OS from taking its intended action: displaying the secure desktop, where users can rest assured that subsequent UI interactions involve a trusted OS component.
This problem is by no means unique to desktop operating systems. Identical concerns arise when using a phone or tablet for security critical scenarios. One popular scenario, given as the first example on ARM Trustzone page and explored in greater detail in another ARM presentation (slide #18) is PIN collection during a payment transaction.
The scenario has different manifestations:
- User typing PIN credentials into their own device as part of an online purchase– explicitly alluded to in the slide.
- Entering same credentials into a different mobile device such as iPad used as a point-of-sale terminal at a merchant location. (This is similar to the iPad/iPhone based POS that Square offers, except there is no PIN entry going on when processing credit cards in the US.)
For the second scenario, PCI requirements are very stringent around the collection of PIN, typically offloading this to dedicated PIN-entry-device (PED) hardware that does encryption on-board, before transmitting the PIN to the POS itself. The purported reason for not allowing PIN entry directly on the POS is the assumption that it is a higher risk environment as far as software attacks go. Such general-purpose computing devices are difficult to lock down, as openness is a virtue: users are free to install their choice of applications. The flip side however is that they can also make bad decisions around installing malware or intentionally disable security protections defined by the operating system. In fact the ARM scenario goes further in rejecting the commodity OS as part of the trusted computing base. Even if CTRL+ALT+DELETE style gestures could be resurrected from the 1990s, they would not help. They depend on the security of the underlying commodity OS such as Android, and the assumption is those components are too complex, too rich and present too large an attack surface.
Enter TrustZone into the fray. TZ is enjoying something of a resurgence, largely owing to wireless carriers success in stifling innovation with hardware secure elements— even when nearly all high-end Android devices have one ready for use in security critical applications. Unlike embedded secure elements or micro-SD based , TZ is a feature of the ARM processor and does not represent additional hardware cost. Based primarily in software, it defines a “secure world” similar to the informal ring -1 where hypervisors in x86/x64 world operate. Vanilla applications including the host OS run in standard mode, without access to the memory/resources of the privileged mode. There is a locked-down IPC mechanism for making calls to privileged applications and triggering certain entry points. For example when it is time for an extra-sensitive operation such as PIN entry during a payment, the point-of-sale application can initiate a context-switch to the secure world. At that point pre-existing code in the isolated compartment takes over and does not return control until user has entered the PIN. During this time both the display output as well as input devices such as touch screen, are directly controlled by privileged code. Even if malware happens to be resident on the device in the unprivileged compartment, it can not observe PIN entry. Sensor data– such as the location touch events on the screen– are routed directly to the special PIN collection application, with all code and data residing in privileged mode. When PIN entry is done, it is encrypted using the public-key of the payment processor and returned to the “ordinary” POS application as unintelligible ciphertext, safe from any mishap.