Channels ▼


Enhanced Privacy ID

Application of Hardware Authentication

In this article, we present a new cryptographic scheme called Enhanced Privacy ID (EPID) that satisfies the security, privacy, and revocation requirements just discussed. Before we discuss EPID, however, we first discuss two applications of EPID. We first describe remote anonymous attestation and then discuss the application in digital drivers' licenses and identity cards.

Remote Anonymous Attestation. Why are we interested in the problem of remote hardware authentication? The answer lies in the fact that in many scenarios a verifier wants to know whether a request comes from an authentic hardware device or from a software emulator.

Consider the following remote attestation example, depicted in Figure 1 as a conversation between a client and a service provider. A client platform is running a hardware-based trusted execution environment, based on a smartcard, or on a Trusted Platform Module (TPM). The trusted execution environment includes functionalities, such as secure code execution, secure data storage, and secure key generation. The platform requests a resource from a service provider, such as a Digital Rights Management (DRM) key. The service provider needs to determine whether the platform can protect its resource. The platform can do a remote attestation by sending the service provider a measurement of its computation environment, for example, the platform can send its hardware and software configuration. The attestation needs to be combined with a remote hardware authentication, that is, one signed by the hardware's private key. The logic of such an authentication is that an attacker can easily forge a measurement, but an attacker cannot compute a valid signature without knowing a valid hardware private key. A hardware authentication scheme satisfying the design requirements, outlined in the previous section, can provide both security and privacy for the remote attestation.

Figure 1: An Example of Remote Attestation (Source: Intel Corporation, 2009)

The remote attestation problem was first introduced in the domain of a TPM, a small hardware module integrated into a platform, such as a laptop or a desktop. A direct anonymous attestation (DAA) scheme was developed by Brickell, Camenisch, and Chen [4] for remote authentication of a TPM, while preserving the privacy of the TPM. The DAA scheme was adopted by the Trusted Computing Group, an industry standardization body that aims to develop and promote an open industry standard for trusted computing hardware and software building blocks, and it was included in TPM specification version 1.2 [11].

Note that the EPID scheme presented here is an extension of the DAA scheme but has more revocation capabilities. Our EPID scheme has broader applicability beyond the remote attestation of a TPM. Let us look at two concrete applications of anonymous attestation.

Secure E-Commerce and On-line Banking. We now describe how EPID can be used for secure on-line banking. On-line banking is increasingly popular and provides great convenience to end users. However, the security of on-line banking is a concern, not only to end users but also to the banks. If the end user runs a platform that has a trusted execution environment and trusted I/O, the end user can conduct business in a relatively secure environment. However, the bank does not know whether the user is running in a secure environment. An anonymous attestation from the user's platform to the bank would give the bank more confidence that the transaction is secure.

For example, if a bank user performs some high-volume transactions, the bank wants to make sure that the transactions are properly authorized. If the user runs a trusted execution environment, the user can use the EPID scheme to anonymously attest to the bank so that the bank can give a token to the platform for future transactions.

The bank would know that the token was being secured in a trusted execution environment. In later transactions, the user enters a password into the trusted execution environment that unlocks the token so that the bank can authenticate the user's environment. This assures the bank of the authenticity of the transaction.

Content Protection. Here we describe how EPID can be used to protect content. An on-line media server provides high-definition media content to clients. In order to download media content, each client needs to first download a Digital Rights Management (DRM) key from the server in order to decrypt the content. Before sending a DRM key to the client, the server wants to know whether the client can protect its DRM key. If the client has a hardware-based trusted execution environment and has a unique EPID private key embedded, it can use EPID to perform an anonymous attestation to the media server. After the attestation, the media server is convinced that the client is indeed running a trusted execution environment and is not in fact running a software emulator.

Observe that in this example, if an attacker corrupts one EPID private key from a hardware device, the attacker may not publish the private key publicly. Instead, the attacker may use the compromised private key to obtain a DRM key from the media server. If the DRM key is found to be compromised on the Internet (for example, in ripper software), it can be traced back to the EPID private key that links it to the transaction that was used for provisioning the DRM key. Consequently, the issuer can revoke the compromised private key, based on the transaction of the key. This is an example in which the media server may wish to be assured that it issues only one DRM key for each EPID private key. This is accomplished through making the requests for DRM keys linkable to each other. But these requests would not be linkable to any other transactions.

Drivers' Licenses and Identity Cards. Various governments are considering including machine-readable information on drivers' licenses and identity cards. In the case of drivers' licenses, the machine-readable portion (for example, the bar code or magnetic strip) of the license is readable to anyone with a license reader. Unfortunately, such an approach raises serious privacy concerns, as personal information in the magnetic strip or bar code can be easily gathered and then sold without the owner's consent -- potentially leading to identity theft.

Encrypting the machine-readable portion of the license has also been proposed. Such a practice poses significant key management challenges; the decryption must be available to authorized parties only.

We describe how EPID can be applied to drivers' licenses. Each license has an embedded smart card chip that can store and process information. A card reader is used to communicate with the license. The license is assigned a unique private key when it is issued by the government department that oversees the licensing of automobile drivers. It can be used for various purposes without violating the user's privacy. The smart card license would be able to prove to the reader that it is a valid license and that it has not been revoked, suspended, reported lost, and so forth. The smart card accomplishes this by using the proof of membership protocol; in this way the identity of the license is not revealed.

Each government agency would have multiple groups capable of issuing of licenses. During the process of proving its validity to a reader, a license reveals which license group it is in, and it reveals whether or not it is a valid license in good standing. It does not, however, reveal which license it is within that license group.

Using the EPID scheme, the membership proof is unlinkable. This means that if a license is used at a restaurant, for example, and it is valid and issued to someone of legal age, when that same license is used again at the same restaurant the next night, the restaurant owners would not be able to tell that it was the same license that was being presented. The restaurant owner is only acquainted with certain information: the validity of the license and that the patron is of legal age.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.