WO2018177905A1 - Échange de clés hybride - Google Patents

Échange de clés hybride Download PDF

Info

Publication number
WO2018177905A1
WO2018177905A1 PCT/EP2018/057392 EP2018057392W WO2018177905A1 WO 2018177905 A1 WO2018177905 A1 WO 2018177905A1 EP 2018057392 W EP2018057392 W EP 2018057392W WO 2018177905 A1 WO2018177905 A1 WO 2018177905A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
network node
exchange
protocols
group
Prior art date
Application number
PCT/EP2018/057392
Other languages
English (en)
Inventor
Oscar Garcia Morchon
Original Assignee
Koninklijke Philips N.V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips N.V. filed Critical Koninklijke Philips N.V.
Publication of WO2018177905A1 publication Critical patent/WO2018177905A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms

Definitions

  • the invention relates to an electronic key exchange method, a first network node, a second network node, a computer readable medium.
  • Cryptography 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.
  • 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
  • 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.
  • the problem refers to the way a client and server in TLS 1.3 can agree on the hybrid group.
  • An electronic method for a cryptographic key-exchange between a first network node and a second network node comprises
  • the second network node being configured with a second network node key- exchange policy, the second network node
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Apple's App Store e.g., Apple's App Store, Google's Play Store, or Microsoft's Windows Store
  • 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.
  • Hybrid keys introduce a problem.
  • the problem refers to the way a client and server in TLS 1.3 can agree on the hybrid group.
  • this is done by exchanging fixed hybrid groups in the extension field
  • hybrid groups 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.
  • a client might have as hybrid groups: (spLWR quantum, SIDH quantum, ECDH 256) and (NTRU high,
  • Hybrid keys may be used in a number of contexts, but they have the same associated problem as sketched above for TLS.
  • TLS Transport Later Security
  • IPSec Internet Key Exchange
  • SSH secure shell
  • VPN Virtual Private Network
  • MacSec specified in IEEE 802.1AE
  • a connectionless data confidentiality and integrity protection is defined.
  • 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.
  • VPNs based on MacSec are managed by a central entity, in this case, the authenticator server.
  • 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).
  • This 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.
  • TLS Transport Layer Security
  • the present application provides a number of improvements thereon.
  • 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.
  • 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.
  • the server 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.
  • the ClientHello message includes the list of classical cipher suites the client wishes to negotiate (e.g., TLS ECDH ECDSA WITH NULL SHA).
  • 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.
  • each ID represents a quantum safe encryption
  • 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
  • each ID represents a quantum safe encryption
  • 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:
  • QSHSecret QSHS1
  • 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
  • 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]).
  • 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.
  • 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.
  • This section specifies a TLS extension that can be included with the
  • 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.
  • This extension allows a server to notify the client the ID(s) for the quantum- safe encryption scheme(s) it chooses from the QSHSchemelDList.
  • the server selects a number of QSHSchemelDs in response to a ClientHelloExtension message. The selection is based on client's preference.
  • 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.
  • 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:
  • 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.
  • the first network node may, e.g., be a client
  • 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
  • a supported group comprises at least one indication of a key-exchange protocol.
  • 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.
  • 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.
  • 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.
  • the key share may be implemented as in section 4.2.5 of draft-ietf-tls-tls 13-19.
  • a key share may comprise the value g x in some suitable mathematical group, with private key x.
  • a network node can compute a shared key from g xy .
  • Method 402 further comprises, by second network node 500
  • 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.
  • 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 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).
  • 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.
  • 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
  • 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
  • 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,
  • the key derivation function can be a hash, etc.
  • 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:
  • quantum-resistant algorithms e.g., quantum, paranoid, etc.
  • SIDH quantum-resistant algorithm
  • the server can send back a hybrid group including the key shares for (ECDH 1024, LWE quantum, RLWE quantum).
  • An electronic method for a cryptographic key-exchange between a first network node and a second network node comprising
  • the two nodes can each:
  • 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.
  • the second network may select the larger of the minimums that may be in the policy.
  • 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.
  • 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.
  • an orchestrator in charge of distributing some keying material used to protect the communication channel.
  • 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.
  • EAP EAP
  • 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.
  • 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.
  • 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.
  • a classical key exchange e.g., a classical key exchange
  • This is currently proposed for IKE.
  • 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.
  • 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.
  • 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.
  • this key is a PSK
  • this is not a quantum-resistant key.
  • 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.
  • 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:
  • 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.
  • the corresponding PSK identities would be exchanged in the PSK Extension.
  • the client and/or 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.
  • 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.
  • 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.
  • 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.
  • communication interfaces may be selected from various alternatives.
  • 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.
  • API application interface
  • 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.
  • the network node may contain means to obtain data before use, say by obtaining them over an optional network connection.
  • 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
  • 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.
  • ASIC application-specific integrated circuit
  • 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.
  • the storage may have volatile and a non- volatile part. Part of the storage may be read-only.
  • 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.
  • FPGA field-programmable gate array
  • 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.
  • 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.
  • 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.
  • a first and/or second network node configured for key exchange may comprise a processor circuit and a memory circuit, the processor being arranged to execute software stored in the memory circuit.
  • the processor circuit may be an Intel Core ⁇ processor, ARM Cortex - R8, etc.
  • 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.
  • the device may comprise a non- volatile software interface, e.g., a hard drive, a network interface, etc., arranged for providing the software.
  • An electronic method for a cryptographic key-exchange between a first network node and a second network node comprising
  • 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
  • An electronic method for a cryptographic key-exchange between a first network node and a second network node comprising
  • a key- exchange policy comprises one or more parameters defining one or more of the following conditions
  • 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.
  • a first network node comprising
  • a communication unit configured to digitally communicate with a second network node over a computer network
  • a second network node comprising
  • a communication unit configured to digitally communicate with a first network node over a computer network
  • 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
  • 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:
  • 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,
  • 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.
  • 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.
  • communication interfaces may be selected from various alternatives.
  • 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.
  • API application interface
  • 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.
  • the network node may contain means to obtain data before use, say by obtaining them over an optional network connection.
  • 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).
  • a microprocessor not separately shown
  • a volatile memory such as RAM
  • Flash non-volatile memory
  • 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.
  • ASIC application-specific integrated circuit
  • the circuits may be implemented in CMOS, e.g., using a hardware description language such as Verilog, VHDL etc.
  • first network node 630 may comprise a processor circuit 661, a memory 662, and a communication interface 663.
  • second network node 650 may comprise a processor circuit 664, a memory 665, and a communication interface 666.
  • 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.
  • first network node 630 may comprise an
  • 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.
  • 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.
  • 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.
  • 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.
  • second network node 650 may compute a key share for each of the key-exchange protocols in the selected satisfying supported group.
  • 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.
  • 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.
  • 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.
  • 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.
  • second network node 650 may comprise a final derivation unit 654 to do this.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Certains modes de réalisation de la présente invention concernent un procédé électronique d'échange de clés cryptographique entre un premier nœud de réseau et un second nœud de réseau. Le procédé consiste : à déterminer si des groupes quelconques d'une liste de groupes supportés, avec l'ajout d'au moins un autre protocole d'échange de clés indiqué dans au moins un autre des groupes supportés, satisfont la politique d'échange de clés du second nœud de réseau ; et, si tel est le cas, à sélectionner un groupe supporté avec l'ajout dudit protocole d'échange de clés.
