Temporal key generation and PKI gateway

Abstract

Temporal key generation devices and methods are described. One such device of a first domain receives a “seed” to generate a private key associated with a public key for use in a second domain. The device uses the private key in cryptographic operations with the second domain. When the device loses power or is no longer connected to the second domain, the private key may be erased or no longer stored on the device.

Claims

1. A gateway device of a second domain comprising: an interface; and a processor operable to: authenticate, through the interface, with a key generation device of a first domain as a function of using a credential of the first domain; send a unique identifier of the key generation device to a database of the second domain; receive, from the second domain database, a key generation numeric value associated with the unique identifier; and send the key generation numeric value to the key generation device.

2. The gateway device of claim 1 wherein the interface is further operable to: receive, from the second domain database, a second domain public key certificate of the key generation device; and send the second domain public key certificate of the key generation device to the key generation device.

3. The gateway device of claim 1 wherein the first domain is a first certificate authority domain.

4. The gateway device of claim 3 wherein the credential is digitally signed by a first certificate authority of the first certificate authority domain.

5. The gateway device of claim 1 wherein the second domain is a second certificate authority domain.

6. The gateway device of claim 1 wherein the gateway device is also of the first domain.

7. The gateway device of claim 1 wherein the key generation numeric value comprises a numeric value for signature private key generation.

8. A non-transitory, machine readable medium having computer-executable instructions stored thereon that, when executed by at least one hardware processor of a gateway, causes the at least one hardware processor to perform a plurality of operations, the gateway being of a second domain, the operations comprising: authenticating with a key generation device of a first domain as a function of using a credential of the first domain; sending a unique identifier of the key generation device to a database of the second domain; receiving, from the second domain database, a key generation numeric value associated with the unique identifier; and sending the key generation numeric value to the key generation device.

9. The non-transitory, machine readable medium of claim 8 wherein the operations further comprise: receiving, from the second domain database, a second domain public key certificate of the key generation device; and sending the second domain public key certificate of the key generation device to the key generation device.

10. The non-transitory, machine readable medium of claim 8 wherein the first domain is a first certificate authority domain.

11. The non-transitory, machine readable medium of claim 10 wherein the credential is digitally signed by a first certificate authority of the first certificate authority domain.

12. The non-transitory, machine readable medium of claim 8 wherein the second domain is a second certificate authority domain.

13. The non-transitory, machine readable medium of claim 8, wherein the gateway is also of the first domain.

14. The non-transitory, machine readable medium of claim 8 wherein the key generation numeric value comprises a numeric value for signature private key generation.

15. A method comprising: authenticating a key generation device of a first domain with a gateway of a second domain as a function of using a credential of the first domain; sending a unique identifier of the key generation device to a database of the second domain; receiving, from the second domain database, a key generation numeric value associated with the unique identifier; and sending the key generation numeric value to the key generation device.

16. The method of claim 15 further comprising: receiving, from the second domain database, a second domain public key certificate of the key generation device; and sending the second domain public key certificate of the key generation device to the key generation device.

17. The method of claim 15 wherein the first domain is a first certificate authority domain.

18. The method of claim 17 wherein the credential is digitally signed by a first certificate authority of the first certificate authority domain.

19. The method of claim 15 wherein the second domain is a second certificate authority domain.

20. The method of claim 15 wherein the gateway is also of the first domain.

21. The method of claim 15 wherein the key generation numeric value comprises a numeric value for signature private key generation.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The present invention will become more fully understood from the detailed description given herein below and the accompanying drawings which are given by way of illustration only, wherein like reference numerals designate corresponding parts in the various drawings, and wherein:

(2) FIG. 1 illustrates an example network and logical diagram showing example elements and their relation according to the present invention;

(3) FIG. 2A illustrates a diagram of example elements of a device according to an embodiment of the present invention;

(4) FIG. 2B illustrates a diagram of example elements of a PKI Gateway according to an embodiment of the present invention

(5) FIG. 3 illustrates an example flow diagram of device initialization according to an embodiment of the present invention;

(6) FIG. 4 illustrates a logical diagram showing an example logical storage layout of key generation information stored on the device according to an embodiment of the present invention;

(7) FIG. 5 illustrates a flow diagram showing an example provisioning of a device to a CA Domain according to an embodiment of the present invention;

(8) FIGS. 6A and 6B illustrate a flow diagram showing an example key generation according to an embodiment of the present invention;

(9) FIG. 7 illustrates a logical diagram showing example logical relationships of CA domains, devices and PKI gateways in a pivot relation according to an embodiment of the present invention; and

(10) FIG. 8 illustrates a logical diagram showing example logical relationships of CA domains, devices and PKI gateways in a chaining relation according to an embodi-ment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

