WO2012112124A1 - Communication terminal and method for performing communication - Google Patents

Communication terminal and method for performing 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
French (fr)
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/en

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

A communication terminal of a cellular mobile communication system is described, the cellular mobile communication system comprising the communication terminal, another 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, the communication terminal comprising a determiner configured to determine 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; and a transceiver configured to perform secure communication with the other communication terminal via the radio interface between the communication terminal and the other communication terminal using the determined encryption key.

Description

COMMUNICATION TERMINAL AND METHOD FOR PERFORMING
COMMUNICATION
Field of the invention
Embodiments of the invention generally relate to a
communication terminal and a method for performing
communication .
Background of the invention
The IEEE .802.16n System Requirements Document (SRD) specifies a requirement for High Reliability (HR) network. As such, 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) would have to communicate directly with each other without a backbone network in order to provide disaster recovery.
Summary of the invention
In one embodiment, a communication terminal of a cellular mobile communication system is provided, the cellular mobile communication system comprising the communication terminal, another 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, the communication terminal comprising a determiner configured to determine 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 and a transceiver configured to perform secure communication with the. other communication terminal via the radio interface between the communication terminal and the other
communication terminal using the determined encryption key.
According to another embodiment , a method for performing communication according to the communication terminal
described above is provided.
Short description of the figures
Illustrative embodiments of the invention are explained below with reference to the drawings.
Figure 1 shows a communication terminal according to an
embodiment .
Figure 2 shows a flow diagram according to an embodiment.
Figure 3 shows a communication system according to an
embodiment .
Figure 4 shows a message flow diagram according to an
embodiment .
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
embodiment .
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
embodiment .
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
embodiment .
Figure 14. shows a flow diagram according to an embodiment.
Figure 15 shows a message flow diagram according to an
embodiment .
Figure 16 shows a message flow diagram according to an
embodiment . Detailed description
According to one embodiment., 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
communication connection between the communication terminal and the other communication terminal via at least one base station 104 of the communication network.
The communication terminal 101 comprises a determiner 105 configured to determine an encryption key for secure
communication between the communication terminal 101 and the other communication terminal 102 via a radio interface 107 between the communication terminal 101 and the other
communication terminal 102.
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. .
5
According to one embodiment, in other words, 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
communication without involvement of the network .side, e.g. without involvement of any base station of the communication network. For example, the communication terminal may
negotiate the key with the other communication terminal. This negotiation may also take place via a direct communication.
According to an embodiment the secure communication is direct communication between the communication terminal and the other communication terminal.
According to an embodiment 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 .
According to an embodiment 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 .
According to an embodiment 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
communication terminal and the other communication terminal without the communication network being involved in the exchange of the messages.
According to an embodiment 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.
According to an embodiment 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 .
According to an embodiment 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.
According to an embodiment the transceiver is configured to send a message including the determined encryption key to th communication network or to the 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 .
According to an embodiment the communication terminal is configured to act as a base station of the communication network .
According to an embodiment 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.
Figure 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
communication terminal, 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.
In 201, 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.
In 202, 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.
It should be noted that embodiments described in context of the communication terminal are analogously valid for the method for performing communication and vice versa.
As mentioned above, 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.
According to one embodiment, in order to ensure that an attacker is not able to eavesdrop into the direct communications and/or impersonate a HR-MS (i.e. a mobile terminal) in the network, security protocols for
authentication and key exchange in the 802.16η network are designed. The 802.16η SRD (System Requirements Document) specifies two scenarios for security, namely Network Aided Mutual Authentication of HR-MS and Data Security and
Autonomous (limited) Mutual Authentication of HR-MS and Data Security. for Direct Communications.
In the following AKE (Authenticated Key Exchange) protocols for the Network Aided Mutual Authentication of HR-MS (i.e. mobile stations according to IEEE 802.16η) and Data Security and Autonomous Mutual Authentication of HR-MS and Data
Security for Direct Communications according to various embodiments are described. It should be noted that it is assumed in the examples described below that a node (i.e. a mobile stations or a base station) shall resend a message after timeout if the node did not receive any response to th message. According to one embodiment, once the maximum numbe of resends is reached, then the node shall stop the protocol or initiate another instance of the protocol.
In the following description, a sending operation of a message from a sender to a receiver is written as
sender—» receiver : message
Further, in the description of the content of a message, the symbol |' is used to denote concatenation.
With reference to figures 3, 4 and 5, Network Aided Mutual Authentication of HR-MS and Data Security according to one embodiment is described. Figure 3 shows a communication system 300 according to an embodiment .
The communciation system 300 comprises a first mobile
terminal (also referred to as HR-MSl) 301, a second mobile terminal (also referred to as HR-MS2) 302 and a communication network (also referred to as network side of the
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 . In normal operation, 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.
It is supposd that 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) .
For this, according to one embodiment, the protocol as illustrated in figures 4 and 5 is followed to establish the direct communication pre-shared key DMK . Figure 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.
The various protocol steps are shown in more detail in figure 5. Figure 5 shows a flow diagram 500 according to an embodiment.
Step 501: HR-MS1 selects a nonce ^R-MSI, computes
QHR-MSI = MACCMAC1("DC_REQ_MS" |
THR-MS1 I NHR- S1 I HR ~ MSlAddr | HR - MS2Addr) and sends, in 404, a DC_Request_MSG#l message 405 to HR-BS 503 to request a direct communication pre-shared key DMK to be shared with HR-MS2 502.
HR - MSI → HR - BS : DC_Request_MSG# 1 (1) where
DC Request MSG#1 =
"DC_REQ_MS" I THR_MS1 | NHR_MSi I HR - MSlAddr | HR - MS2Addr | %R-MS1 ·
It should be noted that MACC ACI refers to the MAC (Message Authentication Code) generated by MSI using its CMAC key (i.e. CMAC1) . MACCMAc2 refers to the MAC (Message
Authentication Code) generated by MS2 using its CMAC key (i.e. CMAC2 ) . MACDCMAC refers to the MAC (Message
Authentication Code) generated by MSI and/or using it shared CMAC key (i.e. DCMAC) Step 502: HR-BS 503 checks THR_]V[S]_ , I% _MS1 f°r message
freshness and 0HR_j[gi for message authentication. If the verifications are correct, HR-BS selects l%R_Bg, computes
eHR_BS = MACCMAC2("DC_REQ_BS" I THR_BS I NHR-BS I HR - MSlAddr I HR - MS2Addr) and sends, in 406, a DC_Request_MSG#2 message
407 to HR-MS2 502 to inform HR-MS2 502 of the direct
connection request from HR-MSl 501.
HR — BS —> HR — MS2 : DC_Request_MSG#2 (2) where
DC_Request_MSG#2 =
"DC_REQ_BS" I THR_BS | NHR_BS | HR - MSlAddr | HR - MS2Addr | eHR-BS · Step 503: HR-MS2 402 checks THR_Bs, NHR_BS for message
freshness and 6¾R_Bg for message authentication. If the
verifications are correct, HR-MS2 402 selects ¾ -MS2'
computes
QHR-MS2 =
MACCMAC2("DC_REPLY_MSG" I THR-MS2 I NHR-MS2 I HR ~ MSlAddr |
HR - MS2Addr | NHR_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) where
DC_REPLY_MSG#3 = " DC_REPLY_MSG " | THR_MS2 I NHR_MS2 I HR - MSlAddr | HR - MS2Addr | NHR_BS | 6HR_MS2. Note that
"DC_REPLY_MSG" = " DC_REPLY_OK" if HR-MS2 402 agrees for
direct communications with HR-MSl 401 and "DC REPLY MSG" = "DC_REPLY_NOTOK" if HR-MS2 402 refuses direct communications with HR-MS1 401.
Step 504: HR-BS 403 checks ¾R-MS2' NHR-MS2 f°r message freshness and 6pj _][ s2 for message authentication. If the verifications are correct, HR-BS 403 checks the response from HR-MS2 402. If " DC_REPLY_MSG" = " DC_REPLY_NOTOK " , then the protocol stops and HR-BS selects H _BS' I computes
R-BS' = MACCMAC1("DC_REPLY_NOK_BS" | TH R _ B s' I NHR-BS' I NHR-MSl) and sends, in 410, a DC_REPLY_MSG#4 message 411 to HR-MS1
401:
HR — BS —> HR — MSI : DC REPLY MSG#4 (4) where
DC_REPLY_MSG#4 =
" DC_REPLY_NOK_BS " | THR_BS' I NHR-Bs' I NHR-MS1 I QHR-BS' ·
Otherwise, If "DC_REPLY_MSG" = " DC_REPLY_OK" , then HR-BS 403 generates DMK , selects HR_BS' ar>d encrypts
EHR-MS1 KEK(DMK' key_lifetime, HR - MSlAddr, HR - MS2Addr) and computes
eHR-BS' =
MACCMAC1("DC_REPLY_OK_BS" | THR-BS' I %R-BS' I ¾R-MS1 _ KEK(DMK, key_lifetime, HR - MSlAddr, HR - MS2Addr) | HR - MSlAddr |
HR - MS2Addr | NHR_MS1) and sends, in 410, a DC_REPLY_MSG#5 message 412 to HR-MS1 401:
HR - BS → HR - MSI : DC REPLY MSG#5 (5) where
DC_REPLY_MSG#5 =
"DC_REPLY_OK_BS" | THR_BS' | NHR_Bs' I EHR-MS1 _ ΚΕΚ(°ΜΚ'
key_lifetime, HR - SlAddr, HR - MS2Addr) | HR - MSlAddr |
HR - MS2Addr I NHR_MS1 I R-BS' ·
HR-BS 403 also encrypts EHR_MS2 KEK(DMK' key_lifetime,
HR - MS2Addr, HR - MSlAddr) and computes
Figure imgf000015_0001
MACCMAC2("DC_REPLY_OK_BS" I THR_BS" I NRR-BS I EHR-MS2_KEK(DMK> key_lifetime, HR - MS2Addr, HR - MSlAddr) | HR - MS2Addr |
HR - MSlAddr I NHR_MS2) and sends, in 413, a DC_REPLY_MSG# 6 message 414 to HR-MS2 402:
HR - BS → HR - MS2 : DC_REPLY_MSG# 6 (6) where
DC_REPLY_MSG#6 =
"DC_REPLY_OK_BS" | THR_BS " I %R-BS I EHR-MS2 _ ΚΕΚ(™Κ,
key_lifetime, HR - MS2Addr, HR - MSlAddr) | HR - MS2Addr |
HR - MSlAddr | NHR_MS2 | 6HR_BS ' ' .
Step 505:
a) HR-MSl 401 first checks ¾ _Bg' , R-BS' and NHR-MS1 f°r freshness and 6HR_BS' for message authentication. If the verifications are correct, then HR-MSl decrypts
EHR_Msi ΚΕΚ(°ΜΚ' key_lifetime, HR - MSlAddr, HR - MS2Addr) and obtains DMK and its lifetime key_lifetime . b) HR-MS2 first checks THR_BS ' ' , NHR_BS and NHR_MS2 for freshness and 0HR_Bg ' ' for message authentication. If the verifications are correct, then HR-MS2 decrypts EHR-MS2 ΚΕΚ(°ΜΚ' key_lifetime, HR - MS2Addr, HR - MSlAddr) and obtains DMK ^and its lifetime key_lifetime .
The attributes of the messages 405, 407, 409, 411, 412, 414 are summarized in. the following tables.
Table 1: DC Request_MSG#l message attribute
Notation Meaning
Direct communication request sent from
"DC REQ_MS" HR-MS1
THR-MS1 Timestamp generated by HR-MS1
NHR-MS1 Freshly generated random number of 64bits by HR-MS1
Address of HR-MS1
HR - MSlAddr
Address of HR-MS1
HR - MS2Addr
eHR-MSl Message digest calculated using DCMAC key by HR-MS1
Table 2: DC Request_MSG#2 message attribute
Notation Meaning
Direct communication request sent to HR-
"DC_REQ_BS" MS2 by HR-BS
THR-BS Timestamp generated by HR-BS
NHR-BS Freshly generated random number of 64bits by HR-BS
Address of HR-MS1
HR - MSlAddr
Address of HR-MS2
HR - MS2Addr ®HR-BS Message digest calculated using DGMAC key
by HR-BS
Table 3: DC_REPLY_MSG#3 message attribute
Figure imgf000017_0001
Table 4: DC_REPLY_MSG#4 message attribute for rejection of Direct Communications
Notation Meaning
HR-BS response to HR-MS1 that HR-MS2
"DC_REPLY_NOK_BS " rejected direct communications
THR-BS' Timestamp generated by HR-MS2
NHR-BS' Freshly generated random number of
64bits by HR-MS2
NHR-MS1 Nonce generated by HR-MS1 eHR-BS' Message digest calculated using DCMAC key by HR-BS
Table 5: DC_REPLY_MSG#5 message attribute Acceptance of Direct Communications
Notation Meaning
"DC_REPLY_OK_BS" HR-BS response to HR-MS1 that HR-MS2 accepted direct communications
THR-BS' Timestamp generated by HR- BS
NHR-BS' Freshly
generated random number of 64bits by HR-BS
Encryption of
EHR-MS1 ΚΕΚ(°ΜΚ' key lifetime, HR - MSlAddr, DMK, key lifetime by HR-BS using
HR - MS2Addr)
HR-MSl's KEK
HR - MSlAddr Address of HR- MS1
HR - MS2Addr Address of HR- MS2
NHR-MS1 Nonce generated by HR-MS1
%R-BS' Message digest calculated using DCMAC key by HR- BS Table 6: DC_REPLY_MSG#6 message attribute for Acceptance of Direct Communications
Figure imgf000019_0001
In the following, with reference to figures 6 to 12, three AKE protocols for Mutual Authentication of HR-MS and data security for Direct Communications according to various embodiments are described. 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
communications. It should be noted that according to one embodiment, all messages have a MaxResends and a Message Timeout. When a node (e.g. a HR-MS or a HR-BS) does not receive a response message to a message that it has sent from another node within the Message Timeout time, then 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.
Firstly, the PKI approach according to one embodiment is described with reference to figures 6, 7 and 8.
Figure 6 shows a communication arrangement 600 according to an embodiment .
Similarly to the communication system 300 shown in figure 3, the communciation system 600 comprises a first mobile
terminal (also referred to as HR-MS1) 601, a second mobile terminal (also referred to as HR-MS2) 602 and a communication network (also referred to as network side of the
communication system 600) comprising a base station (also referred to as HS-BS) 603 and a backbone network 604.
The communication system 600 is for example a communication system according to a IEEE 802.16 standard.
In normal operation, 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. .
20
For this embodiment, it is assumed that the base station 603 is not available for providing communication between the mobile terminals 601, 602. For example, the backbone network 604 has failed. In this scenario, it is assumed that 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.
The various protocol steps are shown in more detail in figure 8. 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
AHR—MSI = S I GN(THR-MS1 I NHR-MS1 I HR " MS2Addr | HR - MSlAddr) and sends, in 704, a DirectComms_KeyAgreement_MSG_#l message 705 to HR-MS2 702:
" HR - MSI" → " HR - MS2" : DirectComms_KeyAgreement_MSG_# 1 (7) where
DirectComms_KeyAgreement_MSG_#l =
THR-MS1 I NHR-MS1 I HR ~ MS2Addr | HR - MSlAddr |
GHR-MS1 I Cert(HR - MSI) . DirectComms_KeyAgreement_MSG_#l is .
21 also known as PKIDirectComms_KeyAgreement_MSG_#l in P802.16n (802.16e based) and Peer_KeyAgreement_MSG_#l in P802.16.1a (802.16m based) . 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. 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) and
½R-MS2 =
MACDCMAC(NHR _ MS2 I NHR_MS1 I HR - MS2Addr | HR - MSlAddr) in 707. HR-MS2 then uses HR-MSl's public key to encrypt and obtain EHR - MSI K(°MK' key_lifetime, HR - MSlAddr, HR - MS2Addr) .
Finally, in 708, the HR-MS2 702 computes signature
CTHR-MS2 = S I GN(THR-MS2 I
NHR-MS2 I HR - MSlAddr | HR - MS2Addr | NHR_MS1 |
EHR-MS1 K(DMK' key_lifetime, HR - MSlAddr,
HR - MS2Addr) | 0HR _ MS2) and sends, in 709, a
DirectComms_KeyAgreement_MSG_#2 message 710 to HR-MS1 701:
HR - MS2 → HR - MSI : DirectComms_KeyAgreement_MSG_# 2 (8) where
DirectComms_KeyAgreement_MSG_#2 =
THR-MS2 I NHR-MS2 I HR ~ MSlAddr | HR - MS2Addr |
NHR-MS1 I EHR-MS1 PK(DMK' key_lifetime, HR - MSlAddr, HR - MS2Addr) | 9HR-MS2 I HR-MS2 I Cert(HR - MS2).
DirectComms_KeyAgreement_MSG_#2 is also known as
PKIDirectComms_KeyAgreement_MSG_#2 in P802.16n (802.16e based) and Peer_KeyAgreement_MSG_#2 in P802.16.1a (802.16m based)
Step 803: HR-MSl 701 first verifies the received timestamp and nonces for freshness and the certificate Cert(HR - MS2 ) and signature C¾R - MS2 ^n 711. If the verifications are
correct, then HR-MSl 701 decrypts
EHR-MS1 PK(DMK' key_lifetime, HR - MSlAddr, HR - MS2Addr) and obtains DMK and key_lifetime . Next, HR-MSl 701 computes DAK, DCMAC and DTEK and verifies 0HR _MS2 in 712 and 713. If the verification is correct, then HR-MSl 701 computes
QHR - MSI = ma¾cmac(NHR - MS1 I NHR-MS2 I HR - MSlAddr | HR - MS2Addr) and sends, in 714, a DirectComms_KeyAgreement_MSG_#3 message
715:
HR - MSI → HR - MS2 : DirectComms KeyAgreement MSG where
DirectComms_KeyAgreement_MSG_#3 =
NHR_MS2 I HR - MS2Addr | HR - MSlAddr | 0HR _MS1 .
DirectComms_KeyAgreement_MSG_#3 is also known as
PKIDirectComms_KeyAgreement_MSG_#3 in P802.16n (802.16e based) and Peer_KeyAgreement_MSG_#3 in P802.16.1a (802.16m based)
Step 804: HR-MS2 702 receives the
DirectComms_KeyAgreement_MSG_#3 message 715 and 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
communications in 717 and 718. attributes of the messages 704, 706, 708 are summarized the following tables.
Table 7: DirectComms_KeyAgreement_MSG_#l message attribute
Figure imgf000024_0002
Table 8: DirectComms_KeyAgreement_MSG_#2 message attribute
Figure imgf000024_0001
THR-MS2 Tiraestamp generated by HR-MS2.
THR-MS2 is 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)
NHR-MS2 Freshly generated random number of 64bits by HR-MS2. ¾R-MS2 is also known as HR_MS2_Random in P802.16n (802.16e based) and also known as NONCE_HR-MS2 in P802.16.1a
(802.16m based)
HR - MSlAddr Address of HR-MS1
HR - MS2Addr Address of HR-MS2
NHR-MS1 Nonce generated by HR-MS1 in
DirectComms KeyAgreement MSG #1 message
Public key encryption using
EHR-MS1 PK(DMK' key_lifetime, HR-MSl's Public key where DMK =
HR - MSlAddr, HR - MS2Addr) DirectComms Master Key
generated by HR-MS and key lifetime = lifetime of DMK. EHR-MS1 PK(DMK, key_lifetime,
HR - MSlAddr, HR - MS2Addr) can also be written as Encrypted DMK in P802.16n (802.16e based) and P802.16.1a (802.16m based)
%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
CMAC_HR-MS2 in P802.16.1a (802.16m based)
CTHR-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 ) Digital certificate of HR-MS2.
Cert(HR-MS2) is also known as HR-MS2_Certificate in P802.16n (802.16e based) and P802.16.1a
(802.16m based) .
Table 9: DirectComms_KeyAgreement_MSG_#3 message
attribute
Notation Meaning
NHR-MS2 Nonce generated by HR-MS2 in
DirectComms KeyAgreement MSG #2 message
Address of HR-MS2
HR - MS2Addr
Address of HR-MS1
HR - MSlAddr
eHR-MSl Message digest calculated using DCMAC key
by HR-MS1. Q^^gi is also known as HR-
MS1_CMAC in P802.16n (802.16e based) and also known as CMAC_HR-MS1 in P802.16.1a
(802.16m based) In the following, the approach for the scenario that one of the mobile terminals converts into a base station according to one embodiment is described with reference to figures 9, 10 and 11.
Figure 9 shows a communication arrangement 900 according to an embodiment .
Similarly to the communication system 300 shown in figure 3, the communciation system 900 comprises a first mobile
terminal (also referred to as HR-MS1) 901, a second mobile terminal (also referred to as HR-MS2) 902 and a communication network (also referred to as network side of the
communication system 900) comprising a base station (also referred to as HS-BS) 903 and a backbone network 904.
The communication system 900 is for example a communication system according to a IEEE 802.16 standard. In normal operation, 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.
For this embodiment, it is assumed that the base station 903 is not available for providing communication between the mobile terminals 901, 902. For example, the backbone network 904 has failed.
In this scenario, it is assumed that the HR-MS1 converts to a base station (referred to as HR-BS*) 905 in order to
establish a secure direct communication channel with HR-MS2 902. The AKE protocol used according to this embodiment is described in the following with reference to figures 10 and 11.
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.
The various protocol steps are shown in more detail in figure 11.
Figure 11 shows a flow diagram 1100 according to an
embodiment .
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
Cert(HR - BS*) . If the verifications are correct, then HR-MS2 generates a nonce %R_]V[S2. Next, HR-MS2 1002 computes the signature
GHR-MS2 = SIGN(THR-MS2 I NHR-MS2 I HR - BS * Addr | HR - MS2Addr) and sends, in 1005, a DirectComms_KeyAgreement_MSG_#2 message 1006 to HR-BS* 1001:
HR - MS2 —» HR - BS* : DirectComms_KeyAgreement_MSG_#2 (11) where
DirectComms_KeyAgreement_MSG_#2 =
THR-MS2 I NHR-MS2 I HR - BS * Addr | HR - MS2Addr |
(7HR-MS2 I Cert(HR— MS2 ) .
Step 1104: HR-BS* 1001 first verifies the received timestamp and nonce for freshness and certificate Cert(HR - MS2 ) and
signature c¾ _]y[g2. If the verifications are correct, then
HR-BS* 1001 generates a nonce 1%R_B5* an DMK and computes
DAK = Dotl 6KDF( DMK, HR - BS * Addr | HR - MS2Addr | "DAK", 160),
the DCMAC = Dotl 6KDF(DAK, "DCMAC_KEYS" , 128), the
DTEK = DOT16KDF(DAK, "DTEK_KEY", 128) and
6HR-BS* = MACDCMAC(NHR_BS* | NHR_MS2 I HR - BS * Addr |
HR - MS2Addr) . HR-BS* 1001 then uses HR-MS2 ' s 1002 public key to encrypt and obtain EHR_iY[g2 PK(DMK,
key_lifetime, HR-BS * Addr, HR - MS2Addr) . Finally, HR-BS* 1001 computes signature <¾R-BS* =
SIGN(THR_BS* I NHR_BS* I HR - MS2Addr | HR - BS * Addr |
NHR-MS2 I EHR-MS2 _ Ρκ(°Μί key_lifetime,
HR-BS * Addr, HR - MS2Addr) | 6HR_BS*) and, in 1007, sends a
DirectComms_KeyAgreement_MSG_#3 message 1008 to HR-MS2 :
HR - BS* —> HR— MS2 : DirectComms_KeyAgreement_MSG_#3 (] where
DirectComms_KeyAgreement_MSG_#3 =
THR-BS* I NHR-BS* I HR ~ MS2Addr | HR - BS * Addr | NHR_MS2 I EHR-MS2 ΡΚ(°ΜΚ' key_lifetime, HR - BS * Addr, HR - MS2Addr) |
QHR - BS * I <¾R-BS* I Cert(HR - BS* ) .
Step 1105: HR-MS2 1002 first verifies the received timestamp, nonce and signature <¾R-BS* . If the verifications are
correct, then HR-MS2 1002 decrypts
EHR-MS2 PK<DMK' key_lifetime, HR - BS * Addr, HR - MS2Addr) and obtains DMK and its lifetime key_lifetime . Next, 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
EHR-MS2 = MACDCMAC(NHR-MS2 I NHR-BS* I HR ~ MS2Addr | HR - BS * Addr) and sends, in 1009, a DirectComms_KeyAgreement_MSG_#4 message
1010: HR - MS2 → HR - BS* : DirectComms_KeyAgreement_MSG_# 4 (13) where
DirectComms_KeyAgreement_MSG_#4 =
NHR-BS* I HR - BS * Addr | HR - MS2Addr | ΘΗΚ_Μ32 .
Step 1106: HR-BS* 1001 receives the
DirectComms_KeyAgreement_MSG_#4 message 1010 and verifies the received nonce and CMAC tuple. If the verification are
successful, then HR-BS* 1001 confirms that HR-MS2 1002 has computed the correct keys and commences secure direct
communications .
The attributes of the messages 1004, 1006, 1008, 1010 are summarized in the following tables.
Table 10: DirectComms_KeyAgreement_MSG_#l message attribute Notation Meaning
Cert(HR - BS*) Digital certificate of HR-BS*
Table 11: DirectComms_KeyAgreement_MSG_#2 message attribute
Figure imgf000031_0001
Table 12: DirectComms_KeyAgreement_MSG_#3 message attribute
Notation Meaning
THR-BS* Timestamp generated by HR-BS*
NHR-BS* Freshly generated random number of 64bits by HR-BS*
HR - MS2Addr Address of HR-MS2
HR - BS * Addr Address of HR-BS*
NHR-MS2 Nonce generated by HR-MS2 in
DirectComms_KeyAgreement_MSG_#2 message
Public key encryption using
EHR-MS2 PK(DMK' key_lifetime, HR-MS2's Public key where DMK =
DirectComms Master Key HR - BS * Addr, HR - MS2Addr)
generated by HR-BS* and key lifetime = lifetime of DMK
QHR - B S * Message digest calculated using DCMAC key by HR-BS*
°HR—BS* Signature of message generated by HR-BS* using its RSA private key
Cert(HR - BS*) Digital certificate of HR-BS*
Table 13: DirectComms_KeyAgreement_MSG_#4 message attribute
Figure imgf000032_0001
In the following, the pre-shared key approach according to one embodiment is described with reference to figures 6, 16 and 12. It is assumed that HR-MS1 601, 701 and HR-MS2 602, 702 have already established a pre-shared key DMK using one of the methods previously described, such as with the aid of the Network Infrastructure for example using the approach as described above with reference to figures 3, 4 and 5, or some other method and wish to communicate directly. Then the AKE protocol described in the following can be used. This example is based on the scenario illustrated in figure 6. The message flow is shown in figure 16. Figure 16 shows a flow diagram 1600 according to an
embodiment . 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
mobile terminal 602. The various protocol steps are shown in more detail in figure 12.
Figure 12 shows a flow diagram 1200 according to an
embodiment .
Step 1201: In 1603, HR-MSl 1601 selects a nonce NHR_MSi and uses the shared D K and computes DAK = Dotl 6KDF(
DMK, HR - MSlAddr | HR - MS2Addr | "DAK", 160), the
DCMAC = Dotl 6KDF(DAK, "DCMAC_KEYS", 128) and
R-MS1 = MACDCMAC(NHR- S1 I DMK_Sequence_No | DAKID- I
Key_lifetime) and DTEK = DOT16KDF(DAK, "DTEK_KEY", 128) .
Finally, HR-MSl 1601 sends, in 1604, a
DirectComms_KeyAgreement_MSG_#l 1605 to HR-MS2 1602:
HR - MSI — HR - MS2 : DirectComms_KeyAgreement_MSG_# 1 (14) where
DirectComms_KeyAgreement_MSG_#l = NHR_MS]_ | DMK_Sequence_No | DAKID KeyJLifetime I
Figure imgf000033_0001
· DirectComms_KeyAgreement_MSG_#l 1605 is also known as Peer_KeyAgreement_MSG_#l in P802.16.1a
(802.16m based) . 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 | HR - MS2Addr | "DAK", 160),
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 ¾R-MS2 anc computes
0HR_MS2 =
MACDCMAdNHR-MSl I R-MS2 I DAKID | DMK_Sequence_No |
DC_Security_Parameters) .
Finally, in 1608, HR-MS2 1602 sends a
DirectComms_KeyAgreement_MSG_#2 message 1609 to HR-MS1 1601:
HR - MS2 → HR - MSI : DirectComms_KeyAgreement_MSG_#2 (15) where
DirectComms_KeyAgreement_MSG_#2 =
NHR-MS1 I NHR-MS2 I DAKID | DMK_Sequence_No |
DC_Security_Parameters | 6J-IR _ ]V[S2 ·
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_#2 message 1609 from HR-MS2 1602 and checks the received nonces for freshness and also checks DAKID and 0HR - S2- If the verifications are correct, HR-MS1 1601 computes HR - MSI' =
MA¾CMAC(NHR-MS1 1 NHR-MS2 DMK_Sequence_No | DC_SAID |
DC_Security_Parameters) . Finally, in 1611, HR-MSl 1601 sends a
DirectComms_KeyAgreement_MSG_#3 message 16012 to HR-MS2 1602:
HR - MSI → HR - MS2 : DirectComms_KeyAgreement_MSG_#3 (16) where
DirectComms_KeyAgreement_MSG_#3 =
NHR-MS1 NHR-MS2 DMK_Sequence_No
DC_SAID DC_Security_Parameters | enR-Msi' ·
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
parameters and is ready for direct communications with HR-MSl 1601 which is started in 1614 and 1615. Otherwise, if
HR - MSI' is invalid, then HR-MS2 1602 ignores the
DirectComms_KeyAgreement_MSG_#3 message 16012.
The attributes of the messages 1605, 1609, 16012 according to pre-shared key approach are summarized in the following
tables .
Table 14: DirectComms_KeyAgreement_MSG_#l message
attribute
Notation Meaning NHR-MS1 a freshly generated random number of 64 bits. is also known as
HR_MSl_Random in P802.16n (802.16e based) and also known as NONCE HR-MS1 in
P802.16.1a (802.16m based)
DMK Sequence No new DMK sequence number
DAKID identifies the direct communications authorization key
Key lifetime DMK key lifetime eHR-MSl Message digest calculated using DCMAC key. © is also known as HR-MS1 CMAC in P802.16n (802.16e based) and also known as CMAC_HR-MS1 in P802.16.1a
(802.16m based)
Table 15: DirectComms_KeyAgreement_MSG_#2 message attribute
Notation Meaning
NHR-MS1 Nonce generated by HR-MS1 in
DirectComms KeyAgreement MSG #1 message
NHR-MS2 a freshly generated random
number of 64 bits. j]->_.]yis2 is also known as HR MS2 Random in P802.16n (802.16e based) and also known as NONCE_HR-MS2 in
P802.16.1a (802.16m based)
DAKID identifies the direct
communications authorization key for protecting this message
DMK Sequence No new DMK sequence number The requesting HR-MS ' s
DC Security Parameters security capabilities
%R-MS2 Message digest calculated
using DCMAC key. 9HR _MS2 is also known as HR-MS2 CMAC in P802.16n (802.16e based) and also known as CMAC_HR-MS2 in
P802.16.1a (802.16m based)
Table 16: DirectComms_KeyAgreement_MSG_#3 message attribute
Notation Meaning
NHR-MS1 Nonce generated by HR-MS1 in
DirectComms KeyAgreement MSG #1 message
NHR-MS2 Nonce generated by HR-MS2 in
DirectComms KeyAgreement MSG #2 message
DMK Sequence No new DMK sequence number
DC_SAID identifies the direct communications authorization key for protecting this message
The supporting HR-MS ' s
DC Security Parameters security capabilities
QHR-MSl' Message digest calculated
using DCMAC key. 6HR -MSI' is also known as HR-MS1 CMAC in
P802.16n (802.16e based) and also known as CMAC_HR-MS1 in
P802.16.1a (802.16m based) In the following, examples for the derivation of the keys mentioned above are given.
According to one embodiment, the DMK is the security key/pre- established shared key that is randomly generated by HR-BS
303 or HR-MS 301, 302 or a network entity (e.g. an AAA Server etc). According to one embodiment, 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
described with reference to figures 6, 7 and 8 and by HR-BS* 905 in the approach in which a HR-MS converts to a HR-BS* of the Autonomous Security Procedure described with reference to figures 9, 10 and 11. According to one embodiment, it is already pre-established in the pre-shared key approach
described with reference to figures 6, 16 and 12. According to one embodiment, 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 - MS2Addr | "DAK", 160) (17) where :
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:
Direct Communication Cipher-based Message Authentication
(DCMAC) key
Direct Communication Traffic Encryption (DTEK) Key
The DCMAC-DTEK prekey derivation is done as follows:
DCMAC-DTEK prekey = Dotl6KDF (DAK, DAK_COUNT | "DCMAC-DTEK prekey", 160)
The DCMAC key is derived from DAK and used for message authentication for the messages sent during direct
communications .
For example, the DCMAC key is derived as follows: DCMAC = Dotl6KDF(DAK, "DCMAC_KEYS", 128) (18)
DCMAC key = Dot16KDF ( DCMAC-DTEK prekey, "DCMAC__KEYS",
128)
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 I COUNTER DTEK | "DTEK KEY 128)
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.
According to one embodiment 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
standard .
In the following, amendments to Privacy Key Management (PKM) messages in IEEE P802.16.1a according to one embodiment are described.
In the following text changes to the Privacy Key Management (PKM) messages in the P802.16.1a AWD (802.16m standards) to support Security procedure for direct communication data security according to one embodiment are described.
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
Field Size Value/Description Condition
(bits)
PKM v3 4 - PKMv3 Reauth-Request; PKM message type v3 message code = 1
code - PKMv3 EAP-Transfer; PKM v3
message code = 2
-PKMv3 Key_Agreement-MSG#2;
PKM v3 message code = 4
- PKMv3 TEK-Request; PKM v3
message code = 6
- PKMv3 TEK-Invalid; PKM v3
message code =8
- Peer_KeyAgreement_MSG #2;
PKM v3 message code = 10
12-16: Reserved
PKM A value used to match an ABS
identifier response to the AMS requests
or an AMS response to the
ABS requests
CMAC Indicates whether this Shall indicator message is protected always be by CMAC tuple present 0: Not protected
1 : Protected
If ( PKM v3
message code
==2)
{
EAP payload variab
le Contains the EAP
(1..14 authentication data, not
00 x interpreted in the MAC If ( PKM v3
message code
== 4)
{
If ( PKM v3
message code
== 8 )
{
SAID Security association
8
identifier
}
If ( PKM v3
message code
== 10)
{
Key Indicates whether this
Agreement message is for which type of Type Direct communications key agreement
8
0: Pre-shared key
1 : PKI
2: BS-to-BS security
3-255: Reserved
If (Key
Agreement
Type == 0)
{
N0NCE_HR-MS1 A random number of 64 bits
64
used for freshness
NONCE_HR-MS2 A random number of 64 bits
64
used for freshness DAKID identifies the direct
64 communications authorization key
size of ICV 0: size of ICV ± 32 bits
(default; Max Invalid value is 4096)
1
1: size of ICV = 64 bits (Max Invalid value is not used)
PN window The receiver shall track PNs Size 16 within this window to
prevent replay attacks
}
If (Key
Agreement
Type == 1)
{
Timestamp HR Timestamp
32
-MS2
A random number of 64 bits
NONCE_HR-MS2 64
used for freshness
HR-MSlAddr 48 MAC Address
HR-MS2Addr 48 MAC Address
A random number of 64 bits
NONCE HR-MS1 64
used for freshness
Public key encryption using
Encrypted
1024 HR-MSl's Public key
DMK
Signature of message
SigHR-MS2 1024 generated by using its RSA private key
HR-
1024 RSA Digital certificate
MS2_Certific ate
}
If (Key
Agreement
Type == 2)
{
Timestamp HR Timestamp
32
-BS
A random number of 64 bits
NONCE_HR-BS 64
used for freshness
HR-BSdAddr 48 MAC Address
HR-BSAddr 48 MAC Address
A random number of 64 bits
NONCE_HR-BSd 64
used for freshness
Public key encryption using
Encrypted
1024 HR-MSl's Public key
B2MK
Signature of message
SigHR-BS 1024 generated by using its RSA
private key
HR-
BS Certifica 1024 RSA Digital certificate
te
} }
Table 18: Modified Table 727 -AAI-PKM-RSP message field description
Field Size Value/Description Condition
(bits)
PKM v3 4 - PKMv3 EAP-Transfer; PKM v3
message message code =2
type code - PKMv3 Key_Agreement-MSG#l; PKM v3 message code =3
- PKMv3 Key_Agreement-MSG#3
PKM v3 message code =5
- PKMv3 TEK-Reply; PKM v3
message code =7
- PKMv3 TEK-Invalid; PKM v3
message code =8
- Peer KeyAgreement MSG #1;
PKM v3 message code = 9
- Peer KeyAgreement_MSG #3;
PKM v3 message code = 11
12-16: Reserved
PKM A value used to match an ABS
identifier response to the AMS requests
or an AMS response to the
8
ABS requests or an HR-MS
response to another HR-MS
request
CMAC Indicates whether this Shall indicator message is protected always be
1 by CMAC tuple present
0: Not protected
1: Protected
If ( PKM v3
message
code ==2)
{
EAP variab
payload le Contains the EAP
(1..14 authentication data, not
00 x interpreted in the MAC
8) }
If ( PKM v3
message
code == 3)
{
}
If ( PKM v3
message
code == 8
)
{
SAID Security association
8
identifier
}
If ( PKM v3
message
code == 9)
{
Key Indicates whether this
Agreement message is for which type of Type Direct communications key agreement
8
0: Pre-shared key
1: PKI
2: BS-to-BS security
3-255: Reserved
If (Key
Agreement
Type == 0)
{
NONCE_HR- 64 A random number of 64 bits MSI used for freshness
identifies the direct
DAKID 64 communications authorization key
Key lifeti
32 DMK key lifetime me
}
If (Key
Agreement
Type == 1)
{
Timestamp Timestamp
32
HR-MS1
NONCE_HR- A random number of 64 bits
64
MS1 used for freshness
HR-MS2Addr 48 MAC Address
HR-MSlAddr 48 MAC Address
Signature of message
SigHR-MSl 1024 generated by using its RSA private key
HR-
MSl_Certif 1024 RSA Digital certificate icate
}
If (Key
Agreement
Type == 2)
{
imestamp imestamp
32
HR-BSd
NONCE_HR- A random number of 64 bits
64
BSd used for freshness HR-BSAddr 48 MAC Address
HR-BSdAddr 48 MAC Address
Signature of message
SigHR-BSd 1024 generated by using its RSA private key
HR-
BSd_Certif 1024 RSA Digital certificate icate
} }
If ( PKM v3
message
code ==
11)
{
Key Indicates whether this
Agreement message is for which type of Type Direct communications key indicator agreement
8
0: Pre-shared key
1: PKI
2: BS-to-BS security
3-255: Reserved
If (Key
Agreement
Type
indicator
== 0)
{
NONCE_HR- A random number of 64 bits
64
MS1 used for freshness
NONCE_HR- A random number of 64 bits
64
MS2 used for freshness
size of 1 0: size of ICV = 32 bits ICV (default; Max
Invalid value is 4096)
1: size of ICV = 64 bits
(Max Invalid
value is not used)
PN window The receiver shall track PNs Size 16 within this window to
prevent replay attacks
}
If (Key
Agreement
Type
indicator
== 1)
{
NONCE_HR- A random number of 64 bits
64
MS2 used for freshness
HR-MS2Addr 48 MAC Address
HR-MSlAddr 48 MAC Address
}
If (Key
Agreement
Type
indicator
== 2)
{
NONCE_HR- A random number of 64 bits
64
BS used for freshness
HR-BSAddr 48 MAC Address
HR-BSdAddr 48 MAC Address
} } In the following, the amendments of the Privacy Key
Management (PKM) messages in IEEE P802.16n (802.16rev3 baseline) according to one embodiment to support a security procedure for direct communication data security are described.
The Privacy Key Management (PKM) messages are located in Section 6.3.2.3.9 of the 802.16e standards. The. modified Table 50 —PKM message codes according to one embodiment are as follows:
Table 19: Modified Table 50 —PKM message codes
Code PKM message type MAC management
message name
0-2 Reserved -
3 SA Add PKM-RSP
4 Auth Request PKM-REQ
5 Auth Reply PKM-RSP
6 Auth Reject PKM-RSP
33 MIH Comeback Response PKM-RSP
34 DirectComms KeyAgreement MSG PKM-RSP
#1
35 DirectComms KeyAgreement MSG
PKM-REQ
#2
36 DirectComms KeyAgreement MSG
PKM-RSP
#3
37 PKIDirectComms KeyAgreement M PKM-RSP
SG #1
38 PKIDirectComms KeyAgreement M
PKM-REQ
SG #2
39 PKIDirectComms KeyAgreement M PKM-RSP SG #3
40-
Reserved -
255
According to one embodiment, a procedure for establishing secure communications between HR-BS in IEEE 802.16n which deals with BS-to-BS security is provided. According to this embodiment, a secure forwarding of data between HR- infrestructure stations is performed using a Public Key Infrastructure (PKI) .
This procedure provides strong protection and data integrity when data is forwarded between HR-infrastructure stations (e.g. HR-BS) using a Public Key Infrastructure. Each HR-BS has a public/private key pair and digital certificate (e.g. X.509) issued by a certification authority for mutual
authentication and key exchange prior to the start of this direct communications.
The key agreement handshake procedure described below with reference to figures 13 and 14 is for example used for HR-BSs to mutually authenticate themselves (without access to a security server) using PKI and to derive data security keys for secure direct communications. A control connection between the HR-BSs via a designated forwarding HR-MS shall be used for transmitting the key agreement messages. Figure 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
referred to as HR-BSd and a second base station 1302 which is referred to as HR-BS.
The various steps of the procedure are described in more detail in figure 14.
Figure 14 shows a flow diagram 1400 according to an
embodiment .
The key agreement handshake procedure using Public Key
Infrastructure according to this embodiment includes the following steps 1401 to 1404:
Step 1401: Prior to secure connection establishment, the degraded HR-BS (HR-BSd) 1301 generates a nonce NONCE_HR-BSd . In 1303, the HR-BSd 1301 computes the signature SigHR-BSd = SIGN (Timestamp_HR-BSd | NONCE_HR-BSd | HR-BS MAC Addr | HR-BSd MAC Addr) and sends, in 1304, a BStoBS_KeyAgreement_MSG_#l message 1305 to the Designated HR-BS 1302, where
BStoBS_KeyAgreement_MSG_#l = Timestamp_HR-BSd | ONCE_HR- BSd I HR-BS MAC Addr | HR-BSd MAC Addr | SigHR-BSd | HR- BSd_Certificate .
Step 1402: The HR-BS 1302 first verifies the received
timestamp and nonce for freshness and the certificate HR- BSd_Certificate and signature SigHR-BSd in 1306. If the verifications fail, then the HR-BS 1302 ignores the
BStoBS_KeyAgreement_MSG_#l message. If the verifications are correct, then the HR-BS 1302, in 1307, generates a nonce NONCE_HR-BS and security key B2MK and computes B2AK =Dotl 6KDF (B2MK, HR-BSd MAC Addr | HR-BS MAC Addr | "B2AK" , 160) and the B2CMAC key and CMAC_HR-BS = MACB2CMAC (NONCE_HR-BS | NONCE_HR- BSd I HR-BS MAC Addr | HR-BSd MAC Addr). The HR-BS 1302 then uses the HR-BSd's 1301 public key to encrypt and obtain Encrypted B2MK = EHR-BS<I_PK(B2MK, key_lifetime, HR-BSd MAC Addr, HR-BS MAC Addr) . Finally, in 1308, the HR-BS 1301 computes signature SigHR-BS = SIGN (THR-BS INONCE_HR-BS | HR-BSd MAC Addr | HR-BS MAC Addr |NONCE_HR-BSd| Encrypted B2MK |CMAC_HR-BS) and sends, in 1309, a BStoBS_KeyAgreement_MSG_#2 message 1310 to HR-BSd, where BStoBS_KeyAgreement_MSG_#2 = THR-Bs I NONCE_HR-BS I HR-BSd MAC Addr I HR-BS MAC Addr | ONCE_HR-BSd | Encrypted B2MK
I CMAC_HR-BS I SigHR-BS I HR-BS_Certificate . Step 1403: The HR-BSd 1301 in 1311 first verifies the
received timestamp and nonces for freshness and the
certificate HR-BS_Certificate and signature signatureHR-Bs · If the verification is invalid, then HR-BSd ignores the
BStoBS_KeyAgreement_MSG_#2 message 1310. If the verifications are correct, then the HR-BSd 1301 in 1312 decrypts Encrypted B2MK and obtains security key B2MK and key_lifetime . Next, HR-BSd 1301 computes B2AK and B2CMAC keys and verifies
CMAC_HR-BS in 1313. If the verification is invalid, then HR- BSd ignores the BStoBS_KeyAgreement_MSG_#2 message 1310. If the verification is correct, then HR-BSd computes CMAC_HR-BSd = MACB2CMAC (NONCE_HR-BSd | NONCE_HR-BS | HR-BSd MAC Addr | HR-BS MAC Addr) and sends, in 1314, a BStoBS_KeyAgreement_MSG_#3 message 1315 to the HR-BS 1302, where
BStoBS_KeyAgreement_MSG_#3 = NONCE_HR-BS | HR-BS MAC Addr | HR- BSd MAC Addr | CMAC_HR-BSd . If the HR-BSd 1301 does not receive BStoBS_KeyAgreement_MSG_#2 message 1310 from the HR-BS 1302 within BStoBS_KeyAgreement_MSG_#l Timeout, it resends the BStoBS_KeyAgreement_MSG_#l message 1305 up to
BStoBS_KeyAgreement_MSG_#l MaxResends times. If 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
Figure imgf000054_0001
Table 21: Peer_KeyAgreement_MSG_#l message attribute Attribute Contents
Timestamp_HR-BSd Timestamp generated by HR-BSd
Freshly generated random
NONCE_HR-BSd
number of ' 64bits by HR-BSd
HR-BS MAC Addr MAC Address of HR-BS
HR-BSd MAC Addr MAC Address of HR-BSd
Signature of message generated
SigHR-BSd by HR-BSd using its RSA
private key
HR-BSd Certificate Digital certificate of HR-BSd
Table 22: Peer KeyAgreement MSG
Attribute Contents
Timestamp HR-BS Timestamp generated by HR-BS
Freshly generated random number
NONCE_HR-BS
of 64bits by HR-BS
HR-BSd MAC Addr MAC Address of HR-BSd
HR-BS MAC Addr MAC Address of HR-BS
Nonce generated by HR-BSd in
NONCE_HR-BSd BStoBS KeyAgreement MSG_#1
message
Public key encryption EHR-
Bsd PK ( B2MK, key_lifetime, HR-BSd
MAC Addr, HR-BS MAC Addr) using
HR-BSd 's Public key where B2MK =
Encrypted B2MK
BStoBS
Master Key generated by HR-MS and key lifetime = lifetime of B2MK
Message digest calculated using
CMAC_HR-BS
B2CMAC key by HR-BS Signature of message generated
SigHR-BS by HR-BS using its RSA private key
HR-BS Certificate. Digital certificate of HR-BS
Table 23: Peer_KeyAgreement MSG #3 message attribute
Attribute Contents
NONCE_HR-BS Nonce generated by HR-BS in
BStoBS_KeyAgreement MSG #2 message
HR-BS MAC Addr MAC Address of HR-BS
HR-BSd MAC Addr MAC Address of HR-BSd
Message digest calculated using
CMAC_HR-BSd
B2CMAC key by HR-BSd
In the following 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.
Table 24: The B2MK context
Size
Parameter (bit Usage
) BS-to-BS Master Key shared by
B2MK 160
HR-BS and HR-BSd
B2MK SN 4 B2MK sequence number
B2MK Lifetime 32 B2MK Lifetime
B2AK_COUNT 16 Counter to ensure freshness of computed CMAC key and prevent replay attacks.
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.
Table 25: The B2AK context
Parameter Size (bit) Usage
BS-to-BS Communications
B2AK 160 Authentication Key derived from
B2MK.
B2AK Lifetime 32 B2AK Lifetime
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
communication replay attack on the control connection. 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.
Table 26: The B2TEK context
Parameter Size
Usage
(bit)
B2TEK 128 Key used for encryption or
decryption of BS-to-BS
communications messages
B2MK SN 4 B2MK sequence number
The counter used to derive this
C0UNTER_B2TEK 16
B2TEK
B2TEK lifetime 32 B2TEK lifetime=B2 K lifetime
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) The B2SA context according to one embodiment is described in Table 27.
Table 27: The B2SA context
Figure imgf000059_0001
In the following, the key derivation for secure forwarding between HR-infrastructure stations using a Public Key
Infrastructure according to one embodiment is described.
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
Authentication Key (B2AK) .
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.
According to one embodiment, the B2AK derivation is as follows :
B2AK =Dot16KDF (B2MK, HR-BSd MAC Addr | HR-BS MAC Addr | "B2AK", 160)
where: 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:
• BS-to-BS Communication Cipher-based Message
Authentication Code (B2CMAC) key
• BS-to-BS Communication Traffic Encryption (B2TEK) Key
According to one embodiment, the B2CMAC-B2TEK prekey
derivation is done as follows:
B2CMAC-B2TEK prekey = Dot16KDF (B2AK, B2AK_COUN | "B2CMAC- B2TEK prekey", 160)
The B2CMAC key is derived from B2AK and used for message authentication for the messages sent during secure forwarding between HR-infrastructure stations.
According to one embodiment, 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.
According to one embodiment, the B2TEK is derived as follows: B2TEK = Dotl6KDF (B2CMAC-B2TEK prekey, ■
B2SAID I COUNTER_B2TEK | "B2TEK_KEY" , 128)
where 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.
Once the HR-BS 1503 has detected that security direct
communication between the two HR-MSs 1501, 1502 is possible, 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). Following this, 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.
After the 3-way Direct Communications Key Agreement process, both HR-MS1 1501 and HR-MS2 1502 are able to commence secure direct communications and proceed to the Flow Setup phase.
It should be noted that the flow of figure 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
including the pre-shared key method in more detail.
According to various embodiments, as described above, one or more of the following is provided:
• A method for providing mutual authentication for two HR-
MSs with the help of HR-BS for direct communications.
• A method for providing secret keys for data security and data authentication for two HR-MSs with the help of HR-
BS for direct communications.
• A method for providing mutual authentication for two HR- MS in direct communications without infrastructure using
PKI approach.
• A method for providing secret keys for data security and data authentication for two HR-MS in direct communications without infrastructure using PKI
approach .
• A method for providing mutual authentication for two HR- MS in direct communications without infrastructure where one HR-MS converts to HR-BS* (Multimode) .
• A method for providing secret keys for data security and data authentication for two HR-MS in direct
communications without infrastructure where one HR-MS converts to HR-BS* (Multimode) .
• A method for providing mutual authentication for two HR- MS in direct communications without infrastructure where a pre-shared secret key has been earlier established.
• A method for providing secret keys for data security and data authentication for two HR-MS in direct
communications without infrastructure where a pre-shared secret key has been earlier established.
• A method for deriving the DAK and DCMAC keys.
According to various embodiments, authentication and key exchange (AKE) protocols for mutual authentication and data security for IEEE 802.16η HR networks in both network aided and autonomous scenarios are proposed. Specifically, a network-aided AKE protocol in which the HR-BS (base station) assists the two HR-MSs to establish a Direct Communication Master Key (DMK) which would be used for data security and mutual authentication for direct communications is described. Further, three different AKE solutions/protocols for
autonomous mutual authentication of HR-MSs and data security for direct communications are described. 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. Finally, 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.
While the invention has been particularly shown and described with reference to specific aspects, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced .

Claims

aims
Communication terminal of a cellular mobile
communication system, the cellular mobile communication system comprising the communication terminal, another 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, the communication terminal comprising:
a determiner configured to determine 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; and
a transceiver configured to perform secure communication with the other communication terminal via the radio interface between the communication terminal and the other communication terminal using the determined encryption key.
The communication terminal according to claim 1, wherein the secure communication is direct communication between the communication terminal and the other communication terminal .
The communication terminal according to claim 2, wherein the direct communication is communication of data without the data being communicated via a base station of the communication network.
4. The" " communication terminal according to any' one of claim 2 or 3, wherein the direct communication is
communication of data without the communication network being involved in the communication.
5. The communication terminal according to any one of
claims 1 to 4, wherein 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 communication terminal according to claim 5, wherein the messages are exchanged via direct communication between the communication terminal and the other
communication terminal .
The communication terminal according to claim 5 or 6, wherein the messages are exchanged between the
communication terminal and the other communication terminal without being communicated via a base station of the communication network.
The communication terminal according to any one of claims 5 to 7, wherein the messages are exchanged between the communication terminal and the other
communication terminal without the communication network being involved in the exchange of the messages.
The communication terminal according to any one
claims 1 to 8, wherein the communication network
communication network according to a 802.16
communication standard. The communication terminal according to any one
claims 1 to 9, wherein the communication network communication network according to the 802.16η
communication standard.
11. The communication terminal according to any one of
claims 1 to 10, wherein the transceiver is configured to send a request for a direct communication with the other communication terminal to the communication network or to the other communication terminal.
The communication terminal according to claim 11, wherein the transceiver is configured to include a certificate into the reque St.
13. The communication terminal according to claim 11 or 12, wherein the transceiver is configured to include a nonce into the request.
The communication terminal according to any one of claims 1 to 13, wherein the transceiver is configured 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 communication terminal according to claim 14, wherein the transceiver is 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 communication terminal according to claim 14 or wherein the transceiver is configured to check the message for message freshness.
17. The communication terminal according to any one of
claims 1 to 16, wherein the transceiver is configured to send a message including the determined encryption key to the communication network or to the other
communication terminal.
The communication terminal according to claim 17, wherein the transceiver is configured to include a certificate into the request.
19. The communication terminal according to claim 17 or 18, wherein the transceiver is configured to include a nonce into the request.
The communication terminal according to any one of claims 1 to 19, wherein the communication terminal is configured to act as a base station of the communication network .
21. The communication terminal according to any one of
claims 1 to 20, wherein 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.
22. A method for performing 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 communication terminal, 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, the method comprising:
determining 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; and
performing secure communication between the
communication terminal and the other communication terminal via the radio interface between the
communication terminal and the other communication terminal using the determined encryption key.
PCT/SG2012/000045 2011-02-15 2012-02-14 Communication terminal and method for performing communication WO2012112124A1 (en)

Applications Claiming Priority (6)

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

Publications (1)

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

Family

ID=46672846

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2012/000045 WO2012112124A1 (en) 2011-02-15 2012-02-14 Communication terminal and method for performing communication

Country Status (1)

Country Link
WO (1) WO2012112124A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107800539A (en) * 2016-09-05 2018-03-13 华为技术有限公司 Authentication method, authentication device and Verification System

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 (en) * 2016-09-05 2018-03-13 华为技术有限公司 Authentication method, authentication device and Verification System
EP3493462A4 (en) * 2016-09-05 2019-06-05 Huawei Technologies Co., Ltd. Authentication method, authentication apparatus and authentication system
CN107800539B (en) * 2016-09-05 2020-07-24 华为技术有限公司 Authentication method, authentication device and authentication system
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 (en) Handshaking method and system based on datagram secure transmission protocol
KR100704675B1 (en) authentication method and key generating method in wireless portable internet system
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
CN101616410B (en) Access method and access system for cellular mobile communication network
KR100923176B1 (en) System and method for providing security for a wireless network
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 (en) End-to-end service layer authentication
WO2012075825A1 (en) Security configuration method for station in wireless local area network, ap, sta, as and system
RU2509445C2 (en) Method and apparatus for reducing overhead for checking data integrity in wireless communication system
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 (en) Communication terminal and method for performing communication
CN109905345B (en) Communication method, communication device and communication equipment
Zhou et al. Tunnel Extensible Authentication Protocol (TEAP) Version 1
Sithirasenan et al. EAP-CRA for WiMAX, WLAN and 4G LTE Interoperability
CN115314278B (en) Trusted network connection identity authentication method, electronic equipment and storage medium
EP1722503A1 (en) Method used by an access point of a wireless LAN and related apparatus
Siddiqui et al. Security analysis of the WiMAX technology in Wireless Mesh networks
WO2012118445A1 (en) Key management scheme for secure communication in a cellular mobile communication system
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