Post-quantum security profile for JWE and TLS in 3GPP networks

Abstract

The invention relates to a post-quantum security profile for JWE and TLS in a 3GPP network, a method comprising: notifying a responding entity of two or more first key exchange schemes, each first key exchange scheme comprising a respective key exchange supported by an initiating entity for communication between the responding entity and the initiating entity; receiving an indication of the selected key exchange scheme from the responding entity in response to notifying the responding entity of the two or more first key exchange schemes; checking whether the selected key exchange scheme is a mixed key exchange scheme; and, in response to checking that the selected key exchange scheme is not a hybrid key exchange scheme: rejecting communication between the responding entity and the initiating entity; or performing communication by exchanging a key according to the selected key exchange scheme and transmitting an alarm indicating that a key exchange scheme different from the mixed key exchange scheme is used for the communication.

Description

Technical Field

[0001] The present disclosure relates to authentication.

[0002] abbreviation

[0003] 3GPP Third Generation Partnership Project

[0004] 5G / 6G / 7G fifth generation / sixth generation / seventh generation

[0005] AAD additional authentication data

[0006] AEAD Authenticated Encryption with Associated Data

[0007] AES Advanced Encryption Standard

[0008] API Application Programming Interface

[0009] CEK Content Encryption Key

[0010] CRQC Crypto-Related Quantum Computer

[0011] ECDH Elliptic Curve Diffie-Hellman

[0012] GCM Galois / Counter Mode

[0013] HN Home Network

[0014] HTTP Hypertext Transfer Protocol

[0015] ID Identifier

[0016] IE Information Unit

[0017] IETF Internet Engineering Task Force

[0018] IPX IP Exchange

[0019] JOSE JavaScript object signing and encryption

[0020] JSON JavaScript Object Notation

[0021] JWE JSON Web Encryption

[0022] JWS JSON Web Signature

[0023] KEM Key Encapsulation Mechanism

[0024] NF Network Function

[0025] PQC Post-Quantum Cryptography

[0026] PQ / T Post-Quantum / Traditional (Hybrid)

[0027] PRINS Protocol for N32 Interconnect Security

[0028] RAN Radio Access Network

[0029] RFC Request for Comments

[0030] RSA Reset Request / Response

[0031] SEPP Security Edge Protection Proxy

[0032] SN Service Network

[0033] TLS Transport Layer Security

[0034] TS Technical Specifications

[0035] UE User Equipment

[0036] UPF User Plane Function

[0037] Glossary

[0038] “Post-Quantum Algorithm (PQC Key Exchange Algorithm)”: An asymmetric encryption algorithm that is believed to be resistant to attacks using quantum computers as well as traditional computers. Examples of PQC key exchange algorithms include Kyber.

[0039] "Hybrid" key exchange: In this context, refers to the use of two key exchange algorithms based on different cryptographic assumptions, e.g., one classical and one post-quantum, with the goal that the final shared master secret is secure as long as at least one of the component key exchange algorithms remains unbroken. It is referred to as a PQ / T hybrid scheme in draft-ietf-pquip-pqt-hybrid-terminology-00 - Terminology for Post-Quantum-Classical Hybrid Schemes.

[0040] Examples of traditional key exchange algorithms are: Elliptic Curve Diffie Hellman (ECDH), RSA (Rivest Shamir Adelman), Diffie Hellman Key Exchange (DH), Pre-Shared Key (PSK).

[0041] Examples of PQC algorithms include: Kyber, Bit-flipping Key Encapsulation (BIKE), Classical McEliece, Hamming Quasi-Cyclic (HQC).

[0042] PQ / T Hybrid Key Encapsulation Mechanism: A Key Encapsulation Mechanism (KEM) consisting of two or more component KEM algorithms, at least one of which is a post-quantum algorithm and at least one of which is a traditional algorithm.

[0043] Security Edge Protection Proxy (SEPP): A security edge protection proxy is a non-transparent proxy that is located at the periphery of a PLMN network and implements secure communication for inter-PLMN network messages. A SEPP may support the following functions, among others:

[0044] Implement separate security negotiation interface (N32-c) and end-to-end application interface (N32-f)

[0045] N32-C: Context management for security capability negotiation.

[0046] N32-F: used to forward inter-NF signaling across PLMNs.

[0047] • Secure communication of inter-PLMN messages from consumer NF to producer NF using TLS protected mode (HTTP over TLS) or PRINS mode (via one or more IPXs). Background Art

[0048] Current 3GPP work on JOSE JWE: PRINS (N32f application layer protection)

[0049] SEPPs SHOULD protect reformatted HTTP messages between SEPPs using JSON Web Encryption (JWE) as specified in RFC 7516. All encryption schemes supported by JWE are AEAD methods, i.e., methods that encrypt and integrity protect in one single operation and may additionally integrity protect additional data.

