Channels ▼
RSS

Tools

Enhanced Privacy ID


Ernie Brickell is a Senior Principal Engineer and Chief Security Architect at Intel. His e-mail is ernie.brickell@intel.com. Jiangtao Li is a Security Architect at Intel. His e-mail is jiangtao.li@intel.com. Copyright (c) 2009 Intel Corporation. All rights reserved.


Consider the following problem. A hardware device (for example, a mobile device, a graphics chip, a trusted platform module, a processor package, or a smart card) wants to prove to a verifier that it is a genuine hardware device manufactured by a certified hardware manufacturer. The easiest way to prove that it is the genuine article is for the verifier to read the serial number to the hardware manufacturer to verify that it is indeed the device in question. Each hardware device is assigned a unique serial number that is inscribed on the body of the device by the manufacturer. The problem with this solution is its limited application: the verifier needs to physically have the device in order for this kind of authentication to work. In many cases, a piece of hardware needs to be authenticated remotely. Remote hardware authentication is the main focus of this article.

A possible solution to the problem of remote hardware authentication is for the hardware manufacturer to assign each device a unique device certificate. More specifically, each device could be assigned a unique public and private key pair. The hardware manufacturer certifies the device by issuing a cryptographic certificate to the device public key. When the hardware device needs to be verified, it sends its device certificate to the verifier along with a signature signed with its private key. The verifier can then use the hardware manufacturer's public key to verify the device certificate and then use the device's public key in the certificate to verify the signature. This solution is secure, as long as the device can protect its private key, since only hardware devices made by the original manufacturer have valid device certificates.

This certificate approach is also scalable, as the device manufacturers can issue as many device certificates as they want. However, issuing a device certificate raises a privacy concern, because the device certificate is used to uniquely identify the device. The verifier, therefore, can use the device certificate to trace a device and the associated authentication activities.

In this article, we introduce a new cryptographic scheme called Enhanced Privacy ID (EPID) for remote, anonymous authentication of a hardware device. Using EPID, a hardware device can prove to a verifier remotely that it is a valid device, certified by the hardware manufacturer, without revealing its identity and without the verifier being able to link multiple authentication attempts made by the device.

Conceptually, an EPID scheme can be viewed as a special digital signature scheme. Unlike traditional digital signature schemes, one public key in the EPID scheme corresponds to multiple private keys. There are three types of entities in an EPID scheme: issuer, members, and verifiers. In our context, the issuer is the hardware manufacturer, the member is a hardware device made by the manufacturer, and the verifier could be software on the host, a server on the Internet, or another hardware device. The issuer creates an EPID public key and issues a unique EPID private key to each member. Each member can use this private key to digitally sign a message, and the resulting signature is called an EPID signature. The verifier can use the public key to verify the correctness of a signature, that is, to verify that the EPID signature was indeed created by a member in good standing with a valid private key. The EPID signature, however, does not reveal any information about which unique private key was used to create the signature.

Prerequisites and Design Requirements

We first formalize the remote hardware authentication problem, then describe the prerequisites for the problem, and end with our design requirements.

Remote Hardware Authentication Problem. To do remote authentication securely, cryptographic keys need to be used. There are three entities involved in a remote authentication scenario: the issuer, members, and verifiers. The issuer is a hardware manufacturer who creates a group. A member is a hardware device manufactured by the issuer. A member can join or leave the group.

When a member joins the group as it is manufactured, the issuer issues a private key to the member. When the member leaves the group, the issuer revokes the private key of the member. Leaving the group is a rare event. It occurs only when the private key of the member (the hardware device) has been extracted from the hardware device, and the issuer has to revoke the membership of the device, or in other words, revoke the private key. A verifier is an entity that wants to know that a hardware device is a member of the group. The remote hardware authentication is an interaction between a member and a verifier. The member uses its private key to prove to the verifier that it is a valid member of the group and has not been revoked.

Prerequisite. To have a secure remote hardware authentication scheme, the member (that is, the hardware device) must have a good protection system for its private key. In other words, the member should have secure storage to store the private key and have a trusted execution environment to use the key to perform the membership proof. If an attacker can easily extract the key information from a member, then there is no way to do remote hardware authentication securely, as the attacker can always use the extracted private key to perform the membership proof before the key is revoked. This means that the verifier cannot tell whether the proof comes from the attacker or from a real hardware device.

Security Requirements. The basic security requirement is straightforward; that is, only a member in good standing could perform the membership proof successfully. In other words, if the prover is not a member of the group, then its proof of membership would be rejected by the verifier. This property should hold unless a private key has been removed from a member and has not yet been revoked, or unless a problem considered computationally infeasible has been solved.

Privacy Requirements. In a remote hardware authentication scheme, the membership proof must be anonymous and unlinkable. In addition, the private key of each member should be unknown to the issuer. More specifically, these are the required privacy properties:

  • Given a membership proof, the verifier or the issuer cannot identify the actual prover, that is, cannot extract any identifiable information about the member from the proof. This is known as the anonymity property.
  • Given two membership proofs, the verifier or the issuer cannot tell whether the proofs are generated by one member or by two different members. This is known as the unlinkability property.
  • The issuer does not know any of the private keys of the members. Therefore, the issuer does not have a database of all the members' private keys.

The unlinkability requirement is optional. In some applications, the verifier may require the membership proofs from a member to be linkable. Linkable proofs help to prevent a member from abusing the anonymity requirement. For example, suppose a verifier is a key-provisioning server that provisions a key to each member (that is, each hardware device). This verifier wants to make sure that each member is provisioned with only one key. Suppose that an adversary is able to extract a private key from a member device. If the remote hardware authentication scheme has the property of anonymity but not unlinkability, then the verifier would issue many keys to this adversary by using this one compromised member key. Then if the verifier found that one of the provisioned keys had been abused, he or she would be able to revoke it but would not be able to revoke all of the other keys that this adversary had obtained from the one compromised member key. Privacy issues with this use can be controlled, since the member needs to obtain the provisioned key from this verifier only once, and this usage can be unlinkable to any usage with any other verifier.

Revocation Requirements. A remote hardware authentication scheme must handle revocation. In general, when a hardware device is manufactured, it joins the group. Even if the ownership of the hardware device changes or the device is stolen, it is still a valid, authentic hardware device; thus, it is still in the group and does not need to be revoked.

Only if the private key has been extracted from the secure storage of the hardware device, does the member have to be revoked. Given the prerequisites mentioned earlier, the issuer assumes that the member's (the hardware device's) private key is well protected. Thus, the revocation of a member is a rare event. However, the issuer needs to have the ability to revoke a member from the group if needed. The first revocation requirement is that the revocation of a group member should have minimum impact on the rest of the group members.

The second revocation requirement is that if an extracted private key is known to the issuer, then the issuer should be able to revoke that private key.

The third revocation requirement is that if a private key is used in a transaction, and it is later discovered that the key used in that transaction had been extracted, then this key should be revocable, even if it is not known. An example of such a case would be if a transaction was to provision a verifier key into a hardware device, and this verifier key was later shown to be extracted, the issuer may conclude that the private key of the hardware device has been corrupted and should be revoked.

Note that if an attacker extracts a private key from a hardware device and never uses the key, the key can probably never be revoked. On the other hand, if the attacker never uses the extracted private key to forge or emulate a hardware device, there is no damage to the hardware authentication scheme.


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.
 

Video