PCT/EP2018/057392 2017-03-29 2018-03-23 Échange de clés hybride WO2018177905A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP17163667.3 2017-03-29
EP17163667 2017-03-29

Publications (1)

Publication Number Publication Date
WO2018177905A1 true WO2018177905A1 (fr) 2018-10-04

Family

ID=58454987

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2018/057392 WO2018177905A1 (fr) 2017-03-29 2018-03-23 Échange de clés hybride

Country Status (1)

Country Link
WO (1) WO2018177905A1 (fr)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021237724A1 (fr) * 2020-05-29 2021-12-02 华为技术有限公司 Procédé de négociation de clé, appareil et système
US11240014B1 (en) 2019-09-10 2022-02-01 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11322050B1 (en) 2020-01-30 2022-05-03 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11343270B1 (en) 2019-09-10 2022-05-24 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11381391B2 (en) 2020-06-15 2022-07-05 Cisco Technology, Inc. Pre-shared secret key capabilities in secure MAC layer communication protocols
US11449799B1 (en) 2020-01-30 2022-09-20 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11477016B1 (en) 2019-09-10 2022-10-18 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11533175B1 (en) 2020-01-30 2022-12-20 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography on a smartcard
US20230034127A1 (en) * 2020-04-29 2023-02-02 Agency For Defense Development Ring-lwr-based quantum-resistant signature method and system thereof
US11626983B1 (en) 2019-09-10 2023-04-11 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
CN116582265A (zh) * 2023-07-12 2023-08-11 北京信安世纪科技股份有限公司 密钥协商方法和密钥协商系统
US11838410B1 (en) 2020-01-30 2023-12-05 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
EP4170962A4 (fr) * 2020-08-31 2023-12-06 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Procédé de transmission de données, client, serveur et support de stockage

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
RESCORLA RTFM E ET AL: "The Transport Layer Security (TLS) Protocol Version 1.3; draft-ietf-tls-tls13-19.txt", THE TRANSPORT LAYER SECURITY (TLS) PROTOCOL VERSION 1.3; DRAFT-IETF-TLS-TLS13-19.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 11 March 2017 (2017-03-11), pages 1 - 127, XP015118425 *
SCHANCK SECURITY INNOVATION & U WATERLOO W WHYTE SECURITY INNOVATION Z ZHANG SECURITY INNOVATION J M: "Quantum-Safe Hybrid (QSH) Ciphersuite for Transport Layer Security (TLS) version 1.3; draft-whyte-qsh-tls13-03.txt", QUANTUM-SAFE HYBRID (QSH) CIPHERSUITE FOR TRANSPORT LAYER SECURITY (TLS) VERSION 1.3; DRAFT-WHYTE-QSH-TLS13-03.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 5 October 2016 (2016-10-05), pages 1 - 18, XP015115601 *

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11477016B1 (en) 2019-09-10 2022-10-18 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11240014B1 (en) 2019-09-10 2022-02-01 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11343270B1 (en) 2019-09-10 2022-05-24 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11736281B1 (en) 2019-09-10 2023-08-22 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11902431B1 (en) 2019-09-10 2024-02-13 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11626983B1 (en) 2019-09-10 2023-04-11 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11750378B1 (en) 2019-09-10 2023-09-05 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11322050B1 (en) 2020-01-30 2022-05-03 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11838410B1 (en) 2020-01-30 2023-12-05 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11449799B1 (en) 2020-01-30 2022-09-20 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11533175B1 (en) 2020-01-30 2022-12-20 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography on a smartcard
US11727829B1 (en) 2020-01-30 2023-08-15 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US11727310B1 (en) 2020-01-30 2023-08-15 Wells Fargo Bank, N.A. Systems and methods for post-quantum cryptography optimization
US20230034127A1 (en) * 2020-04-29 2023-02-02 Agency For Defense Development Ring-lwr-based quantum-resistant signature method and system thereof
US11909891B2 (en) * 2020-04-29 2024-02-20 Agency For Defense Development Ring-LWR-based quantum-resistant signature method and system thereof
WO2021237724A1 (fr) * 2020-05-29 2021-12-02 华为技术有限公司 Procédé de négociation de clé, appareil et système
US11381391B2 (en) 2020-06-15 2022-07-05 Cisco Technology, Inc. Pre-shared secret key capabilities in secure MAC layer communication protocols
EP4170962A4 (fr) * 2020-08-31 2023-12-06 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Procédé de transmission de données, client, serveur et support de stockage
CN116582265A (zh) * 2023-07-12 2023-08-11 北京信安世纪科技股份有限公司 密钥协商方法和密钥协商系统
CN116582265B (zh) * 2023-07-12 2023-10-20 北京信安世纪科技股份有限公司 密钥协商方法和密钥协商系统

