SECURE ONLINE ISSUANCE OF CUSTOMER-SPECIFIC CERTIFICATES WITH OFFLINE KEY GENERATION

Abstract

In a system comprising a client providing a service to a plurality of client devices, a method and system for providing a client-specific digital certificate to one of the client devices is described. The method comprises receiving, at an intermediate certification authority, a previously generated digital certificate and an encrypted client device private key encrypted according to a PrKEK private key encryption key; receiving, from the client device, a request for the client-specific digital certificate; the request comprising information identifying at least one of the client devices and information identifying the client; the request signed according to a previously provided client device digital certificate; and transmitting the client-specific digital certificate and the encrypted client device private key to the client device.

Description

SECURE ONLINE ISSUANCE OF CUSTOMER-SPECIFIC CERTIFICATES WITH OFFLINE KEY GENERATION ινΐΛ / a / zuzz / ui 11 (or CROSS REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. provisional patent application no. 62 / 994,996, entitled “SECURE ONLINE ISSUANCE OF CUSTOMER-SPECIFIC CERTIFICATES WITH OFFLINE KEY GENERATION”, by Alexander Medvinsky, Tat Chan, Xin Qui, Jason Pasión, Ting Yao, Shanthakumar Ramakrishnan, filed on March 26, 2020, the application of which is incorporated herein by reference. This application relates to the following jointly pending and commonly assigned patent application(s), all of which are incorporated by reference in this description: Application serial no. 15 / 885,107, entitled “ONLINE CERTIFICATE ISSUANCE BASED ON CERTIFICATE OF ORIGIN”, filed on January 31, 2018, by Alexander Medvinsky, Eric J. Sprunk, Xin Qiu, and Paul Moroney, whose application claims the benefit of U.S. provisional application no. 62 / 452,750, entitled “ONLINE CERTIFICATE ISSUANCE BASED ON CERTIFICATE OF ORIGIN” filed on January 31, 2017, by Alexander Medvinsky, Eric J. Sprunk, Xin Qiu, and Paul Moroney. FIELD OF INVENTION The present invention relates to systems and methods for secure communication, and in particular to a system and method for rapidly issuing digital certificates. BACKGROUND OF THE INVENTION A certificate authority (CA) is expected to operate a highly secure system. Device manufacturers and service providers rely on CAs to maintain control over secure parameters such as device private keys and the CA private key used to sign device certificates. However, any online system is vulnerable to numerous network-based threats and attacks. Therefore, maintaining a CA in a secure, offline facility is typically preferred. However, some certificate profiles and requirements may require an online Certificate Authority (CA). For example, sometimes it's necessary to include device characteristics within a certificate. These characteristics might include the device's serial number(s) and identifier(s), device model, software version, hardware version, etc., and it's not always possible for a CA to know this information about a device before the device certificate is requested. Instead, sometimes the information needs to be provided online at the time of a certificate request. In another example, the certificate's lifespan might be very short, e.g., only a few months. Certificates with such a short lifespan might be issued to devices that aren't very secure and are therefore not as trusted as certificates with longer lifespans. In other cases, short certificate lifespans are associated with short subscription periods, such as a 1-hour or 1-day subscription for a public Wi-Fi hotspot. In such cases, certificates that were issued in batches before being requested might remain on a key server for weeks or even months before being requested and could be nearing their expiration date when needed. To avoid supplying certificates for devices that are close to expiring, it's best to issue them online at the time a certificate is requested. Therefore, there is a need for a system and method that provides online access to digital certificates upon request and with minimal delay. U.S. Patent Application No. 20180219678, published on August 2, 2018, describes a system and method in which device and certificate key pairs are generated in a secure offline facility and then reissued as new certificates at the factory with additional information that was not available during the initial offline generation. In this system and method, for each certificate type, there is a template used to determine how the new certificate should be issued—based on the original certificate and certain new information available at the factory. However, there are situations where, during the offline generation of peer and key certificates, the target client is unknown, and each target client has its own certificate template that includes a separate, client-specific Sub-CA. What is needed is a system and method that provides for the generation and provisioning of certificates under such circumstances. BRIEF DESCRIPTION OF THE INVENTION This summary is provided to introduce a selection of concepts in a simplified form, which are described in more detail below in the detailed description. This summary is not intended to identify key features or essential characteristics of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. To address the requirements described above, this document outlines a system and method for providing a client-specific digital certificate to one or more client devices. Such clients may include IoT service providers, cloud service providers, wireless network operators, or other entities.The method comprises receiving, at an online certification authority, a pre-generated digital certificate and an encrypted private key from a client device encrypted according to a PrKEK private key encryption key; receiving, from the client device, a request for a client-specific digital certificate; the request comprising information identifying at least one of the client devices and information identifying the client; the request signed according to a previously provided client device digital certificate; and transmitting the client-specific digital certificate and the encrypted client device private key to the client device. Another embodiment is demonstrated with a device having a processor and a communicatively coupled memory that stores processor instructions for performing the above operations. The features, functions, and advantages described can be achieved independently in various embodiments of the present invention or can be combined in still other embodiments, further details of which can be seen with reference to the following description and figures. BRIEF DESCRIPTION OF THE FIGURES Referring now to the figures in which similar reference numbers represent corresponding parts in all figures: Figure 1 is a diagram illustrating one type of certificate issuance system; Figure 2 is a diagram illustrating the derivation and use of a key agreement encryption key; and Figure 3 illustrates an illustrative computer system that could be used to implement processing elements of the geolocation system. DETAILED DESCRIPTION OF THE INVENTION The following description refers to the accompanying figures, which form part of this description and illustrate various modalities. It is understood that other modalities may be used and structural changes may be made without deviating from the scope of this description. General information An Offline Certificate Authority (OFFCA) is used to generate customer public / private key pairs, encrypt the private keys, and issue the corresponding digital certificates. This information is transferred to an Online Certificate Authority (ONCA), which incorporates multiple customer-specific issuing CAs and does not have the means to decrypt or modify the device's private keys. However, the ONCA (upon receiving a certificate request) can extract the public key and other relevant information from a previously generated offline device certificate and sign a new device certificate (Final Certificate) that includes the information from the request.In this context, data signing refers to a digital signature scheme in which a message or data is "signed" with a signature generated from the data and a private key from a private / public key pair associated with a client-specific Certificate Authority (CA). The client-specific CA private key is selected based on the client's identification information in the certificate request message. The response message from the CA is then transmitted, containing the new client-specific certificate, the corresponding encrypted device private key, the CA message signing certificate chain, and a message signature. The message recipient can then verify the message's authenticity (that it originated from the message sender) using the message, the enclosed certificate chain, and the signature. This solution offers flexibility typically found only in a Certificate Authority (CA) and can generate device certificates using device information available only at the time of a certificate request. It also enhances system security by limiting the functions the CA must perform. Because the CA cannot generate, replace, or access device private keys and is also limited in the information it can generate and include in device certificates, none of the device private keys will be exposed, even if the CA is compromised. The ONCA obtains encrypted device private keys and source certificates from the offline CA and, therefore, cannot generate more device private keys and source certificates than those already provided by the OFFCA. Once a security risk is identified within the ONCA, it stops receiving new encrypted device private keys and source certificates, limiting the number of individual device certificates that would later need to be revoked and replaced. Furthermore, OFFCA incorporates high-quality, hardware-based random number generation to ensure that public / private key pairs are unique with a high level of entropy, rather than relying on client devices, which may have limited CPU resources and low entropy, potentially resulting in duplicate key pairs. Additionally, after a device is already installed at a customer's location, it provides a customer name or ID in a certificate request, and one of the previously generated offline certificates is used along with the customer information to find a correct customer-specific template and issue a customer-specific certificate from a customer-specific CA. Pre-generation of cryptographic assets Figure 1 is a diagram illustrating one mode of the Certificate Issuance System (CIS) 100. The CIS 100 comprises a key generation facility 102 that has the OFFCA 104 and the ONCA 106. In one mode, the operation of the CIS 100 is described as follows according to the numbered operations shown in Figure 1. In the first process, OFFCA 104 generates device private keys 150, the corresponding public keys, and source certificates (containing the client device public keys 108). Since the source certificates 152 are pre-generated (e.g., generated before they are requested by client devices 108), they are alternatively referred to hereafter as pre-generated certificates 152. The device private key type and device public key type in the certificate can be Rivest-Shamir-Adleman (RSA), Elliptic Curve, EIGamal, Digital Signature Algorithm (DSA), or any other type of public / private key pair. In the second process, OFFCA 104 encrypts the private keys of device 150. In one mode, each private key of device 150 is encrypted separately using a key that is not accessible to OFFCA 106. For example, the encryption key used to encrypt each of the private keys could be a private key encryption key (PrKEK) that is global, applicable to all client devices 108 for a particular client, applicable to all client devices 108 for all clients, unique per client device model 108, or it can even be a unique value that has been previously provided separately on each target client device 108 or chip within the target client device 108. PrKEK can be a symmetric encryption key such as AES or 3DES, or it can be a public key of type RSA or EIGamal so that client devices use a matching PrKEK-Private private key to decrypt their private keys. It is important to note that PrKEK (or the corresponding Private PrKEK) is not available to ONCA 106, and ONCA 106 does not need to decrypt or make any further modifications to the private keys for device 150 received from OFFCA 104. In one mode, PrKEK (or Private PrKEK) is available only to the target client devices 108. In other modes that have a proxy agent 110 (described further below) interposed between ONCA 106 and the target client devices 108, PrKEK may be available to the proxy agent 110, which provides an indirect network connection between ONCA 106 and the client devices 108. The proxy agent 110 is described in further detail below. In one mode, an optional second layer of encryption is imposed where the private keys of device 150 are further encrypted (e.g., double-encrypted) using an encryption key that is specific to a particular instance or server of ONCA 106. This optional encryption key is henceforth referred to as the Outer Layer Encryption Key (OLEK). This additional encryption of the private keys of device 150 according to the OLEK is illustrated in the third process in Figure 1. In operation four, OFFCA 104 optionally makes copies of the source digital certificates and encryption private keys and archives them in a data repository, for example, the central PKI repository illustrated in Figure 112. This archived information can be used to generate reports later or to re-provide the device private key and source certificates to client devices 108 that lose their private key and / or certificate, for example, due to memory corruption in the client device 108 itself. This allows the PKI of the same device to be re-provided to those devices. Regulations or customer requirements may prohibit the storage of device 150 private keys in the data repository, or limit the period during which such device 150 private keys may be stored or archived (after which they must be deleted), even when the device 150 private keys are in encrypted format. In such cases, device 150 private keys are not archived as described in operation four. However, even in such cases, source digital certificates 152 may be archived, as there are generally no prohibitions against storing or retaining source digital certificates 152. Provision of pre-generated cryptographic assets to the intermediate certification authority In operation five, the previously generated (in operation one) and encrypted device private keys 150 and the previously generated origin certificates 152 are delivered MA / a / ZUZZ / UI 1 l (or from the key generation facility 102 to the ONCA 106). Since OFFCA 104 is offline, a manual transfer step may be involved, such as transferring the generated keys and certificates to an online computer via removable media. These previously generated encrypted private keys 150 and source digital certificates 152 are subsequently retrieved and used by the ONCA 106 in response to certificate requests from client devices 108. Optionally, the interface used to transfer this information from an online computer is authenticated and encrypted, e.g., using TLS or SSL, or an IPsec-based VPN to ensure that all PKI assets transferred to an ONCA 106 came from a legitimate source and to prevent denial-of-service attacks. In operation six, client device 108 and ONCA 106 establish a secure (encrypted and authenticated) session—for example, using an authenticated bidirectional TLS protocol. This operation is optional, as it is possible to encrypt / authenticate each transaction separately (as described below) without using a separate, pre-established secure session between client device 108 and ONCA 106. Additionally, a secure session can be established between ONCA 106 and the proxy agent 110 referenced earlier. In that case, the process of establishing a secure session could occur earlier, at any time before one of the client devices 108 sends a request to ONCA 106 for identity (operation seven below) via proxy agent 110. Request for a specific customer crypto asset In process seven, client device 108 requests a client-specific digital certificate 156 and a private key from client device 150. This request includes at least one piece of client device identification information (e.g., MAC address, client ID, serial number, or client device model information) and information that identifies the client (e.g., client ID) for whom the client-specific digital certificate 156 is desired. For example, client device 108 might be a radio controller that wants a digital certificate for use with a particular group or unit of a plurality of cellular network operators 170 that provide service to client devices 108.This request may also include a Device Credentials Profile ID (DCC ID), which is an alphanumeric identifier associated with a specific set of device credentials. This set may include an asymmetric device private key and a unique digital certificate for the device, along with any number of additional unique and global device keys, digital certificates, and identifiers. This optional information may be included in the client-specific device digital certificate generated by ONCA and returned to the client device. The digital certificate request can be authenticated (e.g., digitally signed) by the requesting client device 108 using a pre-installed private key and digital certificate 172 that are already factory-installed on the client device 108 prior to deployment. This pre-existing private key and digital certificate can be global or unique in a variety of ways (e.g., unique among all devices from all sources, unique among devices from a particular source, or unique among devices of a particular class or model). The request can be delivered directly to ONCA 106 or it can be delivered first to proxy agent 110. Proxy agent 110 can simply forward the request message as is to ONCA 106. Alternatively, proxy agent 110 can verify the signature in the request message (if the message includes a signature) as well as verify the authorization of the requesting client device 108 to request certificates. If both verifications pass, then proxy agent 110 re-signs the same request with its own signing key and forwards the message to ONCA 106. In some modes, in addition to or instead of a secure session established during process six, this request message may include a Client Key Agreement Public Key (CKAPK). CKAPK can be, for example, a Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) public key and will be used to protect the private key returned by ONCA 106 at a later stage. CKAPK can be generated either by the client device 108 or by the proxy agent 110. CKAPK must be generated together with the corresponding Client Key Agreement Private Key (CKAPrK), as they are paired keys. In operation eight, ONCA106, upon receiving the request, first authenticates it by verifying the signature. It then validates the authorization provided by ensuring that any entity signing the request (either the proxy agent 110 or the client device 108) is authorized to obtain the requested client-specific digital certificate. If the request authentication or authorization validation fails, ONCA106 returns an error code to the client device instead of a valid (and encrypted) device private key 150 and a client-specific device certificate 156. In operation nine, ONCA 106 determines the identity of the client device 108 and the identity of the client 170 for whom the client-specific digital certificate 156 is requested. Regarding the identification of the client device, several different methods are provided. In one method, the previously provided client digital certificate 172 is a global digital certificate, and the client device identification information and the client identification information are explicitly provided in the certificate request message, for example, the client's MAC address or IP address, and are simply extracted for use. In another mode, the previously provided client digital certificate 172 is unique to the client device 108, and the client device identification information is determined from the previously provided client device digital certificate 172. The client is then optionally identified according to a comparison between the client device identification information and a predetermined mapping of the client device identification information and the INALA / a / zuzz / ui 11 (or client) that ONCA 106 provides and maintains. For example, the digital certificate may include a MAC address of the client device, and the client may be identified according to a comparison between the client device's MAC address and a whitelist of MAC addresses for each of the plurality of clients.Alternatively, the client's identity is explicitly specified in the client device certificate or in the request message. In yet another modality, the client-specific digital certificate is a pre-generated digital certificate associated exclusively with the client device's identification information, and the pre-generated digital certificate is one of a batch of pre-generated digital certificates for a group of multiple client devices 108 of which the requesting client device 108 is a member, and the pre-generated digital certificate is provided to ONCA 106 before receiving the request for the client-specific device digital certificate 156. Recovery and creation of a client-specific crypto asset In operation ten, ONCA 106 finds an available pre-generated certificate 152 (not yet assigned to a client device 108) and an encrypted device private key 150 from its local repository. Subsequently, ONCA 106 generates a new client-specific device certificate 156 derived from the previously generated certificate 152 while keeping the encrypted device private key 150 the same as the encrypted device private key 150, as described below. In operation eleven, after identifying the requesting client device 108, identifying the client 170, validating the authorization, and retrieving the previously generated digital certificate 152 appropriate for the requesting client device 108 and the client 170, the ONCA 106 selects and retrieves a target digital certificate template 158 for the client device 108 that matches the requesting client 170 and the client device 108 for this request from a certificate template database 114. A certificate template 158 includes information such as the certificate lifetime and various certificate attributes and extensions that must be present in the client-specific device certificate 156.The same set of digital certificates of origin 152 that are issued by the same OFFCA 104 and have a common profile can be assigned to different certificate templates and different signing keys depending on a configuration of ONCA 106. Or, they can be combined with a specific certificate template, but with different client-specific CA signing keys. Many of these attributes and extensions may already be present in the source digital certificates 152 generated by OFFCA 104. However, some attributes, such as a device ID, chip ID, device serial number, device software (SW), and hardware (HW) version, may not have been known prior to OFFCA 104. In one mode, certificate template 158 indicates which of these attributes should be added to the source digital certificate 152 to generate the client-specific device certificate 156 issued by OFFCA 106, and where such attributes fit within the client-specific device certificate 156. It is possible for multiple client device models 108 to share the same 158 certificate template. The reverse is also true—a single client device model 108 can support multiple 158 certificate templates. In the latter case, a request message sent in step 7 would specify which 158 certificate template is being requested. Optionally, ONCA 106 can determine which certificate template and signing key should be applied to the new client device certificate based on the information in the request message from the device. Optionally, certificate template 158 can contain a digital signature from OFFCA 104 that needs to be verified by ONCA 106 before certificate template 158 can be used. This digital signature protects against unauthorized corruption of certificate templates 158 in the ONCA 114 certificate template database. During operation twelve, ONCA 106 accesses a signing key 164 from Certification Authority 162, which ONCA 106 will use to sign the client-specific digital certificate 156. This CA 162 signing key is typically referenced in the certificate template 158 and is client-specific. This CA 162 signing key may be stored in a hardware security module (HSM) 160 that is communicatively coupled to a computer or other hardware device of ONCA 106. In that case, ONCA 106 obtains a handle for the CA 162 signing key within the HSM 160, and the handle can then be used to sign a client-specific device certificate 156. In other cases, the CA 162 signing key can be stored as an encrypted value referenced by certificate template 158. In this mode, ONCA 106 sends the encrypted CA 162 signing key to HSM 160, and HSM 160 "unwraps" (i.e., decrypts) the CA 162 signing key within the HSM. ONCA 106 then uses the CA 162 signing key to sign the client-specific device certificate 156. In operation thirteen, ONCA 106 creates the customer-specific unsigned device digital certificate 155, which contains the encrypted device public key, and selects other attributes from the previously generated source certificate 152 retrieved in step ten, the selected target digital certificate template 158, and the customer identification information. The remaining attributes in the new customer-specific device certificate 156 are determined based on the certificate template 158. Typically, this would include a validity period start date based on the current date and time and a validity period end date based on the lifetime of the customer-specific device certificate 156, as determined by the certificate template 158.Other data such as an identifier or serial number of the client device 108 as well as other attributes of the client device 108 specified by the certificate template 158 may be added to the client-specific device certificate 156 during this stage. In step fourteen, ONCA 106 then signs the new unsigned customer-specific device certificate 155 using the CA signing key 162 obtained in step twelve, which is usually protected within HSM 160. In operation fifteen, ONCA 106 returns the client-specific device certificate issued 156 along with the corresponding encrypted device private key 150 (copied unchanged from the database or repository 112) to the requesting client device 108 in the response message. In addition to the optional protection provided by a secure session between ONCA 106 and the requesting client device 108, the encrypted device private key 150 can be further encrypted with a KAEK (Key Agreement Encryption Key). The KAEK is derived from a key agreement protocol, such as Diffie-Hellman (DH) or Diffie-Hellman Elliptic Curve (ECDH). ONCA 106 can also archive the client-specific device certificate and associate it with the corresponding offline certificate 152. This association can also be reported to OFFCA 104 for traceability and reporting purposes. Optionally at this stage, ONCA also returns the previously generated source certificate 152 that contains the same device public key as the recently issued customer-specific device certificate 156. Figure 2 is a diagram illustrating the derivation and use of the KAEK. Client device 108 generates a client key agreement public key (CKAPK) and a corresponding client key agreement private key (CKAPrK), as shown in block 202. Similarly, ONCA 106 generates the CA key agreement public key (CAKAPK) and the corresponding CA key agreement private key (CAKAPrK), as shown in block 204. In block 206, client device 108 transmits the CKAPK to ONCA 106 as part of the request message, as shown in block 206. ONCA 106 receives the client key agreement public key (CKAPK) in block 208 and uses the received client key agreement public key (CKAPK) to derive the KAEK from the client key agreement public key (CKAPK) and the CA key agreement private key (CAKAPrK), as shown in block 210.This can be achieved through a variety of methods, including: Diffie-Hellman KAEK = Drift ( CKAPKCAKAPrKmod p) and Elliptic Curve DH KAEK = Drift (CAKAPrK * CKAPK) where “*” denotes a special elliptic curve multiplication operation known to cryptography experts, and p denotes a prime number. Next, ONCA 106 encrypts the client device's private key with KAEK to generate the additional encrypted client device private key (EKAEK[Encrypted Client Device Private Key]), and transmits the client device's client-specific certificate 156 and the additional encrypted device private key to client device 108 in the reply message, as shown in blocks 214 and 216. In blocks 218 and 220, client device 108 receives the reply message and uses the CA key agreement public key CAKAPK and the client key agreement private key CKAPrK to generate the KAEK key agreement encryption key.Then, in block 222, client device 108 decrypts the encrypted client device private key using the generated KAEK key agreement encryption key to produce the encrypted client device private key. Now, returning to Figure 1, in operation sixteen, client device 108 optionally verifies that a received client-specific device certificate 156 is valid and has a valid CA signature (using CA signing key 162), then decrypts one or more encryption layers from device 150's private key. For example, two encryption layers might be the inner-layer encryption with PrKEK (which was originally added by OFFCA 104) followed by the outer-layer encryption with KAEK described in the previous operation. All of these encryption layers are then removed (the outer-layer encryption with KAEK is removed as shown in block 222 of Figure 2), after which client device 108 verifies that the fully decrypted device private key 150 matches the client-specific device certificate 156 and the device private key contained within it. Alternatively, proxy agent 110 can perform the verification and decryption steps described above and then forward the client-specific device certificate 156 and the device private key 150 to the target client device 108 over a separate connection. Once client device 108 possesses a fully decrypted and verified client-specific device certificate 156 and a device private key 150, the certificate and private key are installed locally on the target client device 108. Additional protection (e.g., local protection on client device 108) such as encryption or hardware-based protection can be added by using secure memory or a secure CPU on client device 108. Alternatively, the inner-layer encryption with PrKEK that was originally added to the private key of device 150 by OFFCA 104 can remain, and the PrKEK-encrypted private key of device 150 can be persistently stored in this way on the target client device 108. In such a mode, the target client device 108 removes the PrKEK encryption from the private key of device 150 each time it is used internally within the client device 108 to perform an encryption operation such as decryption or digital signature. The previously generated source certificate 152 can also be transmitted by ONCA 106 to the client device 108 in the previous operation. In this case, the source digital certificate 152 can be persistently stored on the client device 108 along with the client-specific device certificate 156 and the encrypted device private key 150. The source digital certificate 152 can have a longer lifespan than the corresponding client-specific device certificate 156 derived from the source digital certificate 152 and can be used in the future to request other device certificates 156 or additional certificates. As shown in operation seventeen, the client-specific device certificates 156 that had been generated by ONCA 106 can optionally be copied back to the central PKI repository 112 for archiving and for later querying and reporting. In operation eighteen, an authorized administrator using an administrative processor at the key generation facility (for example, a person working for an operator of MA / a / ZUZZ / UI 1 l (or the network that deployed the 108 client devices) may want to run some queries or reports on the device certificates that were installed on the 108 client devices in its network. The queries could count the number of 108 client devices of various models that were provisioned with client-specific certificates from the 156 client device, run reports for specific time periods, for specific factory locations (if the certificate provisioning was done at a factory), etc. In operation nineteen, a report can be optionally generated based on the content of the central PKI repository 112 and returned to the requesting administrator. If a client device 108 makes a subsequent request with the same information (e.g., the same client ID), the same client-specific device certificate can be retrieved and returned as is, instead of generating a new device certificate. The need for such a returned certificate might arise if the client-specific device certificate or private key becomes corrupted within the client device 108. Alternatively, OFFCA 104 can simply issue a newly generated client-specific device certificate each time a client device 108 requests one. Hardware environment Figure 3 illustrates an illustrative computer system 300 that could be used to implement processing elements of the above description, which include one or more of OFFCA 104, the central PKI repository 112, the computer 168, the ONCA 106, the proxy agent 110, and the client device 108. The computer 302 comprises a processor 304 and memory, such as random access memory (RAM) 306. The computer 302 is operatively coupled to a display 322, which presents images such as windows to the user in a graphical user interface 318B. The computer 302 can be coupled to other devices, such as a keyboard 314, a mouse device 316, a printer 328, etc. Of course, those skilled in the art will recognize that any combination of the above components, or any number of different components, peripherals, and other devices, can be used with the computer 302. Generally, the computer 302 operates under the control of an operating system 308 stored in memory 306, and interacts with the user to accept input and commands and to present results through a graphical user interface (GUI) module 318A. Although the GUI module 318B is illustrated as a separate module, the instructions that perform the GUI functions may be resident or distributed within the operating system 308, the computer program 310, or implemented using special-purpose processors and memory. The computer 302 also implements a compiler 312 that allows an application program 310 written in a programming language such as COBOL, C++, FORTRAN, or another language to be translated into code readable by the processor 304.After completion, application 310 accesses and manipulates the data stored in memory 306 of computer 302 using the relationships and logic generated using compiler 312. Computer 302 also optionally comprises an external communication device such as a modem, satellite link, Ethernet card, or other device for communicating with other computers. In one embodiment, the instructions implementing the operating system 308, the software program 310, and the compiler 312 are tangibly realized on a computer-readable medium, e.g., a data storage device 320, which could include one or more fixed or removable data storage devices, such as a Zip drive, floppy disk drive 324, hard disk drive, CD-ROM drive, tape drive, etc. Furthermore, the operating system 308 and the software program 310 comprise instructions that, when read and executed by the computer 302, cause the computer 302 to perform the operations described herein. The software program 310 and / or the operating instructions may also be tangibly realized in memory 306 and / or data communication devices 330, thereby resulting in a manufactured item or software product.As such, the terms “article of manufacture,” “program storage device,” and “computer program product” as used herein are intended to encompass a computer program accessible from any computer-readable device or medium. Those skilled in the art will recognize that many modifications can be made to this configuration without departing from the scope of this description. For example, those skilled in the art will recognize that any combination of the above components, or any number of different components, peripherals, and other devices, can be used. Conclusion This concludes the description of the preferred modalities of the present description. The foregoing description of preferred embodiments has been presented for illustrative and descriptive purposes. It is not intended to be exhaustive, nor is it intended to limit the description to the precise embodiment described. Many modifications and variations are possible in light of the foregoing teachings. It is intended that the scope of the rights be limited not by this detailed description, but by the claims appended hereto.