(11) Exemplary embodiments of methods and devices for generating temporal public and private cryptographic keys to preserve privacy are described herein and are shown by way of example in the drawings. Throughout the following description and drawings, like reference numbers/characters refer to like elements.

(12) It should be understood that, although specific exemplary embodiments are discussed herein, there is no intent to limit the scope of the present invention to such embodiments. To the contrary, it should be understood that the exemplary embodiments discussed herein are for illustrative purposes, and that modified and alternative embodiments may be implemented without departing from the scope of the present invention.

(13) It should also be noted that one or more exemplary embodiments may be described as a process or method. Although a process/method may be described as sequential, it should be understood that such a process/method may be performed in parallel, concurrently or simultaneously. In addition, the order of each step within a process/method may be re-arranged. A process/method may be terminated when completed, and may also include additional steps not included in a description of the process/method.

(14) As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items. As used herein, the singular forms “a,” “an” and “the” are intended to include the plural form, unless the context and/or common sense indicates otherwise. It should be further understood that the terms “comprises”, “comprising,”, “includes” and/or “including”, when used herein, specify the presence of stated features, systems, subsystems, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, systems, subsystems, steps, operations, elements, components, and/or combinations thereof.

(15) As used herein the terms “computer”, “CPU”, “hardware server” or “servers” means at least an electronic device that is specially configured to complete associated functions and features described herein. Such devices may be operable to execute stored, specialized instructions stored as electrical signals in an onboard memory, in separate memory, or in a specialized database for example to complete the associated functions and features described herein. Such instructions represent functions and features that have been integrated into memory as stored, electronic signals. Moreover, as used herein the terms “device” and “server” may also be embodied in virtual form on an e electronic device that is specially configured to complete associated functions and features described herein.

(16) It should be understood that where used herein, the designations “first”, “second”, etc., are used to distinguish one component (e.g., app, device, subsystem, section, etc.,) or part of a process from another and does not indicate an importance, priority or status. In fact, the component or parts of a process could be re-designated (i.e., re-numbered) and it would not affect the operation of systems or methods provided by the present invention.

(17) It should be understood that when one part of a device or system is described or depicted as being connected to another part, other well-known components used to facilitate such a connection may not be described or depicted because such components are well known to those skilled in the art.

(18) Yet further, when one part of a device or system is described or depicted as being connected to another part using “a connection” (or single line in a figure) it should be understood that practically speaking such a connection (line) may comprise (and many times will comprise) more than one physical connection or channel, may be omni-directional or bi-directional, and may or may not include separate data, formatting and signaling.

(19) It should be noted that the systems and devices, as well as any subsystems, etc., thereof, illustrated in the figures are not drawn to scale, are not representative of an actual shape or size and are not representative of any actual system, platform or device layout, or manufacture's drawing. Rather, the systems and devices are drawn so as to help explain the features, functions and processes of exemplary embodiments of the present invention described herein.

(20) As used herein, the term “embodiment” refers to an example of the present invention.

(21) FIG. 1 illustrates an exemplary network and logical diagram showing exemplary elements and their relation according to one embodiment of the present invention. As shown, various elements are connected to network 180. Base CA Domain 160 is shown as a logical construct and may include a base certification authority (CA.sub.B) 162 which may comprise one or more hardware servers configured as a certification authority; a base database (DB.sub.B) 164; a PKI Gateway.sub.n 150 which may comprise one or more hardware servers configured as a gateway; a computer 111; a smart card reader 113; and several exemplary temporal key generating devices such as: a smart card 100, a computer 102, a smart watch 104, and a smart phone 106.

(22) Also depicted in FIG. 1 is a CA Domain.sub.n 170 that may include an n.sup.th certification authority (CA.sub.n) 172 for the CA Domain.sub.n 170 which may comprise one or more hardware servers configured as a certification authority, a database (DB.sub.n) 174, and the PKI Gateway.sub.n 150. While the configuration shown depicts two separate CA domains, another exemplary configuration combines CA Domain.sub.n (170) and its associated elements within Base CA Domain (160). Moreover, in one embodiment the databases 164, 174 may be X.500 databases.

