WO2012112124A1 - Terminal de communication et procédé permettant d'établir une communication - Google Patents

Terminal de communication et procédé permettant d'établir une communication Download PDF

Info

Publication number
WO2012112124A1
WO2012112124A1 PCT/SG2012/000045 SG2012000045W WO2012112124A1 WO 2012112124 A1 WO2012112124 A1 WO 2012112124A1 SG 2012000045 W SG2012000045 W SG 2012000045W WO 2012112124 A1 WO2012112124 A1 WO 2012112124A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication terminal
communication
message
key
msg
Prior art date
Application number
PCT/SG2012/000045
Other languages
English (en)
Inventor
Chee Ming Joseph TEO
Original Assignee
Agency For Science, Technology And Research
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Agency For Science, Technology And Research filed Critical Agency For Science, Technology And Research
Publication of WO2012112124A1 publication Critical patent/WO2012112124A1/fr

Links

Classifications

    • 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
    • H04L9/0844—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 with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • 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/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/3271—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 using challenge-response
    • H04L9/3273—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 using challenge-response for mutual authentication
    • 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/047—Key management, e.g. using generic bootstrapping architecture [GBA] without using a trusted network node as an anchor
    • H04W12/0471—Key exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • 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

Definitions

  • the IEEE . 802.16n System Requirements Document specifies a requirement for High Reliability (HR) network.
  • HR High Reliability
  • one of the requirements is for the mobile stations (HR-MSs) to communicate directly with each other in the event of network failure.
  • the HR-MS to HR-MS direct communications scenario could for example occur in the event of a disaster where the backbone network is destroyed.
  • the rescue teams e.g. firemen and police officers
  • a communication terminal of a cellular mobile communication system comprising the communication terminal, another communication terminal and a communication network for providing a communication connection between the
  • the communication terminal comprising a determiner configured to determine an encryption key for secure communication between the communication terminal and the other
  • Figure 1 shows a communication terminal according to an
  • Figure 2 shows a flow diagram according to an embodiment.
  • FIG. 3 shows a communication system according to an
  • Figure 4 shows a message flow diagram according to an
  • Figure 5 shows a flow diagram according to an embodiment.
  • Figure 6 shows a communication arrangement according to an embodiment .
  • Figure 7 shows a message flow diagram according to an
  • Figure 8 shows a flow diagram according to an embodiment.
  • Figure 9 shows a communication arrangement according to an embodiment .
  • Figure 10 shows a message flow diagram according to an
  • Figure 11 shows a flow diagram according to an embodiment.
  • Figure 12 shows a flow diagram according to an embodiment.
  • Figure 13 shows a message flow diagram according to an
  • Figure 14 shows a flow diagram according to an embodiment.
  • Figure 15 shows a message flow diagram according to an
  • Figure 16 shows a message flow diagram according to an
  • a communication terminal as illustrated in figure 1 is provided.
  • Figure 1 shows a communication terminal 101 according to an embodiment .
  • the communication terminal 101 is a (mobile) communication terminal of a cellular mobile communication system 100.
  • the cellular mobile communication system 100 comprises the communication terminal 101, another communication terminal 102 and a communication network 103 for providing a
  • the communication terminal 101 comprises a determiner 105 configured to determine an encryption key for secure
  • the communication terminal 101 further comprises a
  • transceiver 106 configured to perform secure communication with the other communication terminal 101 via the radio interface 107 between the communication terminal 101 and the other communication terminal 102 using the determined encryption key.
  • a communication terminal of a cellular mobile communication network provides a key for a direct communication between the communication terminal and another communication terminal, i.e. a
  • the communication terminal may perform communication without involvement of the network .side, e.g. without involvement of any base station of the communication network.
  • the communication terminal may
  • This negotiation may also take place via a direct communication.
  • the secure communication is direct communication between the communication terminal and the other communication terminal.
  • the direct communication is communication of data without the data being communicated via a base station of the communication network.
  • Direct communication is for example communication of data without the communication network being involved in the communication .
  • the determiner is configured to determine the encryption key by exchanging messages with the other communication terminal via the radio interface between the communication terminal and the other communication terminal .
  • the messages are exchanged via direct communication between the communication terminal and the other communication terminal.
  • the messages are for example exchanged between the communication terminal and the other communication terminal without being communicated via a base station of the communication network.
  • the messages are for example exchanged between the
  • the communication network is a communication network according to a 802.16 communication standard .
  • the communication network is for example a communication network according to the 802.16 ⁇ communication standard.
  • the transceiver is configured to send a request for a direct communication with the other communication terminal to the communication network or to th other communication terminal.
  • the transceiver may be configured to include a certificate into the request.
  • the transceiver may be configured to include a nonce into th request .
  • the transceiver is configured to receive the encryption key from the communication network or from the other communication terminal and wherein the determiner is configured to determine the encryption key as the received encryption key.
  • the transceiver may for example be configured to receive the encryption key with a message from the communication network or the other communication terminal and is configured to authenticate the message.
  • the transceiver is for example configured to check the message for message freshness.
  • the transceiver may be configured to include a certificate into the request.
  • the transceiver may be configured to include a nonce into th request .
  • the communication terminal is configured to act as a base station of the communication network .
  • the determiner is configured to determine the encryption key based on a pre-shared encryption key which was pre-shared between the communication terminal and the other communication terminal.
  • the communication terminal 100 for example carries out a method as illustrated in figure 2.
  • FIG. 2 shows a flow diagram 200 according to an embodiment.
  • the flow diagram 200 illustrates a method for setting up a communication between a communication terminal of a cellular mobile communication system and another communication terminal of the cellular mobile communication system, the cellular mobile communication system comprising the
  • the other communication terminal and a communication network for providing a communication connection between the communication terminal and the other communication terminal via at least one base station of the communication network.
  • an encryption key for secure communication between the communication terminal and the other communication terminal via a radio interface between the communication terminal and the other communication terminal is determined.
  • secure communication between the communication terminal and the other communication terminal is performed via the radio interface between the communication terminal and the other communication terminal using the determined encryption key.
  • the communication network is for example a communication network according to a 802.16 communication standard.
  • the current 802.16 standards do not provide security protocols for the direct communications scenario.
  • the 802.16 ⁇ SRD System Requirements Document
  • AKE Authenticated Key Exchange
  • HR-MS i.e. mobile stations according to IEEE 802.16 ⁇
  • a node i.e. a mobile stations or a base station
  • a node shall resend a message after timeout if the node did not receive any response to th message.
  • the node shall stop the protocol or initiate another instance of the protocol.
  • Figure 3 shows a communication system 300 according to an embodiment .
  • the communciation system 300 comprises a first mobile
  • HR-MSl HR-MSl
  • HR-MS2 second mobile terminal
  • communication network also referred to as network side of the
  • a communication system 300 comprising a base station (also referred to as HS-BS) 303 and a backbone network 304.
  • the communication system 300 is for example a communication system according to a 802.16 standard, i.e. a IEEE 802.16 standard .
  • the base station 303 provides coverage for the mobile terminals 301, 302 such that the mobile terminals 301, 302 can communicate via the base station 303.
  • HR-MSl 301 wishes to establish a direct communication pre-shared key with HR-MS2 302 so that HR-MSl 301 and HR-MS2 302 can communicate with each other directly in the event of a backbone (i.e. backbone network 304) failure (i.e. in case that there is no HR-BS 103 around to provide a communication connection via the network side) .
  • backbone i.e. backbone network 304
  • FIG. 4 shows a message flow diagram 400 according to an embodiment .
  • the message flow takes plase between a first mobile terminal 401 corresponding to the first mobile terminal 301, a second mobile terminal 402 corresponding to the second mobile terminal 302 and a base station 403 corresponding to the base station 303.
  • Figure 5 shows a flow diagram 500 according to an embodiment.
  • Step 501 HR-MS1 selects a nonce ⁇ R-MSI, computes
  • MAC C ACI refers to the MAC (Message Authentication Code) generated by MSI using its CMAC key (i.e. CMAC1) .
  • MAC CMA c2 refers to the MAC (Message Authentication Code) generated by MSI using its CMAC key (i.e. CMAC1) .
  • MAC DCMAC refers to the MAC (Message
  • Step 502 HR-BS 503 checks TH R _]V[S]_ , I% _MS1 f° r message
  • HR-BS selects l% R _ B g, computes
  • HR-MS2 402 selects 3 ⁇ 4 -MS2'
  • N HR _ BS and sends, in 408, a DC_REPLY_MSG#3 message 409 to HR-BS 403 to inform HR-BS 403 of its decision to directly communication with HR-MSl 401.
  • HR - MS2 ⁇ HR - BS DC_REPLY_MSG#3 (3)
  • DC_REPLY_MSG#3 " DC_REPLY_MSG "
  • DC_REPLY_MSG " DC_REPLY_OK” if HR-MS2 402 agrees for
  • R-BS' MAC CMAC1 ("DC_REPLY_NOK_BS"
  • HR-BS 403 also encrypts EH R _MS2 KEK( DMK ' key_lifetime,
  • HR-MSl 401 first checks 3 ⁇ 4 _ B g' , R-BS' and N HR-MS1 f° r freshness and 6HR_ B S' for message authentication. If the verifications are correct, then HR-MSl decrypts
  • E HR _ M si ⁇ (° ⁇ ' key_lifetime, HR - MSlAddr, HR - MS2Addr) and obtains DMK and its lifetime key_lifetime .
  • HR-MS2 first checks T HR _ BS ' ' , N HR _ BS and N HR _ MS2 for freshness and 0HR_ B g ' ' for message authentication. If the verifications are correct, then HR-MS2 decrypts E HR-MS2 ⁇ (° ⁇ ' key_lifetime, HR - MS2Addr, HR - MSlAddr) and obtains DMK ⁇ and its lifetime key_lifetime .
  • the three protocols are designed to address the three scenarios, namely 1) PKI scenario (figure 6, 7 and 8), where it is assumed each HR-MS has a digital certificate to assist in the AKE protocol, 2) HR-MS convert to HR-BS* scenario (figures 9, 10 and 11), which covers the multimode HR-mode capabilities and 3) Pre-shared key scenario (figures 6, 16 and 12), where it is assumed that HR-MS1 and HR-MS2 shares a key prior to direct
  • all messages have a MaxResends and a Message Timeout.
  • a node e.g. a HR-MS or a HR-BS
  • the node resends its message. If the MaxResends number is reached for the message then it initiates another round of authentication or drops the direct communication.
  • Figure 6 shows a communication arrangement 600 according to an embodiment .
  • the communciation system 600 comprises a first mobile
  • HR-MS1 also referred to as HR-MS1
  • HR-MS2 second mobile terminal
  • a communication network also referred to as network side of the
  • a communication system 600 comprising a base station (also referred to as HS-BS) 603 and a backbone network 604.
  • HS-BS base station
  • the communication system 600 is for example a communication system according to a IEEE 802.16 standard.
  • the base station 603 provides coverage for the mobile terminals 601, 602 such that the mobile terminals 601, 602 can communicate via the base station 603. .
  • the base station 603 is not available for providing communication between the mobile terminals 601, 602.
  • the backbone network 604 has failed.
  • each. mobile terminal 601, 602 has a digital certificate issued by a certification authority for mutual authentication and key exchange .
  • Figure 7 shows a message flow diagram 700 according to an embodiment.
  • the message flow takes plase between a first mobile terminal 701 corresponding to the first mobile terminal 601 and a second mobile terminal 702 corresponding to the second mobile terminal 602.
  • Figure 8 shows a flow diagram 800 according to an embodiment.
  • Step 801 HR-MS1 701 first generates a nonce ⁇ R - MSI ⁇ Next, HR-MS1 701, in 703, computes the signature
  • HR—MSI S I GN ( T HR-MS1 I N HR-MS1 I HR " MS2Addr
  • Step 802 HR-MS2 702 first verifies the received timestamp and nonce for freshness and the certificate Cert(HR - MSI) and signature —MSI ⁇ n 706.
  • HR-MS2 If the verifications are correct, then HR-MS2 generates a nonce % R _
  • [s2 and DMK and computes DAK Dotl6KDF( DMK, HR - MSlAddr I HR - MS2Addr
  • "DAK", 160) and the DCMAC Dotl 6KDF(DAK, "DCMAC_KEYS” , 128) and
  • DTEK DOT16KDF(DAK, "DTEK_KEY”, 128)
  • HR-MS2 uses HR-MSl's public key to encrypt and obtain EHR - MSI K(° MK ' key_lifetime, HR - MSlAddr, HR - MS2Addr) .
  • DirectComms_KeyAgreement_MSG_#2 is also known as
  • Step 803 HR-MSl 701 first verifies the received timestamp and nonces for freshness and the certificate Cert(HR - MS2 ) and signature C3 ⁇ 4R - MS2 ⁇ n 711. If the verifications are
  • HR-MS1 PK( DMK ' key_lifetime, HR - MSlAddr, HR - MS2Addr) and obtains DMK and key_lifetime .
  • HR-MSl 701 computes DAK, DCMAC and DTEK and verifies 0 HR _ MS2 in 712 and 713. If the verification is correct, then HR-MSl 701 computes
  • DirectComms_KeyAgreement_MSG_#3 is also known as
  • Step 804 HR-MS2 702 receives the
  • DirectComms_KeyAgreement_MSG_#3 message 715 verifies the received nonce and the CMAC tuple in 716. If the verification is correct, then HR-MS2 702 confirms that HR-MSl 701 has computed the correct keys and commences secure direct
  • Table 8 DirectComms_KeyAgreement_MSG_#2 message attribute T HR-MS2 Tiraestamp generated by HR-MS2.
  • HR-MS2 i also known as HR_MS2_Timestamp in P802.16n (802.16e based) and also known as Timestamp HR-MS2 in P802.16.1a (802.16m based)
  • HR - MSlAddr, HR - MS2Addr can also be written as Encrypted DMK in P802.16n (802.16e based) and P802.16.1a (802.16m based)
  • HR-MS2_CMAC %R-MS2 Message digest calculated using DCMAC key by HR-MS2. 6>HR-MS2 is also known as HR- MS2_CMAC in P802.16n (802.16e based) and also known as
  • CT HR-MS2 Signature of message generated by HR-MS2 using its RSA private key diR_][g2 is also known as sigHR-MS2 in P802.16n (802.16e based) and P802.16.1a (802.16m based) .
  • Cert(HR-MS2) is also known as HR-MS2_Certificate in P802.16n (802.16e based) and P802.16.1a
  • Figure 9 shows a communication arrangement 900 according to an embodiment .
  • the communciation system 900 comprises a first mobile
  • HR-MS1 also referred to as HR-MS1
  • HR-MS2 second mobile terminal
  • communication network also referred to as network side of the
  • a communication system 900 comprising a base station (also referred to as HS-BS) 903 and a backbone network 904.
  • a base station also referred to as HS-BS
  • the communication system 900 is for example a communication system according to a IEEE 802.16 standard.
  • the base station 903 provides coverage for the mobile terminals 901, 902 such that the mobile terminals 901, 902 can communicate via the base station 903.
  • the base station 903 is not available for providing communication between the mobile terminals 901, 902.
  • the backbone network 904 has failed.
  • HR-MS1 converts to a base station (referred to as HR-BS*) 905 in order to
  • Figure 10 shows a message flow diagram 1000 according to an embodiment .
  • the message flow takes plase between a first mobile terminal 1001 corresponding to the first mobile terminal 901 which is converted to a base station HR-BS* and a second mobile terminal 1002 corresponding to the second mobile terminal 902.
  • Figure 11 shows a flow diagram 1100 according to an
  • Step 1101 The first mobile terminal 901 converts to HR-BS* 905, 1001.
  • Step 1102 In 1003, the transformed HR-BS* 1001 sends a
  • DirectComms_KeyAgreement_MSG_#l message 1004 to HR-MS2 1002: HR - BS* ⁇ HR - MS2 : DirectComms_KeyAgreement_MSG_#1 (10) where DirectComms_KeyAgreement_MSG_#l Cert(HR -BS*).
  • Step 1103 HR-MS2 1002 first verifies the certificate
  • HR-MS2 generates a nonce %R_]V[S2.
  • HR-MS2 1002 computes the signature
  • Step 1104 HR-BS* 1001 first verifies the received timestamp and nonce for freshness and certificate Cert(HR - MS2 ) and
  • HR-BS* 1001 generates a nonce 1% R _ B 5* an DMK and computes
  • DAK Dotl 6KDF( DMK, HR - BS * Addr
  • DTEK DOT16KDF(DAK, "DTEK_KEY”, 128)
  • 6HR-BS* MAC DCMAC (N HR _ BS *
  • HR-MS2Addr HR-BS* 1001 then uses HR-MS2 ' s 1002 public key to encrypt and obtain EH R _iY[g2 PK(DMK,
  • Step 1105 HR-MS2 1002 first verifies the received timestamp, nonce and signature ⁇ 3 ⁇ 4R-BS* . If the verifications are
  • HR-MS2 1102 computes DAK, DCMAC key and DTEK and verifies 0HR - B S * ⁇ I F the verification is correct, then HR-MS2 1102 can compute
  • E HR-MS2 MAC DCMAC( N HR-MS2 I N HR-BS* I HR ⁇ MS2Addr
  • Step 1106 HR-BS* 1001 receives the
  • DirectComms_KeyAgreement_MSG_#4 message 1010 verifies the received nonce and CMAC tuple. If the verification are:
  • HR-BS* 1001 confirms that HR-MS2 1002 has computed the correct keys and commences secure direct
  • the message flow takes plase between a first mobile terminal 1601 corresponding to the first mobile terminal 601 and a second mobile terminal 1602 corresponding to the second
  • Figure 12 shows a flow diagram 1200 according to an
  • DCMAC Dotl 6KDF(DAK, "DCMAC_KEYS", 128)
  • R-MS1 MAC DCMAC( N HR- S1 I DMK_Sequence_No
  • DTEK DOT16KDF(DAK, "DTEK_KEY", 128) .
  • HR-MSl 1601 sends, in 1604, a
  • DirectComms_KeyAgreement_MSG_#l N HR _ MS] _
  • DirectComms_KeyAgreement_MSG_#l 1605 is also known as Peer_KeyAgreement_MSG_#l in P802.16.1a
  • Step 1202 In 1606, HR-MS2 1602 first verifies that the
  • received nonce is fresh and, in 1607, uses the shared DMK and computes
  • DAK Dotl 6KDF(DMK, HR - MSlAddr
  • DCMAC Dotl 6KDF(DAK, "DCMAC_KEYS", 128) ,
  • DTEK DOT16KDF(DAK, "DTEK_KEY”, 128) and uses DCMAC to check ⁇ HR-MSl ⁇ If the verification is correct, HR-MS2 1602 selects 3 ⁇ 4R-MS2 anc computes
  • HR-MS2 1602 sends a
  • DirectComms_KeyAgreement_MSG_#2 1609 is also known as
  • Peer_KeyAgreement_MSG_#2 in P802.16.1a 802.16m based
  • Step 1203 In 1610, HR-MS1 1601 receives the
  • DirectComms_KeyAgreement_MSG_#3 1612 is also known as
  • Peer_KeyAgreement_MSG_#3 in P802.16.1a 802.16m based
  • Step 1204 Upon receiving the DirectComms_KeyAgreement_MSG_#3 message 16012, HR-MS2 1602 checks the received nonces for freshness and 6HR - MS1' in 1613. If the verifications are correct, HR-MS2 1602 applies the negotiated security
  • HR-MSl 1601 which is started in 1614 and 1615. Otherwise, if
  • N HR-MS1 a freshly generated random number of 64 bits. is also known as
  • DAKID identifies the direct communications authorization key
  • DAKID identifies the direct
  • 9HR _MS2 is also known as HR-MS2 CMAC in P802.16n (802.16e based) and also known as CMAC_HR-MS2 in
  • DC_SAID identifies the direct communications authorization key for protecting this message
  • P802.16n (802.16e based) and also known as CMAC_HR-MS1 in
  • the DMK is the security key/pre- established shared key that is randomly generated by HR-BS
  • the DMK is a key (e.g. a 160-bit key) that is randomly generated by HR-BS 303 in the Network-aided Security Procedure described with reference to figures 3, 4 and 5, by HR-MS2 602 in the PKI approach
  • the DMK is delivered by Key Transfer (EAP) messages .
  • the DMK may be used as a source for keying materials required by upper layers.
  • DAK is derived from DMK and belongs to a pair of HR-MSs.
  • the DAK is used for Direct Communications in the event of failure in the backbone.
  • the DAK derivation is for example done as follows:
  • DAK Dotl 6KDF(DMK, HR - MSlAddr
  • HR - MSlAddr and HR - MS2Addr are the addresses of HR-MS1 and HR-MS2 respectively.
  • the DCMAC-DTEK prekey is derived from DAK and is used to derive other keys:
  • the DCMAC-DTEK prekey derivation is done as follows:
  • DCMAC-DTEK prekey Dotl6KDF (DAK, DAK_COUNT
  • the DCMAC key is derived from DAK and used for message authentication for the messages sent during direct
  • DCMAC Dotl6KDF(DAK, "DCMAC_KEYS", 128) (18)
  • DCMAC key Dot16KDF ( DCMAC-DTEK prekey, "DCMAC__KEYS",
  • DTEK is used to transport encryption key used to encrypt data in direct communications.
  • DTEK is for example derived as follows:
  • DTEK Dotl6KDF(DAK, "DTEK KEY" (19)
  • DTEK Dotl6KDF (DCMAC-DTEK prekey
  • DSAID is the security association to which the DTEK belongs .
  • COUNTER_DTEK is a counter used to derive different DTEKs for the same DSAID, the value of the counter is changed everytime a new DTEK needs to be derived within the same DAK and DAK_COUNT pair is valid. Everytime a new DCMAC-DTEK prekey is derived, this counter is reset.
  • the PKM messages in the 802.16m and 802.16e standards are modified to support the direct communication security feature in the 802.16 ⁇ GridMAN
  • PAM Privacy Key Management
  • PAM Privacy Key Management
  • the Privacy Key Management (PKM) messages are located in Section 16.2.3.43 of the 802.16m-2011 standards.
  • the modified Table 726 —AAI-PKM-REQ message field description and Table 727 —AAI-PKM-RSP message field description are according to one embodiment modified as follows:
  • Table 17 Modified Table 726-AAI-PKM-REQ message field description
  • N0NCE_HR-MS1 A random number of 64 bits
  • NONCE_HR-MS2 A random number of 64 bits
  • the receiver shall track PNs Size 16 within this window to
  • Table 18 Modified Table 727 -AAI-PKM-RSP message field description
  • NONCE_HR- 64 A random number of 64 bits MSI used for freshness
  • DAKID 64 communications authorization key
  • NONCE_HR- A random number of 64 bits
  • NONCE_HR- A random number of 64 bits
  • NONCE_HR- A random number of 64 bits
  • NONCE_HR- A random number of 64 bits
  • size of 1 0: size of ICV 32 bits ICV (default; Max
  • the receiver shall track PNs Size 16 within this window to
  • NONCE_HR- A random number of 64 bits
  • NONCE_HR- A random number of 64 bits
  • PLM P802.16n (802.16rev3 baseline) according to one embodiment to support a security procedure for direct communication data security are described.
  • PLM Privacy Key Management
  • a procedure for establishing secure communications between HR-BS in IEEE 802.16n which deals with BS-to-BS security is provided.
  • a secure forwarding of data between HR- infrestructure stations is performed using a Public Key Infrastructure (PKI) .
  • PKI Public Key Infrastructure
  • HR-infrastructure stations e.g. HR-BS
  • HR-BS HR-infrastructure stations
  • a Public Key Infrastructure e.g. HR-BS
  • Each HR-BS has a public/private key pair and digital certificate (e.g. X.509) issued by a certification authority for mutual
  • FIG. 13 shows a message flow diagram 1300 according to an embodiment .
  • the message flow takes place between a first base station 1301 which is in this example a degraded HR-BS and is
  • HR-BSd a second base station 1302 which is referred to as HR-BS.
  • Figure 14 shows a flow diagram 1400 according to an
  • Step 1401 Prior to secure connection establishment, the degraded HR-BS (HR-BSd) 1301 generates a nonce NONCE_HR-BSd .
  • BStoBS_KeyAgreement_MSG_#l Timestamp_HR-BSd
  • Step 1402 The HR-BS 1302 first verifies the received
  • "B2AK" , 160) and the B2CMAC key and CMAC_HR-BS MAC B2CMAC (NONCE_HR-BS
  • CMAC_HR-BS) and sends, in 1309, a BStoBS_KeyAgreement_MSG_#2 message 1310 to HR-BSd, where BStoBS_KeyAgreement_MSG_#2 T HR - B s I NONCE_HR-BS I HR-BSd MAC Addr I HR-BS MAC Addr
  • Step 1403 The HR-BSd 1301 in 1311 first verifies the
  • BStoBS_KeyAgreement_MSG_#3 NONCE_HR-BS
  • HR-BSd 1301 reaches its maximum number of resends, it initiates another authentication or drop the request.
  • Step 1404 The HR-BS 1302 receives the BStoBS_KeyAgreement_MSG_#3 message 1315 and in 1316 verifies the received nonce and the CMAC tuple. If the verification fails, then HR-BS ignores BStoBS_KeyAgreement_MSG_#3 message. 1315. If . the verification is correct, -then the HR-BS 1302 confirms that HR-BSd 1301 has computed the correct keys and commences secure direct communications. If the HR-BS 1302 does not receive the BStoBS_KeyAgreement_MSG_#3 message 1414 from the HR-BSd 1301 within BStoBS_KeyAgreement_MSG_#2
  • Timeout it shall resend the BStoBS_KeyAgreement_MSG_#2 message up to BStoBS_KeyAgreement_MSG_#2 MaxResends times. If the HR-BS 1302 reaches its maximum number of resends, it shall initiate another authentication or drop the request.
  • the HR-BSd 1301 and the HR-BS 1302 can now, in 1317 and 1318, derive B2TEK and commence secure connection establishment.
  • the messages 1305, 1310 and 1315 are in one embodiment for example formed according to the following tables 20 to 23.
  • Table 20 Secure forwarding between HR-infrastructure stations using Public Key Infrastructure message type
  • a BS to BS communications security context according to one embodiment is described that describes the set of parameters that links the BS to BS security keys for secure forwarding between HR-infrastructure stations.
  • the B2MK context includes all parameters associate with the B2MK. This context is created when the B2MK is derived.
  • the B2MK context according to one embodiment is described in Table 24.
  • the B2AK context includes all parameters associate with the B2AK. This context is created whenever a new B2AK is derived. According to one embodiment, this context is deleted when the B2AK is not in used.
  • the B2AK context according to one embodiment is described in Table 25.
  • B2AKID 64 Identifies the B2AK key.
  • B2CMAC_KEY 128 Key which is used for signing BS- to-BS Communications MAC control messages.
  • B2CMAC_PN 24 Used to avoid BS-to-BS
  • B2CMAC_PN The initial value of B2CMAC_PN is zero .
  • B2AK_COUNT 16 Counter to ensure freshness of computed B2CMAC key and prevent replay attacks.
  • the B2SA context is the set of parameters managed by each B2SA in order to ensure B2TEK management and usage in a secure way for secure forwarding between HR-infrastructure stations.
  • the B2SA holds the B2TEK context and additional information that belongs to the B2SA itself.
  • the B2TEK context includes all parameters of the B2TEK.
  • the B2TEK context according to one embodiment is described in Table 26.
  • B2TEK_PN 22 The PN used for encrypting BS-to- BS communication packets. After each BS-to-BS communication MAC PDU transmission, the value shall be increased by 1. (0x000000- OxlFFFFF)
  • Table 27 The B2SA context according to one embodiment is described in Table 27.
  • the key hierarchy defines what keys are present in the system for secure forwarding between HR-infrastructure stations and how the keys are generated.
  • the B2MK is the security key that is randomly generated by HR-BS.
  • the B2M is a 160-bit key.
  • the B2MK may be used as a source for keying materials required by upper layers.
  • the B2MK is used to derive the BS-to-BS Communication
  • B2AK Authentication Key
  • B2AK is derived from B2MK and belongs -to a pair of HR-BSs (HR-BSd and HR-BS) .
  • the B2AK is used for secure forwarding between HR-infrastructure stations.
  • the B2AK derivation is as follows :
  • B2AK Dot16KDF (B2MK, HR-BSd MAC Addr
  • HR-BSd MAC Addr and HR-BS MAC Addr are the addresses of HR-BSd and HR-BS respectively.
  • the B2CMAC-B2TEK prekey is derived from B2AK and is used to derive other keys:
  • B2CMAC Authentication Code
  • B2CMAC-B2TEK prekey Dot16KDF (B2AK, B2AK_COUN
  • the B2CMAC key is derived from B2AK and used for message authentication for the messages sent during secure forwarding between HR-infrastructure stations.
  • the B2CMAC key is derived as follows:
  • B2CMAC key Dotl6KDF (B2CMAC-B2TEK prekey, "B2CMAC_KEYS” , 128)
  • B2TEK is the transport encryption key used to encrypt data in secure forwarding between HR-infrastructure stations.
  • B2SAID is the security association to which the B2TEK belongs .
  • COUNTER_B2TEK is a counter used to derive different B2TEKs for the same B2SAID, the value of the counter is changed every time a new B2TEK needs to be derived within the same B2AK and B2AK_COUNT pair is valid. Every time a new B2CMAC- B2TEK prekey is derived, this counter is reset. Another example for a security authorization and key exchange is described in the following with reference to figure 15.
  • Figure 15 shows a message flow diagram 1500 according to an embodiment .
  • the message flow takes plase between a first mobile terminal 1501 for example corresponding to the first mobile terminal 301, a second mobile terminal 1502 for example corresponding to the second mobile terminal 302 and a base station 1503 for example corresponding to the base station 303.
  • HR-BS 1503 sends the security key DMK in 1504 and 1505 to the first HR-MS .1501 and the second HR-MS 1502 (which are assumed to have requested direct communication) with a Key-Transfer- MSG#1 message 1506 and a Key-Transfer-MSG#2 message 1507 (e.g. AAI-PKM-RSP messages).
  • the HR-MSs 1501, 1502 carry out a 3-way Direct Communications Key Agreement process in 1508 to 1517 in which they exchange key agreement messages DirectComms_KeyAgreement_MSG_#l (AAI-PKM-RSP MAC Control Message) 1518, DirectComms_KeyAgreement_MSG_#2 (AAI- PKM-REQ MAC Control Message) 1519 and
  • DirectComms_KeyAgreement_MSG_#3 (AAI-PKM-RSP MAC Control Message) 1520.
  • both HR-MS1 1501 and HR-MS2 1502 are able to commence secure direct communications and proceed to the Flow Setup phase.
  • FIG. 15 can be seen as a first part including the DMK being sent from the HR-BS 1502 to the HR-MS1 1501 and HR-MS2 1502 and a second part
  • HR-MS converts to HR-BS* (Multimode) .
  • HR-BS base station
  • DMK Direct Communication Master Key
  • the first autonomous AKE solution includes a PKI approach, whereby each HR-MS possess a digital certificate which can be used for mutual authentication and key exchange for data security in direct communications between two HR-MSs without backbone network.
  • the second autonomous AKE solution can be used in the event where one HR-MS converts into a Base Station (denoted as HR- BS*) when there is no backbone network (i.e. no HR-BS) in the environment.
  • the third autonomous AKE solution is used in the event where two HR-MSs that wishes to establish direct communications with each other autonomously have already established a pre-shared key DMK using the network- aided AKE protocol described above.

Abstract

La présente invention se rapporte à un terminal de communication d'un système de communication mobile cellulaire, le système de communication mobile cellulaire comprenant le terminal de communication, un autre terminal de communication et un réseau de communication pour établir une connexion de communication entre le terminal de communication et l'autre terminal de communication par l'intermédiaire d'au moins une station de base du réseau de communication, le terminal de communication comprenant un dispositif de détermination configuré pour déterminer une clé de cryptage pour sécuriser la communication entre le terminal de communication et l'autre terminal de communication par l'intermédiaire d'une interface radio entre le terminal de communication et l'autre terminal de communication ; et un émetteur-récepteur configuré pour établir une communication sécurisée avec l'autre terminal de communication par l'intermédiaire de l'interface radio entre le terminal de communication et l'autre terminal de communication à l'aide de la clé de cryptage déterminée.
PCT/SG2012/000045 2011-02-15 2012-02-14 Terminal de communication et procédé permettant d'établir une communication WO2012112124A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
SG201101079-0 2011-02-15
SG2011010790 2011-02-15
SG2011051794 2011-07-18
SG201105179-4 2011-07-18
SG201108175-9 2011-11-04
SG2011081759 2011-11-04

Publications (1)

Publication Number Publication Date
WO2012112124A1 true WO2012112124A1 (fr) 2012-08-23

Family

ID=46672846

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2012/000045 WO2012112124A1 (fr) 2011-02-15 2012-02-14 Terminal de communication et procédé permettant d'établir une communication

Country Status (1)

Country Link
WO (1) WO2012112124A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107800539A (zh) * 2016-09-05 2018-03-13 华为技术有限公司 认证方法、认证装置和认证系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060087999A1 (en) * 2004-10-22 2006-04-27 Alcatel Method of authenticating a mobile network node in establishing a peer-to-peer secure context between a pair of communicating mobile network nodes

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060087999A1 (en) * 2004-10-22 2006-04-27 Alcatel Method of authenticating a mobile network node in establishing a peer-to-peer secure context between a pair of communicating mobile network nodes

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GUPTA ET AL.: "Decentralized key generation scheme for cellular-based heterogeneous wireless ad hoc networks", JOURNAL OF PARALLEL AND DISTRIBUTED COMPUTING, vol. 67, no. 9, September 2007 (2007-09-01), pages 981 - 991 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107800539A (zh) * 2016-09-05 2018-03-13 华为技术有限公司 认证方法、认证装置和认证系统
EP3493462A4 (fr) * 2016-09-05 2019-06-05 Huawei Technologies Co., Ltd. Procédé d'authentification, appareil d'authentification et système d'authentification
CN107800539B (zh) * 2016-09-05 2020-07-24 华为技术有限公司 认证方法、认证装置和认证系统
US10742418B2 (en) 2016-09-05 2020-08-11 Huawei Technologies Co., Ltd. Authentication method, authentication apparatus, and authentication system
US11228442B2 (en) 2016-09-05 2022-01-18 Huawei Technologies Co., Ltd. Authentication method, authentication apparatus, and authentication system

Similar Documents

Publication Publication Date Title
CN108650227B (zh) 基于数据报安全传输协议的握手方法及系统
KR100704675B1 (ko) 무선 휴대 인터넷 시스템의 인증 방법 및 관련 키 생성방법
US8285990B2 (en) Method and system for authentication confirmation using extensible authentication protocol
Simon et al. The EAP-TLS authentication protocol
US8001381B2 (en) Method and system for mutual authentication of nodes in a wireless communication network
US7707412B2 (en) Linked authentication protocols
US9392453B2 (en) Authentication
KR100923176B1 (ko) 무선 네트워크에 보안성을 제공하기 위한 시스템 및 방법
CN101616410B (zh) 一种蜂窝移动通信网络的接入方法和系统
US8959333B2 (en) Method and system for providing a mesh key
Cam-Winget et al. The flexible authentication via secure tunneling extensible authentication protocol method (EAP-FAST)
EP3213488A1 (fr) Authentification de couche de service de bout en bout
EP2288195A2 (fr) Procédé et appareil de réduction de surcharge pour la vérification de l'intégrité dans un système de communication sans fil
WO2012075825A1 (fr) Procédé de configuration de sécurité pour une station dans un réseau local sans fil, ap, sta, as et système
RU2509445C2 (ru) Способ и устройство для уменьшения служебных данных для проверки целостности данных в беспроводной системе связи
Alhakami et al. A secure MAC protocol for cognitive radio networks (SMCRN)
Sigholt et al. Keeping connected when the mobile social network goes offline
WO2012112124A1 (fr) Terminal de communication et procédé permettant d'établir une communication
CN109905345B (zh) 通信方法、通信装置和通信设备
Zhou et al. Tunnel Extensible Authentication Protocol (TEAP) Version 1
Sithirasenan et al. EAP-CRA for WiMAX, WLAN and 4G LTE Interoperability
CN115314278B (zh) 可信网络连接身份认证方法、电子设备及存储介质
EP1722503A1 (fr) Méthode utlisée par un point de accès d'un réseau sans fils LAN et appareil associé
Siddiqui et al. Security analysis of the WiMAX technology in Wireless Mesh networks
Kucharzewski et al. Mobile identity management system in heterogeneous wireless networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12746503

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12746503

Country of ref document: EP

Kind code of ref document: A1