[0050] The dataToIntegrityProtectAndCipher and dataToIntegrityProtect blocks should be input to JWE as plain text and JWE Additional Authentication Data (AAD) respectively. The JWE AEAD algorithm generates JWE encrypted text (ciphertext) and JWE authentication tag (message authentication code). The ciphertext is the output from symmetrically encrypted plaintext, while the authentication tag is a value that verifies the integrity of both the generated ciphertext and the additional authentication data.

[0051] The Flattened JWE JSON serialization syntax will be used to represent the JWE as a JSON object.

[0052] The session key shared between the two SEPPs (as described in clause 13.2.4.4.1 of 3GPP TS 33.501) shall be used as the Content Encryption Key (CEK) value for the algorithm indicated in the Encryption Algorithm ("enc") parameter in the JOSE header. The Algorithm ("alg") parameter in the JOSE header indicating the key exchange method shall be set to "dir", i.e. "use the shared symmetric key directly as CEK".

[0053] Key Exchange

[0054] The N32-f key hierarchy is based on the N32-f master secret generated during the N32-c initial handshake by TLS key derivation. The N32-f key hierarchy includes two pairs of session keys and two pairs of IV salts, which are used for two different HTTP / 2 sessions. In one session, the N32-c initiator acts as an HTTP client, while in the second session, the N32-c responder acts as a client.

[0055] If the exported master key is reused to set up multiple HTTP sessions or to set up new HTTP sessions when stream IDs are exhausted, a new, unique N32-f context ID should be generated to avoid key and IV reuse.

[0056] IPX Modification

[0057] Reformatted HTTP messages over IPX SHOULD use JSON Web Signatures (JWS) as specified in RFC 7515 for protecting attributes modified by the IPX provider. The mechanism described in this clause uses signatures (i.e., an asymmetric method) and private / public key pairs.

[0058] More specifically, when an IPX node modifies one or more attributes of the original HTTP message and creates a modifiedDataToIntegrityProtect object to record its modifications, it should use JWS to integrity protect the modifiedDataToIntegrityProtect object.

[0059] Verification by receiving SEPP

[0060] The receiving SEPP shall decrypt the JWE ciphertext using the shared session key and the following parameters obtained from the JWE object - Initialization Vector, Additional Authentication Data value (“aad” in the clearTextEncapsulatedMessage), and the JWE Authentication Tag (“tag”).

[0061] The receiving SEPP shall check the integrity and authenticity of the clearTextEncapsulatedMessage and the encrypted text by verifying the JWE Authentication Tag in the JWE object using the JWE AAD algorithm. Only if the JWE Authentication Tag is correct, the algorithm returns the decrypted plaintext (dataToIntegrityProtectAndCipher).

[0062] The receiving SEPP refers to the NF API data type placement mapping table and reconstructs the original reformatted message by updating the corresponding entry in clearTextEncapsulatedMessage with the value in the dataToIntegrityProtectAndCipher array.

[0063] The receiving SEPP shall next verify the IPX provider update (if included) by verifying the JWS signature added by the intermediate IPX(s). The receiving SEPP shall verify the JWS signature using the corresponding original public key or certificate contained in the IPX provider's security information list obtained during the parameter exchange in the relevant N32-c connection setup, or alternatively configured for the specific peer SEPP. It shall then check, based on the information provided in the IPX provider security information list, whether the original public key or certificate of the identity of the JWS signing IPX in the modifiedDataToIntegrity block matches the IPX provider referenced in the "authorizedIPX ID" field added by the sending SEPP.

[0064] The receiving SEPP shall check whether the modification performed by the intermediate is allowed by the corresponding modification policy. The receiving SEPP shall use the modification policy of the cIPX obtained during the parameter exchange in the relevant N32-c connection setup and use the modification policy of the pIPX configured in the receiving SEPP. The details are described in 3GPP TS 33.501.

[0065] Figure 1 An architecture according to the above principles is shown. The network functions and SEPPs on the left and right sides belong to different PLMNs. The prefix "c" means "consumer" and the prefix "p" means "producer". The SEPPs are connected via the N32-c interface for initial handshake via TLS key derivation and the N32-f interface for inter-NF signaling across PLMNs. One or more IPXs can be inserted on the path between cSEPP and pSEPP via the N32-f interface. The IPXs can be represented as cIPX and pIPX, respectively, depending on whether they belong to the consumer side or the producer side commercially.

[0066] If the cSEPP receives an HTTP / 2 request from the NF (consumer) of the PLMN on the consumer side, it encrypts at least some IEs by JWE using the symmetric key A. Therefore, the message to the pSEPP may include plaintext IEs, JWE encrypted IEs and some metadata, such as Figure 1 This message can be passed to the pSEPP, which generates a raw HTTP / 2 request and provides it to its NF (producer).