Claims

1. In a system comprising a plurality of clients providing services to a plurality of client devices, a method for providing a client-specific digital certificate to a client device of the plurality of client devices, the method comprising: receiving, at an online certification authority, a previously generated digital certificate and a client device private key encrypted in accordance with a private key encryption key PrKEK; receiving, from the client device, a request for the client-specific digital certificate, the request comprising at least one of the information identifying the client device and information identifying the client, the request signed in accordance with a previously provided client device digital certificate;Create the client-specific digital certificate from the previously generated digital certificate, a selected target digital certificate template, information that identifies the client device, and information that identifies the client, comprising: identifying the client device from the information that identifies the client device; identifying the client; retrieving the previously generated digital certificate; selecting the target digital certificate template for the client device based, at least in part, on the information that identifies the client, the target digital certificate template with attributes that vary by client; generating the client-specific digital certificate in accordance with the previously generated digital certificate, the target digital certificate template, and the client device identification information;access a client-specific digital certificate signing key from a certification authority associated with the identified client; re-sign the client-specific digital certificate with the client-specific digital certificate signing key; and transmit the client-specific digital certificate and encrypted client device private key to the client device.

2. The method of claim 1, wherein: the previously provided client device digital certificate is a global digital certificate; (or the client device identification information is explicitly provided in the client-specific digital certificate request.) 3. The method of claim 1, wherein: the previously provided client device digital certificate is unique to the client device; and the information identifying the client device is determined from the previously provided client device digital certificate.

