WO2020025128A1 - Certificate management - Google Patents

Certificate management Download PDF

Info

Publication number
WO2020025128A1
WO2020025128A1 PCT/EP2018/070872 EP2018070872W WO2020025128A1 WO 2020025128 A1 WO2020025128 A1 WO 2020025128A1 EP 2018070872 W EP2018070872 W EP 2018070872W WO 2020025128 A1 WO2020025128 A1 WO 2020025128A1
Authority
WO
WIPO (PCT)
Prior art keywords
blockchain
cryptographic certificate
published
message
node
Prior art date
Application number
PCT/EP2018/070872
Other languages
French (fr)
Inventor
Silke Holtmanns
Ian Justin Oliver
Yoan Jean Claude MICHE
Nagendra Bykampadi
Original Assignee
Nokia Technologies Oy
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 Nokia Technologies Oy filed Critical Nokia Technologies Oy
Priority to PCT/EP2018/070872 priority Critical patent/WO2020025128A1/en
Publication of WO2020025128A1 publication Critical patent/WO2020025128A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • 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/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys

Definitions

  • the present disclosure relates to management of cryptographic information, such as public keys and/or certificates.
  • Securing protocol connections may rely on cryptographic principles.
  • One method is to distribute encryption keys out-of-band, using a trusted messenger, for example, and to use such encryption keys to secure a connection.
  • Such keys may comprise symmetric encryption keys, for example. Since the keys are not shared over the connection used for the protocol connection, the protocol connection is secure.
  • Another family of methods relies on the use of public-key cryptography, where the Diffie-Hellman exchange, for example, may be used to establish a shared secret over an untrusted channel. Further, cryptographic certificates may be employed.
  • an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to receive a message requesting a cryptographic certificate comprising a public key to be published in a blockchain, responsive to the message, publish the cryptographic certificate in the blockchain, and responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publish the revocation of the cryptographic certificate in the blockchain.
  • an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to provide a message to a hrst node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and provide a second message to the hrst node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
  • a method comprising receiving a message requesting a cryptographic certificate comprising a public key to be published in a blockchain, responsive to the message, publishing the cryptographic certificate in the blockchain, and responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publishing the revocation of the cryptographic certificate in the blockchain.
  • a method comprising providing a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and providing a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
  • an apparatus comprising means for receiving a message requesting a cryptographic certificate comprising a public key to be published in a blockchain, responsive to the message, publishing the cryptographic certificate in the blockchain, and responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publishing the revocation of the cryptographic certificate in the blockchain.
  • an apparatus comprising means for providing a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and providing a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
  • a non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least receive a message requesting a cryptographic certificate comprising a public key to be published in a blockchain, responsive to the message, publish the cryptographic certificate in the blockchain, and responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publish the revocation of the cryptographic certificate in the blockchain.
  • a non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least provide a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and provide a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
  • a user equipment apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to provide a message to a node participating in a blockchain, the message requesting a cryptographic certificate from the blockchain to be provided to the apparatus, and receive from the node either the requested cryptographic certificate or an indication the requested cryptographic certificate has been revoked.
  • a method comprising providing a message to a node participating in a blockchain, the message requesting a cryptographic certificate from the blockchain to be provided to the apparatus, and receiving from the node either the requested cryptographic certificate or an indication the requested cryptographic certificate has been revoked.
  • a system comprising an edge node configured to participate in maintaining a blockchain, the edge node being configured to publish at least one cryptographic certificate comprising a public key in the blockchain, and a server configured to communicate with the edge node, to request publication of the at least one cryptographic certificate in the blockchain.
  • a computer program configured to cause a method according to at least one of the third, fourth and tenth aspects to be performed, when run on a computer.
  • FIGURE 1 illustrates an example system in accordance with at least some embodiments
  • FIGURE 2 illustrates a 5G system wherein certain embodiments may be employed
  • FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments
  • FIGURE 4 illustrates signalling in accordance with at least some embodiments
  • FIGURE 5 is a flow graph of a method in accordance with at least some embodiments
  • FIGURE 6 is a flow graph of a method in accordance with at least some embodiments.
  • Certificate publishing and certificate revocation may be performed via a blockchain, which makes both the publication and the revocation of the certificate public and dependable.
  • the certificates might be directly embedded or a link to the certificate storage file, a .CER file, may be embedded.
  • the revocation information may be directly embedded or may be embedded using a linkage to a storage location, for example using online certificate status protocol, OCSP.
  • the fetching methods might use domain name system security extensions, DNS SEC.
  • employing hashes to store certificates in a blockchain enables standardising a size of an entry in the blockchain, regardless of the length of a public key comprised in the certificate.
  • Blockchains in accordance with principles paid out herein may be maintained by network operators, for example.
  • FIGURE 1 illustrates an example system in accordance with at least some embodiments. Schematically are illustrated a cellular network comprising core network 110 and a radio access network 130, and a non-cellular network comprising radio-access part 140 and gateway 120.
  • the cellular network may comprise long term evolution, LTE, or fifth generation, 5G, for example.
  • the non-cellular network may rely on wireless local area network, WLAN, or wireless interoperability for microwave access, WiMAX, for example.
  • Networks have subscribers, which may be connected to the networks via wireless links, as illustrated, or via wire-line connections, such as in the case of, for example, internet service providers, ISPs, or in corporate networks.
  • networks are deployed as functions in one or more telco cloud computing substrates, replacing conventional network elements with virtualized network functions, VNFs, running on data center servers. This may apply to network core functions and also to radio access networks. Example of the latter include cloud radio access network, CloudRAN, and edge cloud solutions.
  • the networks may be connected with each other via an interconnection network, IPX, 150, enabling subscribers of the networks to form protocol connections with each other.
  • IPX interconnection network
  • subscriber 131 may form a connection with subscriber 141 such that the subscribers are the endpoints of the connection.
  • At least one, and possibly both, of subscribers 131, 141 may comprise an internet of things, IoT, device.
  • cryptographic certificates may be used to secure connections between protocol connection endpoints.
  • TLS transport layer security
  • IPSec IPSec protocol
  • a secure channel may be established between the subscribers based on cryptographic certificates, which will be referred to as certificates herein for brevity.
  • a certificate of an endpoint may be signed by a trusted entity, which may be a network operator or, ultimately, a certificate authority, CA.
  • a trusted entity which may be a network operator or, ultimately, a certificate authority, CA.
  • CA certificate authority
  • a receiver of a secured data subscriber may verify a certificate of the other endpoint, such as another node or a server, by checking the signature on the certificate is correct, and then verifying that a signature on a certificate used to verify the first signature is correct, using a root certificate, also known as a trust anchor, for example.
  • a root certificate also known as a trust anchor, for example.
  • a chain of trust may be built from the certificate being used all the way to a root certificate.
  • Certificates may be formatted according to the X.509 standard, or another suitable standard.
  • certificates comprise a public key of a public key - private key pair.
  • Such key pairs may be generated and used in accordance with a public key cryptography cryptosystem, examples of which include the Rivest- Shamir- Adleman, RSA, and ElGamal or DHS cryptosystems.
  • Signatures may be created using the private key, which is not shared, and the signatures may be verified using the public key, which may indeed be shared.
  • information may be encrypted using the public key, such that the encryption may only be reversed using the private key. This makes communication over an untrusted channel secure, as long as the public key really is the public key of the intended endpoint.
  • Signed certificates are a method of ensuring the public key is the public key of the intended endpoint and not, for example, a man-in-the-middle attacker seeking to compromise the protocol connection.
  • the system of FIGURE 1 further comprises a blockchain.
  • This blockchain is a distributed, or at least public, ledger, which may be maintained in more than one node.
  • core network 110 stores a first copy 161 of the blockchain
  • gateway 120 stores a second copy 162 of the blockchain.
  • a blockchain it is meant an ordered sequence of blocks of information.
  • the information in an individual block comprises so-called transaction data, which may comprise any data that it is desired to store in the blockchain.
  • Each individual block also comprises a hash of the immediately preceding block in the sequence.
  • the subsequent block will, in turn, comprise a corresponding hash of the present block, calculated over the transaction data and the hash in the block, the blocks in the sequence collectively form a Merkle tree, or hash tree.
  • the transaction data stored in a blockchain becomes inherently secure against modification, since changing even a single bit in an already established block in the chain would be easily detectable, as the hash values would no longer match. This allows full transparency of the actions of, optimally, ah operators in the world.
  • each block in the chain further comprises a timestamp indicating when the block was established into the blockchain.
  • a new block may be established at regular time intervals, or as a response to accumulation of a pre-determined quantity of new transaction data, for example.
  • a blockchain may be decentralized in that it may be stored in a number of nodes, which copy newly established blocks to each other such that each node has a complete copy of the blockchain.
  • entries making up the transaction data may be shared between participating nodes, to build up the transaction data for a next block to be established into the blockchain. This is the case in FIGURE 1.
  • network operators may participate in maintaining the blockchain by storing copies of it. This may be useful in the present context, as plural operators or ISPs may participate in maintaining the blockchain.
  • Parties may enter entries into the transaction data of the blockchain by transmitting the entry to a node which participates in the blockchain. In these entries, the parties may identify themselves as the owner or originator of the entry.
  • an entry in the blockchain may comprise publication of a certificate of the party making the entry.
  • an entry in the blockchain may comprise publication of a revocation of a certificate. While certificates may have an expiry date built into them, they may also be explicitly revoked, for example as a response to theft of a private key corresponding to the public key in the certificate.
  • a chameleon hash function also known as a trapdoor-hash function, is a hash function that involves a trapdoor the knowledge of which allows one to find arbitrary collisions in the domain of the hash function.
  • Chameleon hash functions are collision resistant as long as the trapdoor is not known.
  • it is easy to derive a second input to the hash function such that it hashes to the same hash value.
  • the node may publish the certificate by including it in transaction data of a block in the blockchain.
  • the request message may comprise the certificate, or the request message may comprise a link to the certificate, for example.
  • the node, or another node participating in the blockchain may publish a revocation of the certificate.
  • the revocation request message may comprise an identifier of the certificate or a link to a certificate.
  • the revocation request message may comprise a signature of the certificate holder or local authority, calculated over the revocation request, such that malicious third parties cannot“revoke” certificates held by others. Such a signature may be generated using the private key corresponding to the public key comprised in the certificate.
  • the certificate may be published in the blockchain in its entirety, that is, such that also the public key part of the certificate is published in the blockchain.
  • the certificate may be published such that the public key is replaced by at least one hash of the public key.
  • An advantage is thereby obtained, wherein the public key may be of any length, but the entry in the blockchain will be of a standard length. As hashes have collisions, using more than one hash, obtained using different hash functions, yields the benefit that the public key may be identified from its hash much more dependably.
  • a pointer to a location where the public key may be fetched from may be stored in the blockchain.
  • the pointer may be cryptographically signed.
  • the pointer may comprise a universal resource locator, URL, for example. Where a hash or hashes are used, this or these may comprise chameleon hashes.
  • At least one corresponding hash may be obtained of the public key of the new certificate and this at least one hash may be compared to the hashes stored in the blockchain.
  • hash functions which may be used in connection with storing the certificates or public keys in the blockchain is locality-sensitive hash functions.
  • Such hash functions have the property that they preserve a similarity between inputs, in that two inputs which differ from each other only slightly produce hashes which differ only slightly. In other words, the relative distance between the input values is preserved in the relative distance between output hash values. Input values that are close to each other will produce output hash values that are close to each other.
  • Using locality- sensitive hashing enables setting a predetermined closeness criterion, such that the new public key may be compared to the earlier public keys, and the new key may be rejected if it is too similar to at least one of the earlier keys.
  • the new public key differs, by accident, only by one bit from an earlier key, it will very likely be too close to the earlier key.
  • Examples of locality sensitive hashes include Nilsimsa hashes and TLSH hashes.
  • attempts to re-introduce an expired certificate into the blockchain may be thwarted, since by checking the hashes in the blockchain, it may be detected that the public key of the certificate has already been stored in the blockchain, and moreover that the certificate it was associated with has expired.
  • Using more than one locality-preserving hash to publish a public key in the blockchain may increase the reliability of the closeness determination.
  • the closeness criterion may comprise an“or” criterion relating to these hash functions, wherein the new key is considered close to an older one in case at least one of the locality preserving hash functions indicates the keys are close.
  • the closeness criterion may comprise that the new key is close to the old key only in case both locality-preserving hash functions indicate the key is close.
  • blockchain updates may piggyback normal messages which are exchanged between operators in any case.
  • a blockchain update may be included in a location update authentication request sent via interconnection network to another network, such as a home network of subscriber 131, where a core network node charged with maintaining the blockchain will use the update to modify the copy of the blockchain it has, before passing the message along to a node which will handle it.
  • FIGURE 2 illustrates a fifth generation, 5G system wherein certain embodiments may be employed.
  • the security edge protection proxy is the edge node and the N32 interface corresponds to an interface with the interconnection network 150 of FIGURE 1.
  • the user equipment, UE corresponds to a subscriber and (R)AN corresponds to a (radio) access network.
  • Access and Mobility Management Function, AMF supports NAS functions and connection management.
  • Session Management Function, SMF supports session management functions such as establishment and release.
  • User Plane Function, UPF supports packet routing, quality-of- service and interconnects to data networks, DN.
  • a similar system is possible for 4G with the S6a interface and the MME/HSS for example.
  • Network Slice Selection Function supports selecting network slices to serve a user equipment.
  • Network Exposure Function supports exposure of capabilities and secure provision of information from external networks, for example.
  • NF Repository Function performs a service discovery function.
  • a Policy Control Function, PCF provides policy rules to functions.
  • Application Functions, AF supports interactions with policy control and performs application influence on traffic routing.
  • the SEPP is an edge node that sits at the perimeter of the network and protects the network from incoming messages.
  • the SEPP may be the node in the core network which participates in the blockchain, for example.
  • the vSEPP is a visited-network SEPP, while the hSEPP is a SEPP in the home network.
  • a new message type may be defined to transfer blockchain updates.
  • the message may be sent using the N32 control plane protocol, which may be HTTP or HTTPS based.
  • existing messages using HTTP REST API could be extended with further information to carry updates to the blockchains. For example, a location update takes place and this message that is send to the SEPP is extended to carry also the blockchain update.
  • An end to end, e2e, TLS connection may be established between the sending SEPP and each target SEPP.
  • a HTTP based message may be generated and the blockchain update respectively stored in the payload. The message may then be sent to each of its partner SEPPs, directly or indirectly.
  • Blockchain updates may be carried within the HTTP message as for JSON content, for example. Alternatively, the updates may be contained in XML document or even a binary stream.
  • FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments. Illustrated is device 300, which may comprise, for example, a core network node of FIGURE 1 or FIGURE 2.
  • processor 310 which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core.
  • Processor 310 may comprise, in general, a control device.
  • Processor 310 may comprise more than one processor.
  • Processor 310 may be a control device.
  • a processing core may comprise, for example, a Cortex- A8 processing core manufactured by ARM Holdings or a Steamroller processing core produced by Advanced Micro Devices Corporation.
  • Processor 310 may comprise at least one Qualcomm Snapdragon and/or Intel Atom processor.
  • Processor 310 may comprise at least one application-specific integrated circuit, ASIC.
  • Processor 310 may comprise at least one field-programmable gate array, FPGA.
  • Processor 310 may be means for performing method steps in device 300.
  • Processor 310 may be configured, at least in part by computer instructions, to perform actions.
  • a processor may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with embodiments described herein.
  • circuitry may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a core network node, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
  • firmware firmware
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
  • Device 300 may comprise memory 320.
  • Memory 320 may comprise random- access memory and/or permanent memory.
  • Memory 320 may comprise at least one RAM chip.
  • Memory 320 may comprise solid-state, magnetic, optical and/or holographic memory, for example.
  • Memory 320 may be at least in part accessible to processor 310.
  • Memory 320 may be at least in part comprised in processor 310.
  • Memory 320 may be means for storing information.
  • Memory 320 may comprise computer instructions that processor 310 is configured to execute. When computer instructions configured to cause processor 310 to perform certain actions are stored in memory 320, and device 300 overall is configured to run under the direction of processor 310 using computer instructions from memory 320, processor 310 and/or its at least one processing core may be considered to be configured to perform said certain actions.
  • Memory 320 may be at least in part comprised in processor 310.
  • Memory 320 may be at least in part external to device 300 but accessible to device 300.
  • Device 300 may comprise a transmitter 330.
  • Device 300 may comprise a receiver 340.
  • Transmitter 330 and receiver 340 may be configured to transmit and receive, respectively, information in accordance with at least one cellular or non-cellular standard.
  • Transmitter 330 may comprise more than one transmiter.
  • Receiver 340 may comprise more than one receiver.
  • Transmiter 330 and/or receiver 340 may be configured to operate in accordance with global system for mobile communication, GSM, wideband code division multiple access, WCDMA, 5G, long term evolution, LTE, IS-95, wireless local area network, WLAN, Ethernet and/or worldwide interoperability for microwave access, WiMAX, standards, for example.
  • Device 300 may comprise user interface, UI, 360.
  • UI 360 may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device 300 to vibrate, a speaker and a microphone.
  • a user may be able to operate device 300 via UI 360, for example to configure network parameters.
  • Processor 310 may be furnished with a transmitter arranged to output information from processor 310, via electrical leads internal to device 300, to other devices comprised in device 300.
  • Such a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 320 for storage therein.
  • the transmitter may comprise a parallel bus transmitter.
  • processor 310 may comprise a receiver arranged to receive information in processor 310, via electrical leads internal to device 300, from other devices comprised in device 300.
  • a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from receiver 340 for processing in processor 310.
  • the receiver may comprise a parallel bus receiver.
  • Processor 310, memory 320, transmitter 330, receiver 340 and/or UI 360 may be interconnected by electrical leads internal to device 300 in a multitude of different ways.
  • each of the aforementioned devices may be separately connected to a master bus internal to device 300, to allow for the devices to exchange information.
  • this is only one example and depending on the embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention..
  • FIGURE 4 illustrates signalling in accordance with at least some embodiments.
  • node 401 On the vertical axes are disposed, on the left, node 401, in the center, nodes BCN participating in the blockchain and on the right, node 402.
  • the nodes BCN may comprise SEPP nodes, for example. Time advances from the top toward the bottom.
  • Phase 410 is the maintenance of the blockchain by nodes BCN. This may comprise, for example, maintaining a copy of the blockchain in each of the nodes BCN, such that any node BCN can serve a request concerning information stored in the blockchain. Phase 410 may thus comprise, for example, copying new blocks among nodes BCN as they are established into the blockchain.
  • node 401 transmits a message to the blockchain, requesting a certificate to be published in the blockchain.
  • nodes BCN include the certificate in a block which is established in the blockchain, thus publishing it.
  • node 402 inquires from the blockchain, if a certificate it has is genuine.
  • one of the nodes BCN provides a section of a block, or an entire block, of the blockchain data to node 402, enabling node 402 to verify it has an authentic copy of the certificate.
  • node 402 may want to obtain a certificate of node 401 it does not have, and phase 430 would be seen as a request to be provided the certificate, which is provided in phase 440 in response.
  • node 401 requests the blockchain to publish a revocation of the certificate published as a response to phase 420.
  • the nodes BCN publish the requested revocation in the blockchain, as described herein above.
  • node 402 or, indeed, another node, requests the certificate from the blockchain by transmitting a request 460 to one of the nodes BCN. Responsively, the BCN node responds, phase 470, by informing that the certificate has been revoked. Thus node 402 may be spared from using a potentially unsafe certificate in establishing a protocol connection, such as, for example, a TLS connection.
  • a protocol connection such as, for example, a TLS connection.
  • FIGURE 5 is a flow graph of a method in accordance with at least some embodiments.
  • the phases of the illustrated method may be performed in a core network node, for example.
  • Phase 510 comprises receiving a message requesting a cryptographic certificate comprising a public key to be published in a blockchain.
  • Phase 520 comprises, responsive to the message, publishing the cryptographic certificate in the blockchain.
  • Phase 520 comprises, responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publishing the revocation of the cryptographic certificate in the blockchain
  • FIGURE 6 is a flow graph of a method in accordance with at least some embodiments.
  • the phases of the illustrated method may be performed in a core network node, for example a key management node.
  • Phase 610 comprises providing a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain.
  • Phase 620 comprises providing a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
  • At least some embodiments of the present invention find industrial application in managing certificates for communication network security.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

