FIELD OF THE INVENTION

The invention relates to an electronic key exchange method, a first network node, a second network node, a computer readable medium. BACKGROUND

Quantum computers pose a significant threat to modern cryptography. Two most widely adopted public key cryptosystems, namely, RSA and Elliptic Curve

Cryptography (ECC), will be broken by general purpose quantum computers. RSA is adopted in TLS from Version 1.0 and to TLS Version 1.3: RFC2246, RFC4346, RFC5246. ECC is enabled, e.g., in RFC 4492 and adopted in TLS version 1.2, RFC5246 and version 1.3. On the other hand, there exist several quantum-safe cryptosystems that deliver similar performance, yet are conjectured to be robust against quantum computers.

Currently, TLS is being updated to TLS 1.3 introducing a number of improvements towards improved efficiency and security. Version 19 of the new TLS 1.3 has been published (see document draft-ietf-tls-tls 13-19, published, e.g., at

https://datatracker.ietf.org/doc/draft-ietf-tls-tlsl3/, included herein by reference).

Simultaneously, an increased awareness on quantum attacks is motivating the introduction of a hybrid handshake. This hybrid TLS (QH-TLS) handshake aims at ensuring confidentiality of the communications even if a quantum-computer is built and then classical cipher suites are broken. The basic idea is that the secret key used to protect the traffic is derived from both a secret derived from a classical key exchange (e.g., ECDH) and a quantum-resistant key exchange (e.g., LWE-based DH, RLWE-based DH, SIDH.

Hybrid keys introduce a problem. For example, in the context of TLS 1.3, the problem refers to the way a client and server in TLS 1.3 can agree on the hybrid group.

Currently, this is done by exchanging fixed hybrid groups in the extension field

supported groups. However, there are a limited number of entries and there are many potential hybrid groups. For instance, consider different algorithms such as RLWE, LWE, Isogeny-based Diffie-Hellman key exchanges. Considering, that for many of those schemes there are several variants with pros and cons regarding performance and security. It is not feasible to express this variety in a few hybrid groups. The exchange of hundreds of hybrid groups would not be an efficient alternative.

SUMMARY OF THE INVENTION

It would be advantageous to have an improved key exchange. An electronic method for a cryptographic key-exchange between a first network node and a second network node is provided. The method comprises

sending by the first network node to the second network node an initial key- exchange message, said message comprising multiple indications of key-exchange protocols, the first network node supporting the key-exchange protocols indicated in the message, and a first network node key-exchange policy,

the second network node being configured with a second network node key- exchange policy, the second network node

selecting a group comprising key-exchange protocols indicated in the message satisfying the first network node key-exchange policy and the second network node key- exchange policy

sending to the first network node an indication of the selected satisfying supported group.

A group is found which is acceptable to both the first and second network node, with very little overhead.

The first and second network nodes are electronic devices, e.g., a mobile electronic device. For example, a network node may be a mobile phone, set-top box, smart- card, computer, etc.

A method according to the invention may be implemented on a computer as a computer implemented method, or in dedicated hardware, or in a combination of both.

Executable code for a method according to the invention may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product comprises non-transitory program code stored on a computer readable medium for performing a method according to the invention when said program product is executed on a computer.

In a preferred embodiment, the computer program comprises computer program code adapted to perform all the steps of a method according to the invention when the computer program is run on a computer. Preferably, the computer program is embodied on a computer readable medium.

Another aspect of the invention provides a method of making the computer program available for downloading. This aspect is used when the computer program is uploaded into, e.g., Apple's App Store, Google's Play Store, or Microsoft's Windows Store, and when the computer program is available for downloading from such a store.

BRIEF DESCRIPTION OF THE DRAWINGS

Further details, aspects, and embodiments of the invention will be described, by way of example only, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. In the Figures, elements which correspond to elements already described may have the same reference numerals. In the drawings,

Fig. 1 schematically shows the message flow in a full TLS 1.3 handshake, Figs. 2 and 3 schematically shows data flow of a zero round trip quantum-safe

Fig. 4a schematically shows an example of an embodiment of a cryptographic system for a cryptographic key-exchange between a first network node 400 and a second network node 500.

Fig. 4b schematically shows an example of an embodiment of a cryptographic method for a cryptographic key-exchange between a first network node and a second network node.

Fig. 5a schematically shows a computer readable medium having a writable part comprising a computer program according to an embodiment,

Fig. 5b schematically shows a representation of a processor system according to an embodiment,

Fig. 6a schematically shows an example of an embodiment of a cryptographic method for a cryptographic key-exchange between a first network node and a second network node,

Fig. 6b schematically shows an example of an embodiment of a cryptographic method for a cryptographic key-exchange between a first network node and a second network node,

Fig. 7a schematically shows an example of an embodiment of a first and second network node, Fig. 7b schematically shows an example of an embodiment of a first and second network node.

DETAILED DESCRIPTION OF THE EMBODIMENTS

While this invention is susceptible of embodiment in many different forms, there are shown in the drawings and will herein be described in detail one or more specific embodiments, with the understanding that the present disclosure is to be considered as exemplary of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described.

In the following, for the sake of understanding, elements of embodiments are described in operation. However, it will be apparent that the respective elements are arranged to perform the functions being described as performed by them.

Further, the invention is not limited to the embodiments, and the invention lies in each and every novel feature or combination of features described herein or recited in mutually different dependent claims.

With the threat of quantum computers, it has been proposed to design hybrid solutions in which one or several quantum-resistant key exchanges are executed next to a classical key exchange so that the cryptographic key used to protect the channel depends on both a classical and at least a quantum-resistant key exchange.

Hybrid keys introduce a problem. For example, in the context of TLS 1.3, the problem refers to the way a client and server in TLS 1.3 can agree on the hybrid group. Currently, this is done by exchanging fixed hybrid groups in the extension field

supported groups. However, there are a limited number of entries and there are many potential hybrid groups. For instance, consider different algorithms such as RLWE, LWE, Isogeny-based Diffie-Hellman key exchanges. Considering, that for many of those schemes there are several variants with pros and cons regarding performance and security. It is not feasible to express this variety in a few hybrid groups. Consider that a client might have as hybrid groups: (spLWR quantum, SIDH quantum, ECDH 256) and (NTRU high,

ECDH 512). However, the server might rather prefer a different group including

(spLWR_paranoid, NTRU high, ECDH 512). The reason for this preference would be that the server has a policy that requires, say, a hybrid group with at least 2 different quantum- resistant key exchanges and that specific server does not trust SIDH. It is clear that expressing all hybrid groups with all potential variants cannot be done with a few hundred of identifiers since there are many more options. Furthermore, the exchange of hundreds of hybrid groups would not be an efficient alternative.

Hybrid keys may be used in a number of contexts, but they have the same associated problem as sketched above for TLS. In addition to Transport Later Security (TLS), there a number of network protocols such as or IPSec using the Internet Key Exchange or the secure shell (SSH). There are a number of Virtual Private Network (VPN) protocols that allow a secure connection over the Internet, e.g., based on TLS or IPSec. In these protocols, the security is negotiated between two end points, e.g., client/server in TLS or

initiator/responder in IKE.

In other relevant protocols, e.g., MacSec specified in IEEE 802.1AE, a connectionless data confidentiality and integrity protection is defined. In the case of MacSec, key management and establishment is specified in 802.1x-2010. This protocol basically defines how to encapsulate EAP over LAN supporting service identification and point-to- point encryption over the local LAN network. Thus, such type of VPNs based on MacSec are managed by a central entity, in this case, the authenticator server.

In an embodiment, a client exchanges proposed hybrid groups as indicated in the previous paragraph and then the server applies its own preferences to construct a new hybrid group that is then proposed to the client, for instance, by sending the selected group (spLWR_paranoid, NTRU high, ECDH 512).

The construction of such a group can be done by:

- Scanning all proposed groups and searching the group that is closest to the own policy regarding number of quantum-resistant trusted group.

- Removing from that hybrid group non-trusted groups

- Adding to that group other quantum-resistant trusted groups available in other hybrid groups.

Version 03 of the 'Quantum-Safe Hybrid (QSH) Ciphersuite for Transport Layer Security (TLS) version 1.3' has been published (see document draft-whyte-qsh-tlsl3- 03.txt, published, e.g., at https://tools.ietf.org/html/draft-whyte-qsh-tlsl3-03, included herein by reference).

The latter document describes the Quantum-Safe Hybrid ciphersuite, which provides a modular design for quantum-safe cryptography to be adopted in the handshake for the Transport Layer Security (TLS) protocol version 1.3. The present application provides a number of improvements thereon. Below parts of this document are adopted herein for reference: This document describes a modular design that allows one or many quantum- safe cryptosystems to be adopted in the handshake protocol, applicable to TLS Version 1.3 [TLS 1.3]. It uses a hybrid approach that combines a classical handshake mechanism with key encapsulation mechanisms instantiated with quantum-safe encryption schemes. The modular design provides quantum-safe features to TLS 1.3 without any introduction of extra cipher suites. Yet, it allows the flexibility to include new and advanced quantum-safe encryption schemes at present and in the future.

Extensions to TLS 1.2 [RFC5246] and earlier versions can be found in " Quantum- SafeHybrid (QSH) Ciphersuite for Transport Layer Security (TLS) version 1.2", draft-whyte-qsh-tls 12-00, referred to as [QSH 12].

2. Modular design for quantum-safe hybrid handshake This document introduces a modular approach to including new quantum- safe key exchange algorithms within TLS 1.3, while maintaining the assurance that comes from the use of already established cipher suites. It allows the TLS premaster secret to be agreed using both an established classical cipher suite and a quantum-safe key encapsulation mechanism. See fig. 1 for a Message flow in a full TLS 1.3 handshake. Fig. 1 shows all messages involved in the TLS key establishment protocol (aka full handshake). The addition of quantum-safe cryptography has direct impact only on the ClientHello, the HelloRetryRequest, and the ServerKeyShare messages. In the rest, of this document, we describe each quantum-safe key exchange data structure in greater detail in terms of the content and processing of these messages.

The authentication is provided by classical cryptography. The introduction of quantum-safe encryption schemes delivers forward secrecy against quantum attackers. The additional cryptographic data exchanged between the client and the server is shown in Fig. 2 and 3.

Fig. 2 illustrates the data flow of a zero round trip quantum-safe handshake for TLS. This handshake is proceeded when 1) the classical key exchange is also zero round trip, and 2) the server supports the QSH schemes from QSHPKList.

In the case that the server does not support the QSH schemes from QSHPKList, the server will reply with a HelloRetryRequest, which results into a full handshake, see fig. 3.

As usual, the ClientHello message includes the list of classical cipher suites the client wishes to negotiate (e.g., TLS ECDH ECDSA WITH NULL SHA). In addition, there will be two potential extension fields indicating qshData and qshNegotiate extensions. The ClientHelloExtension field MUST have qshData extension field:' o QSHPKList: a list of distinct public keys for QSH Scheme from the client, each public key for a distinct quantum safe encryption scheme supported by the client.

The ClientHelloExtension field MAY have qshNegotiate extension field: o QSHSchemelDList:

a list of distinct QSHSchemelDs from the client,

each ID represents a quantum safe encryption

scheme/parameter set supported by the client QSHSchemelDList must not list the scheme IDs whose public key is already included in the QSHPKList.

If the server supports QSH schemes/parameter sets for the public keys received from QSHPKList, the server will proceed the zero round trip handshake, provided that the zero round trip is also permitted by classical handshake. If not, the server will pick a (list of) QSHSchemelD(s) from the QSHSchemelDList to form the

AcceptQSHSchemelDList, and request public keys for those schemes in a

HelloRetryRequest message. If the server does not support any of the QSH schemes from either QSHPKList or QSHSchemelDList, the server will abort the handshake.

The extension field of the HelloRetryRequest message MUST have an qshNegotiate extension field:

o AcceptQSHSchemelDList:

a list of distinct QSHSchemelDs from the server,

each ID represents a quantum safe encryption

scheme/parameter set supported/selected by the server

The ServerKeyShare message contains an indication of the classical cipher suite selected, and the ServerKeyShare material appropriate to that cipher suite. Additionally, the ServerKey ShareExtension (a.k.a. EncryptedExtension) field message MUST contain a qshData extension field listing ciphertexts:

o QSHCipherList:

a list of ciphertests

[Encrypt_QSHPKl(QSHSl)]|[Encrypt_QSHPK2(QSHS2)]|...

where the QSH secret keying material is

QSHSecret = QSHS1 |QSHS2|..., and QSHPKi is from QSHPKList.

The final premaster secret negotiated by the client and the server is the concatenation of the classical premaster secret, QSHSecret, QSHPK1 |QSHPK2|... in that order. A 48 bytes fixed length master secret is derived from the premaster secret at the end of the handshake, using a pseudo random function specified by the classical cipher suite (see Section 8.1. RFC 5246 [RFC5246]).

Meaning of these extensions:

qshNegotiate extension allows a client to send a QSHSchemelDList that enumerates QSHSchemelDs for supported quantum safe cryptosystems.

qshData extension allows a client to send a QSHPKList of public keys for quantum-safe encryption schemes.

Note: QSHSchemelD MUST be distinct in QSHSchemelDList. If qshNegotiate extension and qshData extension are both send within a same ClientHello extension, QSHSchemelDList must not enumerate QSHschemelDs whose public keys are already in QSHPKList.

3.3. HelloRetryRequest Extensions

This section specifies a TLS extension that can be included with the

HelloRetryRequest message as described in [TLS 1.3].

When this extension is sent: The server will send this message in response to a ClientHello message where the extension fields contains a extension type quantum- safe-hybrid, when it was able to find an acceptable set of QSHSchemes from qshNegotiate but not from qshData. If it cannot find such a match, it will respond with a handshake failure alert.

Meaning of this extension:

This extension allows a server to notify the client the ID(s) for the quantum- safe encryption scheme(s) it chooses from the QSHSchemelDList.

Actions of the sender:

The server selects a number of QSHSchemelDs in response to a ClientHelloExtension message. The selection is based on client's preference. The

QSHSchemelDs selected MUST exist in the received QSHSchemelDList. The server form the acceptQSHSchemelDList with the list of selected QSHSchemelDs. Actions of the receiver:

A client that receives a HelloRetryRequest message containing an extension type qshNegotiate will extract the agreed QSHSchemelDs and from the

acceptQSHSchemelDList. Those QSHSchemelDs will be used when the client generates another ClientHello message.

In summary, the current QH-TLS describes a number of potential extensions to create a hybrid TLS exchange for TLS 1.3. In particular, it describes the following:

Introduces the concept of a hybrid group, i.e., a group that does not identify a single mathematical structure such as an ECC Diffie Hellman key exchange but a set of them. The client can use the key share extension to exchange the hybrid group (components and public keys). The server than replies with the chosen hybrid group in the key share. The client uses the supported group extension to exchange the supported groups without including the actual public keys. The definition of the hybrid groups is exchanged in a new (not defined in TLS 1.3 vl 9) header called hybrid extension.

Fig. 4a schematically shows an example of an embodiment of a cryptographic system for a cryptographic key-exchange between a first network node 400 and a second network node 500. In the context of TLS, the first network node may, e.g., be a client, and the second network node may, e.g., be a server. Fig. 4a shows a communication link between first network node 400 and second network node 500.

Fig. 4b schematically shows an example of an embodiment of a cryptographic method 402 for a cryptographic key-exchange between a first network node 400 and a second network node 500.

Method 402 comprises

By first network node 400:

- sending 410 to the second network node an initial key-exchange message. The message comprising a list of supported groups. A supported group comprises at least one indication of a key-exchange protocol. For example, the first and second client may both recognize fixed abbreviations for various key exchange protocols. A key exchange protocol may also include a security strength indication, e.g., a key length.

At least one of the supported groups comprises multiple key-exchange protocol indications, the first network node supporting the key-exchange protocols indicated in the supported groups.

Optionally, first network node 400 may also send 410 to second network node 500 with the initial key-exchange message, key shares corresponding to one or more of the indicated supported groups.

Typically, these are the same the message.

A key share contains the cryptographic parameters needed for establishing a shared key, shared between the first and second network node. It is assumed a key exchange protocol works by selecting a private key and a public key share. Two parties, e.g., the first and second network node send each other a key share and combined their own private key with the received public key share. There are many key exchange protocols that follow this template, for example, various Diffie-Hellman style key exchange protocols. In an embodiment, the key share may be implemented as in section 4.2.5 of draft-ietf-tls-tls 13-19. For example, a key share may comprise the value g ^x in some suitable mathematical group, with private key x. Upon receiving a corresponding key share with g ^y , a network node can compute a shared key from g ^xy .

Method 402 further comprises, by second network node 500

- determining 510 if any of the supported groups satisfy the second network node key-exchange policy. Second network node 500 is configured with a second network node key-exchange policy, which, e.g., may be stored in a storage of network node 500. The second network node key-exchange policy determines the hybrid groups that are acceptable by second network node 500.

For example, a key exchange policy may comprise one or more parameters that define one or more of the following conditions

a minimum number of protocols from a first group of key-exchange protocols, e.g., quantum-resistant key-exchange protocols,

a minimum security level of the protocols in the first group,

- a minimum number of protocols from a second group of key-exchange protocols, e.g., classical key-exchange,

a minimum security level of the protocols in the second group, a list of untrusted algorithms.

For example, a second network node key exchange policy maybe (minimum: 2; security level: quantum; non-trusted: SIDH). The server could accept a hybrid group (ECDH 1024, LWE quantum, RLWE quantum).

If the determination was successful, the second network node 500 may select 522 a satisfying supported group. If multiple groups can be chosen, then preferably second network node 500 selects a group for which network node 400 already sent key shares.

send 532 to the first network node an indication of the selected satisfying supported group, and

send 542 to the first network node a key share for each of the key- exchange protocols in the selected satisfying supported group. The latter two may be in a same message.

If the determination was unsuccessful, the second network node 500 may - determining 524 if any of the supported groups with the addition of at least one further key-exchange protocol indicated in at least one other of the supported groups satisfy the second network node key-exchange policy, and if so

selecting 534 a supported group with the addition of the at least one key-exchange protocol

- sending 544 to the first network node an indication of the selected supported group with the addition of at least one key-exchange protocol.

send 554 to the first network node a key share for each of the key- exchange protocols in the selected supported group with the addition of at least one key- exchange protocol. The latter two may be in a same message.

At this point it may happen that both nodes key shares for all key exchange protocols in a selected group, possibly with one or more additional protocols. If so, then both network nodes can compute a shared key. For example, this may happen in case in part 420 the correct key shares were sent. If not, the first network node 400 now sends the key shares, or at least the missing key shares. For example, first network node 400 may

- send 430 to the second network node, in response the selected satisfying supported group or in the selected supported group with the addition of at least one key-exchange protocol to receiving from the second network node, one or more key shares corresponding to each of the key-exchange protocols in the selected satisfying supported group or in the selected supported group with the addition of at least one key-exchange protocol.

In an embodiment, key shares for the same key exchange protocol are not sent twice.

Each of the first and second node computes the shared key, by derive 460, 560 an intermediate key for each of the key-exchange protocols in the selected satisfying supported group or in the selected supported group with the addition of at least one key-exchange protocol from a corresponding received key share and a private key share,

- derive 465, 565 a final key by applying a key derivation function to the derived intermediate keys.

The key derivation function can be a hash, etc.

In an embodiment, first network node 400 may be configured to use the TLS key share extension to exchange the group, including key shares, the second network node being configured to reply with the selected group in a key share message.

A different embodiment comprises expressing the desired type of exchange and its properties instead of determining a fixed (set of) groups. Both client and server can then express and exchange required properties for a hybrid handshake including:

- Minimum number of quantum-resistant algorithms (e.g., 3).

- Desired security level of quantum-resistant algorithms (e.g., quantum, paranoid, etc.)

- Not trusted quantum-resistant algorithms (e.g., SIDH)

- Minimum security level of classical key exchange (e.g., ECDH 1024) With this approach, the client expresses its preferences as above, and then the server compares them with the own preferences. The server then makes a proposal to the client fulfilling the client's preferences.

For instance, if the preferences of the client are (minimum: 2; security level: quantum; non-trusted: SIDH), then the server can send back a hybrid group including the key shares for (ECDH 1024, LWE quantum, RLWE quantum).

An embodiment may comprise the following parts:

An electronic method for a cryptographic key-exchange between a first network node and a second network node, the method comprising

- sending by the first network node to the second network node an initial key- exchange message, said message comprising multiple indications of key-exchange protocols, the first network node supporting the key-exchange protocols indicated in the message, and a first network node key-exchange policy,

- sending key shares (optional) corresponding to one or more supported key- exchange protocols. - selecting by the second network node a group comprising key-exchange protocols indicated in the message satisfying the first network node key-exchange policy and the second network node key-exchange policy,

- sending by the second network node to the first network node an indication of the selected satisfying supported group,

- sending by the second network node to the first network node a key share for each of the key-exchange protocols in the selected supported group with the addition of at least one key-exchange protocol.

- sending to the second network node (optional), in response to receiving the selected supported group with the addition of at least one key-exchange protocol, one or more key shares corresponding to each of the key-exchange protocols in the selected supported group with the addition of at least one key-exchange protocol.

Finally, the two nodes can each:

- derive an intermediate key for each of the key-exchange protocols in the selected satisfying supported group or in the selected supported group with the addition of at least one key-exchange protocol from a corresponding received key share and a private key share, and

- derive a final key by applying a key derivation function to the derived intermediate keys.

Because the key derivation is applied to multiple intermediate keys, the final key is secure as long as at least one of the intermediate keys are secure.

Selecting by the second network node a group satisfying the first and second network node key-exchange policy and the second network node key-exchange policy may be done by generating a joint key-exchange policy by combining the first network node and second network node key-exchange policies. For example, the second network may select the larger of the minimums that may be in the policy. For example, the second network may compute the intersection of the first, e.g., quantum resistant, groups and the intersection of the second, e.g., classic, groups.

Interestingly, embodiments need not be applied to quantum safe or not quantum safe protocols but any suitable division may be made. This makes the key exchange future safe, as it is protected from advances in individual key exchange protocols.

The above embodiment may be applied in to protocols involving two devices, e.g., TLS, IKE, or SSH. However, in other protocols and systems there is an orchestrator in charge of distributing some keying material used to protect the communication channel. This is the case of MacSec since MacSec is applied to Ethernet Networks and a number of stations might be in the same group. All the stations in the same group are using the same symmetric- key as distributed by the orchestrator by means of EAP. The above problem becomes more complex in this setting because the individual negotiation between multiple stations and the orchestrator. Aspects for consideration are for instance: (i) different stations have different minimum security requirements, (ii) an adversary can attack the weakest hybrid link.

A solution to this problem is that the orchestrator publishes its security policy to join specific network groups with specific security requirements. This can be done during a handshake between a station and the orchestrator or beforehand, if the orchestrator broadcasts its security requirements regarding hybrid handshakes.

In a network with N stations, the first station communicating with the orchestrator has to learn the preferences of the orchestrator during the handshake as well as any set of public parameters. However, the remaining stations can learn these parameters by observing the communication between the first station and the orchestrator. This can speed up the setup phase.

Other public security parameters can also be shared during the same session in order to minimize the communication overhead, for instance, in a LWE key exchange, the public matrix A that is derived from a seed can be reused by all stations. This allows them to compute their public keys (b = As + e) in advance. Furthermore, the orchestrator only has to keep a single matrix A in memory and use it to compute the public key with each of the stations.

In an embodiment, there is a single second network node, e.g., a server, for multiple first network nodes, e.g., clients. The second network node verifies satisfying multiple key-exchange policies, e.g., a key exchange policy of all clients. If a client joints with a key exchange policy that is stricter than those of the existing nodes, the second network node may trigger a re -keying to resolve this.

Embodiment, may use, or may also use, so-called pre-shared keys or PSK. Pre-shared keys are quantum-resistant, and therefore, they can be used next to other algorithms, e.g., a classical key exchange, to ensure the confidentiality of the exchanged information. This is currently proposed for IKE. Here, the idea is that initiator and responder share a common key that is used together with a key derived from a ECC Diffie-Hellman key exchange. This ensure that even if the ECDH exchange is not secure anymore, and therefore, advanced security properties such as forward secrecy are lost, message confidentiality is still ensured by the shared symmetric key. There is a challenge to this approach. We illustrate this by describing the situation in TLS 1.3 and the usage there of PSKs. In TLS 1.3 vl9, a PSK can be used in two modes, either standalone to enable a 0-RTT handshake or next to a ECDH key exchange with the purpose of authentication, and not confidentiality. In this case, the origin of a PSK is not defined so that the PSK could be derived from a previous TLS handshake in which a ECDH key exchanged was performed. Thus, even if this key is a PSK, this is not a quantum-resistant key. Furthermore, in the current version of the quantum-hybrid TLS key exchange, the usage of is described. However, they are used as part of a quantum-hybrid group so that they do not enable a 0-RTT handshake.

These issues can be overcome if two things are done. First, a PSK should include its quantum-resistant features. In particular, it is not even enough to describe whether the key was generated from a classical key exchange or not, but it is also required to describe which quantum-resistant key exchanges were used. The reason is that if at later point of time an attack against a quantum-resistant KEX is discovered, then a PSK derived only from it should not be considered quantum-resistant. Thus, a PSK could include information such as:

Generation or distribution time

Algorithms used in the generation or distribution

Strength of the algorithms used in the generation or distribution When two devices search for common PSKs based on a PSK identity, the devices should also make use of a policy that defines the required properties for a PSK in order to be used as part of a hybrid key exchange.

In the context of TLS 1.3, the current specification of the quantum-hybrid TLS for PSKs can be improved to support quantum-resistant PSKs and 0-RTT handshake as follows.

a new mode psk qh mode should be sent in the psk key extension mode

(section 4.2.6 in TLS 1.3 vl9). The usage of this mode implies that only quantum-resistant PSKs can be used and that such PSKs can be used next to keys derived from a key exchanged based on either classical groups or hybrid groups including quantum-resistant groups.

The corresponding PSK identities would be exchanged in the PSK Extension. When the client and/or server search for a common PSK, the client and server shall also verify that the origin of the PSK key is suitable for a quantum-resistant key exchange by verifying the metadata stored together with the key.

In an embodiment, the first network node and second network node store one or more pre-shared keys and corresponding meta-data, the meta-data comprising the key- exchange protocol used in the generation or distribution of said pre-shared key, and a pre- shared key identity, at least one of the key-exchange protocol indications referring to a pre- shared key identity, wherein the second network node is configured to use the meta-data to verify if the pre-shared key satisfies the second network node key-exchange policy.

The execution of the methods may be implemented in a processor circuit, examples of which are shown below. For example, functional units may be wholly or partially implemented in computer instructions that are stored at the network node 400 or 500 and are executable by a microprocessor of the node. In hybrid embodiments, functional units may be implemented partially in hardware, e.g., as coprocessors, e.g., crypto coprocessors, and partially in software stored an executed on the node.

In the various embodiments of the network nodes, communication interfaces may be selected from various alternatives. For example, input interface may be a network interface to a local or wide area network, e.g., the Internet, a storage interface to an internal or external data storage, a keyboard, an application interface (API), etc.

The network nodes may have a user interface, which may include well-known elements such as one or more buttons, a keyboard, display, touch screen, etc. The user interface may be arranged for accommodating user interaction for performing a key exchange action.

The network nodes, e.g., nodes 400 and 500, may comprise storage which may be implemented as an electronic memory, say a flash memory, or magnetic memory, say hard disk or the like. The storage may comprise multiple discrete memories together making up storage. The storage may also be a temporary memory, say a RAM. In the case of a temporary storage, the network node may contain means to obtain data before use, say by obtaining them over an optional network connection.

Typically, the network nodes, e.g., nodes 400 and 500 each comprise a microprocessor (not separately shown) which executes appropriate software stored at the nodes; for example, that software may have been downloaded and/or stored in a

corresponding memory, e.g., a volatile memory such as RAM or a non- volatile memory such as Flash (not separately shown). Alternatively, the nodes may, in whole or in part, be implemented in programmable logic, e.g., as field-programmable gate array (FPGA). The network nodes may be implemented, in whole or in part, as a so-called application-specific integrated circuit (ASIC), i.e. an integrated circuit (IC) customized for their particular use. For example, the circuits may be implemented in CMOS, e.g., using a hardware description language such as Verilog, VHDL etc. A processor circuit may be implemented in a distributed fashion, e.g., as multiple sub-processor circuits. A storage may be distributed over multiple distributed sub- storages. Part or all of the memory may be an electronic memory, magnetic memory, etc. For example, the storage may have volatile and a non- volatile part. Part of the storage may be read-only.

Many different ways of executing the method are possible, as will be apparent to a person skilled in the art. For example, the order of the steps can be varied or some steps may be executed in parallel. Moreover, in between steps other method steps may be inserted. The inserted steps may represent refinements of the method such as described herein, or may be unrelated to the method. For example, some parts may be executed, at least partially, in parallel. Moreover, a given step may not have finished completely before a next step is started.

A method according to the invention may be executed using software, which comprises instructions for causing a processor system to perform method according to an embodiment, e.g., method 402. The software may also be configured to execute only the client or only the server side of the method. Software may only include those steps taken by a particular sub-entity of the system. The software may be stored in a suitable storage medium, such as a hard disk, a floppy, a memory, an optical disc, etc. The software may be sent as a signal along a wire, or wireless, or using a data network, e.g., the Internet. The software may be made available for download and/or for remote usage on a server. A method according to the invention may be executed using a bitstream arranged to configure programmable logic, e.g., a field-programmable gate array (FPGA), to perform the method.

It will be appreciated that the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in any other form suitable for use in the implementation of the method according to the invention. An embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the processing steps of at least one of the methods set forth. These instructions may be subdivided into subroutines and/or be stored in one or more files that may be linked statically or dynamically. Another embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the means of at least one of the systems and/or products set forth. Fig. 5a shows a computer readable medium 1000 having a writable part 1010 comprising a computer program 1020, the computer program 1020 comprising instructions for causing a processor system to perform a method of key exchange, e.g., for a first network node, e.g., a client, or for a second network node, e.g., a server, or for both, according to an embodiment. The computer program 1020 may be embodied on the computer readable medium 1000 as physical marks or by means of magnetization of the computer readable medium 1000. However, any other suitable embodiment is conceivable as well. Furthermore, it will be appreciated that, although the computer readable medium 1000 is shown here as an optical disc, the computer readable medium 1000 may be any suitable computer readable medium, such as a hard disk, solid state memory, flash memory, etc., and may be non- recordable or recordable. The computer program 1020 comprises instructions for causing a processor system to perform said a method of key exchange, e.g., for a first and/or second network node.

Fig. 5b shows in a schematic representation of a processor system 1140 according to an embodiment. The processor system 1140 may implement a first and/or second network node according to an embodiment, e.g., client and/or a server. The processor system comprises one or more integrated circuits 1110. The architecture of the one or more integrated circuits 1110 is schematically shown in Fig. 5b. Circuit 1110 comprises a processing unit 1120, e.g., a CPU, for running computer program components to execute a method according to an embodiment and/or implement its modules or units. Circuit 1110 comprises a memory 1122 for storing programming code, data, etc. Part of memory 1122 may be read-only. Circuit 1110 may comprise a communication element 1126, e.g., an antenna, connectors or both, and the like. Circuit 1110 may comprise a dedicated integrated circuit 1124 for performing part or all of the processing defined in the method. Processor 1120, memory 1122, dedicated IC 1 124 and communication element 1126 may be connected to each other via an interconnect 1130, say a bus. The processor system 1110 may be arranged for contact and/or contact-less communication, using an antenna and/or connectors, respectively.

For example, in an embodiment, a first and/or second network node configured for key exchange according to an embodiment may comprise a processor circuit and a memory circuit, the processor being arranged to execute software stored in the memory circuit. For example, the processor circuit may be an Intel Core \Ί processor, ARM Cortex - R8, etc. In an embodiment, the processor circuit may be ARM Cortex M0. The memory circuit may be an ROM circuit, or a non- volatile memory, e.g., a flash memory. The memory circuit may be a volatile memory, e.g., an SRAM memory. In the latter case, the device may comprise a non- volatile software interface, e.g., a hard drive, a network interface, etc., arranged for providing the software.

The following list of numbered clauses provide embodiments of cryptographic key-exchange between a first network node and a second network node.

1. An electronic method for a cryptographic key-exchange between a first network node and a second network node, the method comprising

- sending by the first network node to the second network node an initial key- exchange message, said message comprising a list of supported groups, a supported group comprising at least one indication of a key-exchange protocol, at least one of the supported groups comprising multiple key-exchange protocol indications, the first network node supporting the key-exchange protocols indicated in the supported groups,

- the second network node being configured with a second network node key- exchange policy, the second network node determining if any of the supported groups satisfy the second network node key-exchange policy, and

- if so

- selecting a satisfying supported group,

- sending to the first network node an indication of the selected satisfying supported group

- and if not

- determining if any of the supported groups with the addition of at least one further key-exchange protocol indicated in at least one other of the supported groups satisfy the second network node key-exchange policy, and if so

- selecting a supported group with the addition of the at least one key- exchange protocol

- sending to the first network node an indication of the selected supported group with the addition of at least one key-exchange protocol.

2. An electronic method for a cryptographic key-exchange between a first network node and a second network node, the method comprising

- sending by the first network node to the second network node an initial key- exchange message, said message comprising multiple indications of key-exchange protocols, the first network node supporting the key-exchange protocols indicated in the message, and a first network node key-exchange policy, - the second network node being configured with a second network node key- exchange policy, the second network node

- selecting a group comprising key-exchange protocols indicated in the message satisfying the first network node key-exchange policy and the second network node key-exchange policy

- sending to the first network node an indication of the selected satisfying supported group.

3. An electronic method as in clause 1 or 2 wherein the second network node is configured to send to the first network node a key share for each of the key-exchange protocols in the selected satisfying supported group or in the selected supported group with the addition of at least one key-exchange protocol.

4. An electronic method as in clause any one of the preceding clauses, wherein the first network node is configured to send to the second network node with the initial key-exchange message,

- key shares corresponding to one or more of the indicated supported groups, or

- key shares corresponding to one or more supported key-exchange protocols.

5. An electronic method as in clause 3, wherein the first network node is configured to send to the second network node, in response the selected satisfying supported group or in the selected supported group with the addition of at least one key-exchange protocol to receiving from the second network node, one or more key shares corresponding to each of the key-exchange protocols in the selected satisfying supported group or in the selected supported group with the addition of at least one key-exchange protocol.

6. A method as in any one of the preceding clauses, wherein the second network node and the first network node are configured to

- derive an intermediate key for each of the key-exchange protocols in the selected satisfying supported group or in the selected supported group with the addition of at least one key-exchange protocol from a corresponding received key share and a private key share, - derive a final key by applying a key derivation function to the derived intermediate keys.

7. A method as in Clause 1 , wherein the second network node is configured to determine if any of the supported groups

- with the removal of a key-exchange protocol indicated in the supported group satisfies the second network node key-exchange policy.

8. A method as in any one of the preceding clauses, wherein the second network node verifies satisfying multiple key-exchange policies, and wherein the second network node triggers a re-keying if a key-exchange policy is added which does not allow a previously selected group.

9. A method as in clause 2, wherein the second network node generates a joint key-exchange policy by combining the first network node and second network node key-exchange policies before selecting the group satisfying the first network node key- exchange policy and the second network node key-exchange policy, a group of key-exchange protocols satisfying the joint key-exchange policy also satisfying the first network node and second network node key-exchange policy.

10. A method as in any one of the preceding clauses wherein a key- exchange policy comprises one or more parameters defining one or more of the following conditions

- a minimum number of protocols from a first group of key-exchange protocols, e.g., quantum-resistant key-exchange protocols,

- a minimum security level of the protocols in the first group,

- a minimum number of protocols from a second group of key-exchange protocols, e.g., classical key-exchange,

- a minimum security level of the protocols in the second group,

- a list of untrusted algorithms.

11. A method as in any one of the preceding clauses, wherein - the first network node is configured to use the TLS key share extension to exchange the group, including key shares, the second network node being configured to reply with the selected group in a key_share message. 12. A method as in any one of the preceding clauses, wherein the first network node and second network node store one or more pre-shared keys and corresponding meta-data, the meta-data comprising the key-exchange protocol used in the generation or distribution of said pre-shared key, and a pre-shared key identity, at least one of the key- exchange protocol indications referring to a pre-shared key identity, wherein the second network node is configured to use the meta-data to verify if the pre-shared key satisfies the second network node key-exchange policy.

13. A method as in Clause 1, wherein multiple supported groups comprise multiple key-exchange protocols, or wherein all supported groups comprise multiple key-exchange protocols

14. A first network node comprising

- a communication unit configured to digitally communicate with a second network node over a computer network, and

- a process circuit configured for any one of the preceding methods.

15. A second network node comprising

- a communication unit configured to digitally communicate with a first network node over a computer network, and

- a process circuit configured for any one of the preceding methods.

16. A computer readable medium (1000) comprising transitory or non- transitory data (1020) representing instructions to cause a processor system to perform a method according to any of clause 1-13, a first network node side thereof, or a second network node side thereof.

Fig. 6a schematically shows an example of an embodiment of a cryptographic method 601 for a cryptographic key-exchange between a first network node and a second network node. Method 601 comprises: sending 610 by the first network node to the second network node an initial key-exchange message, said message comprising multiple indications of key-exchange protocols, the first network node supporting the key-exchange protocols indicated in the message, and a first network node key-exchange policy, the second network node being configured with a second network node key-exchange policy, the second network node

selecting 611 a group comprising key-exchange protocols indicated in the message satisfying the first network node key-exchange policy and the second network node key-exchange policy

sending 612 to the first network node an indication of the selected satisfying supported group .

Fig. 6b schematically shows an example of an embodiment of a cryptographic method 602 for a cryptographic key-exchange between a first network node and a second network node. Method 602 comprises:

sending 620 by the first network node to the second network node an initial key-exchange message, said message comprising multiple indications of key-exchange protocols, the first network node supporting the key-exchange protocols indicated in the message, and a first network node key-exchange policy, the second network node being configured with a second network node key-exchange policy, the second network node

generating 621 by the second network node a joint key-exchange policy by combining the first network node and second network node key-exchange policies before selecting the group satisfying the first network node key-exchange policy and the second network node key-exchange policy, a group of key-exchange protocols satisfying the joint key-exchange policy also satisfying the first network node and second network node key- exchange policy,

- selecting 622 a group comprising key-exchange protocols indicated in the message satisfying the first network node key-exchange policy and the second network node key-exchange policy

sending 623 to the first network node an indication of the selected satisfying supported group,

- sending 624 by the second network node to the first network node a key share for each of the key-exchange protocols in the selected satisfying supported group.

sending 625 by the first node to the second network node, in response to receiving from the second network node the selected satisfying supported group, one or more key shares corresponding to each of the key-exchange protocols in the selected satisfying supported group.

deriving 626 both by the first and second node an intermediate key for each of the key-exchange protocols in the selected satisfying supported group from a corresponding received key share and a private key share,

deriving 627 both by the first and second node a final key by applying a key derivation function to the derived intermediate keys.

Fig. 7a schematically shows an example of an embodiment of a first network node 630 and a second network node 650. Network nodes 630 and 650 may be implemented using a processor circuit, examples of which are shown herein. Fig. 7a shows functional units may be wholly or partially implemented in computer instructions that are stored at the network node and are executable by a microprocessor of the node. In hybrid embodiments, functional units may be implemented partially in hardware, e.g., as coprocessors, e.g., crypto coprocessors, and partially in software stored an executed on the node.

In the various embodiments of the network nodes, communication interfaces may be selected from various alternatives. For example, input interface may be a network interface to a local or wide area network, e.g., the Internet, a storage interface to an internal or external data storage, a keyboard, an application interface (API), etc.

The network nodes may have a user interface, which may include well-known elements such as one or more buttons, a keyboard, display, touch screen, etc. The user interface may be arranged for accommodating user interaction for performing a key exchange action.

The network nodes may comprise storage which may be implemented as an electronic memory, say a flash memory, or magnetic memory, say hard disk or the like. The storage may comprise multiple discrete memories together making up storage. The storage may also be a temporary memory, say a RAM. In the case of a temporary storage, the network node may contain means to obtain data before use, say by obtaining them over an optional network connection.

Typically, the network nodes each comprise a microprocessor (not separately shown) which executes appropriate software stored at the nodes; for example, that software may have been downloaded and/or stored in a corresponding memory, e.g., a volatile memory such as RAM or a non-volatile memory such as Flash (not separately shown).

Alternatively, the nodes may, in whole or in part, be implemented in programmable logic, e.g., as field-programmable gate array (FPGA). The network nodes may be implemented, in whole or in part, as a so-called application-specific integrated circuit (ASIC), i.e. an integrated circuit (IC) customized for their particular use. For example, the circuits may be implemented in CMOS, e.g., using a hardware description language such as Verilog, VHDL etc.

Fig. 7b schematically shows an example of an embodiment of first network node 630 and second network node 650. For example, first network node 630 may comprise a processor circuit 661, a memory 662, and a communication interface 663. For example, second network node 650 may comprise a processor circuit 664, a memory 665, and a communication interface 666.

Returning to fig. 7a. First network node 630 and second network node 650 are configured for a cryptographic key-exchange between them. First network node 630 supports multiple key-exchange protocols, so that the first and second network node need to agree on a combination of key-exchange protocols that is acceptable to both of them.

First network node 630 comprises an initiation unit configured to send to second network node 650 an initial key-exchange message 641. The initial key-exchange message 641 comprises multiple indications of key-exchange protocols that are supported by first network node 630. Initial key-exchange message 641 further comprises a first network node-key exchange policy. For example, first network node 630 may comprise an

initialization unit 631.

Second network node 650 is also configured with a second network node key- exchange policy, and selection unit 651 is configured to select a group comprising key- exchange protocols indicated in the message satisfying the first network node key-exchange policy and the second network node key-exchange policy. For example, second network node 650 may comprise a selection unit 651.

The first and/or second network node key-exchange policy may, e.g., comprise one or more parameters that a minimum number of key-exchange protocols are to be selected. There are various ways in which minimums may be used. For example, in the protocols a suitable division may be made, e.g., according to the type of exchange. The first and/or second network node key-exchange policy may define a minimum number of protocols from a first group of key-exchange protocols, e.g., quantum-resistant key-exchange protocols, a minimum number of protocols from a second group of key-exchange protocols, e.g., classical key-exchange, etc.

The first and/or second network node key-exchange policy may define other properties of the exchange. For example: a minimum security level of the protocols in the first group, a minimum security level of the protocols in the second group, a list of untrusted algorithms, etc.

To select key-exchange protocols that satisfy both policies, second network node 650, e.g., unit 651 , may be configured to generate a joint key-exchange policy by combining the first network node and second network node key-exchange policies before selecting the group satisfying the first network node key-exchange policy and the second network node key-exchange policy. For example, if both first and second key-exchange policies comprise a minimum, the second network node may compute the larger of the two minimums.

For example, in an embodiment, the initial key exchange message may comprise a list of supported groups, a supported group comprising at least one indication of a key-exchange protocol, at least one of the supported groups comprising multiple key- exchange protocol indications. The first and/or second network node key-exchange policy may express a minimum number of protocols from the groups of key-exchange protocols. The first network node key-exchange policy and the second network node key-exchange policy may comprise a first and second minimum number respectively of key exchange protocols that are to be selected. Second network node 650 may be configured to select the larger of the first and second minimum.

After second network node 650 selected a satisfying supported group, then it sends an indication 642 of the selected satisfying supported group to first network node 630. Moreover, second network node 650 may compute a key share for each of the key-exchange protocols in the selected satisfying supported group. For example, second network node 650 may comprise a key share unit 652 configured to compute key shares for the selected key exchange protocols. The second network node may be configured to send the key shares 643 together with indication 642 of the selected satisfying supported group. First network node 630 could also send key shares together with initial message 641, in the hope that the key exchange protocols for which it sends key shares are selected by second network node 650. However, the latter is optional, in an embodiment first network node 630 is configured not to send key shares to the second network node with the initial key-exchange message.

First network node 630 thus receives from the second node an indication 642 of the selected satisfying supported group together with the key shares 643 for it. First network node 630 is configured to derive an intermediate key for each of the key-exchange protocols in the selected satisfying supported group from a corresponding received key share and a private key share. For example, first network node 630 may comprise an intermediate key derivation unit 632. First network node 630 is also configured to compute one or more key shares 644 corresponding to each of the key-exchange protocols in the selected satisfying supported group, and send them to second network node 650. First network node 630 is configured to derive a final key by applying a key derivation function to the derived intermediate keys. For example, first network node 630 may comprise a final derivation unit 633 to do this.

Second network node 650 also derives the intermediate keys for each of the key-exchange protocols in the selected satisfying supported group from a corresponding received key share and a private key share. For example, second network node 650 may comprise an intermediate key derivation unit 653. Second network node 650 is configured to derive the final key by applying the key derivation function to the derived intermediate keys. For example, second network node 650 may comprise a final derivation unit 654 to do this.

To address the threat of quantum computers, one or several of the intermediate keys may be obtained from a quantum-resistant key exchanges, and an intermediate key may be obtained from a classical key exchange so that the cryptographic key used to protect the channel depends on both a classical and at least a quantum-resistant key exchange.

First network node 630 may be configured to use the TLS key share extension to exchange the group, including key shares, second network node 650 may be configured to reply with the selected group in a key_share message.

The first and second network node may store one or more pre-shared keys and corresponding meta-data. The meta-data comprising the key-exchange protocol used in the generation or distribution of said pre-shared key, and a pre-shared key identity, at least one of the key-exchange protocol indications referring to a pre-shared key identity, wherein the second network node is configured to use the meta-data to verify if the pre-shared key satisfies the second network node key-exchange policy.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments.

In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

In the claims references in parentheses refer to reference signs in drawings of exemplifying embodiments or to formulas of embodiments, thus increasing the intelligibility of the claim. These references shall not be construed as limiting the claim.