4. The method of claim 1, wherein: the client-specific digital certificate is the pre-generated digital certificate associated exclusively with information that identifies the client device; and the pre-generated digital certificate is one of a batch of pre-generated digital certificates for a group of the plurality of client devices of which the client device is a member, and is provided to an online certificate authority prior to receiving the request for the client-specific digital certificate.

5. The method of claim 1, wherein: the system comprises a plurality of clients providing services to a plurality of client devices; and the private key encryption key PrKEK is a common encryption key shared among all devices for all clients.

6. The method of claim 1, wherein: the system comprises a plurality of clients providing services to a plurality of client devices, and the private key encryption key PrKEK is different for each of the plurality of clients.

7. The method of claim 6, wherein: the private key encryption key PrKEK is different for each of the plurality of client devices.

8. The method of claim 1, wherein the information that identifies a client device is a MAC address of the client device.

9. The method of claim 8, wherein the information identifying the client includes one or more of: a client identifier; a client device credential profile identifier; and a client device MAC address.

10. The method of claim 1, wherein: identifying the client device from the client device identification information comprises: extracting the information that identifies the client device from the previously provided client device digital certificate; and identifying the client comprises: identifying the client according to a comparison between the information that identifies the client device and a predetermined mapping of the client device identification information and the client provided to an online certification authority.