According to an example aspect of the present invention, there is provided an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to receive a message requesting a cryptographic certificate comprising a public key to be published in a blockchain, responsive to the message, publish the cryptographic certificate in the blockchain, and responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publish the revocation of the cryptographic certificate in the blockchain.

Description

CERTIFICATE MANAGEMENT
FIELD
[0001] The present disclosure relates to management of cryptographic information, such as public keys and/or certificates.
BACKGROUND
[0002] Securing protocol connections may rely on cryptographic principles. One method is to distribute encryption keys out-of-band, using a trusted messenger, for example, and to use such encryption keys to secure a connection. Such keys may comprise symmetric encryption keys, for example. Since the keys are not shared over the connection used for the protocol connection, the protocol connection is secure. Another family of methods relies on the use of public-key cryptography, where the Diffie-Hellman exchange, for example, may be used to establish a shared secret over an untrusted channel. Further, cryptographic certificates may be employed.
SUMMARY [0003] According to some aspects, there is provided the subject-matter of the independent claims. Some embodiments are defined in the dependent claims.
[0004] According to a first aspect, there is provided an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to receive a message requesting a cryptographic certificate comprising a public key to be published in a blockchain, responsive to the message, publish the cryptographic certificate in the blockchain, and responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publish the revocation of the cryptographic certificate in the blockchain.
[0005] According to a second aspect, there is provided an apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to provide a message to a hrst node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and provide a second message to the hrst node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
[0006] According to a third aspect, there is provided a method comprising receiving a message requesting a cryptographic certificate comprising a public key to be published in a blockchain, responsive to the message, publishing the cryptographic certificate in the blockchain, and responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publishing the revocation of the cryptographic certificate in the blockchain.
[0007] According to a fourth aspect, there is provided a method, comprising providing a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and providing a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
[0008] According to a fifth aspect, there is provided an apparatus comprising means for receiving a message requesting a cryptographic certificate comprising a public key to be published in a blockchain, responsive to the message, publishing the cryptographic certificate in the blockchain, and responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publishing the revocation of the cryptographic certificate in the blockchain.
[0009] According to a sixth aspect, there is provided an apparatus comprising means for providing a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and providing a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
[0010] According to a seventh aspect, there is provided a non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least receive a message requesting a cryptographic certificate comprising a public key to be published in a blockchain, responsive to the message, publish the cryptographic certificate in the blockchain, and responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publish the revocation of the cryptographic certificate in the blockchain.
[0011] According to an eighth aspect, there is provided a non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least provide a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and provide a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
[0012] According to a ninth aspect, there is provided a user equipment apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to provide a message to a node participating in a blockchain, the message requesting a cryptographic certificate from the blockchain to be provided to the apparatus, and receive from the node either the requested cryptographic certificate or an indication the requested cryptographic certificate has been revoked.
[0013] According to a tenth aspect, there is provided a method, comprising providing a message to a node participating in a blockchain, the message requesting a cryptographic certificate from the blockchain to be provided to the apparatus, and receiving from the node either the requested cryptographic certificate or an indication the requested cryptographic certificate has been revoked. [0014] According to an eleventh aspect, there is provided a system comprising an edge node configured to participate in maintaining a blockchain, the edge node being configured to publish at least one cryptographic certificate comprising a public key in the blockchain, and a server configured to communicate with the edge node, to request publication of the at least one cryptographic certificate in the blockchain.
[0015] According to a twelfth aspect, there is provided a computer program configured to cause a method according to at least one of the third, fourth and tenth aspects to be performed, when run on a computer.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] FIGURE 1 illustrates an example system in accordance with at least some embodiments;
[0017] FIGURE 2 illustrates a 5G system wherein certain embodiments may be employed;
[0018] FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments;
[0019] FIGURE 4 illustrates signalling in accordance with at least some embodiments; [0020] FIGURE 5 is a flow graph of a method in accordance with at least some embodiments, and
[0021] FIGURE 6 is a flow graph of a method in accordance with at least some embodiments.
EMBODIMENTS [0022] Certificate publishing and certificate revocation may be performed via a blockchain, which makes both the publication and the revocation of the certificate public and dependable. The certificates might be directly embedded or a link to the certificate storage file, a .CER file, may be embedded. Similarly the revocation information, may be directly embedded or may be embedded using a linkage to a storage location, for example using online certificate status protocol, OCSP. The fetching methods might use domain name system security extensions, DNS SEC. Further, employing hashes to store certificates in a blockchain enables standardising a size of an entry in the blockchain, regardless of the length of a public key comprised in the certificate. Blockchains in accordance with principles paid out herein may be maintained by network operators, for example.
[0023] FIGURE 1 illustrates an example system in accordance with at least some embodiments. Schematically are illustrated a cellular network comprising core network 110 and a radio access network 130, and a non-cellular network comprising radio-access part 140 and gateway 120. The cellular network may comprise long term evolution, LTE, or fifth generation, 5G, for example. The non-cellular network may rely on wireless local area network, WLAN, or wireless interoperability for microwave access, WiMAX, for example. Networks have subscribers, which may be connected to the networks via wireless links, as illustrated, or via wire-line connections, such as in the case of, for example, internet service providers, ISPs, or in corporate networks. In some embodiments, networks are deployed as functions in one or more telco cloud computing substrates, replacing conventional network elements with virtualized network functions, VNFs, running on data center servers. This may apply to network core functions and also to radio access networks. Example of the latter include cloud radio access network, CloudRAN, and edge cloud solutions.
[0024] The networks may be connected with each other via an interconnection network, IPX, 150, enabling subscribers of the networks to form protocol connections with each other. For example, subscriber 131 may form a connection with subscriber 141 such that the subscribers are the endpoints of the connection. At least one, and possibly both, of subscribers 131, 141 may comprise an internet of things, IoT, device. To secure connections between protocol connection endpoints, cryptographic certificates may be used. Using the transport layer security, TLS, or IPSec protocol, for example, a secure channel may be established between the subscribers based on cryptographic certificates, which will be referred to as certificates herein for brevity. A certificate of an endpoint may be signed by a trusted entity, which may be a network operator or, ultimately, a certificate authority, CA. In an IPX network it is expected that many certificates will be self-signed and that there will be no world central CA. There might be regional Cas. A receiver of a secured data subscriber may verify a certificate of the other endpoint, such as another node or a server, by checking the signature on the certificate is correct, and then verifying that a signature on a certificate used to verify the first signature is correct, using a root certificate, also known as a trust anchor, for example. Thus a chain of trust may be built from the certificate being used all the way to a root certificate.
[0025] Certificates may be formatted according to the X.509 standard, or another suitable standard. In general, certificates comprise a public key of a public key - private key pair. Such key pairs may be generated and used in accordance with a public key cryptography cryptosystem, examples of which include the Rivest- Shamir- Adleman, RSA, and ElGamal or DHS cryptosystems. Signatures may be created using the private key, which is not shared, and the signatures may be verified using the public key, which may indeed be shared. Likewise, information may be encrypted using the public key, such that the encryption may only be reversed using the private key. This makes communication over an untrusted channel secure, as long as the public key really is the public key of the intended endpoint. Signed certificates are a method of ensuring the public key is the public key of the intended endpoint and not, for example, a man-in-the-middle attacker seeking to compromise the protocol connection.
[0026] The system of FIGURE 1 further comprises a blockchain. This blockchain is a distributed, or at least public, ledger, which may be maintained in more than one node. In the example of FIGURE 1, core network 110 stores a first copy 161 of the blockchain, and gateway 120 stores a second copy 162 of the blockchain.
[0027] By a blockchain it is meant an ordered sequence of blocks of information. The information in an individual block comprises so-called transaction data, which may comprise any data that it is desired to store in the blockchain. Each individual block also comprises a hash of the immediately preceding block in the sequence. As the subsequent block will, in turn, comprise a corresponding hash of the present block, calculated over the transaction data and the hash in the block, the blocks in the sequence collectively form a Merkle tree, or hash tree. Thus the transaction data stored in a blockchain becomes inherently secure against modification, since changing even a single bit in an already established block in the chain would be easily detectable, as the hash values would no longer match. This allows full transparency of the actions of, optimally, ah operators in the world. It is a characteristic of normal hash functions, that changing even a single bit in the input data causes a large change in the hash itself. In some embodiments, each block in the chain further comprises a timestamp indicating when the block was established into the blockchain. A new block may be established at regular time intervals, or as a response to accumulation of a pre-determined quantity of new transaction data, for example.
[0028] In principle a blockchain may be decentralized in that it may be stored in a number of nodes, which copy newly established blocks to each other such that each node has a complete copy of the blockchain. In establishing a new block, entries making up the transaction data may be shared between participating nodes, to build up the transaction data for a next block to be established into the blockchain. This is the case in FIGURE 1. In general, network operators may participate in maintaining the blockchain by storing copies of it. This may be useful in the present context, as plural operators or ISPs may participate in maintaining the blockchain. Parties may enter entries into the transaction data of the blockchain by transmitting the entry to a node which participates in the blockchain. In these entries, the parties may identify themselves as the owner or originator of the entry. For example, an entry in the blockchain may comprise publication of a certificate of the party making the entry. As another example, an entry in the blockchain may comprise publication of a revocation of a certificate. While certificates may have an expiry date built into them, they may also be explicitly revoked, for example as a response to theft of a private key corresponding to the public key in the certificate.
[0029] When a revocation of a certificate is published in the blockchain, an endpoint can easily determine, with reference to the blockchain, the certificate has been revoked, and responsively stop using it in communications. In connection with a revocation, a new certificate may be published, for example in the blockchain. Owing to the irrevocable nature of the blockchain, a malicious party having stolen the private key is not able to remove the revocation from the blockchain once it has been included in transaction data of a block established into the chain.
[0030] A chameleon hash function, also known as a trapdoor-hash function, is a hash function that involves a trapdoor the knowledge of which allows one to find arbitrary collisions in the domain of the hash function. Chameleon hash functions are collision resistant as long as the trapdoor is not known. On the other hand, in case the trapdoor is known, it is easy to derive a second input to the hash function such that it hashes to the same hash value.
[0031] In general, once a node participating in the blockchain receives a request message requesting a certificate to be published in the blockchain, the node may publish the certificate by including it in transaction data of a block in the blockchain. The request message may comprise the certificate, or the request message may comprise a link to the certificate, for example. Later on, responsive to a revocation request message, the node, or another node participating in the blockchain, may publish a revocation of the certificate. The revocation request message may comprise an identifier of the certificate or a link to a certificate. The revocation request message may comprise a signature of the certificate holder or local authority, calculated over the revocation request, such that malicious third parties cannot“revoke” certificates held by others. Such a signature may be generated using the private key corresponding to the public key comprised in the certificate.
[0032] The certificate may be published in the blockchain in its entirety, that is, such that also the public key part of the certificate is published in the blockchain. Alternatively to publishing the certificate in full, the certificate may be published such that the public key is replaced by at least one hash of the public key. An advantage is thereby obtained, wherein the public key may be of any length, but the entry in the blockchain will be of a standard length. As hashes have collisions, using more than one hash, obtained using different hash functions, yields the benefit that the public key may be identified from its hash much more dependably. In addition to the hash or hashes, a pointer to a location where the public key may be fetched from may be stored in the blockchain. The pointer may be cryptographically signed. The pointer may comprise a universal resource locator, URL, for example. Where a hash or hashes are used, this or these may comprise chameleon hashes.
[0033] Before publishing a certificate in the blockchain, it may be checked, if the public key is distinct from public keys of certificates published earlier in the blockchain. Where the certificates are published in the blockchain in their entirety, this may comprise comparing the public key of the new certificate to the keys of earlier-published certificates.
[0034] On the other hand, where hashes are used in publishing certificates, as described above, at least one corresponding hash may be obtained of the public key of the new certificate and this at least one hash may be compared to the hashes stored in the blockchain.
[0035] One type of hash functions which may be used in connection with storing the certificates or public keys in the blockchain is locality-sensitive hash functions. Such hash functions have the property that they preserve a similarity between inputs, in that two inputs which differ from each other only slightly produce hashes which differ only slightly. In other words, the relative distance between the input values is preserved in the relative distance between output hash values. Input values that are close to each other will produce output hash values that are close to each other. Using locality- sensitive hashing enables setting a predetermined closeness criterion, such that the new public key may be compared to the earlier public keys, and the new key may be rejected if it is too similar to at least one of the earlier keys. For example, if the new public key differs, by accident, only by one bit from an earlier key, it will very likely be too close to the earlier key. Examples of locality sensitive hashes include Nilsimsa hashes and TLSH hashes. Using this mechanism, attempts to re-introduce an expired certificate into the blockchain may be thwarted, since by checking the hashes in the blockchain, it may be detected that the public key of the certificate has already been stored in the blockchain, and moreover that the certificate it was associated with has expired. Using more than one locality-preserving hash to publish a public key in the blockchain may increase the reliability of the closeness determination. For example, two different locality preserving hash functions may be used, and the closeness criterion may comprise an“or” criterion relating to these hash functions, wherein the new key is considered close to an older one in case at least one of the locality preserving hash functions indicates the keys are close. Alternatively, the closeness criterion may comprise that the new key is close to the old key only in case both locality-preserving hash functions indicate the key is close.
[0036] For example, blockchain updates may piggyback normal messages which are exchanged between operators in any case. For example, in case subscriber 131 connects to radio access network 130 and core network 110 in a situation where the operator of core network node 110 has a new key it wishes to distribute, a blockchain update may be included in a location update authentication request sent via interconnection network to another network, such as a home network of subscriber 131, where a core network node charged with maintaining the blockchain will use the update to modify the copy of the blockchain it has, before passing the message along to a node which will handle it. [0037] FIGURE 2 illustrates a fifth generation, 5G system wherein certain embodiments may be employed. Here the security edge protection proxy, SEPP, is the edge node and the N32 interface corresponds to an interface with the interconnection network 150 of FIGURE 1. The user equipment, UE, corresponds to a subscriber and (R)AN corresponds to a (radio) access network. Access and Mobility Management Function, AMF, supports NAS functions and connection management. Session Management Function, SMF, supports session management functions such as establishment and release. User Plane Function, UPF, supports packet routing, quality-of- service and interconnects to data networks, DN. A similar system is possible for 4G with the S6a interface and the MME/HSS for example.
[0038] Network Slice Selection Function, NSSF, supports selecting network slices to serve a user equipment. Network Exposure Function, NEF, supports exposure of capabilities and secure provision of information from external networks, for example. NF Repository Function, NRF, performs a service discovery function. A Policy Control Function, PCF, provides policy rules to functions. Application Functions, AF, supports interactions with policy control and performs application influence on traffic routing.
[0039] In the architecture of FIGURE 2, for 5G SBA, the SEPP is an edge node that sits at the perimeter of the network and protects the network from incoming messages. The SEPP may be the node in the core network which participates in the blockchain, for example. The vSEPP is a visited-network SEPP, while the hSEPP is a SEPP in the home network.
[0040] When an operator successfully adds or updates its own certificate in the blockchain or sees an update to the blockchain, the SEPP belonging to that operator may distribute these updates to its partner SEPPs over the N32 interface. A new message type may be defined to transfer blockchain updates. The message may be sent using the N32 control plane protocol, which may be HTTP or HTTPS based. Alternatively, existing messages using HTTP REST API could be extended with further information to carry updates to the blockchains. For example, a location update takes place and this message that is send to the SEPP is extended to carry also the blockchain update. An end to end, e2e, TLS connection may be established between the sending SEPP and each target SEPP. A HTTP based message may be generated and the blockchain update respectively stored in the payload. The message may then be sent to each of its partner SEPPs, directly or indirectly. Blockchain updates may be carried within the HTTP message as for JSON content, for example. Alternatively, the updates may be contained in XML document or even a binary stream.
[0041] FIGURE 3 illustrates an example apparatus capable of supporting at least some embodiments. Illustrated is device 300, which may comprise, for example, a core network node of FIGURE 1 or FIGURE 2. Comprised in device 300 is processor 310, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core. Processor 310 may comprise, in general, a control device. Processor 310 may comprise more than one processor. Processor 310 may be a control device. A processing core may comprise, for example, a Cortex- A8 processing core manufactured by ARM Holdings or a Steamroller processing core produced by Advanced Micro Devices Corporation. Processor 310 may comprise at least one Qualcomm Snapdragon and/or Intel Atom processor. Processor 310 may comprise at least one application-specific integrated circuit, ASIC. Processor 310 may comprise at least one field-programmable gate array, FPGA. Processor 310 may be means for performing method steps in device 300. Processor 310 may be configured, at least in part by computer instructions, to perform actions.
[0042] A processor may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with embodiments described herein. As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a core network node, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
[0043] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
[0044] Device 300 may comprise memory 320. Memory 320 may comprise random- access memory and/or permanent memory. Memory 320 may comprise at least one RAM chip. Memory 320 may comprise solid-state, magnetic, optical and/or holographic memory, for example. Memory 320 may be at least in part accessible to processor 310. Memory 320 may be at least in part comprised in processor 310. Memory 320 may be means for storing information. Memory 320 may comprise computer instructions that processor 310 is configured to execute. When computer instructions configured to cause processor 310 to perform certain actions are stored in memory 320, and device 300 overall is configured to run under the direction of processor 310 using computer instructions from memory 320, processor 310 and/or its at least one processing core may be considered to be configured to perform said certain actions. Memory 320 may be at least in part comprised in processor 310. Memory 320 may be at least in part external to device 300 but accessible to device 300.
[0045] Device 300 may comprise a transmitter 330. Device 300 may comprise a receiver 340. Transmitter 330 and receiver 340 may be configured to transmit and receive, respectively, information in accordance with at least one cellular or non-cellular standard. Transmitter 330 may comprise more than one transmiter. Receiver 340 may comprise more than one receiver. Transmiter 330 and/or receiver 340 may be configured to operate in accordance with global system for mobile communication, GSM, wideband code division multiple access, WCDMA, 5G, long term evolution, LTE, IS-95, wireless local area network, WLAN, Ethernet and/or worldwide interoperability for microwave access, WiMAX, standards, for example.
[0046] Device 300 may comprise user interface, UI, 360. UI 360 may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device 300 to vibrate, a speaker and a microphone. A user may be able to operate device 300 via UI 360, for example to configure network parameters. [0047] Processor 310 may be furnished with a transmitter arranged to output information from processor 310, via electrical leads internal to device 300, to other devices comprised in device 300. Such a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 320 for storage therein. Alternatively to a serial bus, the transmitter may comprise a parallel bus transmitter. Likewise processor 310 may comprise a receiver arranged to receive information in processor 310, via electrical leads internal to device 300, from other devices comprised in device 300. Such a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from receiver 340 for processing in processor 310. Alternatively to a serial bus, the receiver may comprise a parallel bus receiver.
[0048] Processor 310, memory 320, transmitter 330, receiver 340 and/or UI 360 may be interconnected by electrical leads internal to device 300 in a multitude of different ways. For example, each of the aforementioned devices may be separately connected to a master bus internal to device 300, to allow for the devices to exchange information. However, as the skilled person will appreciate, this is only one example and depending on the embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention..
[0049] FIGURE 4 illustrates signalling in accordance with at least some embodiments. On the vertical axes are disposed, on the left, node 401, in the center, nodes BCN participating in the blockchain and on the right, node 402. The nodes BCN may comprise SEPP nodes, for example. Time advances from the top toward the bottom.
[0050] Phase 410, continuing throughout the process of FIGURE 4, is the maintenance of the blockchain by nodes BCN. This may comprise, for example, maintaining a copy of the blockchain in each of the nodes BCN, such that any node BCN can serve a request concerning information stored in the blockchain. Phase 410 may thus comprise, for example, copying new blocks among nodes BCN as they are established into the blockchain.
[0051] In phase 420, node 401 transmits a message to the blockchain, requesting a certificate to be published in the blockchain. In response, nodes BCN include the certificate in a block which is established in the blockchain, thus publishing it. [0052] In phase 430, node 402 inquires from the blockchain, if a certificate it has is genuine. In response, in phase 440 one of the nodes BCN provides a section of a block, or an entire block, of the blockchain data to node 402, enabling node 402 to verify it has an authentic copy of the certificate. Alternatively, node 402 may want to obtain a certificate of node 401 it does not have, and phase 430 would be seen as a request to be provided the certificate, which is provided in phase 440 in response.
[0053] Later, in phase 450, node 401 requests the blockchain to publish a revocation of the certificate published as a response to phase 420. In response, the nodes BCN publish the requested revocation in the blockchain, as described herein above.
[0054] Subsequently to phase 450, node 402 or, indeed, another node, requests the certificate from the blockchain by transmitting a request 460 to one of the nodes BCN. Responsively, the BCN node responds, phase 470, by informing that the certificate has been revoked. Thus node 402 may be spared from using a potentially unsafe certificate in establishing a protocol connection, such as, for example, a TLS connection.
[0055] FIGURE 5 is a flow graph of a method in accordance with at least some embodiments. The phases of the illustrated method may be performed in a core network node, for example.
[0056] Phase 510 comprises receiving a message requesting a cryptographic certificate comprising a public key to be published in a blockchain. Phase 520 comprises, responsive to the message, publishing the cryptographic certificate in the blockchain. Phase 520 comprises, responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publishing the revocation of the cryptographic certificate in the blockchain
[0057] FIGURE 6 is a flow graph of a method in accordance with at least some embodiments. The phases of the illustrated method may be performed in a core network node, for example a key management node.
[0058] Phase 610 comprises providing a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain. Phase 620 comprises providing a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain. [0059] It is to be understood that the embodiments of the invention disclosed are not limited to the particular structures, process steps, or materials disclosed herein, but are extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular embodiments only and is not intended to be limiting.
[0060] Reference throughout this specification to one embodiment or an embodiment means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases“in one embodiment” or“in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Where reference is made to a numerical value using a term such as, for example, about or substantially, the exact numerical value is also disclosed.
[0061] As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and example of the present invention may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations of the present invention.
[0062] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the preceding description, numerous specific details are provided, such as examples of lengths, widths, shapes, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
[0063] While the forgoing examples are illustrative of the principles of the present invention in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the invention. Accordingly, it is not intended that the invention be limited, except as by the claims set forth below. [0064] The verbs“to comprise” and“to include” are used in this document as open limitations that neither exclude nor require the existence of also un-recited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated. Furthermore, it is to be understood that the use of "a" or "an", that is, a singular form, throughout this document does not exclude a plurality. INDUSTRIAL APPLICABILITY
[0065] At least some embodiments of the present invention find industrial application in managing certificates for communication network security.
REFERENCE SIGNS LIST
Figure imgf000017_0001
CITATION LIST
[1]“Efficient Trapdoor Hash Functions for Digital Signatures” by Fuw-Yi Yang of Chaoyang University of Technology, Taiwan. [2]“Multi-trapdoor hash functions and their applications in network security” by Santosh Chandrasekhar and Mukesh Singhal, 2014 IEEE Conference on Communications and Network Security