(23) FIG. 2A illustrates a diagram of an exemplary temporal key generating device 200 according to an embodiment of the present invention. As shown, temporal key generating device 200 may comprise a smart card form factor, long term memory 202, a controller 204, a short term memory 206, a clock 208, a crypto processor 210, a random number generator 212, a central processing unit (CPU) 214, an interface 216, and a counter 230. While the device 200 is depicted as a smart card, it should be understood that alternative temporal key generating devices according to embodiments of the present invention may have different form factors. For example, the device 200 may comprise: a computer, a PIV card, smart card, RFID card, chip implant, smart watch, smart phone, laptop, or other portable electronic device or virtual device. While long term memory 202 and short term memory 206 are shown as two separate elements, it should be understood they can be implemented as one memory but the functionality of automatic erasure upon power loss might be limited. Moreover, short term memory 206 may be implemented as volatile memory such that it automatically erases once it loses power. Long term memory 202 may be implemented as non-volatile memory so that it does not erase if it loses power. Moreover, long term memory 202 may be implemented as a secure space with limited exposure of information, therein, beyond the limits of the long term memory 202 and processors 210 and 214. As part of the initialization of the device 200, the device 200 may be loaded with a device identification (ID) and instructions for executing the methods and related processes described herein. Moreover, much of the device 200 may be implemented in an integrated circuit and may be configured to be updateable or initialized using firmware.

(24) FIG. 2B illustrates a diagram of an example PKI Gateway according to an embodiment of the present invention. As shown is an exemplary PKI Gateway 250 in a computer form factor (e.g., hardware servers), an interface 266, a memory 252, a cryptoprocessor 260, a random number generator 262 and a central processing unit (CPU) 264. The PKI Gateway 250 may also include instructions for executing the methods and related processes described herein. While the exemplary PKI Gateway 250 is described in a computer form factor, it should be understood that the PKI Gateway 250 may also be implemented in various forms, including virtual computing forms.

(25) FIG. 3 illustrates an exemplary flow diagram 300 of the initialization of an exemplary temporal key generation device, such as device 200, according to an embodiment of the present invention. As shown is an example process flow between the temporal key generation device 200 and a CA.sub.B 162 to initialize the temporal key generation device 200. For purposes of clarity, the following symbol definitions and groupings are provided including information that may be stored in long term memory 202 during Flow 300 initialization:

(26) Persona Long Term Storage Information 400 includes at least one Base CA Domain Key Generation Group 405 and associated t.sub.max CA Domain Key Generation Groups 410.

(27) Each Base CA Domain Key Generation Group 405 includes: e.sub.B=>e for Base CA Domain 160 p.sub.BE, q.sub.BE=>primes to generate a Base CA Domain 160 encryption key pair d.sub.BE=>d for a Base CA Domain 160 private encryption key N.sub.BE=>N used for a Base CA Domain 160 encryption key pair p.sub.BS, q.sub.BS=>primes to generate a Base CA Domain 160 signature key pair d.sub.BS=>d for a Base CA Domain 160 private signature key N.sub.BS=>N used for a Base CA Domain 160 signature key pair (N.sub.BS, e.sub.B, DN.sub.B).sub.CERT_BS=>the persona's digital certificate for the Base CA Domain signature public key which includes a unique identifier, in this example the unique identifier is a distinguished name for the base CA Domain (DN.sub.B); Public Key Certificate of the Base CA, CA.sub.B 162; and Parameter information which includes: Device ID; Number of primes to use for multi-prime RSA; t.sub.max=>the maximum number of CA Domain Key Generation Groups; Desired Base CA Domain key length; and Other information known in the art such as algorithms for key exchange, digital signatures, encryption, decryption, hashing and key generation.

(28) Each CA Domain Key Generation Group t includes: e.sub.t=>e of CA Domain Key Generation Group t used to generate CA Domain key pairs; p.sub.tE, q.sub.tE=>primes of CA Domain Key Generation Group t used to generate a CA Domain encryption key pair; S.sub.tE=>Secret of CA Domain Key Generation Group t used to validate a CA Domain encryption key pair; P.sub.tS, q.sub.tS=>primes of CA Domain Key Generation Group t used to generate a CA Domain signature key pair; and S.sub.tS=>Secret of CA Domain Key Generation Group t used to validate a CA Domain signature key pair;
where t=1 to t.sub.max,

(29) The present invention may implement multi-prime RSA using three or more prime numbers. In an exemplary embodiment of the invention, where multi-prime RSA is used to generate keys for entities within the CA Domain.sub.n, at least two of the prime numbers may be stored in the device 200. In an embodiment, where the Base CA Domain uses x primes of z bit length each to generate keys and the CA Domain.sub.n uses x+y primes, y>=1, of z′ bit length each to generate keys, z′ should equal z and at least x primes of the CA Domain.sub.n may be stored in device 200. For example, if devices within the Base CA Domain use two primes, p and q, to generate 1024 bit keys, primes p and q are 512 bits each or z=512. As such, if a device within CA Domain.sub.n uses three primes, p, q, and r, to generate keys, each of these prime numbers should be 512 bits and at least two of these primes, for example p and q, may be stored on device 200. Using such an approach, the size of Domain.sub.n prime numbers may be calculated. Other variations can be applied, but the risks versus benefits as expressed in Hinek, On the Security of Multi-prime RSA, Jun. 13, 2006 should be considered.