11. The method of claim 1, wherein: identifying the client device from the client device identification information comprises: extracting the information that identifies the client device from the client-specific digital certificate request; and identifying the client comprises: extracting the information that identifies the client from the request.

12. The method of claim 1, wherein: the previously provided digital certificate of the client device comprises a MAC address of the client device; and identifying the client according to a comparison of the MAC address of the client device and the whitelist of MAC addresses for each of the plurality of clients.

13. The method of claim 1, wherein each previously provided client device digital certificate is pre-installed on the associated client device at a factory that manufactures the client device.

14. In a system comprising a plurality of clients providing services to a plurality of client devices, an apparatus for providing a client-specific digital certificate to a client device of the plurality of client devices, comprising: a processor; a memory, communicatively coupled to the processor, the memory storage processor comprising processor instructions for: receiving, at an online certification authority, a pre-generated digital certificate and a client device private key encrypted in accordance with a private key encryption key PrKEK;to receive, from the client device, a request for the client-specific digital certificate, the request comprising at least one of the information that identifies the client device and information that identifies the client, the request signed in accordance with a previously provided client device digital certificate; and to create the client-specific digital certificate from the previously generated digital certificate, a selected target digital certificate template, the information that identifies the client device and the information that identifies the client, comprising: identifying the client device from the information that identifies the client device; identifying the client; retrieving the previously generated digital certificate;Select the target digital certificate template for the client device based, at least in part, on information that identifies the client; the target digital certificate template has attributes that vary depending on the client; generate the client-specific digital certificate according to the previously generated digital certificate, the target digital certificate template, and the client device identification information; access a client-specific digital certificate signing key from a certification authority associated with the identified client; re-sign the client-specific digital certificate with the client-specific digital certificate signing key; and transmit the client-specific digital certificate and the encrypted client device private key to the client device.