[0067] If there is one or more IPXs between cSEPP and pSEPP, according to PRINS, these IPXs can modify the plaintext IE via JWS with the corresponding JSON patch. The JSON patch is signed using the private key of the corresponding IPX. Therefore, for each of the intermediate IPXs that modify the message with the corresponding JSON patch, pSEPP receives the JSON patch, the IPX's identifier and the signature, as Figure 1 As shown below in pSEPP. pSEPP uses the public key of the corresponding IPX to verify whether the JSON patch is indeed provided by the corresponding IPX. In addition, pSEPP can verify whether the corresponding IPX is allowed to perform the modification. If the modification is accepted, pSEPP can adjust the HTTP / 2 request sent to its NF (producer) accordingly.

[0068] Reference above Figure 1 The message flow explained is the message from the consumer side to the producer side. The message from the producer side to the consumer side will be processed accordingly.

[0069] 3GPP TS 33.501 (clause 13.2.4.9) - JOSE JWE profile for PRINS:

[0070] SEPP should follow the JWE profile defined in 3GPP TS 33.210, but is restricted to using only AES GCM with 128-bit or 256-bit keys. The security considerations for the use of AES GCM in section 8.4 of RFC 7518 should be taken into account. In particular, the same key should not be used more than 2^32 times, and the IV salt should not be used with the same key more than once.

[0071] Currently, 3GPP specifications include the use of JWE for the PRINS protocol for protecting the N32f interface in interconnection. JWE can be used in the near future for other security features starting from Release 19, 6G, etc. 3GPP SA3 has created a JOSE JWE profile in 3GPPTS 33.210, which can be referenced by other specifications as a benchmark.

[0072] JOSE profile in 3GPP TS 33.210 (clause 6.3) JWE profile:

[0073] 6.3.1 Overview

[0074] JWS (JSON Web Signature) and JWE (JSON Web Encryption) are used to integrity protect and encrypt JSON objects. The JWE profile and JWS profile describe the restrictions and extensions to the RFCs of 3GPP entities or functions that support JWS and / or JWE.

[0075] The cipher suites used in Section 6.2 are described in RFC 7518.

[0076] 6.3.2JWE Configuration File

[0077] All entities and functions supporting JWE according to RFC 7516 SHOULD adhere to the following restrictions and extensions:

[0078] The "enc" parameter A128GCM (AES GCM with 128-bit keys) shall be supported. The "enc" parameter A256GCM (AES GCM with 256-bit keys) shall be supported.

[0079] The "alg" parameter "dir" (directly use the shared symmetric key as CEK) should be supported.

[0080] If ECDH is used as the key agreement protocol, the receiver SHOULD perform public key verification and check whether the received public key is on the agreed (ECDH) curve. Summary of the invention

[0081] Its purpose is to improve existing technology.

[0082] According to a first aspect, there is provided an apparatus comprising:

[0083] One or more processors, and a memory storing instructions that, when executed by the one or more processors, cause the apparatus to:

[0084] notifying the responding entity of two or more first key exchange schemes, each first key exchange scheme comprising a respective key exchange supported by the initiating entity for communications between the responding entity and the initiating entity;

[0085] receiving, in response to notifying the responding entity of the two or more first key exchange schemes, an indication of a selected key exchange scheme from the responding entity;

[0086] checking whether the selected key exchange scheme is a hybrid key exchange scheme; and, in response to checking that the selected key exchange scheme is not a hybrid key exchange scheme:

[0087] Deny communication between the responding entity and the initiating entity; or

[0088] performing communication by exchanging keys according to the selected key exchange scheme and sending an alert indicating that a key exchange scheme different from the hybrid key exchange scheme is used for communication; wherein:

[0089] The two or more first key exchange schemes include a hybrid key exchange scheme;

[0090] The hybrid key exchange scheme internally includes at least two key exchanges based on different cryptographic assumptions.

[0091] The instructions, when executed by one or more processors, may also cause the apparatus to perform:

[0092] In response to checking that the selected key exchange scheme is not a hybrid key exchange scheme, notifying the requesting entity that the communication is denied; wherein

[0093] Communications may be requested in response to a request from a requesting entity.

[0094] According to a second aspect, there is provided an apparatus comprising:

[0095] One or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to:

[0096] receiving, at the responding entity, information that the initiating entity supports two or more first key exchange schemes, each first key exchange scheme comprising a respective key exchange for communications between the responding entity and the initiating entity;

[0097] selecting one of the first key exchange schemes as the selected key exchange scheme;

[0098] In response to receiving information indicating that the initiating entity supports the two or more first key exchange schemes, notifying the initiating entity of key exchange schemes, wherein:

[0099] The two or more first key exchange schemes include a hybrid key exchange scheme;

[0100] A hybrid key exchange scheme includes at least two key exchanges based on different cryptographic assumptions.

[0101] The instructions, when executed by one or more processors, may also cause the apparatus to perform:

[0102] checking whether the responding entity supports at least one first key exchange scheme of two or more first key exchange schemes;

[0103] Responsive to checking that the responding entity does not support at least one of the two or more first key exchange schemes, the communication is rejected.

[0104] For the apparatus of each of the first and second aspects, one or more of the following may apply:

