WO2017167771A1 - Protocoles d'établissement de liaison "handshake" pour matériau de clé basée sur l'identité et certificats - Google Patents

Protocoles d'établissement de liaison "handshake" pour matériau de clé basée sur l'identité et certificats Download PDF

Info

Publication number
WO2017167771A1
WO2017167771A1 PCT/EP2017/057349 EP2017057349W WO2017167771A1 WO 2017167771 A1 WO2017167771 A1 WO 2017167771A1 EP 2017057349 W EP2017057349 W EP 2017057349W WO 2017167771 A1 WO2017167771 A1 WO 2017167771A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
network node
certificate
identity
authentication token
Prior art date
Application number
PCT/EP2017/057349
Other languages
English (en)
Inventor
Oscar Garcia Morchon
Ronald Rietman
Ludovicus Marinus Gerardus Maria Tolhuizen
Maarten Peter Bodlaender
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 WO2017167771A1 publication Critical patent/WO2017167771A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0847—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 identity based encryption [IBE] schemes
    • 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/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys

Definitions

  • the invention relates to a first network node, a first network node method, a computer program, a computer readable medium.
  • a current approach in cryptography is the use of so-called identity-based key pre-distribution scheme. Using such schemes, two network nodes can agree on a shared key which is based on their identities. A traditional approach in which a key is determined for each pair network nodes would grow quadratically. However, identity -based key pre- distribution scheme need only distribute one set of local key material for each node, and thus grow linearly.
  • certificates In many current cryptographic infrastructures that do not use identity -based key pre-distribution scheme use is made of so-called certificates.
  • One popular certificate system employs X.509 certificates as described in RFC 5280.
  • a certificate contains a public key and information on the owner of the public key. The owner of the public also has the corresponding private key. The public and private key together form a key-pair for use in an asymmetric cryptographic scheme, e.g., encryption or signing, etc.
  • a certificate authority signs the certificate. When later the certificate is used, the signature can be verified. A verification of the signature proves that the certificate authority certified the combination of public key and the other information.
  • Certificates have become ubiquitous in some types of secure communications. For example, X.509 certificate are used in the https protocol against hijacking of a website. Unfortunately, certificates also have a number of drawbacks that make them less suitable for some applications. For example, signed certificate can be quite large. For example, a typical X.509 certificate using 1024 bit RSA keys may be about 1 kilobyte. The size of a certificate for 2048 bit keys would be considerably larger still. This makes certificates less suitable for networks in which communication overhead must be small. For example, in internet-of- things, sensor networks, etc, communication overhead is preferably minimized. Furthermore, using certificates requires quite substantial computation capabilities, not only during set-up of the certificate but during regular use, as the signature on received certificates must be verified. Asymmetric cryptography, such as RSA and the like, typically require large-number computations which may take too long for regular communication on low-resource devices.
  • Handshake protocols are provided which use an identity -based key pre- distribution scheme and also authenticate a network node.
  • the protocols allow the use of certificates that are not signed, yet may still be authenticated.
  • a first network node is provided as defined in the claims that comprises a key storage arranged to store at least first local key material of an identity-based key pre- distribution scheme, and a certificate storage arranged to store a first certificate.
  • the first network node can communicate with a second network node, and authenticate its certificate using its local key material.
  • the communication only involves an exchange of certificates, nonces, and authentication tokens, but no signatures.
  • the certificates need not be signed. Accordingly, long signatures are avoided.
  • a man in the middle would try to intercept a certificate and replace the public key with his own; this will not work as the identity based share key would be different.
  • the system can easily support multiple certificate authorities without little additional overhead.
  • the authentication unit is arranged to generate a further shared key with at least the first private key, the further shared key being a shared-key, shared with the second network node. Because the further shared key depends on secret information to which the trusted third party has no access, this improves security against an attack on trusted third parties that generated the local key material. Even if all local key material is comprised, secure communication remains possible.
  • the first network node comprises a key pair generation unit arranged to generate a first ephemeral public key and a corresponding first ephemeral private key, according to an asymmetric-key cryptographic scheme, the communication device being arranged to send the first ephemeral public key to the second network node, and optionally receive a second ephemeral public key from the second network node.
  • the authentication unit is arranged to generate a combined key from the identity -based shared key and the further shared key, said combined key being used to verify the second authentication token and/or to compute the first authentication token.
  • an authentication token is computed over the public key of the other party and/or over a value encrypted with said public key. This binds the
  • authentication token to the public key, and protects the authentication token from being replayed with other network nodes.
  • the certificate and local key material may be provided in the first and/or second network node in a variety of ways.
  • the first network node is arranged to receive the first certificate and the local key material from a certificate authority device using a protocol executed over a digital computer network.
  • the first and second network device and the certificate authority device are electronic devices.
  • a network node may be a mobile electronic device.
  • a network node may be a mobile phone, set-top box, smart-card, computer, etc.
  • the certificate authority device may be a computer, a server, etc.
  • the first network device is a client and the second network device is a server, e.g., web server arranged to provide web pages to the client on request of said client.
  • 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.
  • Figure 1 schematically shows an example of an embodiment of a cryptographic system
  • Figure 2a schematically shows a sequence diagram of an embodiment of an authentication protocol
  • Figure 2b schematically shows a sequence diagram of an embodiment of an authentication protocol
  • FIG. 3 schematically shows a sequence diagram of an embodiment of an authentication protocol
  • Figure 4 schematically shows of an embodiment a cryptographic system
  • Figure 5 schematically shows a sequence diagram of an embodiment of a protocol for distributing certificates
  • Figure 6a schematically shows a computer readable medium having a writable part comprising a computer program according to an embodiment
  • Figure 6b schematically shows a representation of a processor system according to an embodiment.
  • the current public key infrastructure relies on a certification authority that issues certificates.
  • two network nodes wish to communicate, e.g., a client and a server, e.g., two sensor nodes, etc, they exchange their certificates containing their public-keys. In this way, they can mutually verify the public-keys and agree on a shared key using their public and private keys.
  • the shared key e.g., a common secret accessible by the two network nodes, may be used to encrypt and authenticate messages sent between the client and server in the future.
  • An identity-based key pre-distribution scheme has two phases: key pre-distribution and key derivation. Associated with the two phases of the identity-based key pre-distribution scheme are two algorithms: a local key material generation algorithm and a key establishment algorithm, respectively.
  • the identity-based key pre-distribution scheme is set up by providing a trusted third party with root key material.
  • the trusted third party may be the manufacturer of the device, and may, e.g., provision devices during their manufacturing or in some other trusted environment.
  • the trusted third party may be a certificate authority device, e.g., a device that provisions devices, e.g., using some online protocol.
  • local key material is generated for each network node and stored on the network node, by applying the local key material generation algorithm on the root key material and an identifier of each network node.
  • two network nodes can derive a shared key by applying the key establishment algorithm on their local key material and the identifier of the other network node. For example, a first node may apply the key establishment algorithm on the second identifier of the second network node and its own first local key material, while the second node may apply the key establishment algorithm on the first identifier of the first network node and its second local key material.
  • the result of the key establishment algorithm is an identity-based key shared between two network nodes.
  • HIMMO identity-based key pre-distribution scheme
  • An identity-based key pre-distribution scheme is described in "HIMMO - A lightweight collusion-resistant key predistribution scheme", by Oscar Garcia-Morchon, Domingo Gomez-Perez, Jaime Gutierrez, Ronald Rietman, Berry Schoenmakers and Ludo Tolhuizen. Published in Cryptology ePrint Archive, Report 2014/698.
  • An improved version of HIMMO is described in European patent application "Improved system for key sharing” filed with the EPO at 17.12.2015 and with filing number EP15200857.9, with attorney docket 2015PF01725, of the same applicant, and incorporated by reference.
  • HIMMO like some other identity-based key-distribution schemes, has the disadvantage that sometimes key agreement may fail, or that additional key-reconciliation data (also referred to as helper data) is needed to arrive at a shared key.
  • the key-reconciliation data is usually generated by the first network node that has access to both identities, e.g., the second network node, if the first network note initiated the key agreement.
  • HIMMO is an identity-based key pre-distribution scheme based on the Hiding Information (HI) and Mixing Modular Operations (MMO) problem. HIMMO is lightweight and more quantum-safe since all existing attacks rely on lattices.
  • the TTP has some secret root keying material, e.g. a bivariate function R(x,y).
  • the root key material comprises a bivariate polynomial and the local key material comprises a univariate polynomial.
  • the root key material is formed by a bivariate polynomial f(x, y).
  • a node with local key material g and the identifier of a second node ID 2 obtains a shared key by computing g(ID 2 ) . All polynomial computations may be done modulo a modulus m.
  • FIG. 1 schematically illustrates an embodiment of a cryptographic system 100.
  • Cryptographic system 100 comprises multiple network nodes; shown are network nodes 140, 150 and 160.
  • the network nodes comprise a communication unit allowing the network node to engage in communication with another network node. There is a desire to secure the communication between two network nodes.
  • the communication unit 142 of network node 140 is shown connected to network node 150 to illustrate that network node 140 and network node 150 are currently in communication with each other to execute an authentication protocol.
  • Two such network nodes, such as network node 140 and 150 may be referred to as a first network node and a second network node.
  • the communication between the network nodes could be wireless communication, wired communication or a combination thereof.
  • the multiple network nodes may be a sensor network, in which the sensors communicate with each other.
  • the multiple network nodes may be in the internet of things.
  • One or more of the network nodes may be a server in communication with network nodes that have considerably fewer resources.
  • network node 140 may use an embodiment corresponding to the embodiment of network node 140.
  • n may use an embodiment corresponding to the embodiment of network node 140.
  • most network nodes have the same basic design differing in the keys.
  • Network node 140 comprises a key storage 144 and a certificate storage 145.
  • the storage 144 and 145 may be non-volatile memory, e.g. flash memory, or a magnetic storage, etc. They may be implemented as two parts of a single memory unit. They may also be implemented in different memories.
  • the certificate storage 145 contains information that is not considered secret, while the information in key storage 144 is secret.
  • key storage 144 may be secure memory, protected against tampering;
  • the key storage 144 may be encrypted with a symmetric key stored in a onetime programmable memory, such as fuses; while certificate storage 145 may be stored in regular non-volatile memory.
  • the private key, local key material and the certificate are stored in digital form.
  • the key storage is arranged to store at least first local key material and a first private key.
  • the certificate store 145 is arranged to store a certificate of network node 140.
  • the certificate comprises a public key that corresponds to the private key.
  • the public key may, e.g., be arranged for encryption according to an asymmetric-key cryptographic scheme.
  • the private key corresponds to the public key, e.g., is arranged for decryption according to the asymmetric -key cryptographic scheme.
  • the public and private key correspond to each other and are part of the same asymmetric key-pair.
  • the type of asymmetric scheme may be, e.g., encryption, signing, key agreement (e.g., for Diffie-Hellman), etc.
  • the key- pair may be RSA keys, ECDSA keys, ElGamal keys, etc.
  • the key-pair may be dual use.
  • the key-pair may be an RSA key used both for encryption and for signing, or an ECDSA key used for signing, key-agreement (using Diffie-Hellman) and encryption (using ElGamal).
  • the key-pair may have been generated by network node 140 itself. This has the advantage that the private key need never leave the device which improves security. But this is not needed, for example, the public-private key pair may have been generated by a trusted third party, during manufacture, testing of the device, e.g. during provisioning, etc. Especially for resource restricted devices having key generation external to the device is advantageous.
  • Network node 140 comprises an identity unit 146.
  • Identity unit 146 is arranged to form an identifier by applying an identity forming function to a certificate.
  • the identity forming function is preferably a one-way function, so that it is infeasible to find two different messages with the same function value. What is infeasible is considered with respect to the value of breaking the system.
  • the identifier identifies the certificate.
  • Each network node in the cryptographic system 100 stores a certificate and corresponding local key material.
  • the certificate may be used to identify the network node.
  • the certificate at least comprises a public key, and may also comprise optional additional information.
  • the certificate could comprise one or more of a user name, a computer network address, e.g. a
  • Each network node has an identifier obtainable by applying the identity forming function to its certificate.
  • network node 140 has an identifier obtainable by applying the identity forming function to the certificate in certificate storage 145.
  • the certificate and the local key material are linked through the identifier.
  • the local key material has been generated by applying a local key material generation algorithm of an identity-based key pre-distribution scheme on root key material and the first identifier.
  • the trusted third party may apply the same identifier forming function to the certificates of the multiple network nodes and obtain the corresponding identifiers, then apply the local key material generation algorithm to the identifiers to obtain local key material specific for each certificate.
  • the local key material and the certificate are stored at the certificate.
  • the identity forming function may be a cryptographic hash function, e.g., SHA-1, SHA-2, etc, RIPEMD, etc.
  • the output of the hash function may be shortened if desired and acceptable given the number of public keys generated by the multiple nodes in system 100.
  • the identifier identifies at least the public key. That is, given the identifier and all public keys used in the multiple nodes 140-160, the identifier corresponds to a unique public key.
  • the identity forming function applied to the certificate may be keyed, e.g., a keyed hash, e.g., a MAC, HMAC etc, but in this case all participants in the system have access to the same key used in the identity forming function. This limits participation in the system to devices that have access to the key.
  • a key may be provided in network nodes during manufacture.
  • network node 140 comprises a communication unit 142.
  • Communication unit 140 is arranged to communicate with network node 150, e.g., to exchange multiple digital messages.
  • Communication unit 140 is at least arranged to obtain the certificate of network node 150 and an authentication token from network node 150.
  • the communication of communication unit 142 is preferably digital communication.
  • Identity unit 146 is arranged to obtain the identifier from the certificate received from network node 150.
  • An authentication token generated with a key is a digital message that is hard to create without the key, and thus increases assurance that the origin of the authentication token had access to the key. Often an authentication token is computed over data that includes a nonce, to avoid replay, but this is not always needed. An authentication token is computed by applying a keyed cryptographic function to data. For example, the
  • authentication token may be computed by computing a message authentication code (MAC) using the key as key.
  • MAC message authentication code
  • Possible MACs are HMAC (e.g., RFC 2104), e.g., based on SHA-1, SHA-2, Ripemd, etc, CMAC, e.g., CMAC based on AES or DES, see, e.g., RFC 4493, 4494, and 4615.
  • Network node 140 comprises an identity-based shared key unit 147 arranged to generate an identity-based shared key by applying a key establishment algorithm of the identity-based key pre-distribution scheme on the second identifier and the first local key material.
  • identity -based shared key unit 147 may be connected to key storage 144 to obtain the local key material.
  • the identity -based key pre-distribution scheme is the Blundo scheme a univariate polynomial is applied to the identifier of network node 150 to obtain the shared identity-based key.
  • Network node 140 comprises an authentication unit 148 arranged to authenticate the second network node by cryptographically verifying that the authentication token received form network 150 has been computed from at least the identity-based shared key. Verifying the authentication token implicitly verifies the certificate of network node 150.
  • network node 140 can reason as follows: since the network node 150 has access to the shared key, it must have local key material that corresponds to the second identifier in order to compute the shared key. Thus the trusted third party had access to the second identifier in order to compute the local key material. The trusted third party computes the identifier from a certificate, as the identifiers match, the certificate for which the trusted third party provided local key material, i.e., which the trusted third party authenticated, is the same certificate as the network node 140 received from the network node 150.
  • Authentication unit 148 may also be arranged to compute an authentication token from at least the identity-based shared key and to send the authentication token to the network node 150. It is not always required that both parties authenticate to each other. For example, if network node 140 and network node 150 have a client-server relationship it may not be needed that the client (e.g., network node 140) authenticates to the server. For example, to receive a web page it may be desired that the receiver of the web page can authenticate to origin of the web page, yet the receiver of the information may be anonymous and unauthenticated to the server.
  • a number of embodiments of network nodes are described with reference to sequence diagrams 2a, 2b and 3. In each sequence diagram time increases from top to bottom of the figure. Two time lines are shown one for a first network node 240 and one for a second network node 250.
  • the qualifiers 'first' and 'second' are used mostly for convenience, and serve to distinguish the two nodes. They do not imply an ordering on the network nodes or on the messages they sent. In particular, any one of two network nodes that receives an
  • authentication token from the other party may be termed the first network node.
  • the qualifiers 'first' and 'second' are interchangeable.
  • network node 240 as the 'first' and network node 250 as the 'second' network node.
  • First network node 240 and second network node 250 may be embodiments of network nodes 140 and 150, respectively.
  • Figure 2a shows a sequence diagram in which two messages are exchanged.
  • the diagram shows processing parts 240.1, and 240.3 for first network node 240, and 250.1 for the second network node 250.
  • the diagram shows a message 240.2 sent from first network node 240 to second network node 250, and a message 250.2 sent from second network node 250 to first network node 240.
  • additional messages may be exchanged.
  • the protocols corresponding to figure 2a may be part of a larger communication.
  • additional communication may follow between first network node 240 and second network node 250.
  • first or second Objects such as public key, certificate, local key material, authentication token, etc are referred to as first or second depending on where the object was computed or sent from.
  • first certificate C l 5 first public key
  • the first local key material may be the corresponding material stored at network node 140.
  • Functions x ( ) and / 2 ( ) refer to the first and second local key material respectively.
  • First network node 240 sends to second network node 250 - the first certificate C 1
  • Second network node 250 Second network node 250
  • Second network node 250 sends to first network node 240 the second authentication token, the second certificate
  • Processing part 240.1 may be empty.
  • helper data may be generated when the identity-based shared key is first generated and communicated to the other network node in, say, the next message.
  • helper data may be computed by second network node 250 in processing part 250.1 and communicated to the first network node 240 in message 250.2.
  • First network node 240 uses the helper data when computing the identity based shared key, to ensure that the identity-based shared key is the same at both the first and second network node.
  • the second authentication token may be computed over the first public key or over the first certificate. This helps to prevent replay of messages that were used between a different pair of network nodes. For some applications this is sufficient.
  • the second authentication token may MAC over the first public key using the identity -based shared key. Replay protection may also be achieved through other means outside the scope of the authentication protocol.
  • the first and second certificates need not be signed, yet this does not open up the protocol to a man in the middle attack.
  • first network node 240 is a client and second network node 250 is a server.
  • first network node 240 wants to get a web page with information from second network node 250.
  • the attacker wants to replace the page with a page of his own.
  • the man in the middle could intercept the message 240.2. He sends a message to second network node 250 with his own certificate. This will not work, since second network node 250 will now compute authentication data using the identity- based shared key for the identity of the man in the middle. Such an authentication token will be rejected by first network node 140. If on the other hand, the man in the middle sends the first certificate to second network node 150, he obtains a correct authentication token. But should he try to deliver the authentication token with his own certificate, the authentication token will not verify.
  • first network node can verify that the authentication token he receives really corresponds to second network node 250, even without a signature on the certificate.
  • the authentication protocols have several advantages.
  • the certificates used are not signed. Accordingly, the overhead of signatures is avoided.
  • the signature on a certificate in conventional communication can be an important source of overhead. Moreover, also no signatures need to be verified.
  • Combination with HIMMO based key pre-distribution schemes is especially advantageous as such schemes are considered saver against quantum threads.
  • the security of a signature against non-quantum attacks could be combined with the security against quantum attacks by signing the certificate using a signing key (private) key of certificate authority device 110.
  • the certificate could be signed by RSA, ECDSA, etc, or such keys could be used elsewhere in the protocol.
  • the embodiment A does not use the public key in the certificates other than for identification. This is no problem in itself.
  • Such public keys may be used for unrelated applications.
  • the public keys may have been used to distribute the local key material.
  • the public keys can offer protection for the situation in which the trusted third party is hacked. Below protocols are disclosed that use both the local key material as well as the public key.
  • First network node 240 sends to second network node 250 the first certificate C l5 and first nonce n 1
  • Second network node 250 In processing part 250.1 : Second network node 250
  • Second network node 250 sends to first network node 240 the second authentication token, the second certificate C 2 , and the encrypted key Q
  • the communication key may be used to protect further communication.
  • a further shared key is generated (key Q) with the first private key.
  • a communication key is derived from at least the further shared key.
  • key Q may itself be used as a communication key, but key Q may also be combined with the identity -based shared key.
  • the communication key may be used to cryptographically protect future communication between the first network node 240 and the second network node 250.
  • Processing part 250.1 may comprise computing helper data, and message 250.2 may include the helper data.
  • the further shared key may be obtained from a second random number generated by the second network node encrypted by the first public key.
  • the public/private keys used are suitable for encryption/decryption, e.g., RSA
  • second network node 250 may encrypt key Q and compute a second authentication token with the identity-based shared key K IB , the first nonce n l5 and key Q :
  • second network node 250 computes
  • second network node 250 computes
  • second network node 250 computes
  • the encryption e is sent to network node 240.
  • mac is sent separately; in examples two and three the value mac is sent encrypted.
  • the second authentication token is computed by applying a cryptographic function, e.g., a message authentication code, to a value encrypted with the first public key. This implicitly links the authentication token to the public key of the first network node.
  • a further key e.g., key Q , a nonce, and a public key suitable for encryption. If replay protection between nodes is not required the nonce could be omitted or replaced by, e.g., the certificate or public key of the other party.
  • the protocol of embodiment B could be extended with an additional message by computing a first authentication token at the first network node and sending it to the second network node.
  • Figure 2b shows a sequence diagram in which three messages are exchanged. In addition to the processing parts and messages of figure 2a, figure 2b shows processing parts 250.3, and message 240.4.
  • embodiment A has been extended with nonces and an additional authentication token.
  • a nonce is a number used only once.
  • the nonce may be a random number, a time stamp, a serial number etc. If the communication channel is prone to replay attacks, the nonces protect against this threat.
  • First network node 240 sends to second network node 250 the first certificate C l5 and first nonce ⁇ ⁇
  • Second network node 250 Second network node 250
  • Second network node 250 sends to first network node 240 the second authentication token, the second certificate C 2 , and the second nonce n 2
  • First network node 240 sends to second network node 250 the first authentication token
  • Second network node 250 Second network node 250
  • a communication key may be obtained e.g., the identity-based shared-key, or a key derived therefrom.
  • the communication may be broken off, and/or other appropriate action may be taken, e.g., sending a warning signal for the user, or to a server.
  • the nodes may start further communication.
  • the further communication may be cryptographically protected, e.g., encrypted and/or
  • the shared communication key is typically a symmetric key and may be, e.g., the identity-based shared key.
  • KDF key derivation function
  • the identity-based shared key may be diversified, e.g., into an encryption and authentication key.
  • the former may be used for a block cipher, e.g., AES, the latter for authentication, e.g., a MAC.
  • invention B could be extended with two nonces rather than one, e.g., by selecting and sending a second nonce at the second network node 250, and computing and sending a first authentication token from the first network node 240.
  • Processing part 250.1 may comprise computing helper data
  • message 250.2 may include the helper data.
  • Asymmetric cryptography may be combined in different ways with the identity-based key pre-distribution.
  • keys suitable for Diffie- Hellman (DH) are used.
  • First network node 240 sends to second network node 250 the first certificate C l 5 and first nonce n 1
  • Second network node 250 Second network node 250
  • Second network node 250 sends to first network node 240 the second authentication token, the second certificate C 2 , and the second nonce n 2
  • First network node 240 sends to second network node 250 the first authentication token
  • Second network node 250 Second network node 250
  • a further shared key (Diffie-Hellman key K DH ) is obtained with at least the first private key.
  • This further shared key does not (only) depend on information distributed by the trusted third party. Thus even in the face of an attack of the trusted party, both past and future communication could remain secure.
  • the further shared key is obtained by applying a Diffie-Hellman key agreement algorithm on a second public key obtained from the second certificate and the first private key.
  • the further shared key is used by the first network node to verify the second authentication token and to compute the first authentication token. Note that also a communication key could be derived from the further shared key or from the combined key.
  • Embodiment D sends two nonces, but could instead be adapted not to work with nonces that need not always be sent, e.g., timestamps. Embodiment D could be adapted to work without nonces, if replay is less of a concern and instead compute the authentication token on the public key of the other party, etc.
  • Embodiment D could also be adapted to work with only one authentication token, depending on which party needs to be authenticated.
  • Processing part 250.1 may comprise computing helper data, and message 250.2 may include the helper data.
  • Embodiment D may work with any asymmetric scheme that supports Diffie- Hellman.
  • the Diffie-Hellman shared key may be notated as Pub Priv 2 which key is equal to Pub 2 Priv ⁇ .
  • There are multiple asymmetric cryptosystems which have a component as above which allows for this Diffie Hellmann algorithm.
  • a combined key is generated from the identity-based shared key and the further shared key.
  • the combined key is used to verify the second authentication token and/or to compute the first authentication token.
  • authentication is thus identity-based as well as private key based, without having an increase in the number or size of the messages.
  • Embodiment D may be extended with ephemeral keys, e.g., a temporary key, to improve forward security, so that even if at some point both network nodes and/or the trusted third parties are compromised past communication is still safe.
  • ephemeral keys e.g., a temporary key
  • First network node 240 sends to second network node 250 - the first certificate C l 5 first nonce n l5 and the first ephemeral
  • Second network node 250 Second network node 250
  • Second network node 250 sends to first network node 240 - the second authentication token, the second certificate C 2 , the second nonce n 2 , and the second ephemeral public key,
  • First network node 240 sends to second network node 250 the first authentication token
  • Second network node 250 Second network node 250
  • the first network node 240 and second network node 250 may comprise a key pair generation unit 141 arranged to generate the ephemeral public key and corresponding ephemeral private key, e.g., according to an asymmetric -key cryptographic scheme suitable for Diffie-Hellman, e.g., the same asymmetric-key cryptographic scheme as the one use for the public key in the certificates.
  • a key pair generation unit of the first and second network node is arranged to generate a first ephemeral public key and a
  • the communication device is arranged to send the first ephemeral public key to the second network node, the corresponding private key is kept secret by the network node.
  • the communication unit is also arranged to receive an ephemeral public key from the other network node; e.g. the first communication unit receives the second ephemeral public key from the second network node.
  • the ephemeral public keys are different from the public keys in the certificates.
  • the authentication units are arranged to generate a further shared key from at least the first ephemeral private key and in this case the first private key. For example, a first authentication unit could generate a further shared key from the first ephemeral private key and the second public key.
  • the first ephemeral private key e.g. the first authentication unit could generate a further shared key from the first ephemeral private key and the second public key.
  • the authentication unit generates the further shared key from the first ephemeral private key, the first private key (corresponding to the first certificate), the second public key (from the second certificate) and the second ephemeral public key, using the Diffie-Hellman algorithm.
  • the further shared key is used to verify the second authentication token and/or compute the first authentication token.
  • the authentication unit is arranged to generate a combined key from the identity-based shared key and the further shared key.
  • the further shared key could also be used, instead or in addition, to compute a communication key.
  • the combined key in this embodiment is identity-based as well as private key based.
  • the communication can remain secure.
  • the authentication protocol e.g., after the communication between network nodes 240 and 250 finished, e.g., communication protected using a communication key, the ephemeral keys and communication key derived therefrom are deleted.
  • the same mechanism used to establish an ephemeral key could be used to establish an additional non-ephemeral key.
  • the private key of the first network node comprises a secret exponent a
  • the private key of the second network node comprises a secret exponent b
  • the latter is p re ferred as it allows blinding of the private exponent a with a e .
  • theDiffie-Hellman key may be computed as, e.g., A b B e ae .
  • the first and second authentication token used in the embodiment E may be computed as Hash(K cmb ⁇ n 1 ⁇ n 2 ) and HashiK ⁇ ⁇ respectively or vice versa.
  • This mechanism may also be used to compute authentication tokens in the other embodiments using nonces and a key, e.g. the combined key, further key or identity-based shared key. Note that these two tokens will not be the same, even though they are computed over the same data.
  • the hash may be a cryptographic hash. An identity-based shared key and a Diffie- Hellman key may be combined, e.g., by XOR-ing them, or by hashing their concatenation, etc.
  • Processing part 250.1 may comprise computing helper data, and message 250.2 may include the helper data.
  • Ephemeral keys may also be used that are not necessarily suitable for Diffie- Hellman.
  • the embodiment below uses an ephemeral encryption/decryption key.
  • First network node 240 sends to second network node 250 the first certificate C l5 first nonce n l 5 first ephemeral public key Pub[
  • Second network node 250 Second network node 250
  • Second network node 250 sends to first network node 240 the second authentication token, the second certificate C 2 , and the encrypted first key Q 1 , and encrypted second key Q 2
  • decrypts the encrypted first key Q 1 , and encrypted second key Q 2 - verifies that the second authentication token has been computed with the identity-based shared key, the first nonce, and first key Q 1 , and second key Q 2 .
  • First network node 240 sends to second network node 250 the first authentication token
  • Second network node 250 Second network node 250
  • computing the second authentication token mac and performing the encryption may be done as follows
  • the values e 0 , e l5 and mac are sent in message 250.2
  • the mac may use K IB as key.
  • Other constructions are possible, analogous to those given at embodiment B.
  • the first authentication token may be computed in the same manner as the second authentication token.
  • the authentication token mac is computed over a value a value encrypted with the public key received from the other party; in an embodiment also a nonce received from the other party is added.
  • a further variant for the authentication tokens is given below. This
  • construction may be applied only to the last authentication token in the protocol (in embodiment F the first authentication token) or may be applied also to the other
  • authentication token Similar application in other embodiments is also possible.
  • this authentication token a combined symmetric key is obtained from the further key(s) and the identity-based key. In this case, from Q 1 , Q 2 , and K IB .
  • a message authentication code is computed over all information previously exchanged between the first and second network node in this protocol, or even over all messages exchanged between the first and second network node in this protocol. For example, a message authentication may be computed over C l 5 C 2 , e 0 , e l 5 Pub[, using the combined key as key to obtain a first authentication token.
  • Processing part 250.1 may comprise computing helper data, and message 250.2 may include the helper data.
  • two further shared keys are generated.
  • the further shared keys are used both to compute/verify authentication tokens and to compute a communication key.
  • the way to obtain a communication key from Q 1 and Q 2 should be identical for network nodes 240 and 250.
  • the further shared keys Q 1 and Q 2 may be obtained from random numbers generated by the second network node and encrypted by the first public key and first public ephemeral key.
  • the first network node generates a first ephemeral public key and a corresponding first ephemeral private key, according to an asymmetric-key cryptographic scheme.
  • the asymmetric -key cryptographic scheme is suitable for encryption/decryption, e.g., RSA, ElGamal, etc.
  • the first ephemeral private key is used to decrypt the further keys obtained from the second network node 250.
  • An authentication token is computed by applying a cryptographic function to a value encrypted with the first public key, and (in this case) also to a value encrypted with the first ephemeral public key.
  • an authentication unit may be arranged to generate the further shared key from at least the first ephemeral private key.
  • Figure 3 schematically illustrates an authentication protocol in which four messages are exchanged.
  • public/private keys are used which are suitable for cryptographic signing, e.g., ECDSA, RSA signing etc.
  • random numbers are used, which are a type of nonces. Both parties commit to a random number before computing the combined key, etc.
  • First network node 340 and second network node 350 may be embodiments of network nodes 140 and 150.
  • first network node 340 sends to second network node 350 first random number R 1
  • second network node 350 sends to first network node 340
  • first network node 340 sends to second network node 350 first certificate C l 5 the first and further first authentication token, the encrypted key Q
  • second network node 350 sends to network node 340
  • the signature in processing part 340.3 may be computed using the private key corresponding to the public key in first certificate C x .
  • the latter may be used if the public/private key may both be used for encryption as well as for decryption.
  • Dual use keys may be, e.g., an RSA key which may be used both for encryption/decryption and for verification/signing, or, e.g., an ECDSA key for signing which may also be used for ElGamal encryption.
  • the signature may also be computed using a separate private signing key.
  • the corresponding public verification key may be embedded in the first certificate as a separate key.
  • the signature may, e.g., be computed over the first and second random number, and possibly also over the second certificate.
  • Processing part 340.3 may comprise computing helper data, and message 340.4 may include the helper data.
  • a network node computes two authentication tokens, one using an asymmetric signing key, and one using an identity-based shared key. Introducing a signing based authentication token could be added to other protocols as well.
  • the further first authentication token may be a message authentication code computed over the first and second random number, the first and second certificate, the encrypted key e, and the signature using as key a combined key.
  • the combined key may be obtained from Q, K IB , and the first and second random numbers R R 2
  • the first and second network node may use the combined key as communication key.
  • protocol elements may be added as needed.
  • the messages in a particular protocol may include a session identifier, to identify the protocol session, network addresses, message headers etc.
  • session identifiers and/or addresses may be included in cryptographic elements as well, e.g., authentication tokens etc.
  • message headers may be included in such elements.
  • Devices 140, 150, 240, 250, 340, 350 may be provisioned with certificates, and local key material in any suitable manner.
  • certificates and local key material may be stored at a device during manufacture, during testing, etc. They may also be provided in some online protocol.
  • a certificate authority device e.g., a trusted third party.
  • Figure 4 shows network node 140 comprising a key pair generation unit 141 arranged to generate a public/private key pair according to an asymmetric cryptographic scheme suitable for encryption and decryption and e.g. for inclusion in a certificate, and a decryption unit 143 arranged to decrypt messages using the private key.
  • Network node 140 may be used to receive local key material from a certificate authority device 110 by executing a protocol over a computer network. Only units are shown that may be used in said protocol. Also network nodes 150 and 160 may be provisioned by certificate authority device 110.
  • Figure 5 shows in the form of a sequence diagram how a network node 240, e.g., network node 140 and a certificate authority device 210, e.g., certificate authority device 110 may cooperate to distribute a certificate.
  • Protocol elements may be added if needed.
  • the messages in a particular protocol may include a session identifier, to identify the protocol session.
  • session identifiers may be included in cryptographic elements as well, e.g., authentication tokens etc.
  • Network node 240 generates 240.1 a public key and a corresponding private key and sends 240.2 the public key to the certificate authority device 210.
  • Certificate authority device 210 generates 210.1 a certificate comprising the public key, possibly a nonce, and possibly other information, and forms 210.2 an identifier by applying an identity forming function to the certificate. The identifier depends on the public key and the other information.
  • Certificate authority device 210 then generates 210.3 local key material specific for the network node, by applying the local key material generation algorithm of the identity- based key pre-distribution scheme on the root key material and the identifier. At least the local key material specific for the network node is encrypted 210.4 by the public key of the network node.
  • the certificate is encrypted with the public key.
  • the encrypted local key material is sent 210.5 to the network node.
  • the certificate is also sent to network node 240.
  • the sent encrypted local key material is decrypted 240.3 using the private key, thus obtaining the local key material.
  • the local key material, the private key, and the certificate are stored 240.4, e.g., in local storage, e.g., in a key storage and certificate storage.
  • An optional extension of the protocol up to 240.4 is to use multiple certificate authorities.
  • Figure 5 shows a further certificate authority device 220.
  • Network node 240 may be arranged to send the certificate to further certificate authority 220.
  • network node 240 either constructs the certificate itself, or receives the certificate from certificate authority device 210.
  • the certificate for which it has received local key material and which defines its identity is then send to further certificate authority 220 by network node 240.
  • further certificate authority 220 may receive the certificate from certificate authority device 210.
  • a network node receives local key material from multiple certificate authorities. This local key material may be combined by the network node. Thus if a certificate authority device is hacked the local key material of a network node is not directly compromised.
  • Network node 240 may combine the local key material received from the certificate authority device and the further local key material received from the further certificate authority device into a single local key material. The combination may be done after receiving the local key materials, e.g., by adding the local key materials, to obtain a combined local key material. The combined local key material may be used for key agreement. The combination does not need to be done directly after receiving the
  • certificate authorities In conventional certificate authorities it is hard to certify by more than or a few certificate authorities. However, with certificates according to an embodiment combining certification of multiple certificate authorities is not a problem. For example, in an embodiment, more than two, say 50 certificate authorities are combined. For example, every mobile phone operator may operate a certificate authority. The network node uses a first certificate authority device to get a certificate and first local key material. Next the network node sends the certificate to 49 more certificate authorities and receives 49 times additional local key materials. Once a network node has received local key material, encryption and/or authentication may also be done using a shared key instead or in addition to the public key. In an embodiment, all local key material is encrypted with the public key of the network node in transit and/or with a shared key. By using at least the public key of the network node, even if the first certificate authority is compromised the network node will receive uncompromised key materials from uncompromised subsequent certificate authorities.
  • the local key material used by the first network node may be obtained from a single certificate authority, or from multiple certificate authorities and combined before the network node starts the above protocol. This is not necessary though, the network node may also select which local key material to use during the protocol. For example, in an
  • the communication node is arranged to send to the second network node from which certificate authorities the first network node received local key material, and to receive from the second network node from which certificate authorities the second network node received local key material, the identity-based shared key unit being arranged to combine local keying material generated by the certification authorities for which both the first and second network nodes received local key material, e.g., to combine local keying material for all common certificate authorities.
  • Certificate authority agreement has an advantage as can be seen in the following example.
  • the first network node received local keying material from certificate authorities CAl and CA2, and the second network node from certificate authorities CA2, and CA3.
  • the two network nodes can communicate together using only the keying material from CA2. They cannot communicate with each other if the first network node had combined the material of CAl and CA2, whereas the second network node combined the material of CA2 and CA3.
  • the reduce a possible risk of manipulating a network node into using a weak certificate authority a network node could require that local keying material from at least two common certificate authorities are needed to communicate.
  • the devices 110, 140, 150, 210, 220, 240, 250, 340 and 350 each comprise a microprocessor (not separately shown) which executes appropriate software stored at the devices; 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
  • the devices may also be equipped with any suitable software stored at the devices; 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).
  • the devices may also be equipped with
  • the devices may, in whole or in part, be implemented in programmable logic, e.g., as field-programmable gate array (FPGA).
  • FPGA field-programmable gate array
  • the devices 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 network node may comprise one or more of a key storage circuit, a certificate storage circuit, an identity circuit, a communication circuit, an identity- based shared key circuit, an authentication circuit, a key pair generation circuit.
  • the circuits implement the corresponding units described herein.
  • the circuits may be a processor circuit and storage circuit, the processor circuit executing instructions represented electronically in the storage circuits.
  • the circuits may also be, FPGA, ASIC or the like.
  • a method according to the invention may be executed using software, which comprises instructions for causing a processor system to perform a 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.
  • Figure 6a 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 network node method, 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 network node method.
  • FIG. 6b shows in a schematic representation of a processor system 1140 according to an embodiment.
  • the processor system comprises one or more integrated circuits 1110.
  • the architecture of the one or more integrated circuits 1110 is schematically shown in Figure 6b.
  • 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
  • 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 1124 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.
  • 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 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)
  • Mobile Radio Communication Systems (AREA)