15. The apparatus of claim 14, wherein: the previously provided client device digital certificate is a global digital certificate; and the client device identification information is explicitly provided in the client-specific digital certificate request.

16. The apparatus of claim 14, wherein: the previously provided client device digital certificate is unique to the client device; and the information identifying the client device is determined from the previously provided client device digital certificate.

17. The apparatus of claim 14, wherein: the client-specific digital certificate is the pre-generated digital certificate associated exclusively with information that identifies the client device; and the pre-generated digital certificate is one of a batch of pre-generated digital certificates for a group of the plurality of client devices of which the client device is a member, and is provided to the online certificate authority prior to receiving the request for the client-specific digital certificate.

18. The apparatus of claim 14, wherein: the system comprises a plurality of clients providing services to a plurality of client devices; and ML / a / ZUZZ / U 11 l (or the private key encryption key PrKEK) is a common encryption key shared among all devices for all clients.

19. The apparatus of claim 14, wherein: the system comprises a plurality of clients providing services to a plurality of client devices, and the private key encryption key PrKEK is different for each of the plurality of clients.

20. In a system comprising a client providing a service to a plurality of client devices, an apparatus for providing a client-specific digital certificate to a client device of the plurality of client devices, comprising: means for receiving, at an online certification authority, a pre-generated digital certificate and a client device private key encrypted in accordance with a private key encryption key PrKEK; means for receiving, from the client device, a request for the client-specific digital certificate, the request comprising at least one of the information identifying the client device and information identifying the client, the request signed in accordance with a previously provided client device digital certificate;and means for creating the client-specific digital certificate from the previously generated digital certificate, a selected target digital certificate template, information identifying the client device, and information identifying the client, comprising: means for identifying the client device from the information identifying the client device; means for identifying the client; means for retrieving the previously generated digital certificate; means for selecting the target digital certificate template for the client device based, at least in part, on the information identifying the client; the target digital certificate template having attributes that vary by client;Means for generating the client-specific digital certificate in accordance with the previously generated digital certificate, the target digital certificate template, and the client device identification information; means for accessing a client-specific digital certificate signing key from a certification authority associated with the identified client; means for re-signing the client-specific digital certificate with the client-specific digital certificate signing key; and means for transmitting the client-specific digital certificate and the encrypted client device private key to the client device.

Images