[0105] The communication may include at least one of a handshake and transmission of a payload;

[0106] - The handshake can be a transport layer security handshake; or

[0107] - The payload can be a javascript object notation web encryption payload.

[0108] A hybrid key exchange scheme may include both conventional and post-quantum key exchanges; or

[0109] The entity is a network function or a security edge protection agent.

[0110] According to a third aspect, there is provided a method comprising:

[0111] notifying the responding entity of two or more first key exchange schemes, each first key exchange scheme comprising a respective key exchange supported by the initiating entity for communications between the responding entity and the initiating entity;

[0112] receiving, in response to notifying the responding entity of the two or more first key exchange schemes, an indication of a selected key exchange scheme from the responding entity;

[0113] checking whether the selected key exchange scheme is a hybrid key exchange scheme; and, in response to checking that the selected key exchange scheme is not a hybrid key exchange scheme:

[0114] Deny communication between the responding entity and the initiating entity; or

[0115] performing communication by exchanging keys according to the selected key exchange scheme and sending an alert indicating that a key exchange scheme different from the hybrid key exchange scheme is used for communication; wherein

[0116] The two or more first key exchange schemes include a hybrid key exchange scheme;

[0117] The hybrid key exchange scheme internally includes at least two key exchanges based on different cryptographic assumptions.

[0118] The method may further include:

[0119] In response to checking that the selected key exchange scheme is not a hybrid key exchange scheme, notifying the requesting entity that the communication is denied; wherein

[0120] Communications may be requested in response to a request from a requesting entity.

[0121] According to a fourth aspect, there is provided a method comprising:

[0122] receiving, at the responding entity, information that the initiating entity supports two or more first key exchange schemes, each first key exchange scheme comprising a respective key exchange for communications between the responding entity and the initiating entity;

[0123] selecting one of the first key exchange schemes as the selected key exchange scheme;

[0124] In response to receiving information indicating that an originating entity supports two or more first key exchange schemes, notifying the originating entity of key exchange schemes, wherein:

[0125] The two or more first key exchange schemes include a hybrid key exchange scheme;

[0126] A hybrid key exchange scheme includes at least two key exchanges based on different cryptographic assumptions.

[0127] The method may also include

[0128] checking whether the responding entity supports at least one first key exchange scheme of two or more first key exchange schemes;

[0129] Responsive to checking that the responding entity does not support at least one of the two or more first key exchange schemes, the communication is rejected.

[0130] For the methods of each of the third and fourth aspects, one or more of the following may apply:

[0131] The communication may include at least one of a handshake and transmission of a payload;

[0132] - The handshake can be a transport layer security handshake; or

[0133] - The payload can be a javascript object notation web encryption payload.

[0134] A hybrid key exchange scheme may include both conventional and post-quantum key exchanges; or

[0135] The entity is a network function or a security edge protection agent.

[0136] Each of the methods of the third aspect and the fourth aspect may be a method of secure communication.

[0137] According to a fifth aspect, a computer program product is provided, comprising a set of instructions, which when executed on a device is configured to cause the device to perform a method according to any one of the third and fourth aspects. The computer program product may be embodied as a computer readable medium or may be directly loaded into a computer.

[0138] According to some example embodiments, at least one of the following advantages may be achieved:

[0139] "Harvest first, decrypt later" attacks can be prevented;

[0140] Allows for a smooth transition to PQC;

[0141] ·Respect for traditional implementation.

[0142] It should be understood that any of the above modifications may be applied to the various aspects to which they refer, alone or in combination, unless they explicitly state otherwise. BRIEF DESCRIPTION OF THE DRAWINGS

[0143] Further details, features, objects and advantages will be apparent from the following detailed description of preferred example embodiments taken in conjunction with the accompanying drawings, in which:

[0144] Figure 1 shows an architecture of prior art upon which the architecture may be applied according to some example embodiments;

[0145] Figure 2 shows a message sequence chart according to some example embodiments;

[0146] Figure 3 shows a message sequence chart according to some example embodiments;

[0147] Figure 4 An apparatus according to an example embodiment is shown;

[0148] Figure 5 shows a message sequence chart according to some example embodiments;

[0149] Figure 6 An apparatus according to an example embodiment is shown;

[0150] Figure 7 A method according to an example embodiment is shown;

[0151] Figure 8 An apparatus according to an example embodiment is shown. DETAILED DESCRIPTION

[0152] Certain exemplary embodiments will be described in detail below in conjunction with the accompanying drawings, wherein the features of the exemplary embodiments may be freely combined unless otherwise specified. However, it should be clearly understood that the description of certain exemplary embodiments is given by way of example only and is by no means intended to be construed as limiting the disclosure to the disclosed details.

[0153] In addition, it should be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or the method is described.

