CA2596067C - Method and system for deriving an encryption key using joint randomness not shared by others - Google Patents
Method and system for deriving an encryption key using joint randomness not shared by others Download PDFInfo
- Publication number
- CA2596067C CA2596067C CA2596067A CA2596067A CA2596067C CA 2596067 C CA2596067 C CA 2596067C CA 2596067 A CA2596067 A CA 2596067A CA 2596067 A CA2596067 A CA 2596067A CA 2596067 C CA2596067 C CA 2596067C
- Authority
- CA
- Canada
- Prior art keywords
- key
- wtru
- pmk
- secret
- bits
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0875—Generation of secret information including derivation or calculation of cryptographic keys or passwords based on channel impulse response [CIR]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
- H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
- H04W12/0431—Key distribution or pre-distribution; Key agreement
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/34—Encoding or coding, e.g. Huffman coding or error correction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/80—Wireless
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/061—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying further key derivation, e.g. deriving traffic keys from a pair-wise master key
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
- H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
- Storage Device Security (AREA)
Abstract
The present invention is related to a method and system for deriving an encryption key using joint randomness not shared by others (JRNSO).
Communicating entities generate JRNSO bits from a channel impulse response (CIR) estimate and the JRNSO bits are used in generation of an encryption key.
The authentication type may be IEEE 802.1x or a pre-shared key system. In an IEEE 802.1x system, a master key, a pairwise master key or a pairwise transient key may be generated using the JRNSO bits. The encryption key may be generated by using a Diffie-Hellman key derivation algorithm.
Communicating entities generate JRNSO bits from a channel impulse response (CIR) estimate and the JRNSO bits are used in generation of an encryption key.
The authentication type may be IEEE 802.1x or a pre-shared key system. In an IEEE 802.1x system, a master key, a pairwise master key or a pairwise transient key may be generated using the JRNSO bits. The encryption key may be generated by using a Diffie-Hellman key derivation algorithm.
Description
[0001] METHOD AND SYSTEM FOR DERIVING AN
ENCRYPTION KEY USING JOINT
RANDOMNESS NOT SHARED BY OTHERS
[0002] FIELD OF INVENTION
ENCRYPTION KEY USING JOINT
RANDOMNESS NOT SHARED BY OTHERS
[0002] FIELD OF INVENTION
[0003] The present invention is related to wireless communication security.
More particularly, the present invention is related to a method and system for deriving an encryption key using joint randomness not shared by others (JRNS0).
More particularly, the present invention is related to a method and system for deriving an encryption key using joint randomness not shared by others (JRNS0).
[0004] BACKGROUND
[0005] IEEE
802.11i is used to ensure that a wireless local area network (WLAN) operating under IEEE 802.11 standards can communicate data securely by using a counter mode (CTR) with cipher-block chaining with a message authentication code (CBC-MAC) protocol (CCMP) encapsulation technique which, in turn, utilizes an advanced encryption standard (AES) algorithm. To achieve this goal, IEEE 802.11i provides two schemes that allow a pair of communicating nodes to derive keys that can be used to encrypt exchanged packets.
802.11i is used to ensure that a wireless local area network (WLAN) operating under IEEE 802.11 standards can communicate data securely by using a counter mode (CTR) with cipher-block chaining with a message authentication code (CBC-MAC) protocol (CCMP) encapsulation technique which, in turn, utilizes an advanced encryption standard (AES) algorithm. To achieve this goal, IEEE 802.11i provides two schemes that allow a pair of communicating nodes to derive keys that can be used to encrypt exchanged packets.
[0006] The first scheme is based on an IEEE 802.1x authentication technique that requires a remote authentication server, (e.g. a RADIUS
server).
In IEEE 802.1x, an access point (AP) acts as a router between a wireless transmit/receive unit (WTRU) desiring association with the AP and an authentication server. The authentication server provides a public key to the WTRU via the AP. The WTRU can verify this public key by checking it with a digital certificate provided by the authentication server. The WTRU then derives a random secret, (i.e., master secret), and sends the master secret to the authentication server by encrypting it with the public key provided. Thus, only the authentication server can decrypt the master secret using a corresponding private key. The authentication server and the WTRU use this master secret to derive a master key (MK). The authentication server and the WTRU then derive a pairwise master key (PMK) from the MK. The authentication server provides this PMK to the AP. The AP and the WTRU then derive a pairwise transient key (PTK) using the PMK. A portion of this PTK is a temporal key (TK) that is the actual key used in the CCMP technique for encrypting packets. Because this scheme uses remote authentication servers and digital certificates, (which are currently expensive), such a scheme is typically implemented in an enterprise WLAN.
server).
In IEEE 802.1x, an access point (AP) acts as a router between a wireless transmit/receive unit (WTRU) desiring association with the AP and an authentication server. The authentication server provides a public key to the WTRU via the AP. The WTRU can verify this public key by checking it with a digital certificate provided by the authentication server. The WTRU then derives a random secret, (i.e., master secret), and sends the master secret to the authentication server by encrypting it with the public key provided. Thus, only the authentication server can decrypt the master secret using a corresponding private key. The authentication server and the WTRU use this master secret to derive a master key (MK). The authentication server and the WTRU then derive a pairwise master key (PMK) from the MK. The authentication server provides this PMK to the AP. The AP and the WTRU then derive a pairwise transient key (PTK) using the PMK. A portion of this PTK is a temporal key (TK) that is the actual key used in the CCMP technique for encrypting packets. Because this scheme uses remote authentication servers and digital certificates, (which are currently expensive), such a scheme is typically implemented in an enterprise WLAN.
[0007] The second scheme that is more suitable for home or small business networks utilizes a pre-shared key (PSK). In this scheme, a 256 bit user-configurable secret key is stored on the communicating nodes. When the WTRU
wishes to associate with an AP, the WTRU uses the PSK as a PMK, (without deriving the master secret and the MK), and derives a PTK and uses a portion of the PTK as a TK just like in the IEEE 802.1x system.
wishes to associate with an AP, the WTRU uses the PSK as a PMK, (without deriving the master secret and the MK), and derives a PTK and uses a portion of the PTK as a TK just like in the IEEE 802.1x system.
[0008] There are at least two problems with the IEEE 802.11i system.
First, the final TK is only as secure as the master secret exchanged in the case of IEEE 802.1x networks, or as the PSK in the case of home or small business networks. In the IEEE 802.1x system, an attacker can decrypt the master secret by stealing the authentication server's private key. In home networks, the PSK
can either be deduced using a brute-force attack, (being that PSKs at home are not changed regularly or are generated from a "weak" pass-phrase), or by stealing the key. Knowing the master secret or the PSK allows the attacker to arrive at the identical value for the PMK, in the same manner as the two legitimate communicating nodes, and to thereafter derive an identical PTK value. Thus, knowledge of authentication credentials is sufficient for knowledge of derived encryption keys. Moreover, when keys are updated during a session the MK and the PMK are typically left untouched and only a new PTK is derived using the PMK, (which is supposed to be a secret), and information exchanged in the clear.
As the PMK does not change, the PTK is not fresh and is therefore not a new key.
First, the final TK is only as secure as the master secret exchanged in the case of IEEE 802.1x networks, or as the PSK in the case of home or small business networks. In the IEEE 802.1x system, an attacker can decrypt the master secret by stealing the authentication server's private key. In home networks, the PSK
can either be deduced using a brute-force attack, (being that PSKs at home are not changed regularly or are generated from a "weak" pass-phrase), or by stealing the key. Knowing the master secret or the PSK allows the attacker to arrive at the identical value for the PMK, in the same manner as the two legitimate communicating nodes, and to thereafter derive an identical PTK value. Thus, knowledge of authentication credentials is sufficient for knowledge of derived encryption keys. Moreover, when keys are updated during a session the MK and the PMK are typically left untouched and only a new PTK is derived using the PMK, (which is supposed to be a secret), and information exchanged in the clear.
As the PMK does not change, the PTK is not fresh and is therefore not a new key.
[0009]
Furthermore, the key derivation procedure is very complex and it has many stages, (such as MK, PMK, PTK and TK). This consumes time and resources.
Furthermore, the key derivation procedure is very complex and it has many stages, (such as MK, PMK, PTK and TK). This consumes time and resources.
[0010] Keys can be thought of as bit sequences. A perfectly secret random key of length N bits is an N-bit sequence S, shared by entities. Given all the information available in the system at large, anyone else's estimation about what this key sequence can be is roughly equiprobably distributed over all possible N-bit sequences.
[0011] Prior art crypto systems rely on the fact that it may be extremely difficult from a computational resource point of view to guess the crypto key.
However, in most of these systems, once the correct guess is produced, it is very easy to verify that this is indeed the correct guess. In fact, the prior art implies that this is applicable to any public-key system, (i.e., one where the encryption key is made public, while the decryption key is kept secret).
However, in most of these systems, once the correct guess is produced, it is very easy to verify that this is indeed the correct guess. In fact, the prior art implies that this is applicable to any public-key system, (i.e., one where the encryption key is made public, while the decryption key is kept secret).
[0012] By way of example, assume that p and q are two large prime numbers and s = pq, it is well known that the problem of factoring a product of two large prime numbers is extremely computationally difficult. If a party chooses p and q in secret and makes publicly available their product s, which is then used as an encryption key for an encryption system, it cannot be easily decrypted unless one knows p and q. An eavesdropper wishing to intercept an encrypted message would likely start by attempting to factor s, which is known to be computationally difficult. However, if the eavesdropper guessesp, it will quite easily verify that it has the right answer. The ability to know that the right answer was obtained with a guess differentiates computational secrecy from perfect secrecy. Perfect secrecy implies that even if the attacker guesses the key correctly, it will have no ability to determine that it has indeed done so.
[0013] It is therefore desirable to generate encryption by keys without the limitations of the prior art.
[0014] SUMMARY
[0015] The present invention is related to a method and system for deriving an encryption key using JRNSO. Communicating entities generate JRNSO bits from a CIR estimate and the JRNSO bits are used in generation of an encryption key. The authentication type may be IEEE 802.1x or a pre-shared key system.
In an IEEE 802.1x system, an MK, a PMK and/or a PTK may be generated using the JRNSO bits. The encryption key may be generated by using a Diffie-Hellman key derivation algorithm.
[0015a] According to an embodiment of the present disclosure there is provided a method for deriving an encryption key for securing wireless communications, the method comprising: a wireless transmit/receive unit (WTRU) obtaining an association to an access point (AP); the WTRU determining a secret that complies with a supported authentication type; the WTRU generating a channel impulse response (CIR) estimate based upon a signal received from the AP; the WTRU correcting errors in the CIR estimate and generating parity bits by performing error correction coding on the CIR estimate; the WTRU
multiplexing the parity bits with a synchronization code to generate a multiplexed bit stream; the WTRU transmitting the multiplexed bit stream to the AP; the WTRU
generating joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR
estimate; the WTRU deriving a pairwise master key (PMK) using the secret and the JRNSO bits;
and the WTRU deriving a pairwise transient key (PTK) using the PMK and the JRNSO bits.
[0015b] According to another embodiment of the present disclosure there is provided a wireless transmit/receive unit (WTRU) for deriving an encryption key for securing wireless communications, the WTRU comprising: a memory, the memory being electronically coupled to a processor; a transceiver electronically coupled to the processor;
the processor configured to: report a secret to an authentication server;
generate a channel impulse response (CIR) estimate of a communication received from an access point (AP);
correct errors in the CIR estimate and generate parity bits by performing error correction coding on the CIR estimate; multiplex the parity bits with a synchronization code to generate a multiplexed bit stream; instruct the transceiver to transmit the multiplexed bit stream to the AP; generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR estimate; derive a pairwise master key (PMK) using the secret and the JRNSO bits; and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
[0015c] According to another embodiment of the present disclosure there is provided a wireless transmit/receive unit (WTRU) for deriving an encryption key for securing wireless communications, the WTRU comprising: a memory operatively connected to a processor; a transceiver electronically coupled to the processor; the processor configured to:
report a master secret to an authentication server; generate a channel impulse response (CIR) estimate of a communication received from an access point (AP); correct errors in the CIR
estimate and generate parity bits by performing error correction coding on the CIR estimate;
multiplex the parity bits with a synchronization code to generate multiplexed bit stream;
instruct the transceiver to transmit the multiplexed bit stream to the AP;
generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR
estimate; derive a pairwise master key (PMK) from the master secret and the JRNSO bits; and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
[0015d] According to another embodiment of the present disclosure there is provided a wireless transmit/receive unit (WTRU) for deriving an encryption key for securing wireless communications, the WTRU comprising: a memory operatively connected to a processor; a transceiver operatively coupled to the processor; the processor configured to:
report a pre-master secret to an authentication server; generate a channel impulse response (CIR) estimate of a communication received from an access point (AP); correct errors in the CIR estimate and generate parity bits by performing error correction coding on the CIR
estimate; multiplex the parity bits with a synchronization code to generate a multiplexed bit stream; instruct the transceiver to transmit the multiplexed bit stream to the AP; generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected estimate; derive a master key from the pre-master secret and the JRNSO bits; derive a pairwise master key (PMK) from the master key and the JRNSO bits; and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
In an IEEE 802.1x system, an MK, a PMK and/or a PTK may be generated using the JRNSO bits. The encryption key may be generated by using a Diffie-Hellman key derivation algorithm.
[0015a] According to an embodiment of the present disclosure there is provided a method for deriving an encryption key for securing wireless communications, the method comprising: a wireless transmit/receive unit (WTRU) obtaining an association to an access point (AP); the WTRU determining a secret that complies with a supported authentication type; the WTRU generating a channel impulse response (CIR) estimate based upon a signal received from the AP; the WTRU correcting errors in the CIR estimate and generating parity bits by performing error correction coding on the CIR estimate; the WTRU
multiplexing the parity bits with a synchronization code to generate a multiplexed bit stream; the WTRU transmitting the multiplexed bit stream to the AP; the WTRU
generating joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR
estimate; the WTRU deriving a pairwise master key (PMK) using the secret and the JRNSO bits;
and the WTRU deriving a pairwise transient key (PTK) using the PMK and the JRNSO bits.
[0015b] According to another embodiment of the present disclosure there is provided a wireless transmit/receive unit (WTRU) for deriving an encryption key for securing wireless communications, the WTRU comprising: a memory, the memory being electronically coupled to a processor; a transceiver electronically coupled to the processor;
the processor configured to: report a secret to an authentication server;
generate a channel impulse response (CIR) estimate of a communication received from an access point (AP);
correct errors in the CIR estimate and generate parity bits by performing error correction coding on the CIR estimate; multiplex the parity bits with a synchronization code to generate a multiplexed bit stream; instruct the transceiver to transmit the multiplexed bit stream to the AP; generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR estimate; derive a pairwise master key (PMK) using the secret and the JRNSO bits; and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
[0015c] According to another embodiment of the present disclosure there is provided a wireless transmit/receive unit (WTRU) for deriving an encryption key for securing wireless communications, the WTRU comprising: a memory operatively connected to a processor; a transceiver electronically coupled to the processor; the processor configured to:
report a master secret to an authentication server; generate a channel impulse response (CIR) estimate of a communication received from an access point (AP); correct errors in the CIR
estimate and generate parity bits by performing error correction coding on the CIR estimate;
multiplex the parity bits with a synchronization code to generate multiplexed bit stream;
instruct the transceiver to transmit the multiplexed bit stream to the AP;
generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR
estimate; derive a pairwise master key (PMK) from the master secret and the JRNSO bits; and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
[0015d] According to another embodiment of the present disclosure there is provided a wireless transmit/receive unit (WTRU) for deriving an encryption key for securing wireless communications, the WTRU comprising: a memory operatively connected to a processor; a transceiver operatively coupled to the processor; the processor configured to:
report a pre-master secret to an authentication server; generate a channel impulse response (CIR) estimate of a communication received from an access point (AP); correct errors in the CIR estimate and generate parity bits by performing error correction coding on the CIR
estimate; multiplex the parity bits with a synchronization code to generate a multiplexed bit stream; instruct the transceiver to transmit the multiplexed bit stream to the AP; generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected estimate; derive a master key from the pre-master secret and the JRNSO bits; derive a pairwise master key (PMK) from the master key and the JRNSO bits; and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
[0016] BRIEF DESCRIPTION OF THE DRAWINGS
[0017] Figure 1 is a block diagram of a system including two communicating entities for deriving a secret key in accordance with the present invention.
[0018] Figure 2 illustrates a problem of discrepancy of CIR estimates due to different starting points at a first node and a second node.
[0019] Figure 3 is a flow diagram of a process for deriving a secret key in accordance with the present invention.
[0020] Figure 4 is a flow diagram of a process for deriving an encryption key using JRNSO bits in accordance with one embodiment of the present invention.
[0021] Figure 5 is a flow diagram of a process for deriving an encryption key using JRNSO bits in accordance with another embodiment of the present invention.
[0022] Figure 6 is a flow diagram of a process for deriving an encryption key using JRNSO bits in accordance with yet another embodiment of the present invention.
[0023] Figure 7 is a flow diagram of a process for deriving an encryption key using JRNSO bits in accordance with still another embodiment of the present invention.
- 4a -[0024] Figure 8 is a flow diagram of a process for deriving an encryption key using a Diffie-Hellman key derivation algorithm in accordance with the present invention.
- 4a -[0024] Figure 8 is a flow diagram of a process for deriving an encryption key using a Diffie-Hellman key derivation algorithm in accordance with the present invention.
[0025] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0026] Hereafter, the terminology "WTRU" includes but is not limited to a user equipment, a STA, a fixed or mobile subscriber unit, a pager, or any other type of device capable of operating in a wireless environment. When referred to - 4b -hereafter, the terminology "AP" includes but is not limited to a Node-B, a base station, a site controller or any other type of interfacing device in a wireless environment.
[0027] The features of the present invention may be incorporated into an integrated circuit (IC) or be configured in a circuit comprising a multitude of interconnecting components. The present invention may be implemented as digital signal processor (DSP), software, middleware, hardware, applications or future system architecture. The elements may be sub-components of a larger communication system or ASIC and some or all of the processing elements may be shared for other elements.
[0028] In a wireless communication system, while correlated random sources are a priori difficult to produce without prior communication, a wireless channel provides just such a resource in the form of a channel impulse response (CIR). Specifically, in certain communications systems, two communicating parties, (e.g., Alice and Bob), will measure very similar CIR estimates.
Wideband code division multiple access (WCDMA) time division duplex (TDD) systems have this property. On the other hand, any party not physically co-located with Alice and Bob is likely to observe a CIR that has very little correlation with that of Alice and Bob. This difference can be exploited for generation of perfectly secret keys. The channel is the source of JRNSO and the CIR estimations are the samples taken from the channel.
Wideband code division multiple access (WCDMA) time division duplex (TDD) systems have this property. On the other hand, any party not physically co-located with Alice and Bob is likely to observe a CIR that has very little correlation with that of Alice and Bob. This difference can be exploited for generation of perfectly secret keys. The channel is the source of JRNSO and the CIR estimations are the samples taken from the channel.
[0029] A Diffie-Hellman key derivation procedure is explained hereinafter.
Alice and Bob agree to use a prime number p and a base g. Alice chooses a secret integer a, then sends Bob ga modp. Bob chooses a secret integer b, then sends Alice gb modp. Alice computes (gb modp)a modp. Bob computes (ga mod p)b modp. (gb modp)a modp and (ga modp)b modp are the same. As an example, Alice and Bob agree to use a prime number p=23 and base g=3. Alice chooses a secret integer a=6, then sends Bob ga mod p = 36 mod 23 = 16. Bob chooses a secret integer b=15, then sends Alice gb mod p = 315 mod 23 = 12. Alice computes (gb modp)a modp = 126 mod23 = 9. Bob computes (ga modp)b modp p = 1616 mod 23 = 9.
Alice and Bob agree to use a prime number p and a base g. Alice chooses a secret integer a, then sends Bob ga modp. Bob chooses a secret integer b, then sends Alice gb modp. Alice computes (gb modp)a modp. Bob computes (ga mod p)b modp. (gb modp)a modp and (ga modp)b modp are the same. As an example, Alice and Bob agree to use a prime number p=23 and base g=3. Alice chooses a secret integer a=6, then sends Bob ga mod p = 36 mod 23 = 16. Bob chooses a secret integer b=15, then sends Alice gb mod p = 315 mod 23 = 12. Alice computes (gb modp)a modp = 126 mod23 = 9. Bob computes (ga modp)b modp p = 1616 mod 23 = 9.
[0030] Much larger numbers are needed to make this scheme secure. Ifp is a prime number greater than 300 digits, and a and b are greater than 100 digits, it would be practically impossible to attack since such calculations are too resource intensive, (even for the legitimate communicating parties). As such, this prevents such a protocol from being implemented on mobile devices where battery power is limited.
[0031] If one (or both) of the numbers p or g is agreed upon secretly by using JRNSO, this would allow the two communicating nodes to use smaller numbers for a, b, p and/or g, while achieving comparable security. The Diffie-Hellman shared key can either act as the encryption key or be used to encrypt and send the actual encryption key. Smaller numbers used can make the key derivation process less resource intensive, thus allowing it to be used on mobile devices.
[0032] Figure 1 is a block diagram of a system 100 including two communicating entities, (a first node 110 and a second node 150), for deriving JRNSO bits and a secret key in accordance with the present invention. One of the entities may be a WTRU and the other may be an AP. For simplicity, a point-to-point communication system having only two communicating entities 110, 150 is described in Figure 1. However, the present invention may be applied to a point-to-multipoint communication system involving more than two entities.
It should also be noted that the first node and the second node are essentially the same entities including the same elements, but for simplicity, Figure 1 depicts only relevant elements for the first node and the second node, as the first node is assumed to take a lead in generation of the JRNSO bits and a secret key, which will be explained in detail hereinafter.
It should also be noted that the first node and the second node are essentially the same entities including the same elements, but for simplicity, Figure 1 depicts only relevant elements for the first node and the second node, as the first node is assumed to take a lead in generation of the JRNSO bits and a secret key, which will be explained in detail hereinafter.
[0033] In accordance with the present invention, one of the communicating entities takes a lead. It is assumed that the first node 110 takes the lead.
The first node 110 includes a channel estimator 112, a post-processor 114 (optional), an error correction encoder 118, a synchronization code generator 120 (optional), a secret key generator 116 and a multiplexer 122.
The first node 110 includes a channel estimator 112, a post-processor 114 (optional), an error correction encoder 118, a synchronization code generator 120 (optional), a secret key generator 116 and a multiplexer 122.
[0034] The channel estimator 112 of the first node generates a CIR
estimate 113 based on received signals 111 from the second node 150. The channel estimator 152 in the second node 150 also generates a CIR estimate 153 based on transmissions sent by the first node 110. The outputs of the channel estimators 112, 152 are digitized representations of the CIR estimates. Any prior art methods may be used for generating the CIR estimate. For example, the entities 110, 150 may send special signaling or a pilot sequence to the other node for aiding the generation of the CIR estimates. The CIR estimates may be generated and stored in any way including, but not limited to, in a time domain, in a frequency domain or may be represented using an abstract vector space, or the like. The method for generating the CIR estimate and representation scheme should be the same in both the first node 110 and the second node 150.
estimate 113 based on received signals 111 from the second node 150. The channel estimator 152 in the second node 150 also generates a CIR estimate 153 based on transmissions sent by the first node 110. The outputs of the channel estimators 112, 152 are digitized representations of the CIR estimates. Any prior art methods may be used for generating the CIR estimate. For example, the entities 110, 150 may send special signaling or a pilot sequence to the other node for aiding the generation of the CIR estimates. The CIR estimates may be generated and stored in any way including, but not limited to, in a time domain, in a frequency domain or may be represented using an abstract vector space, or the like. The method for generating the CIR estimate and representation scheme should be the same in both the first node 110 and the second node 150.
[0035]
Depending on the implementation, only partial information of the CIR estimate may be reciprocal, and therefore, suitable for generation of a common secret key. For example, the entities 110, 150 may choose to utilize only amplitude/power profile information of the CIR estimate and may ignore the phase information.
Depending on the implementation, only partial information of the CIR estimate may be reciprocal, and therefore, suitable for generation of a common secret key. For example, the entities 110, 150 may choose to utilize only amplitude/power profile information of the CIR estimate and may ignore the phase information.
[0036] The post-processor 114 may optionally process the CIR estimate using prior art methods. The post-processor 114, (such as a low-pass filter or an interpolating filter), removes noise and redundancies. The post-processor 114 is also necessary in the case where the entities are equipped with multiple antennas for multiple-input multiple-output (MIMO) and therefore differences in the number of antennas and antenna patterns may cause the CIR estimates to differ. In this case the entities 110, 150 may have to exchange information about their antenna configuration.
[0037] Because of channel reciprocity, the CIR estimates generated by the first node 110 and the second node 150 are expected to be very similar.
However, there are three main error sources that introduce discrepancies in the CIR
estimates. First, the channel reciprocity assumes simultaneous estimation of the channel at both entities. Differences in the simultaneity result in some difference in channel estimates. Second, the digitized CIR estimates may need to be synchronized with respect to the starting point. For example, if the CIR
estimates are digitized in time domain, the start of the meaningful portion of the CIR estimate may occur at a different place with respect to the reference zero-time in the two entities 110, 150. This problem is illustrated in Figure 2. As another example, if the CIR estimate is stored using frequency domain representation, a different starting frequency/reference phase may be assumed in determining the storage parameters. Third, the CIR estimates also differ due to errors caused by interference which is inherent in wireless communication.
1100381 As to the first source of error, in order to ensure simultaneity in channel estimation, the channel estimation timing may be tied to a specific system time, such as a radio frame or slot boundary. Alternatively, a synchronization signal maybe embedded in the signals, (such as pilot signals), which the entities 110, 150 transmit to support channel estimation.
Synchronization may be obtained from such pilot signal without requiring embedding of a special signal. Alternatively, channel estimation may be performed with reference to an absolute time reference, such as a global positioning system (GPS). Alternatively, a roundtrip delay may be measured and synchronization may be achieved based on this roundtrip delay.
[0039] As to the second source of error, the starting point of the CIR
estimate may be recorded at the first node 110 and transmitted to the second node 150. Alternatively, a special synchronization code, (e.g., comma-free codes), may be used. Since the synchronization problem is typically limited to just a few samples, only a limited performance is needed from such a code. A special synchronization signal related to a common timing source, (e.g., GPS), may be generated by the terminals and the CIR measurement may be made with respect to such a signal. The synchronization problem may be dealt with by processing the CIR in a domain where it is not an issue. For example, provided that phase information is ignored, the synchronization problem is not present in the frequency domain.
[0040]
Depending on the interference level of the channel, the secrecy rate loss may be large or minimal. For example, in a very noisy channel, the phase information may be highly unreliable, thus ignoring it would cause minimal secrecy rate loss.
[0041]
Referring again to Figure 1, the post-processed CIR estimate 115 is fed to the secret key generator 116, the synchronization code generator 118 and the error correction encoder 120. The secret key generator 116 generates a secret key 117 from the CIR estimate 115, which is JRNSO bits.
[0042] The synchronization code generator 120 generates the synchronization signal/code 121 for simultaneity and synchronizing a "starting point." The error correction encoder 118 performs error correction coding on the CIR estimate 115 and generates parity bits 119. The error correction coding may be a block coding or a convolutional coding. The present invention uses systematic error correction coding such that an original message, (i.e., the encoder input which is the CIR estimate 115) is also output from the error correction encoder 118. In accordance with the present invention, only the parity bits 119 are sent to the second node 150 after being multiplexed with the synchronization signal/code 121 by the multiplexer 122. The multiplexed bit stream 123 is sent to the second node 150.
[0043] The second node 150 includes a channel estimator 152, a synchronization bit demodulator 154, a parity bit demodulator 156, a post processor 158 (optional), a synchronization unit 160, an error correction decoder 162 and a secret key generator 164. The channel estimator 152 generates CIR
estimate from received signals 151 transmitted by the first node 110. The CIR
estimate 153 is optionally processed by the post-processor 156 as stated above.
The synchronization bit demodulator 154 demodulates the received signals 151 to recover the synchronization signal/code 155. The parity bit demodulator 156 demodulates the received signals 151 to recover the parity bits 157. The synchronization signal/code 155 is fed to the synchronization unit 160 and the parity bits 157 are fed to the error correction decoder 162. The post-processed CIR 159 is processed by the synchronization unit 160. The synchronization unit 160 corrects the discrepancy between the CIR estimates due to the lack of simultaneity and/or the misalignment of the starting point in accordance with the synchronization signal/code 155.
[0044] The error correction decoder 162 performs error correction decoding while treating the CIR estimate 159 processed by the synchronization unit 160 as a message part of the codeword, which possibly contains errors and uses the received parity bits 157 to correct the errors. If the block code is well chosen, the output 163 of the error correction decoder 162 is identical to the CIR
estimate generated by the first node 110 with very high probability. Thus, the first node 110 and the second node 150 succeed in obtaining the same data sequence while publicly revealing only some portion of it, (i.e., the parity bits), and may derive the same JRNSO bits.
[0045] The error correction decoder 162 may be used to support synchronization of the starting point of the digitized CIR estimate. The second node 150 generates a set of CIR estimates and decodes each of the possible CIR
estimates with the parity bits 157. The error correction decoder 162 counts the number of errors in each of the CIR estimates. With very high probability, all but the correct one will result in a very high number of corrections; while the correct one results in a very low number of corrections. In this way the error correction decoding process can support the starting point synchronization.
[0046] Once the CIR estimates have been aligned between the first node 110 and the second node 150, the secret key generator 164 generates a secret key 165 which is same to the secret key 117 generated by the first node 110.
[0047] Figure 3 is a flow diagram of a process 300 for deriving JRNSO bits and a secret key for wireless communication in accordance with the present invention. The first node generates a CIR estimate from transmissions sent by the second node and the second node generates a CIR estimate from transmissions sent by the first node (step 302). In order to correct a discrepancy between the CIR estimate generated by the first node and the CIR estimate generated by the second node, (and optionally to support synchronization of the CIR estimates), the first node sends parity bits (and optionally a synchronization signal/code) to the second node (step 304). The parity bits are generated by error correction coding on the CIR estimate generated by the first node. The second node synchronizes the CIR estimate generated by the second node to the CIR
estimate generated by the first node by using a synchronization signal/code sent by the first node or using some other schemes stated above (step 306). The second node then corrects a discrepancy between the synchronized CIR estimate and the CIR estimate generated by the first node by performing error correction decoding on the synchronized CIR estimate with the parity bits (step 308). Steps 302-may be repeated several times. In this way, the first node and the second node can obtain the same CIR estimate (JRNSO bits). The first node and the second node then generate a secret key from the same CIR estimate (step 310).
[0048] Figure 4 is a flow diagram of a process 400 for deriving an encryption key using JRNSO bits in accordance with one embodiment of the present invention. Once a WTRU is associated to an AP at step 402, it is determined whether the authentication type supported by the wireless network is IEEE802.1x or PSK (step 404). If IEEE 802.1x is supported, an authentication, authorization, and accounting (AAA) server and the WTRU authenticate each other using digital certificates (step 406). As part of the authentication signaling, the WTRU sends the AAA server a secret encrypted using a public key of the AAA server such that only the AAA server can decrypt it using a corresponding private key. This secret is used as a seed for deriving the encryption key. The AAA server then sends the secret to the AP (step 408). If the supported authentication type is PSK, the PSK is set as a default secret (step 410).
[0049] The AP
and the WTRU generate JRNSO bits using the process described hereinbefore (step 412). It should be noted that the JRNSO bits may be generated at any step before generation of the encryption key, not just after the secret has been forwarded. The AP and the WTRU derive an encryption key using the secret and the JRNSO bits (step 414). The AP and the WTRU then exchange a portion of the encryption key to confirm the key and identity (step 416). Group keys may be derived and sent to the WTRU using the encryption key as the PTK as done currently in IEEE 802.11i (step 418).
[0050] In the event that sufficient JRNSO bits have not been generated by the time the encryption key is ready to be derived, the process according to the IEEE 802.11i standard may be followed. It should be noted that steps 402-410 are necessary for the initial derivation and the encryption key update or refresh can be performed only by deriving new JRNSO bits.
[0051] For updating keys, in the case of 802.1x, a new secret may be exchanged and new JRNSO bits may be generated, or alternatively, new JRNSO
bits with the old secret may be used. Only the second option is available for the PSK case. Historical information may be used to authenticate JRNSO bits. Both parties may cache some pre-agreed portions of earlier keys. An attacker cannot simply decrypt the master secret using the stolen private key, but must also guess the previous keys derived.
[0052] This process explicitly separates the roles of authentication and key generation in the system. The AAA server deals only with authenticating the client while the AP deals with key generation. This is different from IEEE
802.1x where the AAA server is involved both in key derivation and authentication.
JRNSO allows a new and fresh encryption key to be derived every few hundredths of a second (depending on channel conditions) dynamically. This is different from prior art where key updates are pre-programmed and are not cryptographically fresh and where to generate a fresh key a new secret has to be exchanged. There is no MK or PMK in the process 400 of the present invention.
Thus, the process is simpler than the prior art.
[0053] = In existing 802.11i protocols, an attacker who gains knowledge of authentication credentials (in case of 802.1x) or the PSK (in case of PSK
authentication) has to merely eavesdrop on the signaling exchanges to gain knowledge of the encryption keys. In contrast, while using the method of the present invention, an attacker who possesses the authentication credentials, (e.g., digital certificates or PSK), will be unable to derive the encryption keys as he does not share the same channel that the WTRU and the AP share and hence cannot make the same JRNSO bits.
[0054] Under current IEEE 802 standards, a key update is not really cryptographically secure because only the PTK changes but the MK and the PMK
remain the same. As the PTK is just the PMK plus random information exchanged in the clear if an attacker guesses the PMK, updating keys does not serve any cryptographic purpose. The master secret used to derive the MK and then the PMK serves a cryptographic purpose and is consequently very long (e.g., 48 bytes). Thus, for a fresh key in IEEE 802.11i, it is necessary to exchange a long 48 byte number that has been derived truly randomly (which is resource intensive). However, according to the present invention, the secret exchanged serves to authenticate the secret key derived from the JRNSO bits and thus only need be long enough to prevent brute force attacks (e.g., about 16 bytes).
This makes it feasible to generate it afresh every time a key needs to be updated with JRNSO. The present invention provides a simpler key derivation method with only one short secret exchanged and one set of keys derived, instead of one long key exchanged and 3 sets of keys derived, (i.e., MK, PMK and PTK). This enables power savings on a mobile device.
[0055] Figure 5 is a flow diagram of a process 500 for deriving an encryption key using JRNSO bits in accordance with another embodiment of the present invention. The process 500 is similar to process 400. Steps 502-512 are the same as steps 402-412 and, therefore, will not be explained for simplicity.
After the secret is forwarded to the AP and JRNSO bits are generated, the AP
and the WTRU derive a PMK using the secret and the JRNSO bits (step 514).
Group keys are then derived and sent to the WTRU as done currently in IEEE
802.11i (step 516).
[0056] Figure 6 is a flow diagram of a process 600 for deriving an encryption key using JRNSO bits in accordance with yet another embodiment of the present invention. Once a WTRU is associated to an AP at step 602, it is determined whether the authentication type supported by the wireless network is IEEE802.1x or PSK (step 604). If IEEE 802.1x is supported, an AAA server and the WTRU authenticate each other using digital certificates and exchange a master secret (step 606). The AAA server and the WTRU drive an MK using the master secret (step 608). The AAA server and the WTRU then derive a PMK
from the MK and the AAA server sends this PMK to the AP (step 610). If the supported authentication type is PSK, the PSK is set as a PMK (step 611).
[0057] The AP
and the WTRU generate JRNSO bits using the process described hereinbefore (step 612). It should be noted that the JRNSO bits may be generated at any step before generation of the encryption key, not just after the PMK is derived. It may be carried out prior to deriving the PMK (in the case of 802.1x) to speed up the key derivation process. It may also be done during the 4-way handshake process for deriving the PTK. This will allow the system to be compatible with PSK authentication. The parity checks may also be carried out at any time prior to deriving the PTK.
[0058] The AP
and the WTRU derive a PTK using the PMK and the JRNSO bits (step 614). The PTK may be derived as follows:
PTK = PRF (PMK, Info in the clear, JRNSO bits).
Group keys are then derived and exchanged as done currently in IEEE 802.11i (step 616).
[0059] Figure 7 is a flow diagram of a process 700 for deriving an encryption key using JRNSO bits in accordance with yet another embodiment of the present invention. Once a WTRU is associated to an AP at step 702, it is determined whether the authentication type supported by the wireless network is IEEE802.1x or PSK (step 704). PSK is not supported but only IEEE 802.1x is supported in this embodiment. If PSK is the type supported by the network, the process ends. If IEEE 802.1x is supported, an AAA server and the WTRU
exchange a pre-master secret and the AAA server sends the pre-master secret to the AP (step 706).
[0060] The WTRU
and the AP derive an MK using the pre-master secret and JRNSO bits (step 710). Then the WTRU and the AP derive a PMK using the MK and the JRNSO bits (step 712). The AP and the WTRU derive a PTK using the PMK (step 714). Group keys are then derived and exchanged as done currently in IEEE 802.11i (step 716).
[0061] Figure 8 is a flow diagram of a process 800 for deriving an encryption key using a Diffie-Hellman protocol in accordance with the present invention. A WTRU 802 and an AP 804 agree to use JRNSO for driving a key by exchanging a JRNSO initiation message to an AP and a JRNSO initiation confirmation (steps 812, 814). The WTRU 802 and the AP 804 generate JRNSO
bits based on CIR estimates from transmissions between each other (steps 816, 818). The WTRU 802, (who takes a lead), generates parity bits by performing error correction coding on the generated CIR estimate and sends the parity bits to the AP 804 (step 820). The AP 804 performs error correction decoding using the received parity bits and may optionally send a confirmation (step 822).
The steps 816-822 may be repeated several times.
[0062] The WTRU
802 and the AP 804 have a pre-defined look-up table (LUT) that stores secret numbers p and g (prime numbers) for mapping the JRNSO bits to the p and g values. For example, if the JRNSO measurement generates 5 bits of secret data, the WTRU 802 and the AP 804 can choose one of 16 possible unique values for the prime number p and another 16 values for the base g. It should be noted that other schemes may be used instead of LUT, which is obvious to those skilled in the art. The stored prime numbers should be large but not necessarily as large as in a conventional Diffie-Hellman protocol because of an additional layer of security with p and g secret in accordance with the present invention. The prime numbers should preferably also differ in orders of magnitude so that it is hard for an attacker to guess the range of modulo values.
While the mapping of JRNSO bits to the LUT values can be known publicly, an attacker will not have knowledge of which value was actually picked because the attacker cannot eavesdrop on the JRNSO measurements.
[0063] The WTRU
802 and the AP 804 choose secret integers a and b, respectively, and send ga modp and gb modp to the other party, respectively, and drive b and a, respectively (steps 824, 826). The WTRU 802 and the AP 804 use this to derive a shared secret (step 828). The WTRU and the AP send a JRNSO
key encrypted using the shared secret or use the shared secret as a JRNSO key (step 830).
[0064] Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention.
However, there are three main error sources that introduce discrepancies in the CIR
estimates. First, the channel reciprocity assumes simultaneous estimation of the channel at both entities. Differences in the simultaneity result in some difference in channel estimates. Second, the digitized CIR estimates may need to be synchronized with respect to the starting point. For example, if the CIR
estimates are digitized in time domain, the start of the meaningful portion of the CIR estimate may occur at a different place with respect to the reference zero-time in the two entities 110, 150. This problem is illustrated in Figure 2. As another example, if the CIR estimate is stored using frequency domain representation, a different starting frequency/reference phase may be assumed in determining the storage parameters. Third, the CIR estimates also differ due to errors caused by interference which is inherent in wireless communication.
1100381 As to the first source of error, in order to ensure simultaneity in channel estimation, the channel estimation timing may be tied to a specific system time, such as a radio frame or slot boundary. Alternatively, a synchronization signal maybe embedded in the signals, (such as pilot signals), which the entities 110, 150 transmit to support channel estimation.
Synchronization may be obtained from such pilot signal without requiring embedding of a special signal. Alternatively, channel estimation may be performed with reference to an absolute time reference, such as a global positioning system (GPS). Alternatively, a roundtrip delay may be measured and synchronization may be achieved based on this roundtrip delay.
[0039] As to the second source of error, the starting point of the CIR
estimate may be recorded at the first node 110 and transmitted to the second node 150. Alternatively, a special synchronization code, (e.g., comma-free codes), may be used. Since the synchronization problem is typically limited to just a few samples, only a limited performance is needed from such a code. A special synchronization signal related to a common timing source, (e.g., GPS), may be generated by the terminals and the CIR measurement may be made with respect to such a signal. The synchronization problem may be dealt with by processing the CIR in a domain where it is not an issue. For example, provided that phase information is ignored, the synchronization problem is not present in the frequency domain.
[0040]
Depending on the interference level of the channel, the secrecy rate loss may be large or minimal. For example, in a very noisy channel, the phase information may be highly unreliable, thus ignoring it would cause minimal secrecy rate loss.
[0041]
Referring again to Figure 1, the post-processed CIR estimate 115 is fed to the secret key generator 116, the synchronization code generator 118 and the error correction encoder 120. The secret key generator 116 generates a secret key 117 from the CIR estimate 115, which is JRNSO bits.
[0042] The synchronization code generator 120 generates the synchronization signal/code 121 for simultaneity and synchronizing a "starting point." The error correction encoder 118 performs error correction coding on the CIR estimate 115 and generates parity bits 119. The error correction coding may be a block coding or a convolutional coding. The present invention uses systematic error correction coding such that an original message, (i.e., the encoder input which is the CIR estimate 115) is also output from the error correction encoder 118. In accordance with the present invention, only the parity bits 119 are sent to the second node 150 after being multiplexed with the synchronization signal/code 121 by the multiplexer 122. The multiplexed bit stream 123 is sent to the second node 150.
[0043] The second node 150 includes a channel estimator 152, a synchronization bit demodulator 154, a parity bit demodulator 156, a post processor 158 (optional), a synchronization unit 160, an error correction decoder 162 and a secret key generator 164. The channel estimator 152 generates CIR
estimate from received signals 151 transmitted by the first node 110. The CIR
estimate 153 is optionally processed by the post-processor 156 as stated above.
The synchronization bit demodulator 154 demodulates the received signals 151 to recover the synchronization signal/code 155. The parity bit demodulator 156 demodulates the received signals 151 to recover the parity bits 157. The synchronization signal/code 155 is fed to the synchronization unit 160 and the parity bits 157 are fed to the error correction decoder 162. The post-processed CIR 159 is processed by the synchronization unit 160. The synchronization unit 160 corrects the discrepancy between the CIR estimates due to the lack of simultaneity and/or the misalignment of the starting point in accordance with the synchronization signal/code 155.
[0044] The error correction decoder 162 performs error correction decoding while treating the CIR estimate 159 processed by the synchronization unit 160 as a message part of the codeword, which possibly contains errors and uses the received parity bits 157 to correct the errors. If the block code is well chosen, the output 163 of the error correction decoder 162 is identical to the CIR
estimate generated by the first node 110 with very high probability. Thus, the first node 110 and the second node 150 succeed in obtaining the same data sequence while publicly revealing only some portion of it, (i.e., the parity bits), and may derive the same JRNSO bits.
[0045] The error correction decoder 162 may be used to support synchronization of the starting point of the digitized CIR estimate. The second node 150 generates a set of CIR estimates and decodes each of the possible CIR
estimates with the parity bits 157. The error correction decoder 162 counts the number of errors in each of the CIR estimates. With very high probability, all but the correct one will result in a very high number of corrections; while the correct one results in a very low number of corrections. In this way the error correction decoding process can support the starting point synchronization.
[0046] Once the CIR estimates have been aligned between the first node 110 and the second node 150, the secret key generator 164 generates a secret key 165 which is same to the secret key 117 generated by the first node 110.
[0047] Figure 3 is a flow diagram of a process 300 for deriving JRNSO bits and a secret key for wireless communication in accordance with the present invention. The first node generates a CIR estimate from transmissions sent by the second node and the second node generates a CIR estimate from transmissions sent by the first node (step 302). In order to correct a discrepancy between the CIR estimate generated by the first node and the CIR estimate generated by the second node, (and optionally to support synchronization of the CIR estimates), the first node sends parity bits (and optionally a synchronization signal/code) to the second node (step 304). The parity bits are generated by error correction coding on the CIR estimate generated by the first node. The second node synchronizes the CIR estimate generated by the second node to the CIR
estimate generated by the first node by using a synchronization signal/code sent by the first node or using some other schemes stated above (step 306). The second node then corrects a discrepancy between the synchronized CIR estimate and the CIR estimate generated by the first node by performing error correction decoding on the synchronized CIR estimate with the parity bits (step 308). Steps 302-may be repeated several times. In this way, the first node and the second node can obtain the same CIR estimate (JRNSO bits). The first node and the second node then generate a secret key from the same CIR estimate (step 310).
[0048] Figure 4 is a flow diagram of a process 400 for deriving an encryption key using JRNSO bits in accordance with one embodiment of the present invention. Once a WTRU is associated to an AP at step 402, it is determined whether the authentication type supported by the wireless network is IEEE802.1x or PSK (step 404). If IEEE 802.1x is supported, an authentication, authorization, and accounting (AAA) server and the WTRU authenticate each other using digital certificates (step 406). As part of the authentication signaling, the WTRU sends the AAA server a secret encrypted using a public key of the AAA server such that only the AAA server can decrypt it using a corresponding private key. This secret is used as a seed for deriving the encryption key. The AAA server then sends the secret to the AP (step 408). If the supported authentication type is PSK, the PSK is set as a default secret (step 410).
[0049] The AP
and the WTRU generate JRNSO bits using the process described hereinbefore (step 412). It should be noted that the JRNSO bits may be generated at any step before generation of the encryption key, not just after the secret has been forwarded. The AP and the WTRU derive an encryption key using the secret and the JRNSO bits (step 414). The AP and the WTRU then exchange a portion of the encryption key to confirm the key and identity (step 416). Group keys may be derived and sent to the WTRU using the encryption key as the PTK as done currently in IEEE 802.11i (step 418).
[0050] In the event that sufficient JRNSO bits have not been generated by the time the encryption key is ready to be derived, the process according to the IEEE 802.11i standard may be followed. It should be noted that steps 402-410 are necessary for the initial derivation and the encryption key update or refresh can be performed only by deriving new JRNSO bits.
[0051] For updating keys, in the case of 802.1x, a new secret may be exchanged and new JRNSO bits may be generated, or alternatively, new JRNSO
bits with the old secret may be used. Only the second option is available for the PSK case. Historical information may be used to authenticate JRNSO bits. Both parties may cache some pre-agreed portions of earlier keys. An attacker cannot simply decrypt the master secret using the stolen private key, but must also guess the previous keys derived.
[0052] This process explicitly separates the roles of authentication and key generation in the system. The AAA server deals only with authenticating the client while the AP deals with key generation. This is different from IEEE
802.1x where the AAA server is involved both in key derivation and authentication.
JRNSO allows a new and fresh encryption key to be derived every few hundredths of a second (depending on channel conditions) dynamically. This is different from prior art where key updates are pre-programmed and are not cryptographically fresh and where to generate a fresh key a new secret has to be exchanged. There is no MK or PMK in the process 400 of the present invention.
Thus, the process is simpler than the prior art.
[0053] = In existing 802.11i protocols, an attacker who gains knowledge of authentication credentials (in case of 802.1x) or the PSK (in case of PSK
authentication) has to merely eavesdrop on the signaling exchanges to gain knowledge of the encryption keys. In contrast, while using the method of the present invention, an attacker who possesses the authentication credentials, (e.g., digital certificates or PSK), will be unable to derive the encryption keys as he does not share the same channel that the WTRU and the AP share and hence cannot make the same JRNSO bits.
[0054] Under current IEEE 802 standards, a key update is not really cryptographically secure because only the PTK changes but the MK and the PMK
remain the same. As the PTK is just the PMK plus random information exchanged in the clear if an attacker guesses the PMK, updating keys does not serve any cryptographic purpose. The master secret used to derive the MK and then the PMK serves a cryptographic purpose and is consequently very long (e.g., 48 bytes). Thus, for a fresh key in IEEE 802.11i, it is necessary to exchange a long 48 byte number that has been derived truly randomly (which is resource intensive). However, according to the present invention, the secret exchanged serves to authenticate the secret key derived from the JRNSO bits and thus only need be long enough to prevent brute force attacks (e.g., about 16 bytes).
This makes it feasible to generate it afresh every time a key needs to be updated with JRNSO. The present invention provides a simpler key derivation method with only one short secret exchanged and one set of keys derived, instead of one long key exchanged and 3 sets of keys derived, (i.e., MK, PMK and PTK). This enables power savings on a mobile device.
[0055] Figure 5 is a flow diagram of a process 500 for deriving an encryption key using JRNSO bits in accordance with another embodiment of the present invention. The process 500 is similar to process 400. Steps 502-512 are the same as steps 402-412 and, therefore, will not be explained for simplicity.
After the secret is forwarded to the AP and JRNSO bits are generated, the AP
and the WTRU derive a PMK using the secret and the JRNSO bits (step 514).
Group keys are then derived and sent to the WTRU as done currently in IEEE
802.11i (step 516).
[0056] Figure 6 is a flow diagram of a process 600 for deriving an encryption key using JRNSO bits in accordance with yet another embodiment of the present invention. Once a WTRU is associated to an AP at step 602, it is determined whether the authentication type supported by the wireless network is IEEE802.1x or PSK (step 604). If IEEE 802.1x is supported, an AAA server and the WTRU authenticate each other using digital certificates and exchange a master secret (step 606). The AAA server and the WTRU drive an MK using the master secret (step 608). The AAA server and the WTRU then derive a PMK
from the MK and the AAA server sends this PMK to the AP (step 610). If the supported authentication type is PSK, the PSK is set as a PMK (step 611).
[0057] The AP
and the WTRU generate JRNSO bits using the process described hereinbefore (step 612). It should be noted that the JRNSO bits may be generated at any step before generation of the encryption key, not just after the PMK is derived. It may be carried out prior to deriving the PMK (in the case of 802.1x) to speed up the key derivation process. It may also be done during the 4-way handshake process for deriving the PTK. This will allow the system to be compatible with PSK authentication. The parity checks may also be carried out at any time prior to deriving the PTK.
[0058] The AP
and the WTRU derive a PTK using the PMK and the JRNSO bits (step 614). The PTK may be derived as follows:
PTK = PRF (PMK, Info in the clear, JRNSO bits).
Group keys are then derived and exchanged as done currently in IEEE 802.11i (step 616).
[0059] Figure 7 is a flow diagram of a process 700 for deriving an encryption key using JRNSO bits in accordance with yet another embodiment of the present invention. Once a WTRU is associated to an AP at step 702, it is determined whether the authentication type supported by the wireless network is IEEE802.1x or PSK (step 704). PSK is not supported but only IEEE 802.1x is supported in this embodiment. If PSK is the type supported by the network, the process ends. If IEEE 802.1x is supported, an AAA server and the WTRU
exchange a pre-master secret and the AAA server sends the pre-master secret to the AP (step 706).
[0060] The WTRU
and the AP derive an MK using the pre-master secret and JRNSO bits (step 710). Then the WTRU and the AP derive a PMK using the MK and the JRNSO bits (step 712). The AP and the WTRU derive a PTK using the PMK (step 714). Group keys are then derived and exchanged as done currently in IEEE 802.11i (step 716).
[0061] Figure 8 is a flow diagram of a process 800 for deriving an encryption key using a Diffie-Hellman protocol in accordance with the present invention. A WTRU 802 and an AP 804 agree to use JRNSO for driving a key by exchanging a JRNSO initiation message to an AP and a JRNSO initiation confirmation (steps 812, 814). The WTRU 802 and the AP 804 generate JRNSO
bits based on CIR estimates from transmissions between each other (steps 816, 818). The WTRU 802, (who takes a lead), generates parity bits by performing error correction coding on the generated CIR estimate and sends the parity bits to the AP 804 (step 820). The AP 804 performs error correction decoding using the received parity bits and may optionally send a confirmation (step 822).
The steps 816-822 may be repeated several times.
[0062] The WTRU
802 and the AP 804 have a pre-defined look-up table (LUT) that stores secret numbers p and g (prime numbers) for mapping the JRNSO bits to the p and g values. For example, if the JRNSO measurement generates 5 bits of secret data, the WTRU 802 and the AP 804 can choose one of 16 possible unique values for the prime number p and another 16 values for the base g. It should be noted that other schemes may be used instead of LUT, which is obvious to those skilled in the art. The stored prime numbers should be large but not necessarily as large as in a conventional Diffie-Hellman protocol because of an additional layer of security with p and g secret in accordance with the present invention. The prime numbers should preferably also differ in orders of magnitude so that it is hard for an attacker to guess the range of modulo values.
While the mapping of JRNSO bits to the LUT values can be known publicly, an attacker will not have knowledge of which value was actually picked because the attacker cannot eavesdrop on the JRNSO measurements.
[0063] The WTRU
802 and the AP 804 choose secret integers a and b, respectively, and send ga modp and gb modp to the other party, respectively, and drive b and a, respectively (steps 824, 826). The WTRU 802 and the AP 804 use this to derive a shared secret (step 828). The WTRU and the AP send a JRNSO
key encrypted using the shared secret or use the shared secret as a JRNSO key (step 830).
[0064] Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention.
Claims (19)
1. A method for deriving an encryption key for securing wireless communications, the method comprising:
a wireless transmit/receive unit (WTRU) obtaining an association to an access point (AP);
the WTRU determining a secret that complies with a supported authentication type;
the WTRU generating a channel impulse response (CIR) estimate based upon a signal received from the AP;
the WTRU correcting errors in the CIR estimate and generating parity bits by performing error correction coding on the CIR estimate;
the WTRU multiplexing the parity bits with a synchronization code to generate a multiplexed bit stream;
the WTRU transmitting the multiplexed bit stream to the AP;
the WTRU generating joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR estimate;
the WTRU deriving a pairwise master key (PMK) using the secret and the JRNSO
bits; and the WTRU deriving a pairwise transient key (PTK) using the PMK and the JRNSO
bits.
a wireless transmit/receive unit (WTRU) obtaining an association to an access point (AP);
the WTRU determining a secret that complies with a supported authentication type;
the WTRU generating a channel impulse response (CIR) estimate based upon a signal received from the AP;
the WTRU correcting errors in the CIR estimate and generating parity bits by performing error correction coding on the CIR estimate;
the WTRU multiplexing the parity bits with a synchronization code to generate a multiplexed bit stream;
the WTRU transmitting the multiplexed bit stream to the AP;
the WTRU generating joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR estimate;
the WTRU deriving a pairwise master key (PMK) using the secret and the JRNSO
bits; and the WTRU deriving a pairwise transient key (PTK) using the PMK and the JRNSO
bits.
2. The method of claim 1 further comprising:
receiving a group key from the AP, wherein the group key is derived from one of the PMK and the PTK.
receiving a group key from the AP, wherein the group key is derived from one of the PMK and the PTK.
3. The method of claim 1 wherein the determining a secret includes:
on a condition that the supported authentication type is not pre-shared key (PSK), authenticating with an authentication server and reporting the secret to the authentication server; and on a condition that the supported authentication type is based on a PSK, setting the PSK as one of the secret, the master key, and the PMK.
on a condition that the supported authentication type is not pre-shared key (PSK), authenticating with an authentication server and reporting the secret to the authentication server; and on a condition that the supported authentication type is based on a PSK, setting the PSK as one of the secret, the master key, and the PMK.
4. The method of claim 1 further comprising generating other JRNSO bits for updating the encryption key, whereby a new encryption key is generated by using new JRNSO bits and the encryption key is one of the secret, the master key, the PMK, and the PTK.
5. The method of claim 1 further comprising reporting a portion of an encryption key to the AP to confirm the encryption key, wherein the encryption key is one of the secret, the master key, the PMK, and the PTK.
6. The method of claim 1, wherein the determining the secret includes determining a second pairwise master key (PMK) by:
on a condition that the supported authentication type is not a pre-shared key (PSK) type:
authenticating with an authentication server, reporting a master secret to the authentication server, and deriving the second PMK from the master secret;
on a condition that the supported authentication type is PSK, using a preshared key (PSK) as the second PMK; and using the second PMK as the secret.
on a condition that the supported authentication type is not a pre-shared key (PSK) type:
authenticating with an authentication server, reporting a master secret to the authentication server, and deriving the second PMK from the master secret;
on a condition that the supported authentication type is PSK, using a preshared key (PSK) as the second PMK; and using the second PMK as the secret.
7. The method of claim 6 further comprising receiving a group key from the AP, wherein the group key is derived from one of the second PMK and the PTK.
8. The method of claim 3 further comprising receiving a group key from the AP, wherein the group key is derived from one of the PMK and the PTK.
9. A wireless transmit/receive unit (WTRU) for deriving an encryption key for securing wireless communications, the WTRU comprising:
a memory, the memory being electronically coupled to a processor;
a transceiver electronically coupled to the processor;
the processor configured to:
report a secret to an authentication server;
generate a channel impulse response (CIR) estimate of a communication received from an access point (AP);
correct errors in the coir estimate and generate parity bits by performing error correction coding on the CIR estimate;
multiplex the parity bits with a synchronization code to generate a multiplexed bit stream;
instruct the transceiver to transmit the multiplexed bit stream to the AP;
generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR estimate;
derive a pairwise master key (PMK) using the secret and the JRNSO bits; and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
a memory, the memory being electronically coupled to a processor;
a transceiver electronically coupled to the processor;
the processor configured to:
report a secret to an authentication server;
generate a channel impulse response (CIR) estimate of a communication received from an access point (AP);
correct errors in the coir estimate and generate parity bits by performing error correction coding on the CIR estimate;
multiplex the parity bits with a synchronization code to generate a multiplexed bit stream;
instruct the transceiver to transmit the multiplexed bit stream to the AP;
generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR estimate;
derive a pairwise master key (PMK) using the secret and the JRNSO bits; and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
10. The WTRU of claim 9 wherein the WTRU is configured to receive a group key from the AP, wherein the group key is derived from one of the PMK and the PTK.
11. The WTRU of claim 9 wherein the WTRU is configured to authenticate using IEEE 802.1x authentication.
12. The WTRU of claim 9 wherein a the WTRU is configured to authenticate using pre-shared key (PSK) authentication, and to use a PSK as the secret.
13. The WTRU of claim 9 wherein the WTRU is configured to report a portion of the encryption key to the AP to confirm the encryption key.
14. A wireless transmit/receive unit (WTRU) for deriving an encryption key for securing wireless communications, the WTRU comprising:
a memory operatively connected to a processor;
a transceiver electronically coupled to the processor;
the processor configured to:
report a master secret to an authentication server;
generate a channel impulse response (CIR) estimate of a communication received from an access point (AP);
correct errors in the CIR estimate and generate parity bits by performing error correction coding on the CIR estimate;
multiplex the parity bits with a synchronization code to generate multiplexed bit stream;
instruct the transceiver to transmit the multiplexed bit stream to the AP;
generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR estimate;
derive a pairwise master key (PMK) from the master secret and the JRNSO
bits; and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
a memory operatively connected to a processor;
a transceiver electronically coupled to the processor;
the processor configured to:
report a master secret to an authentication server;
generate a channel impulse response (CIR) estimate of a communication received from an access point (AP);
correct errors in the CIR estimate and generate parity bits by performing error correction coding on the CIR estimate;
multiplex the parity bits with a synchronization code to generate multiplexed bit stream;
instruct the transceiver to transmit the multiplexed bit stream to the AP;
generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected CIR estimate;
derive a pairwise master key (PMK) from the master secret and the JRNSO
bits; and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
15. The WTRU of claim 14 wherein the WTRU is configured to receive a group key from the AP, wherein the group key is derived from one of the PMK or the PTK.
16. The WTRU of claim 14 wherein the WTRU is configured to authenticate using IEEE 802.1x authentication.
17. The WTRU of claim 14 wherein the WTRU is configured to authenticate using pre-shared key (PSK) authentication, whereby the PSK is set to one of the secret, the master key, and the PMK.
18. A wireless transmit/receive unit (WTRU) for deriving an encryption key for securing wireless communications, the WTRU comprising:
a memory operatively connected to a processor;
a transceiver operatively coupled to the processor;
the processor configured to:
report a pre-master secret to an authentication server;
generate a channel impulse response (CIR) estimate of a communication received from an access point (AP);
correct errors in the CIR estimate and generate parity bits by performing error correction coding on the CIR estimate;
multiplex the parity bits with a synchronization code to generate a multiplexed bit stream;
instruct the transceiver to transmit the multiplexed bit stream to the AP;
generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected estimate;
derive a master key from the pre-master secret and the JRNSO bits;
derive a pairwise master key (PMK) from the master key and the JRNSO bits;
and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
a memory operatively connected to a processor;
a transceiver operatively coupled to the processor;
the processor configured to:
report a pre-master secret to an authentication server;
generate a channel impulse response (CIR) estimate of a communication received from an access point (AP);
correct errors in the CIR estimate and generate parity bits by performing error correction coding on the CIR estimate;
multiplex the parity bits with a synchronization code to generate a multiplexed bit stream;
instruct the transceiver to transmit the multiplexed bit stream to the AP;
generate joint-randomness-not-shared-with-others (JRNSO) bits from the corrected estimate;
derive a master key from the pre-master secret and the JRNSO bits;
derive a pairwise master key (PMK) from the master key and the JRNSO bits;
and derive a pairwise transient key (PTK) using the PMK and the JRNSO bits.
19. The WTRU of claim 18 wherein the WTRU is configured to receive a group key from the AP, wherein the group key is derived from one of the PMK and the PTK.
Applications Claiming Priority (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US64748205P | 2005-01-27 | 2005-01-27 | |
| US71617705P | 2005-09-12 | 2005-09-12 | |
| US60/716,177 | 2005-09-12 | ||
| US73433105P | 2005-11-07 | 2005-11-07 | |
| US60/734,331 | 2005-11-07 | ||
| US11/318,381 | 2005-12-23 | ||
| US11/318,381 US8280046B2 (en) | 2005-09-12 | 2005-12-23 | Method and system for deriving an encryption key using joint randomness not shared by others |
| PCT/US2006/001839 WO2006081122A2 (en) | 2005-01-27 | 2006-01-19 | Method and system for deriving an encryption key using joint randomness not shared by others |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2596067A1 CA2596067A1 (en) | 2006-08-03 |
| CA2596067C true CA2596067C (en) | 2013-09-17 |
Family
ID=36740955
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2596067A Expired - Fee Related CA2596067C (en) | 2005-01-27 | 2006-01-19 | Method and system for deriving an encryption key using joint randomness not shared by others |
Country Status (9)
| Country | Link |
|---|---|
| EP (1) | EP1847060A4 (en) |
| JP (1) | JP4734344B2 (en) |
| KR (3) | KR20110076992A (en) |
| CN (1) | CN101951383B (en) |
| CA (1) | CA2596067C (en) |
| MX (1) | MX2007009063A (en) |
| NO (1) | NO20074210L (en) |
| TW (2) | TWI378701B (en) |
| WO (1) | WO2006081122A2 (en) |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7991160B2 (en) | 2006-04-18 | 2011-08-02 | Interdigital Technology Corporation | Method and system for securing wireless communications |
| TW200816768A (en) * | 2006-09-21 | 2008-04-01 | Interdigital Tech Corp | Group-wise secret key generation |
| EP2074740B1 (en) | 2006-10-12 | 2017-03-01 | InterDigital Technology Corporation | A method and system for enhancing cryptographic capabilities of a wireless device using broadcasted random noise |
| GB2447674B (en) * | 2007-03-21 | 2011-08-03 | Lancaster University | Generation of a cryptographic key from device motion |
| US10091648B2 (en) * | 2007-04-26 | 2018-10-02 | Qualcomm Incorporated | Method and apparatus for new key derivation upon handoff in wireless networks |
| WO2009014063A1 (en) * | 2007-07-20 | 2009-01-29 | Nec Corporation | Encrypted communication method and encrypted communication system |
| US9198033B2 (en) * | 2007-09-27 | 2015-11-24 | Alcatel Lucent | Method and apparatus for authenticating nodes in a wireless network |
| EP2223459B1 (en) * | 2007-11-06 | 2011-05-18 | Interdigital Patent Holdings, Inc. | Method and apparatus for enabling physical layer secret key generation |
| EP2294751A1 (en) * | 2008-05-12 | 2011-03-16 | Interdigital Patent Holdings, Inc. | Information-theoretically secure secrecy generation |
| WO2010006035A2 (en) * | 2008-07-08 | 2010-01-14 | Interdigital Patent Holdings, Inc. | Support of physical layer security in wireless local area networks |
| FR2976431B1 (en) * | 2011-06-07 | 2014-01-24 | Commissariat Energie Atomique | SECRET KEY GENERATION METHOD FOR WIRELESS COMMUNICATION SYSTEM |
| KR101269026B1 (en) * | 2011-12-21 | 2013-05-29 | 한국전자통신연구원 | Apparatus and method for group key generation using wireless channel status |
| US10614099B2 (en) | 2012-10-30 | 2020-04-07 | Ubiq Security, Inc. | Human interactions for populating user information on electronic forms |
| US20140269362A1 (en) * | 2013-03-15 | 2014-09-18 | Shahrnaz Azizi | Techniques to Update a Wireless Communication Channel Estimation |
| US9124580B1 (en) * | 2014-02-07 | 2015-09-01 | The Boeing Company | Method and system for securely establishing cryptographic keys for aircraft-to-aircraft communications |
| DE102014208965A1 (en) | 2014-05-13 | 2015-11-19 | Robert Bosch Gmbh | Method for authenticating a network participant and network participant, network and computer program for this purpose |
| DE102014209046A1 (en) | 2014-05-13 | 2015-11-19 | Robert Bosch Gmbh | A method for generating a secret, cryptographic key in a mobile terminal |
| DE102014208975A1 (en) | 2014-05-13 | 2015-11-19 | Robert Bosch Gmbh | A method for generating a key in a network and subscribers to a network and network |
| DE102014208974A1 (en) | 2014-05-13 | 2015-11-19 | Robert Bosch Gmbh | Method for determining information about the distance between two devices and devices and computer programs set up for this purpose |
| DE102014208964A1 (en) | 2014-05-13 | 2015-11-19 | Robert Bosch Gmbh | Method for generating a key in a network as well as network subscribers established for this purpose |
| DE102014217320A1 (en) | 2014-08-29 | 2016-03-03 | Robert Bosch Gmbh | Method for generating a cryptographic key in a device and device set up for this purpose |
| DE102014217330A1 (en) | 2014-08-29 | 2016-03-03 | Robert Bosch Gmbh | Method for comparing information between devices and device set up for this purpose |
| SG11201808317XA (en) | 2014-09-23 | 2018-10-30 | Fhoosh Inc | Secure high speed data storage, access, recovery, and transmission |
| US10579823B2 (en) | 2014-09-23 | 2020-03-03 | Ubiq Security, Inc. | Systems and methods for secure high speed data generation and access |
| DE102015215569A1 (en) | 2015-08-14 | 2017-02-16 | Robert Bosch Gmbh | Method for generating a secret between subscribers of a network and subscribers of the network established for this purpose |
| CN109417469B (en) * | 2015-10-16 | 2021-09-07 | 华为技术有限公司 | MIMO system secure pairing method |
| DE102015225220A1 (en) | 2015-12-15 | 2017-06-22 | Robert Bosch Gmbh | Method for generating a secret sequence of values in a device depending on measured physical properties of a transmission channel |
| DE102015225222A1 (en) | 2015-12-15 | 2017-06-22 | Robert Bosch Gmbh | Method for generating a secret sequence of values in a device depending on measured physical properties of a transmission channel |
| FR3046315B1 (en) * | 2015-12-29 | 2018-04-27 | Thales | METHOD FOR UNIVALENT AND UNIVERSAL EXTRACTION OF KEYS FROM THE PROPAGATION CHANNEL |
| KR20180097903A (en) | 2017-02-24 | 2018-09-03 | 삼성전자주식회사 | Apparatus and method for generating secure key in wireless communication system |
| US11349656B2 (en) * | 2018-03-08 | 2022-05-31 | Ubiq Security, Inc. | Systems and methods for secure storage and transmission of a data stream |
| GB201817117D0 (en) | 2018-10-19 | 2018-12-05 | Nat Univ Ireland Maynooth | Encryption method |
| EP3697052A1 (en) * | 2019-02-14 | 2020-08-19 | Siemens Aktiengesellschaft | Method and system for transfer of data in a network |
| CN117616718A (en) * | 2021-07-16 | 2024-02-27 | 高通股份有限公司 | Key verification in wireless communications |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0301282A1 (en) * | 1987-07-31 | 1989-02-01 | BBC Brown Boveri AG | Signal transmission method |
| US5450456A (en) * | 1993-11-12 | 1995-09-12 | Daimler Benz Ag | Method and arrangement for measuring the carrier frequency deviation in a multi-channel transmission system |
| EP0767543A3 (en) * | 1995-10-06 | 2000-07-26 | Siemens Aktiengesellschaft | Code division multiplex communication with interference suppression |
| US5745578A (en) * | 1996-06-17 | 1998-04-28 | Ericsson Inc. | Apparatus and method for secure communication based on channel characteristics |
| JP2006180549A (en) * | 2002-02-28 | 2006-07-06 | Matsushita Electric Ind Co Ltd | Communication apparatus and communication method |
| JP2004032679A (en) * | 2002-02-28 | 2004-01-29 | Matsushita Electric Ind Co Ltd | Communication apparatus and communication system |
| JP2003273856A (en) * | 2002-03-14 | 2003-09-26 | Communication Research Laboratory | Communication apparatus and communication method |
| JP4245972B2 (en) * | 2002-05-29 | 2009-04-02 | Ｎｔｔエレクトロニクス株式会社 | Wireless communication method, wireless communication device, communication control program, communication control device, key management program, wireless LAN system, and recording medium |
| US7587598B2 (en) * | 2002-11-19 | 2009-09-08 | Toshiba America Research, Inc. | Interlayer fast authentication or re-authentication for network communication |
| JP2004187197A (en) * | 2002-12-06 | 2004-07-02 | Doshisha | Radio communication system, radio communication method and radio station |
| JP2004208073A (en) * | 2002-12-25 | 2004-07-22 | Sony Corp | Radio communication system |
| JP2005130127A (en) * | 2003-10-22 | 2005-05-19 | Sumitomo Electric Ind Ltd | Confidential communication method and communication terminal |
| US7505596B2 (en) * | 2003-12-05 | 2009-03-17 | Microsoft Corporation | Automatic detection of wireless network type |
| CN1993923A (en) * | 2004-07-29 | 2007-07-04 | 松下电器产业株式会社 | Wireless communication apparatus and wireless communication method |
| RU2007104173A (en) * | 2004-08-04 | 2008-08-10 | Мацусита Электрик Индастриал Ко., Лтд. (Jp) | RADIO COMMUNICATION DEVICE, RADIO COMMUNICATION SYSTEM AND RADIO COMMUNICATION METHOD |
| CN1993925A (en) * | 2004-08-04 | 2007-07-04 | 松下电器产业株式会社 | Radio communication method, radio communication system, and radio communication device |
-
2006
- 2006-01-19 KR KR1020117010823A patent/KR20110076992A/en not_active Application Discontinuation
- 2006-01-19 KR KR1020077018514A patent/KR101253370B1/en not_active IP Right Cessation
- 2006-01-19 WO PCT/US2006/001839 patent/WO2006081122A2/en active Application Filing
- 2006-01-19 MX MX2007009063A patent/MX2007009063A/en not_active Application Discontinuation
- 2006-01-19 CN CN2010102981704A patent/CN101951383B/en not_active Expired - Fee Related
- 2006-01-19 EP EP06718847A patent/EP1847060A4/en not_active Withdrawn
- 2006-01-19 CA CA2596067A patent/CA2596067C/en not_active Expired - Fee Related
- 2006-01-19 JP JP2007553138A patent/JP4734344B2/en not_active Expired - Fee Related
- 2006-01-19 KR KR1020077018125A patent/KR101011470B1/en not_active IP Right Cessation
- 2006-01-20 TW TW095102241A patent/TWI378701B/en not_active IP Right Cessation
- 2006-01-20 TW TW095128389A patent/TWI404393B/en not_active IP Right Cessation
-
2007
- 2007-08-16 NO NO20074210A patent/NO20074210L/en not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| EP1847060A2 (en) | 2007-10-24 |
| NO20074210L (en) | 2007-10-24 |
| CN101951383B (en) | 2013-06-19 |
| JP4734344B2 (en) | 2011-07-27 |
| JP2008529413A (en) | 2008-07-31 |
| TW200723818A (en) | 2007-06-16 |
| TW200633460A (en) | 2006-09-16 |
| KR20070096008A (en) | 2007-10-01 |
| TWI378701B (en) | 2012-12-01 |
| TWI404393B (en) | 2013-08-01 |
| EP1847060A4 (en) | 2011-09-14 |
| KR20110076992A (en) | 2011-07-06 |
| MX2007009063A (en) | 2007-10-02 |
| KR101253370B1 (en) | 2013-04-11 |
| KR101011470B1 (en) | 2011-01-28 |
| WO2006081122A3 (en) | 2007-11-22 |
| WO2006081122A2 (en) | 2006-08-03 |
| CN101951383A (en) | 2011-01-19 |
| KR20070088821A (en) | 2007-08-29 |
| CA2596067A1 (en) | 2006-08-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2596067C (en) | Method and system for deriving an encryption key using joint randomness not shared by others | |
| US8280046B2 (en) | Method and system for deriving an encryption key using joint randomness not shared by others | |
| US9130693B2 (en) | Generation of perfectly secret keys in wireless communication networks | |
| Zhang et al. | Design of an OFDM physical layer encryption scheme | |
| US20070036353A1 (en) | Authentication and encryption methods using shared secret randomness in a joint channel | |
| Toorani et al. | An elliptic curve-based signcryption scheme with forward secrecy | |
| KR20110117169A (en) | Identity based authenticated key agreement protocol | |
| JP2014509094A (en) | System and method for securing wireless communication | |
| Yao et al. | Post Quantum KEM authentication in SPDM for secure session establishment | |
| Hwang et al. | A Key management for wireless communications | |
| Mulkey et al. | Towards an efficient protocol for privacy and authentication in wireless networks | |
| de Ree et al. | Grain-128PLE: generic physical-layer encryption for IoT networks | |
| Lavanya et al. | Privacy Preserving Physical Layer Authentication Scheme for LBS based Wireless Networks | |
| Xu et al. | Anti-Quantum Certificateless Group Authentication for Massive Accessing IoT devices | |
| JARECKI | Password Authenticated Key Exchange: Protocols and Security Models | |
| Lim et al. | Secure deniable authenticated key establishment for internet protocols | |
| Patrick | Wireless LAN Security |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20190121 |