(30) In the exemplary embodiment depicted in FIG. 3, device 200 may be initialized to include persona long term storage information 400. FIG. 3 shows a process flow 300 between device 200 and the Certification Authority.sub.B (CA.sub.B) 162 of the Base CA Domain 160. Transfers between the two may pass through the interface 216 of device 200. During the initialization of flow 300, persona long term storage information 400 may be input, generated, or received and stored in long term memory 202. During this process of flow 300, information may be temporarily stored in short term memory 206. In such a case, the temporarily stored information of flow 300 may be erased when such storage may be no longer needed, wanted, or when Flow 300 is complete. If the short term memory 206 is volatile memory, the short term memory 206 may be erased should power be removed from it.

(31) In step 305, the number of primes to use for multi-prime RSA, t.sub.max, the desired Base CA Domain key length and other parameters may be input into the device 200. For purposes of this example embodiment, the number of primes to use for multi-prime RSA is three (p, q and r).

(32) In step 310, e.sub.B and e.sub.t (where t=1 to t.sub.max) are input into the temporal key generation device 200 through the interface 216 and stored in the long term memory 202. The inputting can be done via manual user input through a graphical user interface (GUI) on computer 111 that interfaces with the device 200. Alternatively, the device 200 may be configured and operable to generate e.sub.B and e.sub.t (where t=1 to t.sub.max) using the cryptoprocessor 210 and store them in the long term memory 202.

(33) In step 320, the cryptoprocessor 210 may be operable to generate primes, p.sub.B and q.sub.B, used to generate Base CA Domain key pairs and the primes, p.sub.t and q.sub.t, used to generate CA Domain.sub.n key pairs which may be generated with respect to e.sub.B and e.sub.t, respectively, where t=1 to t.sub.max. The so generated primes may be stored in long term memory 202. Additionally, the random number generator 212 may be operable to randomly generate secrets, S.sub.tE and S.sub.tS, where t=1 to t.sub.max. In one embodiment, a bit length for each Secret may be the same or greater bit length as N.sub.BE or N.sub.BS.

(34) In step 330, cryptoprocessor 210 may be operable to (a) multiply p.sub.BE and q.sub.BE to obtain N.sub.BE, and (b) multiply p.sub.BS and q.sub.BS to obtain N.sub.BS. In an embodiment d.sub.BE and d.sub.BS may be generated by the crypto processor 210. As a result, an encryption key pair for the Base CA Domain [(N.sub.BE, e.sub.B); (N.sub.BE, d.sub.BE)] may be obtained. Moreover, a signature key pair for the Base CA Domain [(N.sub.BS, e.sub.B); (N.sub.BS, d.sub.BS)] may be obtained.

(35) In step 335, long term memory 202 may be operable to store private keys, (N.sub.BE, d.sub.BE) and (N.sub.BS, d.sub.BS).

(36) In step 340, Public keys, (N.sub.BE, e.sub.B) and (N.sub.BS, e.sub.B), may be sent to Base CA (CA.sub.B) 162 through the Interface 216.

(37) In step 355, Base CA (CA.sub.B) 162 may be operable to take the output of step 340 and generate and sign respective digital certificates using the private key of Base CA (CA.sub.B) 162. This step, with sufficient identity proofing, binds a persona's distinguished name (DN.sub.B) for the Base CA Domain 160 to the public keys, (N.sub.BE, e.sub.B) and (N.sub.BS, e.sub.B) and to their respective private keys stored in Long Term Memory 202. A persona can represent a human, machine, role, or group. The resultant digital certificates may be the persona's digital certificate (N.sub.BE, e.sub.B, DN.sub.B).sub.CERT_BE for the Base CA Domain encryption key pair and the persona's digital certificate (N.sub.BS, e.sub.B, DN.sub.B).sub.CERT_BS for the Base CA Domain signature key pair. The example digital certificate notation provided throughout this disclosure is meant to reflect an X.509 digital certificate with only a subset of variables highlighted, e.g., (N, e, DN).sub.CERT_B, for illustrative purposes.

(38) In step 360, one of the resultant outputs of step 355, (N.sub.BE, e.sub.B, DN.sub.B).sub.CERT_BE, is stored in the Base CA Domain database (DB.sub.B). DB.sub.B being an X.500 directory.

(39) In step 370, one of the resultant outputs of step 355, (N.sub.BS, e.sub.B, DN.sub.B).sub.CERT_BS, may be sent to the device 200. Moreover, the pubic key certificate of the Base CA 162 may also be sent to the device 200.