Abstract

Selon l'invention, un premier noeud de réseau est destiné à obtenir un deuxième certificat et un deuxième jeton d'authentification à partir d'un deuxième noeud de réseau. Une unité d'identité est destinée à obtenir un deuxième identifiant à partir du deuxième certificat. Une unité de clé partagée basée sur l'identité (147) est destinée à générer une clé partagée basée sur l'identité par l'application d'un algorithme d'établissement de clé du schéma de pré-distribution de clé basée sur l'identité sur le deuxième identifiant et le premier matériau de clé (5) local. Une unité d'authentification (148) est destinée à authentifier le deuxième noeud de réseau par la vérification cryptographique du fait que le deuxième jeton d'authentification a été calculé à partir d'au moins la clé partagée basée sur l'identité.
PCT/EP2017/057349 2016-03-29 2017-03-29 Protocoles d'établissement de liaison "handshake" pour matériau de clé basée sur l'identité et certificats WO2017167771A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP16162617.1 2016-03-29
EP16162617 2016-03-29

Publications (1)

Publication Number Publication Date
WO2017167771A1 true WO2017167771A1 (fr) 2017-10-05

Family

ID=55637284

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/057349 WO2017167771A1 (fr) 2016-03-29 2017-03-29 Protocoles d'établissement de liaison "handshake" pour matériau de clé basée sur l'identité et certificats

