Patent Application
20100241852
Products that are part of the Public Key Infrastructure (PKI) store a certificate to authenticate the product, as well as corresponding public and private keys. In one approach to storing a certificate and corresponding keys in a product, the product generates a key pair of public and private keys and a certificate request, which includes identification data of the product and the generated public key. The product then signs the certificate request with the generated private key and sends the signed certificate request to a Product Proxy (e.g., a host computer), which contacts a Registration Authority. The Registration Authority verifies the product's identification data and key pair and then contacts a Certificate Authority to issue a certificate. The Certificate Authority generates a certificate, signs the certificate with its own private key, and then sends the certificate back to the Registration Authority, which returns the certificate to the product via the Product Proxy. While this process works well when certificates are to be issued to an individual hardware product (e.g., a single server), this process may be too long and inefficient when certificates are to be stored in a large number of products in a manufacturing process because of the relatively-long time needed for each product to generate its own key pair, as well as the relatively-long time needed to communicate among four parties (the product, the Product Proxy, the Registration Authority, and the Certificate Authority).
VeriSign® Device Certificate Service provides a high-volume batch process to issue certificates that are to be embedded into products in a manufacturing process. In operation, a product manufacturer provides VeriSign® with a list of unique product identifiers for its products (e.g., media access control (MAC) addresses of cable modems) through a Web interface. VeriSign® issues the certificates and corresponding public and private key pairs and securely sends them in an encrypted form to the manufacturer via the Internet. The manufacturer decrypts the certificates and corresponding keys and embeds them in products during the manufacturing process.
The concept(s) presented herein can be implemented in various embodiments, and this summary includes a number of exemplary embodiments.
By way of introduction, the embodiments described below provide methods for producing products with certificates and keys. In one embodiment, a requesting entity transmits a request for a plurality of certificates and corresponding keys to a certifying entity that generates the certificates and corresponding keys. The request preferably includes information for use by the certifying entity to verify an identity of the requesting entity rather than information to verify unique product identifiers of the respective products. The requesting entity then receives the plurality of certificates and corresponding keys from the certifying entity, preferably in a plurality of organized sets instead of in a single series of certificates. The requesting entity then stores the certificates and corresponding keys in respective products. Each stored certificate is thereafter useable for both identification and authentication of the respective product in which it is stored.
Each of the embodiments described herein can be used alone or in combination with one another. Various embodiments will now be described with reference to the attached drawings.
Turning now to the drawings,
As used herein, a “requesting entity” refers to an entity that requests certificates and corresponding keys and is typically a product manufacturer (e.g., a memory card manufacturer). As also used herein, a “certifying entity” refers to an entity that verifies an identity of a requesting entity and generates requested certificates and corresponding keys. As will be clear from the below discussion, the requesting entity 120 and the certifying entity 130 can communicate with each other in any suitable form, either directly or indirectly. “Products” can also take any suitable form and generally contain a memory unit and an interface used to communication with another device. Examples of “products” include, but are not limited to, removable mass storage devices (such as non-volatile, solid-state (e.g., flash) memory cards), solid-state drives (SSDs), smart cards, optical or magnetic memory devices, game consoles, digital video recorders, set-top boxes, mobile phones, ATM machines, cable modems, personal digital assistants (PDAs), email/text messaging devices, digital media players, personal computers, and GPS navigation devices.
Returning to the drawings,
The request itself can contain any desired information.
Referring back to
The requesting entity 120 then verifies the incoming package of certificates and keys using the certifying entity's certificate and stores individual certificates and corresponding keys in respective products 110A, 110B, . . . 110N (act 230). Each certificate is then useable for both identification and authentication of the respective product 110A, 110B, . . . 110N in which it is stored. To securely store the certificates and keys in the products 110A, 110B, . . . 110N, the certificates and keys can be encrypted, preferably using a different key from the one used to encrypt the certificates and keys for transmission to the requesting entity 126, if such encryption was used. The requesting entity 120 can store individual certificates and corresponding keys in respective products 110A, 110B, . . . 110N using one or more computing devices (e.g., a general-purpose computer). Also, one or both of the transmitting and receiving acts (acts 210, 220) can use the same or different computing device(s), depending on whether a computing device is used in the transmitting and/or receiving acts. For example, the same or different computing device(s) that stores the certificates and keys can also be used to prepare the request (e.g., burn a DVD containing the request, email the request to the certifying entity 130 over the Internet, etc.) and/or receive the certificates and keys (e.g., by downloading the certificates and keys from the certifying entity 130 via a Web browser).
There are several advantages associated with these embodiments. First, because certificates are requested and received before the products 110A, 110B, . . . 110N are manufactured (i.e., the certificates are requested and received “off-line”), no time is wasted during the manufacturing process waiting for a certificate to arrive. Further, unlike the process described in the background section, in this embodiment, the products 110A, 110B, . . . 110N themselves do not generate public and private key pairs. Instead, the certifying entity 130 generates those pairs and sends them to the requesting entity 110 along with the corresponding certificates. In this way, no time is wasted during the manufacturing process waiting for the products 110A, 110B, . . . 110N to generate key pairs.
Further, because the requesting entity 120 in these embodiments is the manufacturer of the products and not the products 110A, 110B, . . . 110N themselves, the certifying authority 130 is operating on a per-manufacturer level and not on a per-product level. As a result, the certifying entity 130 need only verify the identity of the requesting entity 120 and not each individual product 110A, 110B, . . . 110N. Such verification can occur relatively easily and quickly (e.g., by verify that the request was signed by a private key previously provided to the requesting entity 120 by the certifying entity 130, by contacting a person at the requesting entity 120 who sent the certifying entity 130 a DVD order form, etc.) compared to verify unique product identifiers of each product (e.g., verifying media access control (MAC) addresses of cable modems). Because verification of the requesting entity 120 can be done directly and easily, these embodiments allow the process to bypass the Registration Authority, thereby saving time that otherwise would need to be spent communicating with the Registration Authority.
In should be noted that, in these embodiments, each certificate is useable for both identification and authentication of the respective product in which it is stored. The certificate can identify its respective product by a subject name of the certificate. While any suitable naming convention can be used for the subject name, in one embodiment, the naming convention uses one or more of the following fields: a time stamp indicating when the certificate was issued, a sequence number of issuance, and a name of the products being produced. For example, the naming convention can be: “<ProductName>MMDDYYYYXXXXXXXX”, where the <ProductName> is the name of the product line (not the name of an individual product), MM is the month the certificate was issued, DD is the day in the month the certificate was issued, YYYY is the year the certificate was issued, and XXXXXXXX is a sequential number of issuance. As can be seen from this exemplary identifier, a certificate is not bound to or identified by a unique identifier of an individual product. This is in contrast to the approach described in the background section, in which certificates are issued based on a list of unique product identifiers (e.g., media access control (MAC) addresses of cable modems). Further, these embodiments do not rely on a unique identifier of an individual product, which is especially beneficial when a product is initially anonymous and does not have a unique identifier (e.g., a removable memory card vs. a cable modem). Unlike cable modems which have uniqueness before storing a certificate, removable memory cards and other anonymous products gain uniqueness when a certificate is stored in them. As such, in addition to being used to authenticate, in these embodiments, a stored certificate is used to provide identification for a previously-anonymous product. So, unlike the approach described in the background section which uses a certificate to authenticate a product's identify, certificates in these embodiments are used to identify a product itself.
There are many alternatives that can be used with these embodiments. For example, for efficient certificate access, the plurality of certificates received from the certifying entity 130 can be presented as a plurality of organized sets instead of in a single series of certificates (e.g., in different ones of a plurality of directories or in a hierarchical directory tree instead of a single linear file or list). Organizing the plurality of certificates into sets makes access to a given certificate easier than if the certificates were contained in single list or file. As a simple example, bulk certificates can be stored in multiple directories, where each directory contains 1,024 certificates and is named with the certificates held in that directory (e.g., 1-1024, 1,025-2,048, etc.). To find a given certificate, a computing device at the requesting entity 120 would find the directory storing the certificate and then search through that directory for the certificate. Because there are relatively few certificates per directory, finding a certificate in a directory takes a relatively-short amount of time. In contrast, if all the certificates were stored in a single directory, the time to find a given certificate among thousands or millions of certificates would be substantially longer. Of course, this is merely one example, and other techniques can be used. For example, instead of placing the certificates in different directories, the certificates can be segmented or partitioned in other ways.
As another alternative, for added security, various encryption techniques can be used in this process. For example, to protect the request during transmission from the requesting entity 120 to the certifying entity 130, the request can be encrypted prior to transmission with a key (e.g., a “Request Encryption Key (REK)”) previously-received from the certifying entity 130. As another example, to protect certificates and keys during transmission from the certifying entity 130 to the requesting entity 120, the requesting entity 120 can send Product Encryption Key (PEKs) to the certifying entity 130 to encrypt each of the plurality of keys and corresponding certificates with a respective PEK. In this way, the plurality of keys and corresponding certificates would be received by the requesting entity 120 in encrypted form, and the requesting entity 120 would use the PEKs to decrypt each of the plurality of keys and corresponding certificates. Since such decryption would expose the plurality of certificates and keys, and the requesting entity can subsequently re-encrypt the plurality of certificates and keys using a different key. As yet another example, the requesting entity 120 can transmit an encryption key (e.g., a “Manufacturer Encryption Key (MEK)”) to the certifying entity 130, so that the certifying entity 120 can encrypt a batch of certificates and keys. After receiving the batch from the certifying entity 130, the receiving entity 120 would decrypt the batch with the MEK. Both PEK and MEK can be used to provide double encryption. Also, in one embodiment, prior to the requesting entity 120 requesting certificates and keys, the requesting entity 120 goes through a one-time set-up process with the certifying entity 130. During this process, the requesting entity 120 provides the certifying entity 130 with the REK and MEK. In this way, the REK and MEK exchange need only happen once and not every time the requesting entity 120 needs certificates and keys.
It is intended that the foregoing detailed description be understood as an illustration of selected forms that the embodiments can take and does not intend to limit the claims that follow. Also, some of the following claims may state that a component is operative to perform a certain function or configured for a certain task. It should be noted that these are not restrictive limitations. It should also be noted that the acts recited in the claims can be performed in any order -not necessarily in the order in which they are recited. Additionally, any aspect of any of the preferred embodiments described herein can be used alone or in combination with one another.