Claims

CLAIMS:
1. An apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to:
- receive a message requesting a cryptographic certificate comprising a public key to be published in a blockchain;
- responsive to the message, publish the cryptographic certificate in the blockchain, and
- responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publish the revocation of the cryptographic certificate in the blockchain.
2. The apparatus according to claim 1, wherein the at least one memory and the computer program code are configured to, with the at least one processing core, cause the apparatus to publish the cryptographic certificate in the blockchain by publishing the entire cryptographic certificate in the blockchain.
3. The apparatus according to claim 1, wherein the at least one memory and the computer program code are configured to, with the at least one processing core, cause the apparatus to publish the cryptographic certificate in the blockchain such that the public key part of the certificate is not stored into the blockchain, and at least one hash of the public key is stored in the blockchain instead of the public key.
4. The apparatus according to claim 3, wherein the at least one memory and the computer program code are configured to, with the at least one processing core, cause the apparatus to publish the cryptographic certificate in the blockchain such that at least two different hashes of the public key are stored in the blockchain.
5. The apparatus according to claim 3 or 4, wherein the at least one memory and the computer program code are configured to, with the at least one processing core, cause the apparatus to use at least one chameleon hash function in obtaining the at least one hash of the public key.
6. The apparatus according to any preceding claim, wherein the at least one memory and the computer program code are configured to, with the at least one processing core, further cause the apparatus to determine, before publishing the cryptographic certificate in the blockchain, whether the public key of the cryptographic certificate is different from keys of certificates published in the blockchain earlier.
7. The apparatus according to claim 6, wherein the at least one memory and the computer program code are configured to, with the at least one processing core, cause the apparatus to determine whether the public key is different at least in part by comparing at least one hash of the public key to hashes of the keys of the earlier published certificates.
8. The apparatus according to claim 6 or 7, wherein the at least one memory and the computer program code are configured to, with the at least one processing core, cause the apparatus to apply a locality sensitive hash together with a predetermined closeness condition to determine, if the public key is sufficiently different from the earlier published keys to be accepted into the blockchain.
9. The apparatus according to any preceding claim, wherein the apparatus comprises a security edge protection proxy, SEPP, node connected with an interconnection network via an N32 interface.
10. An apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to:
- provide a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and
- provide a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
11. The apparatus according to claim 10, wherein the cryptographic certificate has an expiry date.
12. The apparatus according to claim 10 or 11, wherein at least one of the first node and the second node comprises an edge node of a core network of a cellular communication network.
13. A method comprising:
- receiving a message requesting a cryptographic certificate comprising a public key to be published in a blockchain;
- responsive to the message, publishing the cryptographic certificate in the blockchain, and
- responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publishing the revocation of the cryptographic certificate in the blockchain.
14. The method according to claim 13, wherein publishing the cryptographic certificate in the blockchain comprises publishing the entire cryptographic certificate in the blockchain.
15. The method according to claim 13, wherein publishing the cryptographic certificate in the blockchain comprises publishing the cryptographic certificate in the blockchain such that the public key part of the certificate is not stored into the blockchain, and at least one hash of the public key is stored in the blockchain instead of the public key.
16. The method according to claim 15, wherein the cryptographic certificate is published in the blockchain such that at least two different hashes of the public key are stored in the blockchain.
17. The method according to claim 15 or 16, wherein at least one chameleon hash function in obtaining the at least one hash of the public key.
18. The method according to any of claims 13 - 17, further comprising determining, before publishing the cryptographic certificate in the blockchain, whether the public key of the cryptographic certificate is different from keys of certificates published in the blockchain earlier.
19. The method according to claim 18, wherein the determination whether the public key is different comprises comparing at least one hash of the public key to hashes of the keys of the earlier published certificates.
20. The method according to claim 18 or 19, wherein a locality sensitive hash is applied together with a predetermined closeness condition to determine, if the public key is sufficiently different from the earlier published keys to be accepted into the blockchain.
21. A method, comprising:
- providing a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and
- providing a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
22. The method according to claim 21, wherein the cryptographic certificate has an expiry date.
23. The method according to claim 21 or 22, wherein at least one of the first node and the second node comprises an edge node of a core network of a cellular communication network.
24. An apparatus comprising means for:
- receiving a message requesting a cryptographic certificate comprising a public key to be published in a blockchain;
- responsive to the message, publishing the cryptographic certificate in the blockchain, and
- responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publishing the revocation of the cryptographic certificate in the blockchain.
25. An apparatus comprising means for; - providing a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and
- providing a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
26. A non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least:
- receive a message requesting a cryptographic certificate comprising a public key to be published in a blockchain;
- responsive to the message, publish the cryptographic certificate in the blockchain, and
- responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publish the revocation of the cryptographic certificate in the blockchain.
27. A non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least:
- provide a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and
- provide a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
28. A user equipment apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to:
- provide a message to a node participating in a blockchain, the message requesting a cryptographic certificate from the blockchain to be provided to the apparatus, and - receive from the node either the requested cryptographic certificate or an indication the requested cryptographic certificate has been revoked.
29. A method, comprising:
- providing a message to a node participating in a blockchain, the message requesting a cryptographic certificate from the blockchain to be provided to the apparatus, and
- receiving from the node either the requested cryptographic certificate or an indication the requested cryptographic certificate has been revoked.
30. A system comprising:
- an edge node configured to participate in maintaining a blockchain, the edge node being configured to publish at least one cryptographic certificate comprising a public key in the blockchain, and
- a server configured to communicate with the edge node, to request publication of the at least one cryptographic certificate in the blockchain.
31. A computer program configured to cause, when run on at least one processing core, an apparatus comprising the processing core to either:
- receive a message requesting a cryptographic certificate comprising a public key to be published in a blockchain, and
- responsive to the message, publish the cryptographic certificate in the blockchain, and
- responsive to a second message requesting a revocation of the cryptographic certificate to be published in the blockchain, publish the revocation of the cryptographic certificate in the blockchain,
or:
- provide a message to a first node participating in a blockchain, the message requesting a cryptographic certificate to be published in the blockchain, and
- provide a second message to the first node or a second node participating in the blockchain, the second message requesting a revocation of the cryptographic certificate to be published in the blockchain.
PCT/EP2018/070872 2018-08-01 2018-08-01 Certificate management WO2020025128A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2018/070872 WO2020025128A1 (en) 2018-08-01 2018-08-01 Certificate management

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2018/070872 WO2020025128A1 (en) 2018-08-01 2018-08-01 Certificate management