[0154] The migration from traditional security schemes to PQC is unique in the history of modern digital cryptography, as neither traditional nor post-quantum algorithms can be fully trusted to protect data for the required data longevity. Traditional algorithms (such as RSA and elliptic curves) may fall to quantum cryptanalysis, while post-quantum algorithms face uncertainty about the underlying mathematics, compliance issues, unknown vulnerabilities, and hardware and software implementations that have not yet matured enough to rule out classical cryptanalysis attacks and implementation errors. In the transition from traditional algorithms to post-quantum algorithms, it is desirable or required that protocols use both algorithm types simultaneously.

[0155] Specifically, in the presence of a cryptographically dependent quantum computer (CRQC) that can perform quantum cryptanalysis, the public key-based encryption (e.g., ECDH) algorithms used in the JWE profile (standardized in 3GPP) may be cracked and become obsolete. Basically, some example embodiments are intended to avoid the situation where a potential attacker with quantum cryptanalysis capabilities will be able to derive a private key from a public key exchanged with another party and decrypt the shared encryption key used in JWE. It is called a "harvest first, decrypt later" attack, which refers to the attacker collecting encrypted data now and waiting for quantum computers to become powerful enough to crack the encryption later.

[0156] Considering that SEPP uses JOSE JWE for encryption, SEPP or operator traffic will also be compromised and therefore also needs to be migrated to PQC. Similar issues may arise in 3GPP deployments that use or will use JWE, so a generic solution is also needed for any 3GPP NF / node using JWE.

[0157] According to some example embodiments, protection of inter-PLMN traffic by SEPP is enhanced by at least one of:

[0158] 1) N32c negotiation update:

[0159] The network function may enable hybrid key exchange for at least one of TLS and JWE (e.g., for both TLS and JWE).

[0160] TLS: Update TLS stacks and profiles on clients and servers to support hybrid key exchange, for example according to the design described by https: / / datatracker.ietf.org / doc / draft-ietf-tls-hybrid-design (currently version 06 is available). If one of the TLS peers does not support hybrid key exchange, the other TLS peer either rejects the TLS handshake, typically with appropriate alerts (such as a "harvest now, decrypt later" attack alert) to prevent downgrade attacks, or does not reject the TLS handshake but issues an attack alert.

[0161] A hybrid TLS profile can use both traditional and PQC algorithms for key exchange, and in the future, the TLS profile can be upgraded to use only the PQC algorithm for key exchange. A hybrid TLS profile may initially be deployed without updating client / server certificates, but these certificates can be upgraded to composite signatures (using both traditional and PQC signatures) or signatures generated using post-quantum signature algorithms. Network functions can support cryptographic flexibility and backward compatibility to dynamically update the TLS profile used by the network function to address classical and quantum cryptanalysis issues.

[0162] JWE: Update JWE profiles to use hybrid encryption schemes (encryption schemes that include hybrid key exchange). If hybrid encryption schemes are not used, reject JWE payloads. Additionally, receivers of JWE payloads may raise an alarm to notify management systems of a potential "harvest first, decrypt later" attack.

[0163] The hybrid JWE profile can also use both traditional and PQC algorithms for key exchange, and in the future, the JWE profile may be upgraded to use only the PQC algorithm. The hybrid JWE profile may initially be deployed with composite keys (traditional + post-quantum) in the receiver's certificates, which may later be upgraded to use composite signatures (traditional + post-quantum) or signatures using post-quantum signature algorithms. It will enable JSON Web Signatures (JWS) to use PQC signature algorithms (e.g., Falcon). Network functions can support cryptographic flexibility and backward compatibility to dynamically update the JWE profile used by the network function to address classical and quantum cryptanalysis issues.

[0164] 2) Update of PRINS (N32f)

[0165] Updates to the JWE profile can be described in 3GPP TS 33.210. Therefore, it can be referenced in any future use of JWE in 3GPP standards (Rel.19, 6G, etc.). By applying a post-quantum hybrid key exchange mechanism, the JWE profile can enhance robustness against potential vulnerabilities discovered in the future for traditional or post-quantum algorithms. Therefore, the profile is secure even if one of the two mechanisms used (traditional and post-quantum) is compromised.

[0166] The specific issues of PRINS JWE mode are addressed by https: / / datatracker.ietf.org / doc / draft-ietf-tls-hybrid-design. The draft proposes a hybrid key exchange structure in TLS 1.3 that can be applied to the N32-c TLS establishment required to exchange the symmetric shared secret used in JWE.

[0167] 3) TLS N32f Update

[0168] The update of the TLS profile can be described in 3GPP TS 33.210. Therefore, it can be referenced in any future use of JWE in 3GPP standards (Rel.19, 6G, etc.). By applying the post-quantum hybrid key exchange mechanism, the hybrid TLS profile can enhance the robustness against potential vulnerabilities discovered in the future for traditional or post-quantum algorithms. Therefore, even if one of the two mechanisms used (traditional and post-quantum) is compromised, the profile is secure.

[0169] The update of the N32c interface can be generalized to any communication between two arbitrary NFs using TLS or JWE.