Country Status (1)

Country Link
WO (1) WO2017167771A1 (fr)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3745640A1 (fr) * 2019-05-31 2020-12-02 Siemens Aktiengesellschaft Établissement d'une communication sécurisée sans informations temporelles locales
CN112243234A (zh) * 2020-07-21 2021-01-19 丹阳市威鼎汽配有限公司 一种基于身份的车联网隐私安全保护方法
CN112291179A (zh) * 2019-07-22 2021-01-29 科大国盾量子技术股份有限公司 一种实现设备认证的方法、***及装置
CN112311534A (zh) * 2019-08-01 2021-02-02 张英辉 产生非对称算法密钥对的方法
US10951423B2 (en) 2016-03-29 2021-03-16 Koninklijke Philips N.V. System and method for distribution of identity based key material and certificate
CN112805960A (zh) * 2018-10-19 2021-05-14 日本电信电话株式会社 认证授权***、信息处理装置、设备、认证授权方法及程序
CN114065171A (zh) * 2021-11-11 2022-02-18 北京海泰方圆科技股份有限公司 一种身份认证方法、装置、***、设备及介质
CN114221771A (zh) * 2021-12-02 2022-03-22 上海健交科技服务有限责任公司 一种面向深度学习的安全令牌传输及校验加速方法和装置
CN114615012A (zh) * 2022-01-28 2022-06-10 北京威尔文教科技有限责任公司 设备连接方法、装置、电子设备和可读存储介质
CN114747178A (zh) * 2019-11-21 2022-07-12 因温特奥股份公司 用于确保计算机网络中的数据通信安全的方法
CN115102745A (zh) * 2022-06-16 2022-09-23 慧之安信息技术股份有限公司 一种基于轻量级的物联网终端身份安全认证方法
CN115378587A (zh) * 2022-10-24 2022-11-22 北京智芯微电子科技有限公司 密钥获取方法、装置、设备及可读存储介质
US12034875B2 (en) 2019-05-31 2024-07-09 Siemens Aktiengesellschaft Establishing secure communication without local time information

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060095771A1 (en) * 2004-11-02 2006-05-04 Guido Appenzeller Security device for cryptographic communications
EP1906587A2 (fr) * 2004-10-29 2008-04-02 Thomson Licensing, Inc. Canal authentifié sécurisé
WO2009128011A1 (fr) * 2008-04-14 2009-10-22 Philips Intellectual Property & Standards Gmbh Procédé pour identification distribuée, une station dans un réseau
US20100082986A1 (en) * 2002-08-28 2010-04-01 Gentry Craig B Certificate-based encryption and public key infrastructure
US20100211779A1 (en) * 2009-02-17 2010-08-19 Sundaram Ganapathy S Identity Based Authenticated Key Agreement Protocol
WO2016034453A1 (fr) * 2014-09-04 2016-03-10 Koninklijke Philips N.V. Système cryptographique pour un partage de clé

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100082986A1 (en) * 2002-08-28 2010-04-01 Gentry Craig B Certificate-based encryption and public key infrastructure
EP1906587A2 (fr) * 2004-10-29 2008-04-02 Thomson Licensing, Inc. Canal authentifié sécurisé
US20060095771A1 (en) * 2004-11-02 2006-05-04 Guido Appenzeller Security device for cryptographic communications
WO2009128011A1 (fr) * 2008-04-14 2009-10-22 Philips Intellectual Property & Standards Gmbh Procédé pour identification distribuée, une station dans un réseau
US20100211779A1 (en) * 2009-02-17 2010-08-19 Sundaram Ganapathy S Identity Based Authenticated Key Agreement Protocol
WO2016034453A1 (fr) * 2014-09-04 2016-03-10 Koninklijke Philips N.V. Système cryptographique pour un partage de clé

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CARLO BLUNDO: "Perfectly-Secure Key Distribution for Dynamic Conferences", INFORMATION AND COMPUTATION, vol. 146, no. 1, 10 October 1998 (1998-10-10), pages 1 - 23
OSCAR GARCIA-MORCHON ET AL: "HIMMO - A lightweight collusion-resistant key predistribution scheme", CRYPTOLOGY EPRINT ARCHIVE, 2014, pages 698

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10951423B2 (en) 2016-03-29 2021-03-16 Koninklijke Philips N.V. System and method for distribution of identity based key material and certificate
CN112805960A (zh) * 2018-10-19 2021-05-14 日本电信电话株式会社 认证授权***、信息处理装置、设备、认证授权方法及程序
CN112805960B (zh) * 2018-10-19 2024-05-17 日本电信电话株式会社 认证授权***、信息处理装置、设备、认证授权方法及程序
WO2020239294A1 (fr) * 2019-05-31 2020-12-03 Siemens Aktiengesellschaft Établissement d'une communication sécurisée sans informations temporelles locales
US12034875B2 (en) 2019-05-31 2024-07-09 Siemens Aktiengesellschaft Establishing secure communication without local time information
EP3745640A1 (fr) * 2019-05-31 2020-12-02 Siemens Aktiengesellschaft Établissement d'une communication sécurisée sans informations temporelles locales
CN112291179A (zh) * 2019-07-22 2021-01-29 科大国盾量子技术股份有限公司 一种实现设备认证的方法、***及装置
CN112291179B (zh) * 2019-07-22 2022-04-12 科大国盾量子技术股份有限公司 一种实现设备认证的方法、***及装置
CN112311534A (zh) * 2019-08-01 2021-02-02 张英辉 产生非对称算法密钥对的方法
CN114747178A (zh) * 2019-11-21 2022-07-12 因温特奥股份公司 用于确保计算机网络中的数据通信安全的方法
CN112243234A (zh) * 2020-07-21 2021-01-19 丹阳市威鼎汽配有限公司 一种基于身份的车联网隐私安全保护方法
CN114065171A (zh) * 2021-11-11 2022-02-18 北京海泰方圆科技股份有限公司 一种身份认证方法、装置、***、设备及介质
CN114065171B (zh) * 2021-11-11 2022-07-08 北京海泰方圆科技股份有限公司 一种身份认证方法、装置、***、设备及介质
CN114221771A (zh) * 2021-12-02 2022-03-22 上海健交科技服务有限责任公司 一种面向深度学习的安全令牌传输及校验加速方法和装置
CN114221771B (zh) * 2021-12-02 2024-01-30 上海健交科技服务有限责任公司 一种面向深度学习的安全令牌传输及校验加速方法和装置
CN114615012A (zh) * 2022-01-28 2022-06-10 北京威尔文教科技有限责任公司 设备连接方法、装置、电子设备和可读存储介质
CN115102745B (zh) * 2022-06-16 2023-10-27 慧之安信息技术股份有限公司 一种基于轻量级的物联网终端身份安全认证方法
CN115102745A (zh) * 2022-06-16 2022-09-23 慧之安信息技术股份有限公司 一种基于轻量级的物联网终端身份安全认证方法
CN115378587B (zh) * 2022-10-24 2023-01-20 北京智芯微电子科技有限公司 密钥获取方法、装置、设备及可读存储介质
CN115378587A (zh) * 2022-10-24 2022-11-22 北京智芯微电子科技有限公司 密钥获取方法、装置、设备及可读存储介质