(40) In step 380, (N.sub.BS, e.sub.B, DN.sub.B).sub.CERT_BS may be received by the device 200 through the Interface 216 and stored in Long Term Memory 202. Parameter information may be also stored in Long Term Memory 202. The public key certificate of the Base CA 162 may also be received by the device 200 and stored in Long Term Memory 202.

(41) In step 385, the Long Term Storage Information for the persona may be encrypted.

(42) Initialization of the device 200 with Persona Long Term Storage Information is at its end upon the completion of step 385. Other initialization activities, as may be known in the art for initializing tokens such as a FIPS 201-2 personal identity verification card (PIV Card), may also occur for the device 200, such as establishing logon information and encrypting certain information like the Persona Long Term Storage Information.

(43) FIG. 4 illustrates a logical diagram showing an exemplary logical storage layout of key generation information stored on the temporal key generation device 200 according to an embodiment of the present invention. As shown in FIG. 4, a plurality of Persona Long Term Storage Information 400 can be stored on the Device 200. Each of the Persona Long Term Storage Information 400 includes at least one Base CA Domain Key Generation Group 405 and associated t.sub.max CA Domain Key Generation Groups 410.

(44) FIG. 5 illustrates a flow diagram 500 showing an exemplary provisioning of a temporal key generation device to a CA Domain.sub.n according to an embodiment of the present invention. An advantage of the exemplary embodiment is that while the number of CA Domain Key Generation Groups may be limited to t.sub.max during an initialization flow 300, the number of CA Domain provisionings may not be so limited. In the example of FIG. 5, three interacting flows are shown: Device 200 Flow 501, PKI Gateway.sub.n 150 Flow 502, and CA Domain.sub.n 170 Flow 503. Transfers to and from Device 200 pass through interface 216. Transfers to and from PKI Gateway.sub.n 150 pass through interface 266. Information generated, sent or received by Device 200 as part of flow 501 may be predominately, temporarily stored in Short Term Memory 206. In the present embodiment, Short Term Memory 206 can be volatile memory such that should power be removed from Device 200, information stored in Short Term Memory 206 may be no longer retained. This helps ensure that key information associating the UID with CA Domain.sub.n 170 no longer exists on Device 200 when power is removed.

(45) In step 505, a CA Domain provisioning index, n.sub.p, may be set to 1. A CA Domain Key Generation Group provisioning index, t.sub.p, may be set to 1, In step 507, a CA Domain index, n, may be set to n.sub.p. A CA Domain Key Generation Group index, t, may be set to t.sub.p.

(46) In step 510, an authentication occurs between Device 200 and Gateway.sub.n150 using at least one of their certificates signed by a CA of a common CA Domain. If the common CA Domain is the Base CA Domain 160, then at least one digital certificate signed by the Base CA Domain CA.sub.B 162 may be used. If the common CA Domain is the CA Domain.sub.n−1, then at least one digital certificate signed by the CA Domain.sub.n−1 CA.sub.n−1 may be used.

(47) In step 512, PKI Gateway.sub.n 150 sends a request for a unique identifier (UID) to Device 200. The UID may be used by the PKI Gateway.sub.n 150 and DB.sub.n 174 as an index for associated persona values. There may be several identifiers that can be used as a UID. A first means may be to use the persona's Distinguished Name (DN.sub.B) that may be included in the (N.sub.BS, e.sub.B, DN.sub.B).sub.CERT_BS stored in Long Term Memory 202 of the Device 200. A second means may be to use a Device ID that may be available in Device 200. The second means may be problematic if the device 200 is lost or destroyed. The first and second means, however, work with traversing gateways via pivoting as described in FIG. 7. That is, the Device 700 connects directly to a PKI Gateway.sub.n for both provisioning and subsequent CA domain connection. The first and second means also work with chaining as described in FIG. 8 where the Device 800 connects through a path of PKI Gateways.sub.n to get to an end CA Domain.sub.n 874. Using the first or second means during provisioning, the Device 800 can obtain the appropriate key generation information each time the Device 800 connects to the end CA Domain.sub.n 874, regardless of the PKI Gateway.sub.n path taken.

(48) In a third means, if the Device 200 is trying to go from CA Domain.sub.n−1 to CA Domain.sub.n, the DN.sub.(n−1)S may be used as the UID. Depending on implementation, however, if the DN.sub.(n−1)S may be used, the persona may need to go through CA Domain.sub.n−1 170 each time subsequent to provisioning in order to take advantage of the keying information generated during the provisioning. Other values known in the art for a UID may also be used. For the example of FIG. 5, the persona's distinguished name for the Base CA Domain 160 (DN.sub.B) may be used.