[0170] TLS: Update TLS stacks and profiles on clients and servers to support hybrid key exchange, such as according to the design described by https: / / datatracker.ietf.org / doc / draft-ietf-tls-hybrid-design. If one of the TLS peers does not support hybrid key exchange, the other TLS peer rejects the TLS handshake, typically raising an appropriate alert (such as a "harvest now, decrypt later" attack alert) to prevent downgrade attacks, or the other TLS peer may not reject the TLS handshake but raise an attack alert.

[0171] Which of these two options is applied may be implementation specific. In some example embodiments, both options may be implemented, and the other TLS peer decides which option to apply based on certain criteria. For example, the other peer may decide whether to reject the TLS handshake (with or without an alert), or accept the TLS handshake and issue an alert based on the sensitivity of the exchanged information. The higher the sensitivity, the higher the probability of rejecting the TLS handshake.

[0172] JWE: Update the JWE profile to use a hybrid encryption scheme. If the hybrid encryption scheme is not used, the communication partner can reject the JWE payload, usually raising an alarm to inform the management system of a potential "harvest first, decrypt later" attack. The node / NF generates a shared master key based on the hybrid key and provides protection against different attacks.

[0173] Figure 2 A message sequence chart is shown for the case of communication between an initiating SEPP of PLMN1 (also referred to as SEPP1) and a responding SEPP of PLMN2 (also referred to as SEPP2) which is different from PLMN1, according to some example embodiments. The actions are as follows:

[0174] Action 1: Both SEPPs are configured with hybrid key exchange for both TLS and JWE.

[0175] Actions 2, 3: When a service request from NFc of PLMN1 is received at SEPP1, SEPP selects a security scheme (including key exchange scheme) supported for the PLMN. As another option, SEPP1 can negotiate the supported security schemes with SEPP2 over the N32c interface during startup.

[0176] Action 4: SEPP1 sends supported security schemes to SEPP2, and additionally includes supported key exchange mechanisms. For example, SEPP1 may inform SEPP2 that SEPP1 supports (“TLS” and “PRINS” represent “regular TLS” and “regular PRINS” respectively):

[0177] TLS

[0178] ·PRINS

[0179] Supported hybrid PRINS

[0180] Supported Hybrid TLS

[0181] Supported PQCPRINS

[0182] Supported PQC TLS

[0183] In some example embodiments, the initiating SEPP (SEPP1) may not inform the responding SEPP (SEPP2) of one or both of the conventional options (TLS and PRINS). Therefore, SEPP1 prohibits SEPP2 from falling back to this or these conventional methods. In some example embodiments, the initiating SEPP (SEPP1) may not inform the responding SEPP (SEPP2) of one or both of the PQC options (PQC TLS and PQC PRINS). The information may include at least one hybrid option (hybrid PRINS and / or hybrid TLS).

[0184] Actions 5, 6: The responding SEPP (SEPP2) selects a policy based on the peer PLMN (i.e. PLMN1). If SEPP2 does not support any of the indicated key exchange methods (in particular: does not support hybrid methods), the responding SEPP rejects the request. The rejection may include an appropriate error code. Otherwise, the responding SEPP selects one of the offered key exchange schemes and responds with the selected scheme.

[0185] Additional processing depends on the key exchange scheme selected by the responding SEPP:

[0186] Option 1 : The selected key exchange scheme is not a hybrid key exchange

[0187] Action 7: If according to PLMN1's policy, a hybrid key exchange scheme is required, PLMN1 rejects the request.

[0188] Actions 8a, 8b: SEPP1 informs SEPP2 and requests NFc to reject.

[0189] Option 2 : SEPP2 selects Hybrid TLS.

[0190] Action 7: Both SEPPs generate a shared master key based on the TLS profile to use a hybrid encryption scheme and encrypt the data accordingly.

[0191] Action 8: Based on the shared master key, initiate SEPP to send a TLS request on the N32f interface.

[0192] Action 10: SEPP2 allows or denies the service on N32f.

[0193] Option 3 : SEPP2 selects mixed PRINS.

[0194] Action 7: Both SEPPs generate a shared master key based on the JWE profile to use the hybrid encryption scheme and encrypt the data accordingly.

[0195] Actions 8, 9: Communication using a shared master key is performed between SEPP1 and SEPP2 via one or more IPXs.

[0196] Figure 3 Another example embodiment is shown. The message flow corresponds to Figure 2 The message flow in is the same as in except that the SEPPS is replaced by a general node or NF.

[0197] JOSE: For NFs using JOSE, the general solution is to use hybrid key exchange in JOSE to prevent "harvest first, decrypt later" attacks. In the future, if an on-path attacker has a network device equipped with CRQC, JWS will be able to be cracked, and the signature scheme used in JOSE will have to be upgraded to use the PQC signature scheme.

