post I discussed the storage of derived credentials
(Federal credentials carried in a mobile device instead of a PIV/CAC
card) in a software token, i.e. in a cryptographic module
implemented entirely in software, whose contents are stored in
ordinary flash memory. In this post I will discuss the storage of
derived credentials in a Trusted Execution Environment (TEE).
As discussed in the previous post and in a
report, it is possible to protect derived credentials stored in
ordinary flash storage by encrypting them under a high entropy
key-wrapping key kept in a secure back-end, which the mobile device
retrieves by authenticating to the back-end with a key pair
regenerated from a protocredential and an activation passcode.
This provides effective protection against an adversary who captures
the device while the software token is not active, preventing the
adversary from extracting or using the credentials. But it does not
provide protection against malware running on the device while the
legitimate user is using the device. Such malware can carry out the
It can use the derived credentials, by issuing instructions to the
software token after it has been activated by the legitimate user.
It can read the plaintext derived credentials from the flash storage
after the software token has been activated, and transmit them to the
adversary responsible for the malware, who can then use them at will
on a different machine.
It can capture the activation passcode by phishing or intercepting it.
In a phishing attack, malware prompts the user for the passcode while
masquerading as legitimate code that needs the passcode, such as token
activation code. In an interception attack, malware gets the passcode
after it has been obtained from the user by legitimate code.
The first of these attacks may be impossible to prevent once
privileged malware is running on the mobile device without the user
being aware of it. But the second and third attacks can be prevented
using a TEE as we shall see below; and preventing them is important
because they are more damaging than the first attack.
The second attack, extracting the credentials and sending them to the
adversary, is more damaging than the first because it cannot be
stopped by recovering or wiping the stolen device. Use of an
authentication or signature private key cannot be stopped until the
associated certificate is revoked and relying parties become aware of
the revocation. Correspondents should avoid sending messages
encrypted under a symmetric key wrapped by a “key management” public
key after becoming aware that the key management certificate has been
revoked. But there is no time limit for using a key management
private key to decrypt earlier messages that the adversary may have
previously captured or may capture in the future, e.g. by breaching
the security of a MS Exchange server containing older encrypted
The third attack is even more damaging for several reasons. First, it
enables the first two attacks, because once it has the passcode,
malware can activate the software token and use and extract the
plaintext derived credentials. Second, if the adversary captures the
device after using malware to obtain the passcode, the adversary can
use the device, or install more comprehensive malware that is able to
extract the credentials. Third, the passcode may be independently
exploitable because it may be used for other purposes.
A TEE has security features that make it possible to prevent the
second and third attacks.
Features of a TEE
is a computing environment provided by a secure OS running on the same
processor as a normal OS. One or more trusted applications (TAs) run
under the secure OS. A hardware bus architecture ensures that a
portion of the flash storage can only be accessed by the secure OS.
Both OSes can access the touchscreen, but a security indicator lets
the user know when the screen is controlled by the secure OS and the
user interface can be trusted.
, including a Trusted User Interface API
specification, which can be downloaded from the GlobalPlatform site.
TEEs are provided by ARM Cortex-A processors, where a TEE is also
referred to as a
A TA running in a TEE can be used to implement a cryptographic module
in which derived credentials can be stored and used.
Using a TEE to Protect Derived Credentials
Derived credentials stored and used in a cryptographic module
implemented within a TEE can be protected against the second malware
attack discussed above by making their private keys unextractable from
the cryptographic module. The ability to mark private keys as being
unextractable is a typical feature of cryptographic modules. The
#11 cryptographic module API, for example, allows private keys to
be made non-extractable by setting the value of their CKA_EXTRACTABLE
attribute to CK_FALSE. The forthcoming TEE Functional API, mentioned
white paper, will no doubt allow private keys stored in a
cryptographic module within a TEE to be made non-extractable as well.
Furthermore, derived credentials stored in a cryptographic module
within a TEE can be protected against the third malware attack using
the Trusted User Interface feature of the TEE. The passcode can be
prompted for by the TA that implements the cryptographic module, and
the user can be instructed to only enter the passcode when a Security
Indicator shows that the touchscreen is controlled by the Secure OS of
the TEE. The passcode is then protected against phishing and
interception by malware, assuming that all TAs can be trusted and that
the secure OS is not infected by malware. The latter assumption is
motivated by the fact that the secure OS is simpler than the normal OS
and presents a much smaller attack surface.
Virtual Tamper Resistance
Using the same processor and a portion of the same storage for the
secure OS as for the normal OS has important benefits. It provides
greater performance for the secure OS than would typically achieved by
a secondary processor located in a secure element, and it saves the
cost of the secure element. On the other hand, it means that a TEE is
not expected to provide much, if any, tamper resistance. Indeed, the
TEE Secure Element API, available at the GlobalPlatform site,
is concerned with using together a TEE and a secure element, with the
TEE providing a Trusted User Interface, and the secure element
providing tamper resistance.
(BTW, some secure elements do provide serious tamper resistance, but
tamper resistance is never absolute. A fascinating description of the
elaborate anti-tampering countermeasures in a family of Infineon
chips, and how they were defeated by an attacker with no insider
knowledge, can be found in an
demonstration—broken down into ten eight-minute
segments—presented at Black Hat 2010.)
But the lack of tamper resistance in a TEE can be remedied using
the same technique that I described in the previous
post as a solution to the problem of protecting derived
credentials stored in a software token. Encrypting the derived
credentials under a high entropy key-wrapping key, kept in a secure
back-end and retrieved by authenticating to the back-end with a key
pair regenerated from a protocredential and an activation passcode,
can be viewed as a form of cloud-based virtual tamper
Combining such virtual tamper resistance with the TEE Trusted User
Interface feature would make it possible to implement a cryptographic
module that would protect both the derived credentials and their