Similar Documents

Publication Publication Date Title
WO2018177905A1 (fr) Échange de clés hybride
US11240212B2 (en) Content security at service layer
US10601594B2 (en) End-to-end service layer authentication
US10951423B2 (en) System and method for distribution of identity based key material and certificate
US10110595B2 (en) End-to-end authentication at the service layer using public keying mechanisms
US9021552B2 (en) User authentication for intermediate representational state transfer (REST) client via certificate authority
CN106788989B (zh) 一种建立安全加密信道的方法及设备
WO2017167771A1 (fr) Protocoles d'établissement de liaison "handshake" pour matériau de clé basée sur l'identité et certificats
EP3472969B1 (fr) Procédé de génération et de distribution de clés en fonction de cryptographie selon l'identité
CN113821789A (zh) 基于区块链的用户密钥生成方法、装置、设备及介质
CN113872765B (zh) 身份凭据的申请方法、身份认证的方法、设备及装置
EP3340530B1 (fr) Procédé basé sur la sécurité de couche de transport pour générer et utiliser une identité de noeud persistant unique et client et serveur correspondant
CN108259157B (zh) 一种ike协商中身份认证的方法及网络设备
CN112751664B (zh) 一种物联网组网方法、装置和计算机可读存储介质
Songshen et al. Hash-Based Signature for Flexibility Authentication of IoT Devices
EP4044553A1 (fr) Procédé et dispositif pour fournir un niveau de sécurité de communication
US20220255911A1 (en) Method for Secure Communication and Device
US20240154949A1 (en) Devices and Methods for Performing Cryptographic Handshaking

Legal Events

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

Ref document number: 18713863

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18713863

Country of ref document: EP

Kind code of ref document: A1