[0198] from Figure 1 and Figure 2 As can be seen from the 3 options, if both nodes support the hybrid key exchange scheme, they can negotiate and generate a shared master key. If any node does not support the hybrid scheme, the NF / node can reject the request (option 1). If both nodes support the hybrid scheme, they can use the shared master key for TLS encryption (option 2) or use the shared master key for JWE encryption (option 3).

[0199] Figure 4 An apparatus according to an example embodiment is shown. The apparatus may be a network function (such as an initiating network function, eg a SEPP) or an element thereof. Figure 5 A method according to an example embodiment is shown. Figure 4 The device can perform Figure 5 method, but not limited to this method. Figure 5 The method can be Figure 4 The present invention is performed by a device, but is not limited to being performed by the device.

[0200] The device includes at least one of a component 110 for notifying, a component 120 for receiving, a component 130 for checking, a component 140 for rejecting, or a component 150 for executing. The component 110 for notifying, the component 120 for receiving, the component 130 for checking, the component 140 for rejecting, and the component 150 for executing can be a notification component, a receiving component, a checking component, a rejecting component, and an executing component, respectively. The component 110 for notifying, the component 120 for receiving, the component 130 for checking, the component 140 for rejecting, and the component 150 for executing can be a notifier, a receiver, a checker, a rejecter, and an executer, respectively. The component 110 for notifying, the component 120 for receiving, the component 130 for checking, the component 140 for rejecting, and the component 150 for executing can be a notification processor, a receiving processor, a checking processor, a rejecting processor, and an executing processor, respectively.

[0201] The component 110 for notifying notifies the responding entity of one or more first key exchange schemes (S110). Each of the key exchange schemes includes a corresponding key exchange supported by the initiating entity. The key exchange can be used for communication between the responding entity and the initiating entity. The one or more first key exchange schemes include a hybrid key exchange scheme. The hybrid key exchange scheme includes at least two key exchanges based on different encryption assumptions.

[0202] In response to notifying the responding entity of one or more first key exchange schemes at S110, the means for receiving 120 receives an indication of a second key exchange scheme from the responding entity (S120).

[0203] The means 130 for checking checks whether the second key exchange scheme is a hybrid key exchange scheme (S130).

[0204] In response to checking that the second security scheme is not a hybrid key exchange scheme (S130=No):

[0205] If the means 140 for rejecting is implemented in the device, rejecting the communication between the responding entity and the initiating entity (S140); or

[0206] If the means 150 for executing is implemented in the device, communication is performed by exchanging keys according to the second key exchange scheme, and an alarm is sent indicating that the second key exchange scheme different from the hybrid key exchange scheme is used for communication (S150).

[0207] If the device includes both means for denying 140 and means for executing 150, the means for selecting can select whether means for denying 140 or means for executing 150 acts on the communication. The selection can be based on criteria such as the sensitivity of the communication, the type of the responding network function, the identifier of the responding network function, etc.

[0208] The entity may be a network function, such as a SEPP.

[0209] Figure 6 An apparatus according to an example embodiment is shown. The apparatus may be a network function (such as an initiating network function, eg a SEPP) or an element thereof. Figure 7 A method according to an example embodiment is shown. Figure 6 The device can perform Figure 7 method, but not limited to this method. Figure 7 The method can be Figure 6 The present invention is performed by a device, but is not limited to being performed by the device.

[0210] The device includes a component 210 for receiving, a component 220 for selecting, and a component 230 for notifying. The component 210 for receiving, the component 220 for selecting, and the component 230 for notifying can be a receiving component, a selecting component, and a notifying component respectively. The component 210 for receiving, the component 220 for selecting, and the component 230 for notifying can be a receiver, a selector, and a notifier respectively. The component 210 for receiving, the component 220 for selecting, and the component 230 for notifying can be a receiving processor, a selecting processor, and a notifying processor respectively.

[0211] The receiving component 210 receives information that the initiating entity supports one or more first key exchange schemes at the responding entity (S210). Each of the first key exchange schemes includes a corresponding key exchange for communication between the responding entity and the initiating entity. The one or more first key exchange schemes include a hybrid key exchange scheme. The hybrid key exchange scheme includes at least two key exchanges based on different encryption assumptions.

[0212] The component 220 for selecting selects one of the one or more first key exchange schemes as the second key exchange scheme (S220). The component 230 for notifying notifies the initiating entity of the second key exchange scheme in response to receiving the information of the one or more first key exchange schemes supported by the initiating entity in S210 (S230).

[0213] The entity may be a network function, such as a SEPP.

[0214] Figure 8An apparatus according to an example embodiment is shown. The apparatus comprises at least one processor 810, at least one memory 820 storing instructions, which instructions, when executed by the at least one processor 810, cause the apparatus to perform a method according to at least one of the following figures and the related description: Figure 5 or Figure 7 .

[0215] Some example embodiments are explained for 5G (NR). However, other example embodiments may be used for other 3GPP generations, such as 4G, 6G, 7G, etc., for other wireless or wired communication networks, and for other systems employing TLS and / or JWE.