(49) In step 515, the Device 200 receives the request of step 512 and sends e.sub.t and a UID to PKI Gateway.sub.n 150.

(50) In step 520, PKI Gateway.sub.n 150 receives the output of step 515 and generates r.sub.nE and r.sub.ns with respect to et using Crypto Processor 260 and Random Number Generator 262. PKI Gateway.sub.n 150 additionally sends r.sub.nE and r.sub.ns to Device 200.

(51) In step 525, Device 200 receives the output of step 520 and generates N.sub.nE by multiplying p.sub.tE, q.sub.tE, and r.sub.nE and generates N.sub.nS by multiplying p.sub.tS, q.sub.tS, and r.sub.nS.

(52) In step 530, the Device 200 encrypts S.sub.tE using public key (N.sub.nE, e.sub.t) to obtain (S.sub.tE).sub.ENC_nE and encrypts S.sub.tS using public key (N.sub.nS, e.sub.t) to obtain (S.sub.tS).sub.ENC_nS. Device 200 then sends N.sub.nE, N.sub.nS, (S.sub.tE).sub.ENC_nE, and (S.sub.tS).sub.ENC_nS to PKI Gateway.sub.n 150. To further help prevent exposure of S.sub.tE and S.sub.tS, these values could be further obfuscated prior to encryption and sending. As an alternative to sending (S.sub.tE).sub.ENC_nE and (S.sub.tS).sub.ENC_nS, S.sub.tE and S.sub.tS instead could be added to r.sub.nE and r.sub.nS, the sums subsequently hashed and the hashed values encrypted using public key (N.sub.nE, e.sub.t) to obtain (HASH(S.sub.tE+r.sub.nE)).sub.ENC_nE and using public key (N.sub.nS, e.sub.t) to obtain (HASH(S.sub.tS+r.sub.nS)).sub.ENC_nS. As such, (HASH(S.sub.tE+r.sub.nE)).sub.ENC_nE and (HASH(S.sub.tS+r.sub.nS)).sub.ENC_nS could then be handled, throughout, instead of (S.sub.tE).sub.ENC_nE and (S.sub.tS).sub.ENC_nS.

(53) In step 535, the PKI Gateway.sub.n 150 receives the output of step 530 and sends public keys, (N.sub.nE, e.sub.t) and (N.sub.nS, e.sub.t) to CA.sub.n 172.

(54) In step 537, CA.sub.n 172 receives the public keys of step 535, creates and signs a digital certificate for each public key and sends the digital certificates to the PKI Gateway.sub.n 150.

(55) In step 538, the PKI Gateway.sub.n 150 receives the output of step 537 from CA.sub.n 172 and sends the UID and following persona values to DB.sub.n 174: r.sub.nE, (N.sub.nE, e.sub.t).sub.CERT_nEd, (S.sub.tE).sub.ENC_nE; and r.sub.nS, (N.sub.nS, e.sub.t).sub.CERT_nS, (S.sub.tS).sub.ENC_nS.

(56) In step 540, DB.sub.n 174 receives and stores the UID and persona values.

(57) In step 550, the Device 200 determines if it is done interacting with PKI Gateway.sub.n 150. If yes, Device 200 goes to step 552. If not it goes to beginning of step 550.

(58) In step 552, Device 200 erases from memory, without erasing Persona Long Term Storage Information 400 stored in Long Term Memory 202, information on Device 200 involved in the present cycle of process flow 501. This step helps ensure that key information associating the UID with CA Domain.sub.n 170 no longer exists on Device 200.

(59) In step 555, Device 200 determines if it is to provision for another CA Domain.sub.(n+1) 170. If yes, then Device 200 advances to step 557, else starts back at step 555.

(60) In step 557, Device 200 sets n.sub.p=n.sub.p+1 and t.sub.p=t.sub.p+1. If t.sub.p=t.sub.max+1, set t.sub.p=1 and go to step 507. Alternatively, t may be selected within the range, 1 to t.sub.max, by a random means or by a means of another algorithm. Changing the t causes a new CA Domain Key Generation Group 410 to be selected. This helps prevent collisions in situations where device 200 receives a newly generated r.sub.n for a CA Domain Key Generation Group that has already received the same r.sub.n for another CA Domain 170. Another means for reducing the risk of collision consistent with the present invention and multi-prime RSA may be for the PKI Gateway.sub.n 150 to randomly generate two or more prime numbers for use in the key generation process of a particular key pair. For example, the PKI Gateway.sub.n 150 could generate a prime value, s.sub.nS, in addition to r.sub.nS for use in generating a signature key pair of a particular CA Domain Key Generation Group 410.

