System and method for computing an escrow session key and a private session key for encoding digital communications between two devices
11265161 · 2022-03-01
Assignee
Inventors
- Rehana Yasmin (Singapore, SG)
- Yanjiang Yang (Singapore, SG)
- Zhuo Wei (Singapore, SG)
- Tieyan Li (Singapore, SG)
- Hai Yu (Shanghai, CN)
Cpc classification
H04L9/0866
ELECTRICITY
H04L9/3242
ELECTRICITY
H04L9/0894
ELECTRICITY
H04L9/0897
ELECTRICITY
H04L9/0841
ELECTRICITY
International classification
Abstract
This document describes a system and method for generating two types of session keys for encoding digital communications between two devices. In particular, the first type of session key possesses escrow properties whereby a trusted third party will be able to generate the first type of session key to decode the digital communications between the two devices while the second type of session key does not possess escrow properties.
Claims
1. A system for generating an escrow session key SK.sub.1 and a private session key SK.sub.2 for encoding digital communications, the system comprising: a secure server; a device i; and another device j; wherein the secure server is configured to generate a master secret key (MSK) and global system parameters (GSP) for an Identity Based Cryptography (IBC) scheme, wherein the MSK and GSP are utilized together with an identity of a requesting device to generate an IBC private key IBC-K for the requesting device; wherein the device i is configured to: encrypt a first element g.sup.a with an identity ID.sub.j associated with the another device j using an Identity Based Encryption (IBE) scheme associated with the IBC scheme to generate an encrypted first element g.sup.a, wherein “g” is a generator of a cyclic multiplicative group G and “a” is a random number generated by the device i; and communicate, to the another device j, a communication comprising the encrypted first element g.sup.a, an identity ID.sub.i associated with the device i, and a session key request; wherein upon receiving the communication from the device i, the another device j is configured to: use the IBE scheme to decrypt the encrypted first element g.sup.a with an IBC private key IBC-K.sub.j, wherein the IBC private key IBC-K.sub.j is requested and obtained by the another device j from the secure server; and generate a second element g.sup.b, wherein “g” is the generator of the cyclic multiplicative group G and “b” is a random number generated by the another device j; compute the escrow session key SK.sub.1 using the first element g.sup.a; compute the private session key SK.sub.2 using the first element g.sup.a and the random number b; and communicate the second element g.sup.b and the identity ID.sub.j associated with the another device j to the device i; wherein the device i is further configured to: compute the escrow session key SK.sub.1 using the first element; compute the private session key SK.sub.2 using the second element g.sup.b and the random number a; compute a first combined key SK.sub.11 by obtaining a coproduct of the escrow session key SK.sub.1 and the private session key SK.sub.2; generate a key confirmation value using the first combined key SK.sub.11; and communicate the key confirmation value to the another device j; and wherein upon receiving the key confirmation value from the device i, the another device j is configured to: compute a second combined key SK.sub.22 by obtaining a coproduct of the escrow session key SK.sub.1 and the private session key SK.sub.2; verify the key confirmation value using the second combined key SK.sub.22; and validate the escrow session key SK.sub.1 and the private session key SK.sub.2 in response to the key confirmation value being is verified.
2. The system according to claim 1, wherein the another device j being configured to communicate the second element g.sup.b and the identity ID.sub.j associated with the another device j to the device i comprises: using the IBE scheme to encrypt the second element g.sup.b with an identity ID.sub.i associated with the device i to generate an encrypted second element g.sup.b; and communicating the encrypted second element g.sup.b and the identity ID.sub.j associated with the another device j to the device i; wherein upon receiving the encrypted second element g.sup.b and the identity ID.sub.j associated with the another device j from the another device j, the device i is configured to: use the IBE scheme to decrypt the encrypted second element g.sup.b with an IBC private key IBC-K.sub.i, wherein the IBC private key IBC-K.sub.i is requested and obtained by the device i from the secure server.
3. The system according to claim 1, wherein computing the escrow session key SK.sub.1 by the another device j comprises: using the first element g.sup.a and the second element g.sup.b to generate the escrow session key SK.sub.1; and wherein computing the escrow session key SK.sub.1 by the device i comprises: using the first element g.sup.a and the second element g.sup.b to generate the escrow session key SK.sub.1.
4. The system according to claim 1, wherein the another device j communicating the second element g.sup.b and the identity ID associated with the another device j to the device i comprises: using a Public Key Infrastructure (PKI) scheme to encrypt the second element g.sup.b with a PKI Public Key PBK.sub.i associated with the device i to generate an encrypted second element g.sup.b; and communicating the encrypted second element g.sup.b and the identity ID.sub.j associated with the another device j to the device i; wherein upon receiving the encrypted second element g.sup.b and the identity ID.sub.j associated with the another device j, the device i is configured to: use the PKI scheme to decrypt the encrypted second element g.sup.b with a PKI Private Key PRK.sub.i associated with the device i.
5. The system according to claim 1, wherein communicating by the device i the encrypted first element g.sup.a, the identity ID.sub.i associated with the device i, and the session key request to the another device j comprises: signing the encrypted first element g.sup.a using an IBC private signing key IBC-K.sub.i associated with the device i to generate a signed encrypted first element g.sup.a; and transmitting the signed encrypted first element g.sup.a to the another device j; wherein upon receiving the signed encrypted first element g.sup.a, the another device j is configured to: verify the signed encrypted first element g.sup.a using the identity ID.sub.i associated with the device i and a verification function associated with the IBC scheme, wherein the first element g.sup.a is decrypted in response to the signed encrypted first element g.sup.a being verified.
6. A device i for generating an escrow session key SK.sub.1 and a private session key SK.sub.2 for encoding digital communications between the device i and another device j, comprising: a processor; and a non-transitory media readable by the processor, the non-transitory media storing instructions that when executed by the processor, cause the processor to: use an Identity Based Encryption (IBE) scheme associated with an Identity Based Cryptography (IBC) scheme to encrypt a first element g.sup.a with an identity ID.sub.j associated with the another device j to generate an encrypted first element g.sup.a, wherein “g” is a generator of a cyclic multiplicative group G and “a” is a random number generated by the device i, wherein the IBC scheme comprises a master secret key (MSK) and global system parameters (GSP), and wherein the MSK and GSP are utilized together with an identity of a requesting device to generate an IBC private key IBC-K for the requesting device; communicate, to the another device j, the encrypted first element g.sup.a, an identity ID.sub.i associated with the device i, and a session key request; receive, from the another device j, a second element g.sup.b and the identity ID.sub.j associated with the another device j; compute the escrow session key SK.sub.1 using the first element g.sup.a; compute the private session key SK.sub.2 using the second element g.sup.b and the random number a, wherein “g” is the generator of the cyclic multiplicative group G and “b” is a random number generated by the another device j; compute a first combined key SK.sub.11 by obtaining a coproduct of the escrow session key SK.sub.1 and the private session key SK.sub.2; generate a key confirmation value using the first combined key SK.sub.11, wherein the key confirmation value is communicated to the another device j; and validate the key confirmation value in response to a key confirmation validation value associated with the another device j being received.
7. The device according to claim 6, wherein the second element g.sup.b is encrypted using the IBE scheme and the identity ID.sub.i associated with the device i to generate an encrypted second element g.sup.b, wherein the device i uses the IBE scheme to decrypt the encrypted second element g.sup.b with an IBC private key IBC-K.sub.i, wherein the IBC private key IBC-K.sub.i is requested and generated in accordance with the IBC scheme.
8. The device according to claim 6, wherein computing the escrow session key SK.sub.1 by the device i comprises the device i being configured to use the first element g.sup.a and the second element g.sup.b to generate the escrow session key SK.sub.1.
9. The device according to claim 6, wherein the second element g.sup.b is encrypted using a Public Key Infrastructure (PKI) scheme with a PKI Public Key PBK.sub.i associated with the device i to generate an encrypted second element g.sup.b, wherein the device i uses the PKI scheme to decrypt the encrypted second element g.sup.b with the PKI Private Key PRK.sub.i associated with the device i.
10. The device according to claim 6, wherein communicating the encrypted first element g.sup.a, the identity ID.sub.i associated with the device i, and the session key request to the another device j comprises: signing the encrypted first element g.sup.a using an IBC private signing key IBC-K.sub.i associated with the device i to generate a signed encrypted first element g.sup.a; and transmitting the signed encrypted first element g.sup.a to the another device j.
11. A method for generating an escrow session key SK.sub.1 and a private session key SK.sub.2 for encoding digital communications between a device i and another device j, comprising: encrypting, by the device i, a first element g.sup.a with an identity ID.sub.j associated with the another device j using an Identity Based Encryption (IBE) scheme associated with an Identity Based Cryptography (IBC) scheme to generate an encrypted first element g.sup.a, wherein “g” is a generator of a cyclic multiplicative group G and “a” is a random number generated by the device i, wherein the IBC scheme comprises a master secret key (MSK) and global system parameters (GSP), and wherein the MSK and GSP are utilized together with an identity of a requesting device to generate an IBC private key IBC-K for the requesting device; communicating, by the device i to the another device j, the encrypted first element g.sup.a, an identity ID.sub.i associated with the device i, and a session key request; receiving, by the device i from the another device j, a second element g.sup.b and the identity IDj associated with the another device j; computing, by the device i, the escrow session key SK.sub.1 using the first element g.sup.a; computing, by the device i, the private session key SK.sub.2 using the second element g.sup.b and the random number a; computing, by the device i, a first combined key SK.sub.11 by obtaining a coproduct of the escrow session key SK.sub.1 and the private session key SK.sub.2; generating, by the device i, a key confirmation value using the first combined key SK.sub.11, wherein the key confirmation value is communicated to the another device j; and validating, by the device i, the key confirmation value in response to a key confirmation validation value associated with the another device j being received.
12. The method according to claim 11, wherein the second element g.sup.b is encrypted using the IBE scheme and the identity ID.sub.i associated with the device i to generate an encrypted second element g.sup.b, wherein the device i uses the IBE scheme to decrypt the encrypted second element g.sup.b with an IBC private key IBC-K.sub.i, wherein the IBC private key IBC-K.sub.i is requested and generated in accordance with the IBC scheme.
13. The method according to claim 11, wherein computing the escrow session key SK.sub.1 by the device i comprises the device i being configured to use the first element g.sup.a and the second element g.sup.b to generate the escrow session key SK.sub.1.
14. The method according to claim 11, wherein the second element g.sup.b is encrypted using a Public Key Infrastructure (PKI) scheme with a PKI Public Key PBK.sub.i associated with the device i to generate an encrypted second element g.sup.b, wherein the device i uses the PKI scheme to decrypt the encrypted second element g.sup.b with the PKI Private Key PRK.sub.i associated with the device i.
15. The method according to claim 11, wherein communicating the encrypted first element g.sup.a, the identity ID.sub.i associated with the device i, and the session key request to the another device j comprises: signing, by the device i, the encrypted first element g.sup.a using an IBC private signing key IBC-K.sub.i associated with the device i to generate a signed encrypted first element g.sup.a; and transmitting, by the device i, the signed encrypted first element g.sup.a to the another device j.
Description
BRIEF DESCRIPTION OF DRAWINGS
(1) The above advantages and features in accordance with this disclosure are described in the following detailed description and are shown in the following drawings:
(2)
(3)
(4)
(5)
DESCRIPTION OF EMBODIMENTS
(6) This disclosure relates to a system and method for generating two types of session keys for encoding digital communications between two devices. In particular, the first type of session key possesses escrow properties whereby a trusted third party will be able to generate the first type of session key to decode the digital communications between the two devices while the second type of session key does not possess escrow properties. This means that communications secured using the second type of session key may only be accessed by either one of the two devices and not by any trusted third party.
(7)
(8) The system illustrated in
(9) As for secure server 120, this server may comprise a third party that is trusted by devices 105 and/or 110. Server 120 may comprise a secure cloud server or a remotely located secure server which is able to communicate wirelessly with entities 105 and 110 either indirectly through the Internet or through other forms of direct communication means with entities 105 and 110. If server 120 is configured to communicate with entities 105 and 110 through the Internet, server 120 may do so via wired networks or wireless networks 130 such as, but are not limited to, cellular networks, satellite networks, telecommunication networks, or Wide Area Networks (WANs). Alternatively, if server 120 is configured to communicate directly with entities 105 and 110, this may be accomplished through wireless networks 132 such as, but not limited to, Wireless-Fidelity (Wi-Fi), Bluetooth, or Near Field Communication (NFC). It should be noted that entities 105 and 110 may utilize either one of wireless network 130 (via the Internet) or wireless network 132 (direct communication) to exchange data messages with one another.
(10)
(11) In embodiments of the disclosure, device 200 comprises controller 201 and user interface 202. User interface 202 is arranged to enable manual interactions between a user and electronic device 200 and for this purpose includes the input/output components required for the user to enter instructions to control electronic device 200. A person skilled in the art will recognize that components of user interface 202 may vary from embodiment to embodiment but will typically include one or more of display 240, keyboard 235 and track-pad 236.
(12) Controller 201 is in data communication with user interface 202 via bus 215 and includes memory 220, Central Processing Unit (CPU) 205 mounted on a circuit board that processes instructions and data for performing the method of this embodiment, an operating system 206, an input/output (I/O) interface 230 for communicating with user interface 202 and a communications interface, in this embodiment in the form of a network card 250. Network card 250 may, for example, be utilized to send data from electronic device 200 via a wired or wireless network to other processing devices or to receive data via the wired or wireless network. Wireless networks that may be utilized by network card 250 include, but are not limited to, Wireless-Fidelity (Wi-Fi), Bluetooth, Near Field Communication (NFC), cellular networks, satellite networks, telecommunication networks, Wide Area Networks (WANs) and etc.
(13) Memory 220 and operating system 206 are in data communication with CPU 205 via bus 210. The memory components include both volatile and non-volatile memory and more than one of each type of memory, including Random Access Memory (RAM) 220, Read Only Memory (ROM) 225 and a mass storage device 245, the last comprising one or more solid-state drives (SSDs). Memory 220 also includes secure storage 246 for securely storing secret keys, or private keys. It should be noted that the contents within secure storage 246 are only accessible by a super-user or administrator of device 200 and may not be accessed by any user of device 200. One skilled in the art will recognize that the memory components described above comprise non-transitory computer-readable media and shall be taken to comprise all computer-readable media except for a transitory, propagating signal. Typically, the instructions are stored as program code in the memory components but can also be hardwired. Memory 220 may include a kernel and/or programming modules such as a software application that may be stored in either volatile or non-volatile memory.
(14) Herein the term “CPU” is used to refer generically to any device or component that can process such instructions and may include: a microprocessor, microcontroller, programmable logic device or other computational device. That is, CPU 205 may be provided by any suitable logic circuitry for receiving inputs, processing them in accordance with instructions stored in memory and generating outputs (for example to the memory components or on display 240). In this embodiment, CPU 205 may be a single core or multi-core processor with memory addressable space. In one example, CPU 205 may be multi-core, comprising—for example—an 8 core CPU.
(15) Referring back to
(16) Server 120 may also select a Key Deriving Function (KDF) that is to be adopted for use in the system by any of devices 105 and/or 110. In embodiments of the disclosure, the KDF may include any scheme for deriving a secret key from a secret value such as a collision-resistant hash function. An example of a cryptographic collision-resistant hash function that may be employed is H: {0,1}*.fwdarw.{0,1}, whereby
is an appropriate integer known to a person skilled in the art.
(17) When device 105 or 110 joins the system, an IBC private key unique to each of these devices may be issued by secure server 120. These unique IBC private keys once generated may then be communicated to each of these devices whereby the respective IBC private keys may then be stored in the secure memory within each of devices 105 and 110.
(18) In particular, when device 105 registers itself with server 120, device 105 will communicate its identity ID.sub.105 to server 120. The identity ID.sub.105 of device 105 may comprise its user name, email address, telephone number, IP address, MAC address, or any alphanumeric combination that may be utilized to uniquely identify device 105. Server 120 then uses the identity id.sub.105 associated with device 105 with a key generation algorithm to generate an IBC private key IBC-K.sub.105 for device 105. In embodiments of the disclosure, device 105 may choose not to obtain its IBC private key hence it does not need to register itself with server 120. Instead, device 105 may choose to adopt a Public Key Infrastructure (PKI) scheme as such; device 105 will preload its PKI public key and its PKI private key into its secure memory.
(19) As for device 110, when device 110 registers itself with server 120, device 110 will then transmit its identity ID.sub.110 to server 120. In embodiments of the disclosure, identity ID.sub.110 may comprise, but is not limited to, the vehicle's license plate number, a driver's license number, the vehicle's Vehicle Identification Number (VIN) as the VIN contains various details about a vehicle including its manufacturer, model, year, where it was manufactured or any alphanumeric combination that may be utilized to uniquely identify device 110. Server 120 then uses identity ID.sub.110 associated with device 110 with the same key generation algorithm to generate an IBC private key IBC-K.sub.110 for device 110. In embodiments of the disclosure, the IBC private keys IBC-K for each device may be generated using standard Key Generation functions associated with IBC schemes.
(20) The IBC private keys IBC-K.sub.105 (if requested) and IBC-K.sub.110 are then communicated securely to their respective devices. Once the IBC private keys have been stored in the secure memory of the respective devices, the device pair, i.e. device 105 and 110, may then proceed to generate an escrow session key SK.sub.1 and a private session key SK.sub.2 for encoding digital communication between these two devices. In the following description, for ease of reading, device 105 may also be identified as device “i” while device 110 may also be identified as device “j”. In embodiments of the disclosure, instead of requesting for its own IBC private key, device 105 will utilize a PKI scheme as such; device 105 will preload its PKI public key and its PKI private key into its secure memory.
(21) It is useful to note that IBC schemes that may be employed in embodiments of the disclosure include, but are not limited to, the Boneh-Franklin scheme.
(22) Embodiment Based on Both Devices Having IBC Private Keys (Decryption Key), IBC-K
(23) In a first embodiment of the disclosure, devices 105 and 110 will both initially request and obtain their respective IBC private keys from server 120 whereby both of these IBC private keys will act as an Identity Based Encryption (IBC) scheme's decryption keys. The IBC private keys are then stored in each respective device's secure memory.
(24) The generation of the escrow and private session keys for devices 105 and 110 in accordance with this embodiment of the disclosure is illustrated in
(25) The detailed computation of the first element g.sup.a is omitted for brevity as this computation is done using existing Diffie-Hellman key exchange methodologies. For example, in a Diffie-Hellman key exchange between two users A and B, A will first select a random number “a”, and B will first select a random number “b”. Parameters g.sup.a, g.sup.b are then exchanged between them. A then computes (g.sup.b).sup.a using its “a” parameter and B computes (g.sup.a).sup.b with its “b” parameter. As a result, A and B are then able to establish a common secret CommonSecret=g.sup.ab. In other words, given only g.sup.a and g.sup.b, no other third party would be able to compute g.sup.ab.
(26) Returning to step 305, device 105 will then encrypt the first element g.sup.a using the identity of device 110, ID.sub.110. This may be done using an Identity Based Encryption (IBE) function associated with the IBC scheme and this may be represented as θ=Enc.sub.ID110(g.sup.a, ID.sub.105). The encrypted first element θ, the identity of device 105, ID.sub.105 and a session key request are then transmitted at step 310 from device 105 to device 110.
(27) Upon receiving the data transmitted from device 105 at step 315, device 110 then proceeds to decrypt the encrypted first element θ. This decryption step may be done using a decryption function associated with the IBC encryption scheme whereby device 110's IBC private key, IBC-K.sub.110 is used to decrypt encrypted first element θ that was previously encrypted using device 110's identity ID.sub.110 with an IBC encryption scheme. Once the encrypted first element θ has been decrypted, device 110 will now be in possession of the first element g.sup.a.
(28) Device 110 then proceeds to choose a random number “b”. Device 110 then proceeds to compute a second element g.sup.b using the chosen random number “b” where g is a generator of a cyclic multiplicative group G with prime order q.
(29) Device 110 will then encrypt the second element g.sup.b using the identity of device 105, ID.sub.105. This may again be done using an Identity Based Encryption (IBE) function associated with the IBC scheme and this may be represented as ϵ32 Enc.sub.ID105(g.sup.b, ID.sub.110). The encrypted second element ϵ and the identity of device 110, ID.sub.110 are then transmitted at step 320 from device 110 to device 105.
(30) At step 325, after the data has been transmitted to device 105 from device 110, device 110 then proceeds to compute the escrow session key SK.sub.1 using the first element g.sup.a and the second element g.sup.b. The computation of the escrow session key SK.sub.1 above may be done using existing key generation functions and these two parameters. Separately, the private session key SK.sub.2 is then computed using a function of the first element g.sup.a and random number “b”, i.e. g.sup.ab whereby random number “b” is known only to device 110.
(31) Once device 105 has received the data transmitted from device 110 at step 320, at step 335, device 105 then proceeds to decrypt the encrypted second element ϵ. This decryption step may be done using a decryption function associated with the IBC scheme whereby device 105's IBC private key, IBC-K.sub.105 is used to decrypt the encrypted second element ϵ that was previously encrypted using device 105's identity ID.sub.105 with an IBC encryption scheme. Once the encrypted second element ϵ has been decrypted, device 105 will now be in possession of the second element g.sup.b.
(32) Device 105 then proceeds to compute the escrow session key SK.sub.1 using the first element g.sup.a and the second element g.sup.b. Similarly, the computation of the escrow session key SK.sub.1 above may be done using existing key generation functions and these two parameters. Separately, the private session key SK.sub.2 is then computed using a function of the first element g.sup.b and random number “a”, i.e. g.sup.ab whereby random number “a” is known only to device 105.
(33) In embodiments of the disclosure, steps 325 and 335 may take place simultaneously or in other embodiments of the disclosure, step 325 may take place before the data is transmitted at step 320 to device 105.
(34) Once devices 105 and 110 have generated their respective escrow session keys SK.sub.1 and private session keys SK.sub.2, the validity of these two keys are verified by obtaining a coproduct of these two keys. The coproduct obtained by device 105 may be defined as SK.sub.105=SK.sub.1⊕SK.sub.2 while the coproduct obtained by device 110 may be defined as SK.sub.110=SK.sub.1⊕SK.sub.2. In embodiments of the disclosure, the coproduct obtained by device 105 may be defined as combined key SK.sub.105 while the coproduct obtained by device 110 may be defined as combined key SK.sub.110.
(35) In a further embodiment of the disclosure, once device 105 has computed its coproduct SK.sub.105 and once device 110 has computed its own coproduct SK.sub.110, these two devices may then perform a series of steps to confirm that their respectively generated escrow session key SK.sub.1 and private session key SK.sub.2 are similar. In an embodiment of the disclosure, this may be achieved by encrypting a preagreed challenge phrase using device 105's coproduct SK.sub.105. This encrypted challenge phrase is then sent to device 110. Device 110 will then decrypt the encrypted challenge phrase using its own coproduct SK.sub.110. If the decrypted challenge phrase matches the challenge phrase stored in device 110, this implies that both coproducts are similar. In yet another embodiment of the disclosure, device 105's coproduct SK.sub.105 may be used with a message authentication code (MAC) algorithm to produce a MAC data tag. This data tag may then be sent to device 110 who will then in turn use its coproduct SK.sub.110 to verify the data tag. If the data tag is verified, this then implies that both coproducts are similar. In still yet another embodiment of the disclosure, device 105's coproduct SK.sub.105 may be used to generate a hash of a preagreed verification value. This hash is then forwarded to device 110. Device 110 then uses its own coproduct SK.sub.110 to generate a hash of the preagreed verification value. If the two hash values match, this then implies that the coproducts of both devices are similar.
(36) Hence, as server 120 was the trusted source that generated the IBC private keys for devices 105 and 110, server 120 would be able to decrypt the encrypted first element θ and the encrypted second element ϵ thereby allowing server 120 to compute the escrow session key SK.sub.1 on its own. However, as server 120 is unaware of the random number “a” generated by device 105 and the random number “b” generated by device 110, server 120 is unable to compute the private session key SK.sub.2 thereby ensuring that all communication secured using this private session key remains private to devices 105 and 110 only.
(37) Embodiment Based on a Device Having an IBC Private Key (Decryption Key), IBC-K and Another Device Having a PKI Private Key (Decryption Key) and a PKI Public Key
(38) In a second embodiment of the disclosure, only device 110 will initially request and obtain its IBC private key from server 120 and this key will act as the decryption key in accordance with embodiments of the disclosure. The IBC private key is then stored in device 110's secure memory. As for device 105, device 105 utilizes a Public Key Infrastructure (PKI) scheme as such; device 105 will preload its PKI public key PBK.sub.105 and its PKI private key PRK.sub.105 into its secure memory. In accordance with the PKI scheme, device 105's PKI public key PBK.sub.105 is known to the public and in particular known to device 110.
(39) The generation of the escrow and private session keys for devices 105 and 110 in accordance with this embodiment of the disclosure is described with the assistance of the illustration in
(40) Upon receiving the data transmitted from device 105 at step 315, device 110 then proceeds to decrypt the encrypted first element θ. This decryption step may be done using a decryption function associated with the IBC encryption scheme whereby device 110's IBC private key, IBC-K.sub.110 is used to decrypt encrypted first element θ that was previously encrypted using device 110's identity ID.sub.110 with an IBC encryption scheme. Once the encrypted first element θ has been decrypted, device 110 will now be in possession of the first element g.sup.a.
(41) Device 110 then proceeds to choose a random number “b”. Device 110 then proceeds to compute a second element g.sup.b using the chosen random number “b” where g is a generator of a cyclic multiplicative group G with prime order q.
(42) Device 110 will then encrypt the second element g.sup.b using the public PKI key of device 105, which is PBK.sub.105. This may be done using a PKI encryption function that is known to those skilled in the art and this may be represented as ϵ=Enc.sub.PBK105(g.sup.b, ID.sub.110). The encrypted second element ϵ and the identity of device 110, ID.sub.110 are then transmitted at step 320 from device 110 to device 105.
(43) At step 325, after the data has been transmitted to device 105 from device 110, device 110 then proceeds to compute the escrow session key SK.sub.1 using only the first element g.sup.a. The computation of the escrow session key SK.sub.1 above may be done using existing key generation functions and the first element. Separately, the private session key SK.sub.2 is then computed using a function of the first element g.sup.a and random number “b”, i.e. g.sup.ab whereby random number “b” is known only to device 110.
(44) Once device 105 has received the data transmitted from device 110 at step 320, at step 335, device 105 then proceeds to decrypt the encrypted second element ϵ. This decryption step may be done using a decryption function associated with the PKI scheme whereby device 105's private PKI key, PRK.sub.105 is used to decrypt the encrypted second element ϵ that was previously encrypted using device 105's public PKI key, PBK.sub.105. Once the encrypted second element ϵ has been decrypted, device 105 will now be in possession of the second element g.sup.b.
(45) Device 105 then proceeds to compute the escrow session key SK.sub.1 using only the first element g.sup.a. Similarly, the computation of the escrow session key SK.sub.1 above may be done using existing key generation functions and the first element. Separately, the private session key SK.sub.2 is then computed using a function of the first element g.sup.b and random number “a”, i.e. g.sup.ab whereby random number “a” is known only to device 105.
(46) As per the previous embodiments, one skilled in the art will recognize that steps 325 and 335 may take place simultaneously or in other embodiments of the disclosure, step 325 may take place before the data is transmitted at step 320 to device 105.
(47) Once devices 105 and 110 have generated their respective escrow session keys SK.sub.1 and private session keys SK.sub.2, the validity of these two keys may be verified by obtaining a coproduct of these two keys. The coproduct may be obtained as SK=SK.sub.1⊕SK.sub.2.
(48) In a further embodiment of the disclosure, once device 105 has computed its coproduct SK.sub.105 and once device 110 has computed its own coproduct SK.sub.110, these two devices may then perform a series of steps to confirm that their respectively generated escrow session key SK.sub.1 and private session key SK.sub.2 are similar. In an embodiment of the disclosure, this may be achieved by encrypting a preagreed challenge phrase using device 105's coproduct SK.sub.105. This encrypted challenge phrase is then sent to device 110. Device 110 will then decrypt the encrypted challenge phrase using its own coproduct SK.sub.110. If the decrypted challenge phrase matches the challenge phrase stored in device 110, this implies that both coproducts are similar. In yet another embodiment of the disclosure, device 105's coproduct SK.sub.105 may be used with a MAC algorithm to produce a MAC data tag. This data tag may then be sent to device 110 who will then in turn use its coproduct SK.sub.110 to verify the data tag. If the data tag is verified, this then implies that both coproducts are similar. In still yet another embodiment of the disclosure, device 105's coproduct SK.sub.105 may be used to generate a hash of a preagreed verification value. This hash is then forwarded to device 110. Device 110 then uses its own coproduct SK.sub.110 to generate a hash of the preagreed verification value. If the two hash values match, this then implies that the coproducts of both devices are similar.
(49) Hence, as server 120 was the trusted source that generated the private IBE key for device 105, server 120 would be able to decrypt the encrypted first element θ thereby allowing server 120 to compute the escrow session key SK.sub.1 on its own. However, as server 120 is unaware of the random number “a” generated by device 105 and the random number “b” generated by device 110, server 120 is unable to compute the private session key SK.sub.2 thereby ensuring that all communication secured using this private session key remains private to devices 105 and 110 only.
(50) Embodiment Based on a Device Having an IBC Private Key, IBC-K as a Decryption Key and Another Device Having an IBC Private Key as a Signing Key, IBC-K
(51) In a third embodiment of the disclosure, device 110 will initially request and obtain its IBC private key (decryption key) from server 120 and device 105 will request and obtain its IBC private key (signing key) from server 120. The IBC private key IBC-K.sub.110 associated with device 110 is then stored in device 110's secure memory and the IBC private key (signing key) IBC-K.sub.105 associated with device 105 is stored in device 105's secure memory. In this embodiment, device 110's IBC private key (decryption key) will be generated by server 120 using device 110's identity and device 105's IBC private key (signing key) IBC-K.sub.105 will be generated using device 105's identity.
(52) The generation of the escrow and private session keys for devices 105 and 110 in accordance with this embodiment of the disclosure is described with the assistance of the illustration in
(53) Upon receiving the data transmitted from device 105 at step 315, device 110 then proceeds to verify the signed encrypted first element α as received from device 105. This is done by using a standard IBC signature verification function to verify a using device 105's identity ID.sub.105. If α is successfully verified by device 110, device 110 will proceed to decrypt the encrypted first element θ else, device 110 will abort the entire session key generation process.
(54) Once verified, device 110 then proceeds to decrypt the encrypted first element θ. This decryption step may be done using a decryption function associated with the IBC encryption scheme whereby device 110's IBC private key, IBC-K.sub.110 is used to decrypt encrypted first element θ that was previously encrypted using device 110's identity ID.sub.110 with an IBC encryption scheme. Once the encrypted first element θ has been decrypted, device 110 will now be in possession of the first element g.sup.a.
(55) Device 110 then proceeds to choose a random number “b”. Device 110 then proceeds to compute a second element g.sup.b using the chosen random number “b” where g is a generator of a cyclic multiplicative group G with prime order q. The second element g.sup.b and the identity of device 110, ID.sub.110 are then transmitted at step 320 from device 110 to device 105.
(56) At step 325, after the data has been transmitted to device 105 from device 110, device 110 then proceeds to compute the escrow session key SK.sub.1 using only the first element g.sup.a. The computation of the escrow session key SK.sub.1 above may be done using existing key generation functions and the first element. Separately, the private session key SK.sub.2 is then computed using a function of the first element g.sup.a and random number “b”, i.e. g.sup.ab whereby random number “b” is known only to device 110.
(57) Once device 105 has received the data transmitted from device 110 at step 320, at step 335, device 105 will now be in possession of the second element g.sup.b. Device 105 then proceeds to compute the escrow session key SK.sub.1 using only the first element g.sup.a. Similarly, the computation of the escrow session key SK.sub.1 above may be done using existing key generation functions and the first element. Separately, the private session key SK.sub.2 is then computed using a function of the first element g.sup.b and random number “a”, i.e. g.sup.ab whereby random number “a” is known only to device 105.
(58) As per the previous embodiments, one skilled in the art will recognize that steps 325 and 335 may take place simultaneously or in other embodiments of the disclosure, step 325 may take place before the data is transmitted at step 320 to device 105.
(59) Once devices 105 and 110 have generated their respective escrow session keys SK.sub.1 and private session keys SK.sub.2, the validity of these two keys may be verified by obtaining a coproduct of these two keys. The coproduct may be obtained as SK=SK.sub.1⊕SK.sub.2.
(60) In a further embodiment of the disclosure, once device 105 has computed its coproduct SK.sub.105 and once device 110 has computed its own coproduct SK.sub.110, these two devices may then perform a series of steps to confirm that their respectively generated escrow session key SK.sub.1 and private session key SK.sub.2 are similar. In an embodiment of the disclosure, this may be achieved by encrypting a preagreed challenge phrase using device 105's coproduct SK.sub.105. This encrypted challenge phrase is then sent to device 110. Device 110 will then decrypt the encrypted challenge phrase using its own coproduct SK.sub.110. If the decrypted challenge phrase matches the challenge phrase stored in device 110, this implies that both coproducts are similar. In this embodiment, the encrypted challenge phrase represents the key confirmation value that is exchanged between both devices. In yet another embodiment of the disclosure, device 105's coproduct SK.sub.105 may be used with a MAC algorithm to produce a MAC data tag. This data tag may then be sent to device 110 who will then in turn use its coproduct SK.sub.110 to verify the data tag. If the data tag is verified, this then implies that both coproducts are similar. In this embodiment, the data tag represents the key confirmation value that is exchanged between both devices. In still yet another embodiment of the disclosure, device 105's coproduct SK.sub.105 may be used to generate a hash of a preagreed verification value. This hash is then forwarded to device 110. Device 110 then uses its own coproduct SK.sub.110 to generate a hash of the preagreed verification value. If the two hash values match, this then implies that the coproducts of both devices are similar. In this embodiment, the hash value represents the key confirmation value that is exchanged between both devices. It should be noted that other types of key confirmation values may be utilized without departing from this disclosure.
(61) One skilled in the art will recognize that the objective of the steps described in the paragraph above is to generate a key confirmation value that is then used to verify the escrow session key SK.sub.1 and the private session key SK.sub.2 that has been generated by both devices. One skilled in the art will also recognize that the initiator of the key confirmation steps above may be device 110 and is not limited to device 105 as set out above and that this applies to all embodiments of the disclosure.
(62) Hence, as server 120 was the trusted source that generated the private IBE key for device 105, server 120 would be able to decrypt the encrypted first element θ thereby allowing server 120 to compute the escrow session key SK.sub.1 on its own. However, as server 120 is unaware of the random number “a” generated by device 105 and the random number “b” generated by device 110, server 120 is unable to compute the private session key SK.sub.2 thereby ensuring that all communication secured using this private session key remains private to devices 105 and 110 only.
(63) In accordance with an embodiment of the disclosure, a method for a device “i” and a device “j” to generate an escrow session key SK.sub.1 and a private session key SK.sub.2 for encoding digital communications between these two devices, comprises the following steps: Step 1, generate, using a secure server, a master secret key (MSK) and global system parameters (GSP) for an Identity Based Cryptography (IBC) scheme, whereby the MSK and GSP are utilized together with a requesting device's identity to generate an IBC private key IBC-K for the requesting device; Step 2, using the first device, use an Identity Based Encryption (IBE) scheme associated with the IBC scheme to encrypt a first element g.sup.a with an identity ID.sub.j, associated with the second device j, where g is a generator of a cyclic multiplicative group G and a is a random number generated by the first device i; Step 3, communicate to the second device, the encrypted first element, an identity ID.sub.i associated with the first device and a session key request such that upon receiving the communication, the second device is configured to: use the IBE scheme to decrypt the encrypted first element with an IBC private key, IBC-K.sub.j, whereby the IBC private key, IBC-K.sub.j, is requested and obtained from the secure server; generate a second element g.sup.b where g is the generator of the cyclic multiplicative group G and b is a random number generated by the second device j; compute the escrow session key SK.sub.1, using the first element; compute the private session key SK.sub.2, using the first element and the random number b; and communicate the second element and an identity ID.sub.j associated with the second device to the first device, Step 4, compute the escrow session key SK.sub.1, using the first element and compute the private session key SK.sub.2, using the second element and the random number a
(64) In order to provide such a system or method, a process is needed for a device “i” and a device “j” to generate an escrow session key SK.sub.1 and a private session key SK.sub.2 for encoding digital communications between these two devices. The following description and
(65)
(66) Process 400 begins at step 405 with process 400 encrypting first element g.sup.a with identity ID.sub.j that is associated with the second device. The encrypted first element and the identity of the first device ID.sub.i are then transmitted to the second device at step 410.
(67) At step 415, the first device then receives a second element g.sup.b and an identity ID.sub.j associated with the second device. The first device then proceeds to compute the escrow session key SK.sub.1 and the private session key SK.sub.2 using the received second element g.sup.b.
(68) The above is a description of embodiments of a system and process in accordance with the present disclosure as set forth in the following claims. It is envisioned that others may and will design alternatives that fall within the scope of the following claims.