Publications (1)

Publication Number Publication Date
WO2020025128A1 true WO2020025128A1 (en) 2020-02-06

Family

ID=63103949

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2018/070872 WO2020025128A1 (en) 2018-08-01 2018-08-01 Certificate management

Country Status (1)

Country Link
WO (1) WO2020025128A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112187455A (en) * 2020-09-24 2021-01-05 西南交通大学 Method for constructing distributed public key infrastructure based on editable block chain
WO2021172684A1 (en) * 2020-02-28 2021-09-02 엘지전자 주식회사 Method and apparatus for transport layer security
CN113794556A (en) * 2021-09-10 2021-12-14 福建师范大学 PCH revocable method and system oriented to programmable block chain protocol
CN114500051A (en) * 2022-01-26 2022-05-13 中国科学院信息工程研究所 Block chain-based certificate management method and system
CN114650535A (en) * 2022-03-02 2022-06-21 广州爱浦路网络技术有限公司 SEEP mutual trust connection method, system, device and medium in 5G core network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180006826A1 (en) * 2016-07-01 2018-01-04 Intel Corporation Public key infrastructure using blockchains
US20180083771A1 (en) * 2016-09-20 2018-03-22 United States Postal Service Methods and systems for a digital trust architecture
US20180183587A1 (en) * 2016-12-23 2018-06-28 Vmware, Inc. Blockchain-Assisted Public Key Infrastructure for Internet of Things Applications

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180006826A1 (en) * 2016-07-01 2018-01-04 Intel Corporation Public key infrastructure using blockchains
US20180083771A1 (en) * 2016-09-20 2018-03-22 United States Postal Service Methods and systems for a digital trust architecture
US20180183587A1 (en) * 2016-12-23 2018-06-28 Vmware, Inc. Blockchain-Assisted Public Key Infrastructure for Internet of Things Applications

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
FUW-YI YANG: "Efficient Trapdoor Hash Functions for Digital Signatures", CHAOYANG UNIVERSITY OF TECHNOLOGY
GIUSEPPE ATENIESE ET AL: "Redactable Blockchain -- or -- Rewriting History in Bitcoin and Friends", INTERNATIONAL ASSOCIATION FOR CRYPTOLOGIC RESEARCH,, vol. 20170214:204959, 14 February 2017 (2017-02-14), pages 1 - 38, XP061022632, DOI: 10.1109/EUROSP.2017.37 *
SANTOSH CHANDRASEKHAR; MUKESH SINGHAL: "Multi-trapdoor hash functions and their applications in network security", IEEE CONFERENCE ON COMMUNICATIONS AND NETWORK SECURITY, 2014
SPENCE GARY: "Keynote speech 4: Blockchain based systems and edge computing working together as a decentralized public ledger", 2018 THIRD INTERNATIONAL CONFERENCE ON FOG AND MOBILE EDGE COMPUTING (FMEC), IEEE, 23 April 2018 (2018-04-23), pages 4, XP033351549, DOI: 10.1109/FMEC.2018.8364036 *
WHITE PAPER: "Constellation", 25 November 2017 (2017-11-25), XP055577782, Retrieved from the Internet <URL:https://icorating.com/upload/whitepaper/sn95tif0D2rudUCILOvQnNQlryUC4ehgd7fOtOeb.pdf> [retrieved on 20190404] *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021172684A1 (en) * 2020-02-28 2021-09-02 엘지전자 주식회사 Method and apparatus for transport layer security
CN112187455A (en) * 2020-09-24 2021-01-05 西南交通大学 Method for constructing distributed public key infrastructure based on editable block chain
CN112187455B (en) * 2020-09-24 2023-04-18 西南交通大学 Method for constructing distributed public key infrastructure based on editable block chain
CN113794556A (en) * 2021-09-10 2021-12-14 福建师范大学 PCH revocable method and system oriented to programmable block chain protocol
CN113794556B (en) * 2021-09-10 2023-05-23 福建师范大学 PCH revocable method and system for collectable blockchain protocol
CN114500051A (en) * 2022-01-26 2022-05-13 中国科学院信息工程研究所 Block chain-based certificate management method and system
CN114500051B (en) * 2022-01-26 2022-10-11 中国科学院信息工程研究所 Block chain-based certificate management method and system
CN114650535A (en) * 2022-03-02 2022-06-21 广州爱浦路网络技术有限公司 SEEP mutual trust connection method, system, device and medium in 5G core network