(61) FIGS. 6A and 6B illustrate a flow diagram 600 showing an exemplary key generation according to an embodiment of the present invention. In the example of FIG. 6, three interacting flows are shown: Device 200 Flow 601, PKI Gateway.sub.n 150 Flow 602 and CA Domain.sub.n 170 Flow 603. Transfers to and from Device 200 pass through interface 216. Transfers to and from PKI Gateway.sub.n 150 pass through interface 266. Information generated, sent or received by Device 200 as part of flow 601 may be predominately, temporarily stored in Short Term Memory 206. In the present embodiment, Short Term Memory 206 can be volatile memory such that should power be removed from Device 200, information stored in Short Term Memory 206 may be no longer retained. This helps ensure that key information associating the UID with CA Domain.sub.n 170 no longer exists on Device 200 when power is removed.

(62) In step 605, a CA Domain connection index, n.sub.c, may be set to 1.

(63) In step 607, a CA Domain index, n, may be set to n.sub.c.

(64) In step 610, an authentication occurs between Device 200 and Gateway.sub.n 150 using at least one of their certificates signed by a CA of a common CA Domain. If the common CA Domain is the Base CA Domain 160, then at least one digital certificate signed by the Base CA Domain CA.sub.B 162 may be used. If the common CA Domain is the CA Domain.sub.n−1, then at least one digital certificate signed by the CA Domain.sub.n−1 CA.sub.n−1 may be used.

(65) In step 612, PKI Gateway.sub.n 150 sends a request for a unique identifier (UID) to Device 200.

(66) In step 615, Device 200 receives the request of step 612 and sends a UID to PKI Gateway.sub.n 150. For this example, the UID may be the persona's distinguished name for the Base CA Domain 160 (DN.sub.B).

(67) In step 620, PKI Gateway.sub.n 150 receives the output of step 615 and sends the UID to DB.sub.n 174 and requests the persona values stored in step 540.

(68) In step 622, DB.sub.n 174 receives the UID and request. DB.sub.n 174 then fetches the persona values using the UID and sends them to Gateway.sub.n 150 along with the public key certificate of the CA.sub.n 172.

(69) In step 624, Gateway.sub.n 150 receives the persona values and public key certificate of the CA.sub.n 172 and sends them to Device 200.

(70) In step 625, Device 200 receives into Short Term Memory 206 the persona values and public key certificate of CA.sub.n 172. Device 200 also finds the corresponding CA Domain.sub.n Key Generation Group 410 where r.sub.nE and r.sub.nS, when multiplied with the corresponding p.sub.tE, q.sub.tE and p.sub.tS, q.sub.tS, respectively, matches the received N.sub.nE and N.sub.nS values, respectively. This can be accomplished by stepping through or randomly selecting the CA Domain.sub.n Key Generation Groups 410 located on Device 200 and performing a comparison.

(71) In step 625, if the Group 410 cannot be found, flow 601 skips to step 652. If the Group 410 is found, flow 601 goes to step 627.

(72) In step 627, Device 200 uses Group 410 information and received persona value information to calculate d.sub.nE and d.sub.nS. The calculation method being known in the art and using Crypto Processor 210. Device 200 then stores d.sub.nE and d.sub.nS in Short Term Memory 206.

(73) In step 630, Device 200 uses private key (d.sub.nE, N.sub.nE) to decrypt (S.sub.tE).sub.ENC_nE and private key (d.sub.nS, N.sub.nS) to decrypt (S.sub.tS).sub.ENC_nS. If (HASH(S.sub.tE+r.sub.nE)).sub.ENC_nE and (HASH(S.sub.tS+r.sub.nS)).sub.ENC_nS were used in step 530 instead of (S.sub.tE).sub.ENC_nE and (S.sub.tS).sub.ENC_nS, private key (d.sub.nE, N.sub.nE) may be used to decrypt (HASH(S.sub.tE+r.sub.nE)).sub.ENC_nE and private key (d.sub.nS, Nils) may be used to decrypt (HASH(S.sub.tS+r.sub.nS)).sub.ENC_nS.