[0216] UE is an example of a terminal. Other examples are MTC devices. Each of the terminals may be implemented as a smart phone, a mobile phone, a laptop, a sensor device, etc.

[0217] A piece of information can be sent from one entity to another in one or more messages. Each of these messages can include another (different) piece of information.

[0218] The names of network elements, network functions, protocols and methods are based on current standards. In other versions or other technologies, the names of these network elements and / or network functions and / or protocols and / or methods may be different, as long as they provide corresponding functions. The same applies to the corresponding terminals.

[0219] Unless otherwise specified or the context clearly indicates, two entities are different in that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each entity described in this specification can be based on different hardware, or some or all entities can be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each entity described in this specification can be based on different software, or some or all entities can be based on the same software. Each entity described in this specification can be deployed in the cloud.

[0220] Based on the above description, it should be apparent that the example embodiments provide, for example, a network function (such as an initiating network function or a responding network function, or an element thereof), an apparatus embodying the network function, a method for controlling and / or operating the network function, (multiple) computer programs for controlling and / or operating the network function, and a medium that carries (multiple) such computer programs and forms (multiple) computer program products.

[0221] Implementations of any of the above boxes, devices, systems, techniques or methods include (as non-limiting examples) implementations of hardware, software, firmware, dedicated circuits or logic, general purpose hardware or controllers or other computing devices, or some combination thereof. Each entity described in this specification may be embodied in the cloud.

[0222] It should be understood that the above description is what is presently considered to be the preferred exemplary embodiment. However, it should be noted that the description of the preferred exemplary embodiment is given by way of example only and that various modifications may be made without departing from the scope of the disclosure as defined in the appended claims.

[0223] Unless otherwise specified, the terms "first X" and "second X" include options where "first X" is the same as "second X" and "first X" is different from "second X". As used herein, "at least one of: " and "at least one of " and similar expressions, where a list of two or more elements is connected by "and" or "or", mean at least any one element, or at least any two or more elements, or at least all elements.

Claims

1. A device for authentication, comprising: one or more processors, and a memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: Notifying a responding entity of two or more first key exchange schemes, each first key exchange scheme comprising: a respective key exchange supported by an initiating entity for communication between the responding entity and the initiating entity; receiving, in response to notifying the responding entity of the two or more first key exchange schemes, an indication of a selected key exchange scheme from the responding entity; checking whether the selected key exchange scheme is a hybrid key exchange scheme; and, in response to checking that the selected key exchange scheme is not the hybrid key exchange scheme: denying said communication between said responding entity and said initiating entity; or performing the communication by exchanging keys according to the selected key exchange scheme and sending an alert indicating that the key exchange scheme different from the hybrid key exchange scheme is used for the communication; wherein: The two or more first key exchange schemes include the hybrid key exchange scheme; The hybrid key exchange scheme internally includes at least two key exchanges based on different encryption assumptions.

2. The apparatus of claim 1 , wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: In response to checking that the selected key exchange scheme is not the hybrid key exchange scheme, notifying the requesting entity that the communication is rejected; wherein The communication is requested in response to a request from the requesting entity. The apparatus of claim 1 , wherein the communication comprises at least one of: a handshake and transmission of a payload.

4. The device according to claim 3, wherein at least one of the following: - the handshake is a transport layer security handshake; or - The payload is a javascript object notation web encryption payload.

5. The apparatus of claim 1, wherein the hybrid key exchange scheme comprises a traditional key exchange and a post-quantum key exchange. The apparatus of claim 1 , wherein the entity is a network function or a security edge protection agent.

7. A device for authentication, comprising: one or more processors, and a memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: receiving, at a responding entity, information that an initiating entity supports two or more first key exchange schemes, each first key exchange scheme comprising: a respective key exchange for communications between the responding entity and the initiating entity; selecting one of the first key exchange schemes as the selected key exchange scheme; In response to receiving the information indicating that the initiating entity supports the two or more first key exchange schemes, notifying the initiating entity of the key exchange schemes, wherein: The two or more first key exchange schemes include a hybrid key exchange scheme; The hybrid key exchange scheme includes at least two key exchanges based on different cryptographic assumptions.

8. The apparatus of claim 7, wherein the instructions, when executed by the one or more processors, further cause the apparatus to perform: checking whether the responding entity supports at least one first key exchange scheme of the two or more first key exchange schemes; In response to checking that the responding entity does not support at least one of the two or more first key exchange schemes, rejecting the communication.

9. The apparatus of claim 7, wherein the communication comprises at least one of: a handshake and transmission of a payload.

10. The device according to claim 9, wherein at least one of the following: - the handshake is a transport layer security handshake; or - The payload is a javascript object notation web encryption payload.

11. The apparatus of claim 7, wherein the hybrid key exchange scheme comprises a traditional key exchange and a post-quantum key exchange.

12. The apparatus of claim 7, wherein the entity is a network function or a security edge protection agent.

Images