Similar Documents

Publication Publication Date Title
KR102001753B1 (en) End-to-end authentication at the service layer using public keying mechanisms
EP4002760A1 (en) Security procedure
WO2020025128A1 (en) Certificate management
US20210377054A1 (en) Systems and methods for managing public key infrastructure certificates for components of a network
CN113596828A (en) End-to-end service layer authentication
US20210120416A1 (en) Secure inter-mobile network communication
Xu et al. BE-RAN: Blockchain-enabled open RAN with decentralized identity management and privacy-preserving communication
US11425636B1 (en) Network function service subscription control
CN114503644B (en) Supporting indirect communication with TLS
US11855977B2 (en) Systems and methods for configuring a network function proxy for secure communication
EP4017052A1 (en) Authorization of network request
CN110808830A (en) IoT (Internet of things) security verification framework based on 5G network slice and service method thereof
WO2015183583A1 (en) App distribution over the air
US11038869B1 (en) Methods for managing a federated identity environment based on application availability and devices thereof
Abdel-Malek et al. A proxy signature-based drone authentication in 5G D2D networks
US11122083B1 (en) Methods for managing network connections based on DNS data and network policies and devices thereof
Haddad et al. Secure and efficient AKA scheme and uniform handover protocol for 5G network using blockchain
WO2021165925A1 (en) Key management
US10601872B1 (en) Methods for enhancing enforcement of compliance policies based on security violations and devices thereof
WO2021165194A1 (en) Key management
Seedorf et al. Decentralised binding of self-certifying names to real-world identities for assessment of third-party messages in fragmented mobile networks
US11231920B2 (en) Electronic device management
US11870767B1 (en) Methods for providing adaptive authentication for federated environment and devices thereof
WO2015096906A1 (en) Method and system for assessing a message in a decentralized communication network
US20230030315A1 (en) Network Security

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: 18749785

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: 18749785

Country of ref document: EP

Kind code of ref document: A1