(74) In step 635, Device 200 determines if the decrypted values of (S.sub.tE).sub.ENC_nE and (S.sub.tS).sub.ENC_nS match the corresponding S.sub.tE and S.sub.tS of the corresponding CA Domain Key Generation Group 410 found in step 625. If (HASH(S.sub.tE+r.sub.nE)).sub.ENC_nE and (HASH(S.sub.tS+r.sub.nS)).sub.ENC_nS were used in step 530 instead of (S.sub.tE).sub.ENC_nE and (S.sub.tS).sub.ENC_nS, Device 200 determines if the decrypted HASH(S.sub.tE+r.sub.nE) and HASH(S.sub.tS+r.sub.nS) match HASH(S.sub.tE′+r.sub.nE) and HASH(S.sub.tS′+r.sub.nS), respectively; where S.sub.tE and S.sub.tS′ are S.sub.tE and S.sub.tS, respectively, of the corresponding CA Domain Key Generation Group 410 found in step 625. Step 635 helps ensure that Gateway.sub.n 150 or other entity has not performed a “person-in-the-middle” attack to comprise values exchanged. If the values do not match, flow 601 advances to step 652. If the values do match, flow 601 advances to step 640. In this step, device 200 may subsequently send information to PKI Gateway.sub.n 150 that it has appropriate CA Domain.sub.n 170 key information.

(75) In step 640, Device 200 uses the key information received and generated in flow 601 to communicate in the CA Domain.sub.n 170.

(76) In step 650, Device 200 determines if it is done interacting with CA Domain 170. If it is, then flow 601 advances to step 652. If it is not done, flow 601 goes back to step 650.

(77) In step 652, Device 200 erases from Short Term Memory 206 related information of steps 615, 625, 626, 627, 630, 635 and 650. This step helps ensure that key information associating the UID with CA Domain.sub.n 170 no longer exists on Device 200.

(78) As an alternative to this example of finding the CA Domain Key Generation Group 410 as described in step 625, the t generated in the provisioning flow 501 could be stored in the DB.sub.n 174 entry associated with the UID and retrieved in flow 601 to find the Group 410.

(79) In step 655, if Device 200 needs to connect to CA Domain.sub.(n+1), then flow advances to step 657.

(80) In step 655, if Device 200 does not need to connect to CA Domain.sub.(n+1), then flow ends.

(81) In step 657, set nc=nc+1 then goto step 607.

(82) FIG. 7 illustrates a logical diagram showing exem-plary logical relationships of CA domains, devices and PKI gateways in a pivot relation according to an embodiment of the present invention. As shown, Base CA Domain 760 has the same configuration as Base CA Domain 160; CA domains 771, 772, 773 and 774 have the same configuration as CA Domain, 170; PKI Gateways 751, 752, 753, and 754 have the same configuration as PKI Gateway 250; Device 700 has the same configuration as Device 200; and Devices 700a, 700b, 700c, and 700d may be the same as Device 700 except in different instances of time in relation to CA domains 771, 772, 773 and 774. In an aspect of the invention, all elements of FIG. 7 have a relationship with Base CA Domain 760. In a pivot scenario, the Device 700 provisions with any of the CA domains 771, 772, 773 and 774 directly using PKI Gateways 751, 752, 753, and 754, respectively, without going through an intermediary PKI Gateway or CA Domain. This may be also the case for subsequent connections after provisioning. In an aspect of the invention, the Device 700 associates with one CA Domain at a time. In another aspect of the invention, the Device 700 may be associated with more than one CA Domain at a time.

(83) FIG. 8 illustrates a logical diagram showing exem-plary logical relationships of CA domains, devices and PKI gateways in a chaining relation according to an embodiment of the present invention. As shown, Base CA Domain 860 has the same configuration as Base CA Domain 160; CA domains 871, 872, and 874 have the same configuration as CA Domain, 170; PKI Gateways 851, 852, 853, and 854 have the same configuration as PKI Gateway 250; Device 800 has the same configuration as Device 200; and Devices 800a, 800b, 800c, and 800d may be the same as Device 800 except in different instances of time 865 in relation to CA domains 871, 872, and 874. In a chaining scenario, the Device 800 provisions with any of the CA domains 871, 872, and 874, respectively. This may be also the case for subsequent connections after provisioning. In an aspect of the present invention, the Device 800 associates with CA domains 871 and 872 using PKI Gateways 851 and 852 until it gets to PKI Gateway 854 with which it provisions to associate with CA Domain 874. In chaining, the Device 800 will be associated with at least three domains when going from one CA Domain to another. For example, Device 800b may be associated with the Base CA Domain 860, CA Domain 871, and CA Domain 872. When provisioning is complete, there may be no further need to be connected to CA Domain 871 at which time, the short term information related to CA Domain 871 may be erased from the device so that it may be only affiliated with the Base CA Domain 860 and CA Domain 872 as shown by Device 800c. In another aspect of the invention, the Device 800 may be capable of maintaining associations to each CA Domain 871 and 872 on Device 800 as it makes its way to CA Domain 874.

(84) The invention being thus described herein, it should be understood that the same may be varied in many ways. Such variations are not to be regarded as a departure from the spirit and scope of the invention, and all such variations are intended to be included within the scope of the following claims.