Similar Documents

Publication Publication Date Title
US10951423B2 (en) System and method for distribution of identity based key material and certificate
US11323276B2 (en) Mutual authentication of confidential communication
WO2017167771A1 (fr) Protocoles d'établissement de liaison "handshake" pour matériau de clé basée sur l'identité et certificats
CN111740828B (zh) 一种密钥生成方法以及装置、设备、加解密方法
JP4527358B2 (ja) 鍵供託を使用しない、認証された個別暗号システム
JP4814339B2 (ja) 制約された暗号キー
Toorani et al. An elliptic curve-based signcryption scheme with forward secrecy
EP3642997A1 (fr) Communications sécurisées fournissant une confidentialité persistante
WO2018027300A1 (fr) Utilisation d'un certificat numérique avec plusieurs systèmes cryptographiques
CN112104453B (zh) 一种基于数字证书的抗量子计算数字签名***及签名方法
WO2019010421A1 (fr) Systèmes et procédés de génération de clés cryptographiques symmétriques
EP3695561B1 (fr) Fourniture sécurisée de données à un dispositif client
JP2020507243A (ja) ネットワークデバイス及び信頼できるサードパーティデバイス
AU2019379062A1 (en) Method and architecture for securing and managing networks of embedded systems with optimised public key infrastructure
JP6758476B2 (ja) デバイス間の共通セッション鍵を取得するシステムおよび方法
CN113098681B (zh) 云存储中口令增强且可更新的盲化密钥管理方法
GB2543359A (en) Methods and apparatus for secure communication
Resner et al. Key establishment and trustful communication for the internet of things
US20160330025A1 (en) Method to independently complete the personalization of a token
Arkko et al. Rfc 3830: Mikey: multimedia internet keying
Mulkey et al. Towards an efficient protocol for privacy and authentication in wireless networks
WO2022218544A1 (fr) Dispositif et procédé de prise de décision
Yeun et al. Secure software download for programmable mobile user equipment
KR20220049038A (ko) 네트워크 내 복수의 엔티티들간 대칭 키 생성, 인증 및 통신
CN114785487A (zh) 基于ca和国密算法的抗量子计算https通信方法及***

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 17713310

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17713310

Country of ref document: EP

Kind code of ref document: A1