WO2025009998A1

WO2025009998A1 - Method and nodes for decrypting/encrypting communication

Info

Publication number: WO2025009998A1
Application number: PCT/SE2023/050846
Authority: WO
Inventors: Gonzalo HERNANDEZ HARO; Miguel Angel MUÑOZ DE LA TORRE ALONSO
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-07-05
Filing date: 2023-08-21
Publication date: 2025-01-09
Anticipated expiration: 2026-01-05

Abstract

A method performed by a core network node (102) in a telecommunication network (001) for decrypting and encrypting communication between a UE (101) and a destination node (105) is disclosed. The method comprises receiving a private key of the destination node; decrypting using the private key a first message. The first message is encrypted using a public key of the destination node; generating a first symmetric key to secure a first connection using information decrypted from the first message; generating a second symmetric key to secure a second connection; encrypting a second message using the public key. The second message comprises information for generating the second symmetric key; transmitting the encrypted second message to the destination node; and communicating application data traffic between the UE and the destination node using the first connection secured with the first symmetric key and the second connection secured with the second symmetric key.

Description

METHOD AND NODES FOR DECRYPTING/ENCRYPTING COMMUNICATION

TECHNICAL FIELD

[0001] The present disclosure relates to decrypting and encrypting communication between a user equipment and a destination node.

BACKGROUND ART

[0002] One of the most extensive methods to authenticate (also referred to as prove the identity of, verify the identity of) peers (e.g., a client and a server) that need to communicate is by using digital certificates issued by a trusted source (sometimes referred to as a certification authority or CA). A digital certificate includes the public key of a public-private key pair. A public-private key pair may also be used to encrypt traffic. In addition, the ability of public-private key pairs to authenticate and encrypt may be used to establish other encrypted communication, such as the transport layer security (TLS) protocol.

SUMMARY

[0003] According to a first aspect, there is provided a method performed by a core network node in a telecommunication network for decrypting and encrypting communication between a user equipment, UE, and a destination node. The method comprises receiving a private key of the destination node. The method comprises decrypting using the private key, a first message, transmitted by the UE, wherein the first message is encrypted using a public key of the destination node. The method comprises generating a first symmetric key to secure a first connection between the UE and the core network node using information decrypted from the first message. The method comprises generating a second symmetric key to secure a second connection between the core network node and the destination node. The method comprises encrypting a second message using the public key of the destination node, wherein the second message comprises information for generating the second symmetric key. The method comprises transmitting the encrypted second message to the destination node and communicating application data traffic between the UE and the destination node using the first connection secured with the first symmetric key and the second connection secured with the second symmetric key.

[0004] According to a second aspect, there is provided a method performed by a destination node, for decrypting and encrypting communication between a user equipment and the destination node via a core network node in a telecommunication network. The method comprises sending, to the core network node, a private key of the destination node. The method comprises receiving, from the core network node, an encrypted message comprising information for generating a symmetric key to secure a connection between the core network node and the destination node, wherein the encrypted message was encrypted by the core network node using the public key of the destination node. The method comprises decrypting the encrypted message using the private key of the destination node. The method comprises generating the symmetric key based on the information. The method comprises communicating application data traffic between the UE and the destination node using the connection secured with the symmetric key.

[0005] According to a third aspect, there is provided a core network node in a telecommunication network for decrypting and encrypting communication between a user equipment, UE, and a destination node, the core network node comprising a memory and processing circuitry, the memory comprising instructions which when executed on the processing circuitry, cause the core network node to: receive a private key of the destination node; decrypt using the private key, a first message, transmitted by the UE, wherein the first message is encrypted using a public key of the destination node; generate a first symmetric key to secure a first connection between the UE and the core network node using information decrypted from the first message; generate a second symmetric key to secure a second connection between the core network node and the destination node; encrypt a second message using the public key of the destination node, wherein the second message comprises information for generating the second symmetric key; transmit the encrypted second message to the destination node; and communicate application data traffic between the UE and the destination node using the first connection secured with the first symmetric key and the second connection secured with the second symmetric key.

[0006] According to a fourth aspect, there is provided a destination node, for decrypting and encrypting communication between a user equipment and the destination node via a core network node in a telecommunication network, the destination node comprising a memory and processing circuitry, the memory comprising instructions which when executed on the processing circuitry, cause the destination node to: send, to the core network node, a private key of the destination node; receive, from the core network node, an encrypted message comprising information for generating a symmetric key to secure a connection between the core network node and the destination node, wherein the encrypted message was encrypted by the core network node using the public key of the destination node; decrypt the encrypted message using the private key of the destination node; generate the symmetric key based on the information; and communicate application data traffic between the UE and the destination node using the connection secured with the symmetric key.

[0007] According to a fifth aspect, there is provided a computer program comprising instructions which, when executed on a core network node cause the core network node to carry out a method according to the first aspect. [0008] According to a sixth aspect, there is provided a computer program product comprising a computer readable storage means on which the computer program according to the fifth aspect is stored.

[0009] According to a seventh aspect, there is provided a computer program comprising instructions which, when executed on a destination node, cause the destination node to carry out a method according to the second aspect.

[0010] According to an eight aspect, there is provided a computer program product comprising a computer readable storage means on which the computer program according to the seventh aspect is stored.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a data flow diagram illustrating an exemplary system for encrypting and decrypting communication between a user equipment and a destination node via a core network node according to one or more embodiments.

[0012] Figure 2 is a flow diagram illustrating a method performed by a core network node with some optional steps according to one or more embodiments.

[0013] Figure 3 is a flow diagram illustrating a method performed by a destination node with some optional steps according to one or more embodiments.

[0014] Figure 4 is a signaling diagram illustrating message exchanges between the different devices of the system according to one or more embodiments.

[0015] Figure 5 is a signaling diagram illustrating message exchanges between a user equipment and a core network node according to a transport layer security protocol according to one or more embodiments.

[0016] Figure 6 illustrates a fifth generation system service based architecture according to one or more embodiments.

[0017] Figure 7 illustrates a communication system according to one or more embodiments.

[0018] Figure 8 is a block diagram illustrating a blockchain according to one or more embodiments.

[0019] Figure 9 depicts a core network node according to one or more embodiments.

[0020] Figure 10 depicts a destination node according to one or more embodiments.

[0021] Figure 11 is a block diagram illustrating execution of methods and/or nodes in a virtualized environment according to one or more embodiments. DETAILED DESCRIPTION

[0022] The following detailed description is directed to certain specific embodiments of the invention. However, the invention can be embodied in a multitude of different ways as defined and covered by the claims. In this description, reference is made to the drawings wherein like parts are designated with like numerals throughout.

[0023] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0024] In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other.

[0025] Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dotdash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments of the invention. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments of the invention.

[0026] Peers (e.g., a client and a server) may be communicatively coupled over a telecommunication network (also referred to as a mobile network) operated by a mobile network operator (MNO). From the MNO’s perspective: 1) the peers may be user equipment (UE) and a destination node; 2) the telecommunication network may include an access network and a core network; 3) the core network (e.g Fifth Generation(5G) core or Sixth Generation (6G) core) may comprise one or more nodes (referred to as core network nodes); 4) an entity trusted by the MNO (referred to as a trusted network service provider) may provide services to the MNO using electronic devices operated and/or controlled by the trusted network service provider; and 5) the destination node and the trusted network service provider’s electronic devices may be outside of the core network (described in more detail later herein). In the context of UEs and destination nodes/servers communicatively coupled over a telecommunication network, there is presented techniques for decrypting and encrypting communication between the UEs and destination nodes/servers within the telecommunication network. At least some embodiments include a core network node that may decrypt and encrypt communication between the UE and the destination node. This is, for example, achieved by sending a private key of the destination node to the core network node.

[0027] The ability to decrypt and encrypt communication between UEs and destination nodes within the mobile network allows MNO’s to overcome problems presented by the use of end to end encryption between the UEs and the destination nodes. For example, this may allow MNOs to ensure authentication of the communicating peers, ensure security between the communication of a user equipment (UE) and an MNO entity (e.g., MNO DNS Server, HTTP server, etc.) or a trusted network service provider (e.g., Cloudflare)), perform deep packet inspection, classify traffic between a UE and a server, policy routing based on traffic classification, perform charging or accounting based on the type and/or amount of data traffic, and/or perform redirection. Since MNO entities and trusted network service providers are deployed outside of a core network, e.g Fifth Generation(5G) core or Sixth Generation (6G) core, it becomes further challenging for the MNOs to perform functions related to traffic characterization.

[0028] Additionally, for example, 5G core network functions (NFs) do not have access to certification authorities (CA) of the MNO network and thus, currently cannot receive a certificate to decrypt the communication between a UE and a server. In addition, embodiments enable a core network node that performs a core network function to communicate with certification authorities (CA) of the MNO network to receive digital certificates.

[0029] At least some embodiments propose to use a blockchain such as a private permissioned blockchain network, to distribute a private key of the destination node and/or digital certificate, information for all the permissioned users of the blockchain network. The permissioned users may include at least a destination node and a core network node. The permissioned users may further include a CA node. Such solutions may provide for a decentralized, transparent, trustworthy, and/or immutable management and distribution of the digital certificate information and/or a private key.

[0030] At least some embodiments include mechanisms to manage and/or distribute a private key and/or digital certificates between the 5G core NF (e.g. user plane function (UPF)) and an MNO or any external trusted network provider (e.g. Cloudflare).

[0031] At least some of the solutions presented herein allow delivery (and/or management) of certificates from an external trusted entity to the 5GNFs. At least some of the solutions presented herein reduce signaling to deliver the certificates by using a blockchain network; and allow access to security information, e.g. private key, shared from any permissioned user of the blockchain. [0032] At least some of the solutions presented herein enable a core network node to use a digital certificate to verify the identity of the core network node during an authentication request to establish a secure connection, and allow the core network node to decrypt the encrypted traffic to classify and apply policy rules. Further, at least some of the solutions ensure end-to-end security and authentication by allowing the core network node to encrypt the traffic after the traffic classification and send the encrypted traffic to a destination node.

[0033] At least some of the embodiments presented herein advantageously enable the core network node to classify data traffic between the UE and the destination node, by performing, for example, the decryption of data traffic using the private key.

[0034] Figure 1 is a data flow diagram illustrating an exemplary system for encrypting and decrypting communication between a user equipment and a destination node via a core network node according to one or more embodiments. Figure 1 illustrates a UE 101, a certification authority node 104, a destination node 105, a core network node 102 and optionally, a blockchain network 003 including blockchain nodes 103a, 103b. A telecommunication network 001 includes the core network node 102 while a different communication network 002 comprises the destination node 105. The core network node 102 and the destination node 105 may be located or operating in two different or separate communication networks. The communication network 002 may be controlled or operated by an MNO. The blockchain node 103a may be part of the communication network 002, while the blockchain node 103b may be part of the telecommunication network 001. The blockchain nodes 103a, 103b, may, herein, be collectively referred as blockchain node(s) 103.

[0035] The UE 101 and the destination node 105 may want to establish a secure communication with each other, or have an ongoing secure communication. A typical mechanism of securing communication between a client and a server is by using asymmetric key encryption/ decry ption using a public key and a private key. Asymmetric key encryption/decryption is based on publicprivate key encryption techniques using two different keys to encrypt and decrypt the message. As a simple example, consider a client that wants to securely communicate with a server. The client obtains, from a certification authority, a public key of the server. The clients encrypts a message using the obtained public key of the server and sends the encrypted message to the server. The server has a private key corresponding to the public key. The private key and public key have a mathematical relationship such that a message encrypted using the public key may only be decrypted by a corresponding private key. Thus, using the server’s private key, the server is able to decrypt the encrypted message received from the client. More details on the asymmetric key encryption/decryption according to one or more embodiments will be provided later in relation to Figure 5. The UE 101 and the destination node 105 may, for example, employ transport layer security (TLS) protocol to securely communicate with each other. The UE 101 and the destination node 105 may thus communicate over a TLS connection, in one or more embodiments. As used herein, a TLS connection may refer to a connection, between two entities, that is using the TLS protocol.

[0036] An MNO may want to perform certain functions, like traffic classification, on the data traffic that is exchanged between the UE 101 and the destination node 105. Since, the UE 101 and the destination node 105 exchange information via the core network node 102, one or more methods described herein may be implemented in the core network node 102 to achieve one or more objectives of the MNO. The core network node 102 behaves as a proxy for the secure data traffic communication between the UE 101 and the destination node 105. To introduce the functionalities of decryption and encryption of the data traffic, the core network node 102 may be provided with access to the public and/or private keys of the destination node 105.

[0037] As indicated by arrow A in Figure 1, the UE 101 obtains, from a CA node 104, a public key of the CA node 104 KPubcA. While in some embodiments the UE 101 may send, to the CA node 104, a request message requesting for the KPubcA and may further receive a response message comprising the KPubcA., the UE 101 may get the CA’s public key in an alternative or alternative way (e.g., it may be preinstalled on the UE 101). The UE 101 may use the KPubcA to validate the validity of a digital certificate of a node, e.g. the destination node 105. The UE 101 may use the KPubcA, that is derived from a master digital certificate of the CA node 104, to validate the digital signature of the CA node 104 on the digital certificate of the destination node 105. If the information in the digital certificate of the destination node 105 has changed (or if the digital certificate has been revoked) since the time the digital certificate of the destination node 105 was last signed by the CA node 104, or if the public key of the CA node 104 does not correspond to the private key used by the CA node 104 to sign the digital certificate of the destination node 105, the UE 101 may not authenticate the destination node’s identity. If the digital signature of the CA node 104 can be validated, then the digital certificate of the destination node 105 is considered as valid.

[0038] The CA node 104 sends, to the destination node 105, a signed version of the public key of the destination node 105, as indicated by arrow B. The public key of the destination node 105 may be signed using the private key of the CA node 104. The public key of the destination node 105 is herein denoted by KPuboN and its signed version is herein denoted by S(KPuboN). The S(KPuboN) may be used by the destination node 105 for validating the authenticity of the destination node 105 towards a client, for e.g. the UE 101 or the core network node 102.

[0039] The destination node 105 receives the S(KPuboN) from the CA node 104. The destination node 105 includes a private key of the destination node 105 KPrivDN. The KPrivDN and the KPuboN form an asymmetric cryptographic key pair. That is, a message encrypted by using the KPuboN may be decrypted using the KPrivDN. The KPrivDN is typically private to the destination node 105. However, to implement functionalities like traffic classification in the core network node 102, the core network node 102 may need to decrypt the encrypted data traffic sent from the UE 101 to the destination node 105. Thus, to achieve this, the destination node 105 sends, to the core network node 102, the private key of the destination node 105 KPrivDN. The destination node 105 may further send, to the core network node 102, the signed version of the public key of the destination node 105 S(KPuboN). These are indicated by arrow C in Figure 1. This advantageously enables a core network node 102 to authenticate, towards a UE 101, on behalf of an MNO entity located and/or operating in a different communication network, such as the communication network 002. Further, using the private key KPrivDN and the public key KPuboN of the destination node 105, the core network node 102 may advantageously decrypt the data traffic (encrypted with KPuboN) between the UE 101 and the destination node 105, perform traffic classification, and encrypt the data traffic. An advantageous mechanism enabling the sharing of the KPrivDN and the S(KPuboN) from an external MNO network (e.g. communication network 002) to a telecommunication network (or a core network) is, thus, presented.

[0040] In some embodiments, the destination node 105 may send the private key KPrivDN and the public key KPuboN of the destination node 105 via a blockchain network 003 or via blockchain nodes 103 part of the blockchain network 003, as indicated by arrows Cl and C2 of Figure 1. The blockchain network 003 is an incorruptible digital ledger of transaction that may be used to record virtually any digital asset (e.g. the private key and the public keys of the destination node 105) in a distributed way. Each action is recorded to the blockchain network 003 and the data of the records are available to every participant of the blockchain network 003 and may not be changed or deleted. Some advantages of using the blockchain network 003 include, but are not limited to, decentralization, transparency, trustworthiness, and immutability. The blockchain network 003 typically consists of linear sequence blocks, which are added to the blockchain. Each block typically contains a cryptographic hash of the previous block. All the hash information is generated automatically. Each successive block performs the verification of the previous block and secures the blockchain network 003. A higher number of blocks in the blockchain may result in a safer and more reliable system. At least some embodiments employ a permissioned blockchain, in which there may be users who are eligible to record transactions (e.g. related to certificate management) and some users who are eligible to read the recorded transactions.

[0041] The blockchain network 003 may also include smart contracts, or oracles for hybrid smart contracts. A smart contract is a software script which is stored in the blockchain network 003. A smart contract includes a unique address, a set of executable functions and state variables. A smart contract may be launched by addressing a transaction to it. After that, the smart contract is automatically and independently performed in an established order on each node of the blockchain network 003 based on the data contained in the transaction.

[0042] The core network node 102 may receive the KPrivDN and the S(KPuboN) from the destination node 105, either directly from the destination node 105 or via the blockchain network 003. The UE 101 and the destination node 105 may wish to use asymmetric key authentication and encryption to establish a TLS session, and then use that TLS session to encrypt communication between them. However, since the encrypted data passes through the core network node 102, the core network node 102 will need to be able to decrypt and encrypt the traffic. In an effort to establish a TLS session with the destination node 105, the UE 101 may send a first message as part of establishing the TLS connection as indicated by arrow DI of Figure 1. The first message may be encrypted using the public key of the destination node 105. Establishing a TLS connection may include performing a number of sub-steps as will be later explained in relation to Figure 5. It will be appreciated that although the establishment of the TLS connection has been illustrated as being initiated by the UE 101, the TLS connection establishment may instead be initiated by the core network node 102.

[0043] Since the core network node 102 includes the private key of the destination node 105, the core network node 102 may decrypt the encrypted message using the private key of the destination node 105, as indicated by block 112 of Figure 1. Upon decryption, the core network node 102 may obtain a random seed for generating a shared secret key. The core network node 102 and UE 101 may generate the shared secret key and use the shared secret key to encrypt/ decry pt any further communication between them, as part of or after establishing the TLS connection. Thus, the UE 101 may establish the TLS connection with the core network node 102 according to the above procedures and then send encrypted application data (wherein the application data is encrypted using the shared secret key) intended for the destination node 105. The core network node 102, based on obtaining the shared secret key according to the procedures above, may decrypt the application data. Thus, the UE 101 and the core network node 102 may send/receive encrypted application data over the TLS connection, as indicated by arrow E of Figure 1.

[0044] The core network node 102 may further analyze the decrypted application data using the data traffic analyzer 114. The data traffic analyzer 114 may perform functions such as data traffic classification, data traffic redirection, and policy routing.

[0045] The core network node 102 may send, to the destination node 105, the encrypted application data sent by the UE 101. The core network node 102 and the destination node 105 may establish a secure connection for communicating the encrypted application data. Similar to the TLS connection between the UE and the core network node 102, the core network node 102 and the destination node 105 may, for example, establish a secure connection using the TLS protocol. The core network node 102 may send, to the destination node 105, a first message as part of establishing the TLS connection as indicated by arrow D2 of Figure 1. The first message may be encrypted using the public key of the destination node 105. Establishing a TLS connection may include performing a number of sub-steps similar to those explained in relation to Figure 5. [0046] The destination node 105, may decrypt the encrypted message using the private key of the destination node 105. Upon decryption, the destination node 105 may obtain a random seed for generating a shared secret key. The core network node 102 and the destination node 105 may generate the shared secret key and use the shared secret key to encrypt/decrypt any further communication between them, as part of or after establishing the TLS connection. The core network node 102, responsive to receiving encrypted application data from the UE 101, may decrypt that application data, and then encrypt and send that application data to the destination node 105. The application data may be encrypted using the shared secret key between the core network node 102 and the destination node 105. The destination node 105, based on obtaining the shared secret key according to the procedures above, may decrypt the application data. Thus, the core network node 102 and the destination node 105 may send/receive encrypted application data over the TLS connection, as indicated by arrow F of Figure 1.

[0047] In at least some embodiments, encrypted application data traffic may be exchanged between the UE 101 and the destination node 105 (belonging to an external communication network) via the core network node 102, over two TLS connections. Further, the core network node 102 is configured to perform the following operations: i) decrypt the encrypted application data received from the UE 101, ii) analyze the decrypted application data, ii) encrypt the application data, and iv) send the encrypted application data to the destination node 105. Further, the core network node 102 is configured to receive, from an external communication network (e.g. operated by an MNO or trusted entity), the private key of the destination node 105 and the signed public key of the destination node 105, which enables the core network node 102 to perform one or more operations described previously.

[0048] Figure 2 illustrates a method 200 performed by a core network node 102 in a telecommunication network 001 for decrypting and encrypting communication between the UE 101 and the destination node 105. The method 200 comprises a number of steps some of which are optional.

[0049] The method comprises receiving 201, at the core network node 102, a private key of the destination node 105. The core network node 102 may, for example, be a network function (NF) in the Fifth Generation(5G) or Sixth Generation(6G) core network. Such NFs may include, but are not limited to, any one of: a user plane function (UPF), an access and mobility function (AMF), a network exposure function (NEF), and an application function (AF). In some embodiments, the core network node 102 may be part of the blockchain network 003. In further embodiments, the core network node 102 may itself be a blockchain node 103 which includes blockchain related functionalities, for example, functionalities relating to reading and writing of blockchain records. The destination node 105 may, for example, be an application server located in an MNO’s communication network such as the communication network 002. As another example, the destination node 105 may belong to a trusted entity.

[0050] The private key of the destination node 105 may, for example, be a key belonging to a asymmetric cryptography key -pair. In some embodiments, the private key 105 is the KPrivDN described above in relation to Figure 1.

[0051] In some optional embodiments, step 201 comprises receiving 202 a digital certificate of the destination node 105 wherein the digital certificate of the destination node 105 comprises the public key of the destination node 105. The digital certificate may be received from a certification authority (CA) node 104 or the destination node 105, for example, via the blockchain network 103. The digital certificate is signed by the certification authority node 104. The digital certificate is a unique, digitally signed document which authoritatively identifies the identity of an individual or organization. The authenticity of the digital certificate may be verified to ensure, for example, that a software or a website that a user is using is legitimate. The certificate is signed and verified by a trusted source such as the CA node 104. The digital certificate of the destination node 105 comprises the public key of the destination node 105. The public key of the destination node 105 may, for example, be the KPuboN described above in relation to Figure 1. The signed version of the public key may, for example, be the S(KPuboN) described above in relation to Figure 1.

[0052] In some optional embodiments, step 201 comprises registering 203 the core network node 102 in a blockchain network 003. . The step of registering 203 may be performed as a preliminary part of step 201 to receive the private key of the destination node 105 via the blockchain network 003. The core network node 102 may register in the blockchain network 003 to be granted permission for accessing data, e.g. the public key and the private key of the destination node 105, shared by other participants of the blockchain network 003. The core network node 102 may need to be authorized and/or authenticated prior to registration in the blockchain network 103. Once authorized and/or authenticated, the core network node 102 may read/receive event logs, blockchain transactions, or blockchain events. In some further optional embodiments, step 201 comprises receiving 204 the private key and/or the digital certificate of the destination node 105 via the blockchain network 003. The digital certificate of the destination node 105 comprises the public key of the destination node 105 and the digital certificate is signed by the CA node 104. The digital certificate may be the one as described above in relation to Step 202. In some further optional embodiments, step 204 comprises receiving 204a the private key and/or the digital certificate of the destination node 105 via the blockchain node 103 comprised in the blockchain network 003.

[0053] The use of blockchain network 003 for distributing and/or managing the public key and private key provide many different advantages. For example, signalling exchanges between the different nodes may be reduced. The destination node 105, by being part of the blockchain network 003, may directly interact with the core network node 102 and send, for example, the signed public key of the destination node 105 and/or other digital certificate information. Another advantage is enabling efficient management and distribution of digital certificates and asymmetric key pairs to core NFs from external trusted servers. The blockchain network 003 is capable of processing a large number of digital certificates from different MNO entities/trusted providers that need to be provided to each pod of each node of each core NF, thus enabling a scalable solution.

[0054] In some optional embodiments, the method 200 comprises executing 205 a smart contract on the blockchain network 003 for managing the private key and/or the digital certificate. This is performed by the blockchain network 003, and is shown as optional in Figure 2 because, in some embodiments, the core network node 102 is part of the blockchain network 003. For example, in some embodiments, the blockchain node 103b is included in the core network node 102, wherein the blockchain node 103b is part of the blockchain network 003 may execute the smart contract. The smart contract may be executed based on certain conditions/criteria of the smart contract being met. A trigger for initiating the execution of the smart contract may, for example, be a node, e.g. the CA node 104 or the destination node 105, writing to the blockchain network 003. Another trigger for initiating the smart contract may for example be the core network node 102 that is part of the blockchain network 003 receiving an instruction or information (e.g. an event identifier) from the destination node 105. The smart contract may, for example, be the smart contract described above in relation to Figure 1. The smart contract may, for example, be established between one or more of the following entities: the destination node 105 and the core network node 102. The smart contract comprises at least one or more of the following: an identifier of an event, an identifier of a certification authority node, the digital certificate of the destination node, the private key of the destination node 105, an indication of the time for which the digital certificate is valid and information on target.

[0055] In some embodiments, the identifier of the event indicates creating and storing a digital certificate, e.g. of the destination node 105 or the CA node 104, in the blockchain network 003. In such embodiments, the smart contract comprises the identifier of the CA node 104 that issued the digital certificate. The smart contract further comprises the digital certificate, and an indication of the time for which the digital certificate is valid. The smart contract still further comprises information on target. The information on target may include information related to any one of: a target node, a target communication network, and a target geographical region, for which the digital certificate is created. The information on target may include information on whether the digital certificate is to be used based on any one of: location, user identifier, application, source internet protocol (IP) address, destination IP address, source port, destination port, and protocol. The smart contract may further comprise the private key of the destination node 105.

[0056] In some embodiments, the identifier of the event indicates renewing an existing digital certificate, e.g. of the destination node 105 or the CA node 104, in the blockchain network 003. In such embodiments, the smart contract comprises the identifier of the CA node 104 that issued the renew event. The smart contract further comprises the digital certificate, and an indication of a new time for which the digital certificate is valid. The smart contract may further comprise the private key of the destination node 105.

[0057] In some embodiments, the identifier of the event indicates deleting an existing digital certificate, e.g. of the destination node 105 or the CA node 104, in the blockchain network 003. In such embodiments, the smart contract comprises the identifier of the CA node 104 that issued the digital certificate. The smart contract further comprises the digital certificate, and an indication of the time for which the digital certificate is valid. The smart contract may further comprise the private key of the destination node 105.

[0058] Moving on, as mentioned above in relation to arrow DI and/or arrow E of Figure 1, the UE 101 and the core network node 102 may want to establish a secure communication to exchange the encrypted application data between the UE 101 to the destination node 105. The UE 101 and the core network node 102 may establish a secure connection (herein referred to as a ‘first secure connection’), e.g. a TLS connection, for exchanging the application data. As part of this procedure, the UE 101 may send, to the core network node 102, a first message wherein the first message is encrypted. Thus, the method 200 further comprises decrypting 206 using the private key, a first message, transmitted by the UE. The first message is encrypted using the public key of the destination node 105. The private key that is used to decrypt the first message is the private key of the destination node 105. The private key of the destination node 105 may have been provided to the core network node 102 by the destination node 105, either directly or via the blockchain network 003, as explained above in relation to arrows C, Cl and C2 of Figure 1. Further, the first message may, for example, be sent by the UE 101 as part of establishing a TLS connection. The first message may, for example, be the message sent at Step 5 in Figure 5 as will be explained later. The first message may, for example, include a random seed for generating a shared secret key between the UE 101 and the core network node 102. The random seed is generated by the UE 101, and may, for example, be a number (or vector) used to initialize a pseudorandom number generator.

[0059] In some alternative embodiments, the first message includes parameters for determining the random seed, instead of including the random seed itself. The core network node 102 may first determine the random seed using the parameters, and then generate the first symmetric key. Such embodiments may, for example, employ Diffie-Hellman algorithms, for determining the random seed.

[0060] In some optional embodiments, the UE 101 may receive and verify the digital certificate of the destination node 105 prior to sending the first message to the core network node 102.

[0061] Upon decrypting the first message, the method 200 comprises generating 207 a first symmetric key to secure a first connection between the UE 101 and the core network node 102 using information decrypted from the first message. The first symmetric key may, for example, be the shared secret key between the UE 101 and the core network node 102 that is generated using the random seed. As explained above, the first message may include the random seed itself, or may include parameters for determining the random seed, and the first message is decrypted to obtain either of this information. The first connection may, for example, be the TLS connection between the UE 101 and the core network node 102. In some embodiments, the core network node 102 may generate the first symmetric key based on the Rivest-Shamir- Adi eman (RS A) algorithm. In some embodiments, the core network node 102 may generate the first symmetric key based on the Diffie-Hellman algorithm.

[0062] The core network node 102 may establish a secure communication with the destination node 105 to send the encrypted application data received from the UE 101. Thus, the core network node 102 and the destination node 105 may establish a secure connection, e.g. a TLS connection, for exchanging the encrypted application data. This secure connection may be a different connection than the one established between the UE 101 and the core network node 102 and is sometimes referred herein as a ‘second connection’. The method 200 comprises generating 208 a second symmetric key to secure the second connection between the core network node 102 and the destination node 105. The second symmetric key may, for example, be generated during or as part of the secure connection establishment. The second symmetric key may, for example, be the shared secret key that is generated between the core network node 102 and the destination node 105 using a random seed. The random seed may be generated by the core network node 102, and may, for example, be a number (or vector) used to initialize a pseudorandom number generator. In some embodiments, the core network node 102 may generate the second symmetric key based on the RSA algorithm. In some embodiments, the core network node 102 may generate the second symmetric key based on the Diffie-Hellman algorithm. [0063] The method 200 comprises encrypting 209 a second message using the public key of the destination node 105. The public key of the destination node 105 may, for example, be the KPuboN described above in relation to Figure 1. The second message comprises information for generating the second symmetric key. In one example, the information for generating the second symmetric key includes the random seed itself. In another example, the information for generating the second symmetric key includes parameters for determining the random seed. Further, the public key may have been provided to the core network node 102 by the destination node 105, either directly or via the blockchain network 003, as explained above in relation to arrows C, Cl and C2 of Figure 1. The public key of the destination node 105 may have been signed by the CA node 104.

[0064] The method 200 comprises transmitting 210 the encrypted second message to the destination node 105. This is, for example, described above in relation to arrow D2 of Figure 1. The encrypted second message may further be decrypted by the destination node 105 to obtain the information for generating the second symmetric key. The second symmetric key may then be used to establish the second secure connection between the core network node 102 and the destination node 105.

[0065] Once the first connection and the second connection have been securely established, the method 200 comprises communicating 211 the application data traffic between the UE 101 and the destination node 105 via the core network node 102. This is illustrated for example, by the arrows E and F of Figure 1. The core network node 102 communicates the application data traffic using the first connection secured with the first symmetric key and the second connection secured with the second symmetric key. In some embodiments, the core network node 102 uses two separate TLS connections to securely communicate application data traffic between the UE 101 and the destination node 105.

[0066] Optionally, step 211 comprises decrypting 212 the application data traffic using the first symmetric key and performing 213 on the application data traffic one or more of the following: data traffic classification, data traffic redirection, charging, and policy routing. These functions may, for example, be performed by the data traffic analyzer 114 as described above in relation to Figure 1. After decrypting and analysing the application data traffic, the core network node 102 may further need to send the application data traffic in encrypted form to the destination node 105. Optionally, step 211 comprises, encrypting 214 the application data traffic using the second symmetric key. This may be performed as part of or prior to communicating the application data traffic to the destination node 105.

[0067] Figure 3 illustrates a flow chart of a method 300 performed by a destination node 105 according to one or more embodiments. The method 300 will now be explained from the perspective of the destination node 105 and may include a number of steps some of which are optional.

[0068] The method 300 comprises sending 301, to the core network node 102, the private key of the destination node 105. The private key of the destination node 105 may, for example, be a key belonging to an asymmetric cryptography key-pair. The private key may, for example, be the KPrivDN described above in relation to Figure 1. In some embodiments, the private key of the destination node 105 is sent directly to the core network node 102 by the destination node 105, as described above in relation to arrow C of Figure 1. In some embodiments, the private key of the destination node 105 is sent to the core network node 102 via the blockchain network 003, as explained above in relation to arrows Cl and C2 of Figure 1. In some embodiments, the private key of the destination node 105 is sent to the core network node 102 via a core NF.

[0069] In some optional embodiments, the sending 301 comprises sending 302 the digital certificate of the destination node 105.. This is illustrated, for example, by arrow B of Figure 1. The digital certificate of the destination node 105 comprises the public key of the destination node 105. The public key of the destination node 105 may, for example, be the KPuboN described above in relation to Figure 1. The signed version of the public key may, for example, be the S(KPuboN) described above in relation to Figure 1.

[0070] In some optional embodiments, the sending 301 comprises registering 303 the destination node 105 and/or the CA node 104 in the blockchain network 003. The step registering 303 may be performed as a preliminary part of the step 301 to send the private key of the destination node 106 via the blockchain network 003. The destination node 105 may register in the blockchain network 003 to be granted permission for writing data, e.g. the public key and the private key of the destination node 105, to the blockchain network 003. The destination node 105 may need to be authorized and/or authenticated prior to registration in the blockchain network 103. Once authorized and/or authenticated, the destination node 105 may write or read/receive event logs, blockchain transactions, or blockchain events. In some embodiments, the CA node 104 may register to send the digital certificate to the core network node 102 and/or the destination node 105 via the blockchain network 103.

[0071] In some optional embodiments, the sending 301 comprises sending 304 the private key and the digital certificate of the destination node 105 via the blockchain network 003. The digital certificate of the destination node 105 comprises the public key of the destination node 105 and the digital certificate is signed by the CA node 104. The digital certificate may be the one as described above in relation to Step 302. In some further optional embodiments, the step 304 comprises sending 304a the private key and a digital certificate of the destination node 105 via the blockchain node 103 comprised in the blockchain network 003. [0072] The use of blockchain network 003 for distributing and/or managing public key and private key provide many different advantages. For example, signalling exchanges between the different nodes may be reduced. The destination node 105, by being part of the blockchain network 003, may directly interact with the core network node 102 and send, for example, the signed public key of the destination node 105 and/or other digital certificate information. Another advantage is enabling efficient management and distribution of digital certificates and asymmetric key pairs to core NFs from external trusted servers. The blockchain network 003 is capable of processing a large number of digital certificates from different MNO entities/trusted providers that need to be provided to each pod of each node of each core NF, thus enabling a scalable solution.

[0073] In some optional embodiments, the sending 304 comprises storing 304b the private key of the destination node 105 and the digital certificate in the blockchain network 003. The digital certificate may include the digital certificate of the destination node 105 and/or the digital certificate of the CA node 104. In some embodiments, the destination node 105 stores, on the blockchain network 003, the private key of the destination node 105 and the digital certificate of the destination node 105. The private key and the digital certificate may be stored, for example by the destination node 105, in the permissioned blockchain nodes 103 that are part of the blockchain network 003.

[0074] In some optional embodiments, the method 300 comprises sending 305 an instruction to execute a smart contract on the blockchain network 003 for managing the private key and/or the digital certificate. The instruction to execute may be sent to a blockchain node 103 part of the blockchain network 003. The instruction to execute may be a trigger to initiate the execution of the smart contract on the blockchain network 003. The trigger for initiating the smart contract may, for example, be a node, e.g. the destination node 105, writing to the blockchain network 003. The smart contract is self-executing based on certain conditions/criteria of the smart contract being met. The smart contract may, for example, be the smart contract described above in relation to Figure 1 and/or Figure 2.

[0075] The method 300 comprises receiving 306, from the core network node 102, an encrypted message. This is, for example, described above in relation to arrow D2 of Figure 1 and/or in relation to the step 210 of Figure 2. The encrypted message comprises information for generating a symmetric key to secure a connection between the core network node 102 and the destination node 105. In one example, the information for generating the second symmetric key includes the random seed itself. In another example, the information for generating the second symmetric key includes parameters for determining the random seed. The symmetric key may, for example, be the second symmetric key described above in relation to Figure 2. The connection between the core network node 102 and the destination node 105 may, for example, be the second connection described above in relation to Figure 2. Further, the encrypted message was encrypted by the core network node 102 using the public key of the destination node 105, as described above in relation to step 209 of Figure 2. The public key of the destination node 105 may, for example, be the KPuboN described above in relation to Figure 1. Further, the public key may have been provided to the core network node 102 by the destination node 105, either directly or via the blockchain network 003, as explained above in relation to arrows C, Cl and C2 of Figure 1. The public key of the destination node 105 may have been signed by the CA node 104. Alternatively, the public key of the destination node 105 may have been provided to the core network node 102 by the CA node 104, either directly or via the blockchain network 003.

[0076] The method 300 comprises decrypting 307 the encrypted message using the private key of the destination node 105. The public key with which the message was encrypted by the core network node 102 and the private key form an asymmetric cryptography key -pair, making it possible for the destination node 105 to decrypt the message.

[0077] Upon decryption, the core network node 102 obtains the information for generating the symmetric key to secure a connection between the core network node 102 and the destination node 105, as mentioned above. Thus, the method 300 comprises generating 308 the symmetric key based on the information. In some embodiments, the destination node 105 generates the symmetric key based on the RS A algorithm. In some embodiments, the destination node 105 generates the symmetric key based on the Diffie-Hellman algorithm. The symmetric key may then be used to establish the secure connection between the core network node 102 and the destination node 105. [0078] Once the secure connection between the core network node 102 and the destination node 105 has been established, the method 300 comprises communicating 309 the application data traffic between the UE 101 and the destination node 105 via the core network node 102. This is illustrated for example, by the arrow F of Figure 1. The core network node 102 communicates the application data traffic using the connection secured with second symmetric key. The connection may, for example, be a TLS connection.

[0079] Figure 4 illustrates a data flow diagram between different entities using the blockchain network according to some embodiments. Figure 4 illustrates the data flow based on the description provided above in relation to one or more of the Figures 1-3, and thus may be considered as an illustration of an example implementation of these figures. Figure 4 illustrates the UE 101, the core network node 102 exemplifed as the UPF 105, the blockchain node 103, the destination node 105 and the certification authority node 104. The vertical dotted line illustrates that the destination node 105 and the CA node 104 are in a different communication network external to the telecommunication network in which the core network node 102 and the UE 101 are located. The blockchain node 103 is part of the blockchain network 003 located as part of both the communication network 002 and the telecommunication network 001. Figure 4 is explained in further detail below:

[0080] 401: Deploy smart contract

The smart contract may be deployed on the blockchain node 103 that is part of the blockchain network 003. The smart contract may be executed according to one or more procedures described above in relation to Figure 2 and/or Figure 3.

[0081] 402: Register destination node 105 and/or the CA node 104

The destination node 105 registers the destination node 105 and/or the CA node 104 in the blockchain node 103, for example, according to step 303 of Figure 3.

[0082] 403: Register NF node

The core network node 102 registers itself in the blockchain node 103, for example, according to step 202 of Figure 2.

[0083] 404: Listening for events

The core network node 102 listens for any incoming events or transactions on the blockchain network. The events may for example be any one of: creating a digital certificate of the destination node 105, renewing the digital certificate, and deleting the digital certificate, as described above in relation to Figure 2. The destination node 105 may write data, e.g. the private key and/or the public key of the destination node 105, to the blockchain network 003 and this may be propagated to the core network node 102 via the blockchain network 102.

[0084] 131: Send CA certificate

The CA node 104 sends the digital certificate of the CA node 104 to the UE 101. The digital certificate of the CA node 104 includes the public key of the CA node 104. The digital certificate of the CA node 104 may be a master certificate that the UE 101 uses to validate, for example, the digital certificate of the destination node 105 received at the core network node 102, when the UE 101 communicates with the core network node 102. The digital certificate of the destination node 105 may have been created and signed by the CA node 104.

[0085] 405: Generate CSR

The destination node 105 generates a certificate signing request (CSR) for the digital certificate of the destination node 105. The CSR may, for example, include one or more of the following: public key of the destination node 105, information on the fully qualified domain name (FQDN) of the server, information of the legal entity owning the destination node 105, location information. The CSR is generated for the destination node 105 to obtain a signed version of the digital certificate of the destination node 105.

[0086] 132: Send CSR and signed certificate of the DN The destination node 105 sends the CSR to the CA node 104. The CA node 104 signs the CSR using the private key of the CA node 104. The signing of the CSR including the digital certificate of the destination node 105, by the CA node 104, authenticates the identity of the destination node 105. The CA node 104 may compute a hash of the CSR and encrypt the hash using the private key of the CA node 104, forming the digital signature for the digital certificate of the destination node 105. The signed digital certificate of the destination node 105 is then sent from the CA node 104 to the destination node 105.

[0087] 133 depicts the communication between the destination node 105 and the core network node 102. The communication may take place via the blockchain network.

[0088] 134: Send signed certificate and KPrivDN

The destination node 105 sends, to the blockchain node 103, the signed digital certificate of the destination node 105 and the private key of the destination node 105. The signed digital certificate may include the public key of the destination node 105. The destination node 105 may further send, to the blockchain node 103, one or more of the following information: the event ID, the ID of the CA node 104 and the expiration time as described above. In general, the reading and writing of data on the blockchain network may be performed through blockchain-specific libraries. For example, in the Ethereum blockchain, such libraries could be web3 or Metamask. Further, as an example, for Ethereum blockchain, the blockchain node 103 may send or receive application layer messages such as JavaScript Object Notation, JSON, over Hypertext Transfer Protocol, HTTP, POST. Further details on specific libraries may as such be consulted by someone skilled in the art, for example, to identify the relevant calls for interacting with the blockchain network 003.

[0089] 406: Execute smart contract

The smart contract executes in the blockchain network 003. The smart contract may execute based on receiving the message from the destination node 105 at step 134.

[0090] 407: Store signed certificate

The signed digital certificate of the destination node 105 including the public key of the destination node 105, and the private key of the destination node 105 may be stored, e.g. by the destination node 105, in the blockchain network 003 or the blockchain node 103. The stored public key and private key may be accessible to any permissioned participant on the blockchain network 003, e.g. the core network node 102.

[0091] 135: Signed certificate

The core network node 102 may listen for any blockchain related event. Once the smart contract has executed or an event has detected, the core network node 102 may receive the signed digital certificate including the public key of the destination node 105, and the private key of the destination node 105. These data may be used by the core network node 102 to authenticate itself towards the UE 101, and for establishing a secure connection with the UE 101, over which the encrypted application data traffic may be exchanged.

[0092] 136: TLS handshake

The UE 101 and the core network node 102 may establish a secure connection using the TLS protocol. This has been described above, for example, in relation to arrows DI and E of Figure 1. This will further be described in relation to Figure 5.

[0093] 138: Encrypted data traffic

Once the TLS connection has been established, the UE 101 sends, to the core network node 102, the encrypted application data traffic over the TLS connection.

[0094] 408: Decrypt data traffic

The core network node 102 decrypts the encrypted data traffic using the symmetric key generated as part of the TLS connection establishment. The core network node 102 may further perform functions such as data traffic classification, data traffic redirection, and policy routing, on the decrypted application data traffic [0095] 137: TLS handshake

The core network node 102 and the destination node 105 may establish a secure connection using the TLS protocol. This has been described above, for example, in relation to arrows D2 and F of Figure 1 and employs a similar procedure as will be described later in relation to Figure 5.

[0096] 139: Encrypted data traffic

The destination node 105 and the core network node 102 exchange encrypted application data traffic over the secure connection. For instance, the core network node 102 encrypts the decrypted application data traffic and sends the encrypted application data traffic to the destination node 105. The destination node 105 may further decrypt the encrypted application data traffic according to one or more procedures described above in relation to Figures 1-3 and take further actions. [0097] 409: Certificate expire

The signed digital certificate of the destination node 105, that the core network node 102 obtains via the blockchain network 003, may be associated with an expiration time. The signed digital certificate may, thus, expire after a certain time defined by the expiration time. Once, signed digital certificate expires, the core network node 102 may send a request to the destination node 105 via the blockchain network 003 requesting the renewal of the signed digital certificate. The destination node 105 may send the renew event ID, as described above in relation to Step 205 of Figure 2, renewing or updating the signed digital certificate. The renewed signed digital certificate may then be sent to core network node 102 to carry out the core network node 102 operations described herein. [0098] Figure 5 is a signaling diagram illustrating message exchanges between two nodes to establish a secure TLS connection according to the TLS protocol according to some embodiments. Although, the nodes are exemplified as UE 101 and the core network node 102, the procedure of Figure 5 is applicable to message exchanges between the core network node 102 and the destination node 105 according to the TLS protocol. Figure 5 may be considered as illustrating an example implementation of the methods described above in relation to Figures 1-4, for example, the methods related to establishing a secure connection between the UE 101 and the core network node 102, or between the core network node 102 and the destination node 105. Figure 5 is explained in further detail below:

[0099] Step 1 : The UE 101 sends an initial hello message to the core network node 102. The message may include one or more of the following information: the TLS protocol version, the UE 101 random string of bytes, and a list of cipher suites

[00100] Step 2 : The core network node 102 responds by sending a hello message to the UE 101. The hello message from the core network node 102 includes one or more of the following: the signed digital certificate of the destination node 105 including the public key of the destination node 105, the selected cipher suite and the core network node 102 random string of bytes.

[00101] Step 3 : The UE 101 verifies the signed digital certificate of the destination node 105 to confirm the authenticity. The UE 101 may verify the signature using information of the master certificate of the CA node 104 that was received, for example, at 131 of Figure 1.

[00102] Step 4 : The UE 101 generates a seed and encrypts the seed with the public key of the destination node 105. The public key may be the one received in Step 2 of Figure 5, or a previously stored one. The seed may be used to generate a shared secret key (also known as session key) between the UE 101 and the destination node 105. Thus, step 4 may also include the UE 101 generating the shared secret key for securely communicating application data traffic to the core network node 102.

[00103] Step 5 : The UE 101 send the encrypted seed to the core network node 102.

[00104] Step 6 : The UE 101 sends the digital certificate of the UE 101 to authenticate itself towards the core network node 102. It may be noted that this step may be combined with Step 5 of Figure 5, or may be executed prior to the Step 5.

[00105] Step 7: The core network node 102 verifies the digital certificate of the UE 101. This may be based on using the master certificate of the CA node 104.

[00106] Step 8: The core network node 102 decrypts the encrypted seed using the private key of the destination node 105. The private key of the destination node 105 may have been provided to the core network node 102 by the destination node 105, either directly or via the blockchain network 003. [00107] Step 9: The core network node 102 generates a shared secret key from the seed. The shared secret key is a session key used to encrypt or decrypt communication between the UE 101 and the core network node 102. The communication may include communication of application data traffic of the UE 101.

[00108] Step 10: The UE 101 sends a finished message that may be encrypted with the shared secret key. The finished message from the UE 101 may indicate that the UE has finished with its setting up of the TLS connection.

[00109] Step 11: The core network node 102 responds by sending a finished message that may be encrypted with the shared secret key. The finished message from the core network node 102 may indicate that the core network node 102 has finished with its setting up of the TLS connection. [00110] Step 12: The UE 101 and the application data 102 exchange encrypted application data traffic. The application data traffic may be encrypted using the shared secret key.

[00111] It will be appreciated the procedure described in Figure 5 is exemplary and may be subject to certain modifications to arrive at other embodiments. In some embodiments, the step 5 may include sending, as encrypted, one or more parameters for generating the seed, instead of sending the seed. In such embodiments, the core network node 102 may first compute the seed using the decrypted one or more parameters and then generate the shared secret key using the seed. In some embodiments, wherein the signed digital certificate of the destination node 105 has been previously stored in the UE 101, the UE 101 may generate and send the seed as encrypted already in Step 1 of Figure 5, thereby eliminating the steps 3 and 5 of Figure 5. This has an advantage of reduced signaling between UE 101 and the core network node 102.

[00112] Figure 6 illustrates a 5G system service-based architecture according to one or more embodiments. The telecommunication network 001 comprises the different 5G nodes. The Network Exposure Function (NEF) interacts with other 5G core network nodes such as Network Function Repository Function (NRF) via the Nnrf interface, Policy Control Function (PCF) via the Npcf interface, Application Function (AF) via the Naf interface, Network Slice Selection Function (NSSF) via the Nnssf interface, Access and Mobility Management Function (AMF) via the Namf interface and Session Management Function (SMF) via the Nsmf interface. The SMF is connected to a User Plane Function (UPF) via the N4 interface. The core network may further include other nodes not shown in Figure such as the Unified Data Management (UDM) connected via the Nudm interface, and the Authentication Server Function (AUSF) connected via the Nausf interface. The 5G core network nodes are further connected to the 5G Radio Access Network (RAN). For instance, the AMF 107 is connected to an Access Network (AN), here in the form of a 5G Radio AN, via the N2 interface. The UPF is further connected to the AN via the N3 interface and to a Data Network (DN) via the N6 interface. End-user devices, here illustrated as UE are connected to the 5G RAN and the AMF. The UPF 106 is an example of the core network node 102 described herein. The UPF 106 comprises the private key of the destination node 105 and the signed digital certificate including the public key of the destination node 105. The UPF 106 may communicate with the destination node 105 via the DN. The DN itself may be connected to an external communication network, e.g. the communication network 002, comprising the destination node 105, either directly or via the blockchain network 003.

[00113] Figure 7 shows an example of a communication system 700 in accordance with some embodiments. The core network node 102 is part of the core network 706 that ispart of the telecommunication network 001 as illustrated in Figure 7. The person of ordinary skill in the art will appreciate that the telecommunication network 001 may include numerous additional electronic devices, functions, and components that would be involved in the operation of the telecommunication network 001. The telecommunication network 001 can implement any communication technology such as 5G, 6G (e.g., as defined by 3GPP) technologies or similar technologies.

[00114] Each of the RAN base stations (e.g. network nodes 710A, 710B) operates to provide a respective one or more sector carriers corresponding to one or more spectrum bands. For example, assuming that telecommunication network 001 is a 5G network, the RAN base stations may be operated to provide sector carriers corresponding to one or more “low” bands (e.g., frequencies less than 1 gigahertz (GHz)), one or more “mid” bands (e.g., frequencies between 1-2.6 GHz and/or 3.5-6 GHz), and/or one or more “high” bands (frequencies between 24-40 GHz). The configuration of the RAN base stations (e.g., specifying the number and/or spectrum bands of the sector carriers) may be determined to provide a desired service availability and/or performance for the mobile device(s). The person of ordinary skill will understand the RAN base stations 205 may provide any other suitable numbers of sector carriers, which may correspond to any different spectrum bands.

[00115] In the example of Figure 7, the communication system 700 includes a telecommunication network 001 that includes an access network 704, such as a radio access network (RAN), and a core network 706, which includes one or more core network nodes 102. The core network node 102 may, for example, be a UPF 106. The access network 704 includes one or more access network nodes, such as network nodes 710A and 710B (one or more of which may be generally referred to as network nodes 710), or any other similar 3rd Generation Partnership Project (3 GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 001 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 001 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 001, including one or more network nodes 710 and/or core network node 102.

[00116] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU- CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes 710 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 101A, 101B, 101C, and 101D (one or more of which may be generally referred to as UEs 721) to the core network 706 over one or more wireless connections.

[00117] Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 700 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. The communication system 700 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

[00118] The UEs 721 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 710 and other communication devices. Similarly, the network nodes 710 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 721 and/or with other network nodes or equipment in the telecommunication network 001 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 001.

[00119] In the depicted example, the core network 706 connects the network nodes 710 to one or more hosts, such as host 716. The host 716 comprises the destination node 105. The host 716 together with the destination node 105 may be located in a different communication network 002. The connection to the host may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 706 includes one more core network nodes (e.g., core network node 102) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 102. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).

[00120] The host 716 may be under the ownership or control of a service provider other than an operator or provider of the access network 704 and/or the telecommunication network 001, and may be operated by the service provider or on behalf of the service provider. The host 716 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server. [00121] The destination node 105 may communicate with a certification authority (CA) node 104. The CA node 104 may be under the ownership or control of a service provider other than an operator or provider of the access network 704 and/or the telecommunication network 001, and may be operated by the service provider or on behalf of the service provider. The destination node 105 may communicate with the CA node 104 according to one or more procedures described above in relation to any of the Figures 1-5. The CA node 104 may further communicate with UE 721, 101 according to one or more procedures described above in relation any of the Figures 1-5. [00122] In some embodiments, the core network node 102, the destination node 105, the CA node 104 and the UE 721, 101, are connected to a blockchain network 003 (not shown in the Figure 7). Each of the nodes 102, 104, 105, 721 may themselves include the functionalities of blockchain, thus behaving as blockchain nodes 103. In some other embodiments, each of the nodes are connected to the blockchain network 003 via the blockchain nodes 103. In yet other embodiments, some nodes behave as blockchain nodes 103 while some nodes are connected to the blockchain nodes 103 via the blockchain network 003.

[00123] As a whole, the communication system 700 of Figure 7 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[00124] In some examples, the telecommunication network 001 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 001 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 001. For example, the telecommunications network 001 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)/Massive loT services to yet further UEs.

[00125] In some examples, the UEs 721, 101 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 704 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 704. Additionally, a UE may be configured for operating in single- or multi -RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[00126] In the example, the hub 714 communicates with the access network 704 to facilitate indirect communication between one or more UEs (e.g., UE 101C and/or 101D) and network nodes (e.g., network node 710B). In some examples, the hub 714 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 714 may be a broadband router enabling access to the core network 706 for the UEs. As another example, the hub 714 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 710, or by executable code, script, process, or other instructions in the hub 714. As another example, the hub 714 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 714 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 714 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 714 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 714 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[00127] The hub 714 may have a constant/persistent or intermittent connection to the network node 710B. The hub 714 may also allow for a different communication scheme and/or schedule between the hub 714 and UEs (e.g., UE 101C and/or 10 ID), and between the hub 714 and the core network 706. In other examples, the hub 714 is connected to the core network 706 and/or one or more UEs via a wired connection. Moreover, the hub 714 may be configured to connect to an M2M service provider over the access network 704 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 710 while still connected via the hub 714 via a wired or wireless connection. In some embodiments, the hub 714 may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 710B. In other embodiments, the hub 714 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 710B, but which is additionally capable of operating as a communication start and/or end point for certain data channels.

[00128] Figure 8 exemplarily illustrates a portion of a single blockchain network and the generic content of the blocks. As can be seen, each block includes the hash value of the previous block and, therefore, a chain dependency is established which protects against illegitimate modification of a message in a block, by requiring recalculation of any block generated after the modified block. Messages exchanged between the nodes of the blockchain network are stored in the blocks of the blockchain network, wherein each message may comprise user data and a digital signature, e.g., the encrypted hash value of the user data. For example, the private key KPrivDN 807 of the destination node 105 and the hash of the KPrivDN 807 may be stored on the blockchain network. Similarly, the signed public key KPuboN 808 of the destination node 105 and the hash 806 of the signed public key may be stored on the blockchain network. The message may, thus be defined as Msg=D+H(D), where Msg denotes the message, D stands for the data included in the message and H( ) corresponds to a hash function.

[00129] New blocks are created by a consensus procedure among the nodes of the blockchain network and, once created, new blocks are appended to the chain. A typical consensus procedure is the so called “proof-of-work” method which corresponds to the procedure of searching for a hash value with a specific requirement, i.e., searching for a specific hash value that is obtained after applying a hash function on the whole content of a block. The difficulty of computing this hash value is determined by the number of zero bits that must exist at the beginning of the hash value. This number of zero bits is also known as the “degree of difficulty”. By imposing a higher/lower number of zeros at the beginning of the hash value, the computational complexity can be in-creased/reduced. For computing the hash value, a so called “nonce” 804, i.e., a random value that forms part of a block, may be employed. The nonce 804 is modified randomly in the proof-of-work procedure to find the desired target hash value for the whole block. Different hash values may thus be obtained by modifying the nonce 804 and/or adding new incoming messages. Finding the solution in the proof-of-work procedure is generally associated with high computational effort. It is to be noted that the proof-of-work method is not the only available consensus procedure and that other consensus methods are generally known, including proof-of- stake, proof-of-capacity, proof-of-burn and proof-of-activity, for example.

[00130] In the blockchain network, nodes which are responsible for computing blocks, e.g., which participate in performing the proof-of-work, are called “miners”. To compute a new block, miners may collect all recent messages which are not yet included in the blockchain network and combine the hash values obtained from the messages with the hash value of the previous block, the timestamp 803 and the nonce 804. Next, a hash function may be applied on this combined data, which results in a hash value of the new block. Miners perform this computation repeatedly (by modifying the nonce and/or adding new incoming messages) until a solution to the proof-of- work is found. The first miner that finds a solution broadcasts the computed block to the other nodes in the network and, if the other nodes validate the block, the block is added to the chain.

[00131] When a new message including data, e.g. the private key and/or the signed public key described herein, is thus to be added to the blockchain network, the following steps are typically executed in the blockchain network: (1) the new message is broadcast from the originating node, e.g. the destination node 105, into the blockchain network and received by all nodes, (2) the message is validated by all the blockchain nodes 103 and every node broadcasts the result of the validation, i.e., indicating whether the message is considered valid or not, (3) if the message is accepted, i.e., the majority of the nodes determine the message as valid, the miners start the computation of the block (e.g., the proof-of-work computation) for the message, (4) the first miner that finds a solution (e.g., to the proof-of-work) broadcasts the computed block into the network, (5) the other nodes validate the solution and broadcast the validation result into the network, i.e., indicating whether the solution is accepted or rejected, and (6) if the solution is accepted, i.e., the majority of the nodes accept the solution, the block is added to the blockchain and the blockchain nodes 103 update their ledger accordingly.

[00132] Figure 9 shows a core network node 102 in accordance with some embodiments. The core network node 102 may comprise a memory 904 and processing circuitry 902. The memory 904 may comprise software instruction(s) which when executed by the processing circuitry cause the core network node 102 to perform one or more methods/steps described above in relation to any of: Figure 1, Figure 2, Figure 3, Figure 4, Figure 5, Figure 6, Figure 7 and Figure 8. The processing circuitry 902 may include one or more processors. As used herein, the core network node 102 refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE, e.g., the UE 101, and/or with other network nodes or equipment, in a telecommunication network.

[00133] The core network node 102 includes a processing circuitry 902, a memory 904, a communication interface 906, and a power source 908. The processing circuitry 902 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other core network node 102 components, such as the memory 904, to provide core network node 102 functionality. In some embodiments, the processing circuitry 902 includes a system on a chip (SOC).

[00134] The memory 904 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 902. The memory 904 may store any suitable instructions, data, or information, including a computer program 905, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry 902 and utilized by the core network node 102. The memory 904 may be used to store any calculations made by the processing circuitry 902 and/or any data received via the communication interface 906. In some embodiments, the processing circuitry 902 and memory 904 is integrated. The memory 904 may store data such as the private key and/or the public key of a node. The memory 904 may store signed digital certificates of a node.

[00135] The communication interface 906 is used in wired or wireless communication (for e.g. using antenna (not shown in Figure 9)) of signaling and/or data between an core network, access network, and/or UE. As illustrated, the communication interface 906 comprises port(s)/terminal(s) 916 to send and receive data, for example to and from a network over a wired connection. In other embodiments, the communication interface may comprise different components and/or different combinations of components.

[00136] The communication interface 906, and/or the processing circuitry 902 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the electronic device. Any information, data and/or signals may be received from a UE, another electronic device and/or any other network equipment. Similarly, the communication interface 906, and/or the processing circuitry 902 may be configured to perform any transmitting operations described herein as being performed by the electronic device. Any information, data and/or signals may be transmitted to a UE, another electronic device and/or any other network equipment.

[00137] The power source 908 provides power to the various components of core network node 102 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 908 may further comprise, or be coupled to, power management circuitry to supply the components of the core network node 102 with power for performing the functionality described herein. For example, the core network node 102 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 908. As a further example, the power source 908 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[00138] Embodiments of the core network node 102 may include additional components beyond those shown in Figure 9 for providing certain aspects of the core network node 102 functionality, including any of the functionality described herein, e.g. related to traffic analysis of application data, and/or any functionality necessary to support the subject matter described herein. For example, the core network node 102 may include user interface equipment to allow input of information into the core network node 102 and to allow output of information from the core network node 102. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the core network node 102.

[00139] Figure 10 is a block diagram of a destination node 105, which may be an embodiment of the host 716 of Figure 7, in accordance with various aspects described herein. As used herein, the destination node 105 may be or comprise various combinations hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The destination node 105 may provide one or more services to one or more UEs.

[00140] The destination node 105 includes processing circuitry 1002 that is operatively coupled via a bus 1004 to an input/output interface 1006, a network interface 1008, a power source 1010, and a memory 1012. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figure 9, such that the descriptions thereof are generally applicable to the corresponding components of destination node 105.

[00141] The memory 1012 may include one or more computer programs including one or more host application programs 1014 and data 1016, which may include user data, e.g., data generated by a UE 101 or a core network node 102 for the destination node 105; or data generated by the destination node 105, e.g. private key and/or signed digital certificate, for a UE 101 or a core network node 102. Embodiments of the destination node 105 may utilize only a subset or all of the components shown. The host application programs 1014 may be implemented in a containerbased architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 1014 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the destination node 105 may select and/or indicate a different host for over-the-top services for a UE. The host application programs 1014 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[00142] Figure 11 is a block diagram illustrating a virtualization environment 1100 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein such as the core network node 102 and/or the destination node 105, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1100 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1100 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[00143] Applications 1102 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1100 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

[00144] Hardware 1104 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1106 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1108a and 1108b (one or more of which may be generally referred to as VMs 1108), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 1106 may present a virtual operating platform that appears like networking hardware to the VMs 1108.

[00145] The VMs 1108 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1106. Different embodiments of the instance of a virtual appliance 1102 may be implemented on one or more of VMs 1108, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment. [00146] In the context of NFV, a VM 1108 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1108, and that part of hardware 1104 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1108 on top of the hardware 1104 and corresponds to the application 1102.

[00147] Hardware 1104 may be implemented in a standalone network node with generic or specific components. Hardware 1104 may implement some functions via virtualization. Alternatively, hardware 1104 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1110, which, among others, oversees lifecycle management of applications 1102. In some embodiments, hardware 1104 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1112 which may alternatively be used for communication between hardware nodes and radio units.

[00148] While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described, can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.

Claims

CLAIMS:

1. A method (200) performed by a core network node (102, 103, 106) in a telecommunication network (001) for decrypting and encrypting communication between a user equipment, UE, (101) and a destination node (105), the method comprising: receiving (201) a private key of the destination node; decrypting (206) using the private key, a first message, transmitted by the UE, wherein the first message is encrypted using a public key of the destination node; generating (207) a first symmetric key to secure a first connection between the UE and the core network node using information decrypted from the first message; generating (208) a second symmetric key to secure a second connection between the core network node and the destination node; encrypting (209) a second message using the public key of the destination node, wherein the second message comprises information for generating the second symmetric key;

- transmitting (210) the encrypted second message to the destination node; and communicating (211) application data traffic between the UE and the destination node using the first connection secured with the first symmetric key and the second connection secured with the second symmetric key.

2. The method according to claim 1, wherein the receiving comprises registering (203) the core network node in a blockchain network (003).

3. The method according to claim 2, wherein the receiving comprises receiving (204) the private key and a digital certificate of the destination node via the blockchain network (003), wherein the digital certificate of the destination node comprises the public key of the destination node and wherein the digital certificate is signed by the certification authority node (104).

4. The method according to claim 3, wherein the receiving comprises receiving (204a) the private key and the digital certificate of the destination node via a blockchain node (103) comprised in the blockchain network (003).

5. The method according to one or more claims 2-4, wherein a smart contract on the blockchain network (003) is executed for managing the private key and/or the digital certificate.

6. The method according to claim 5, wherein the smart contract comprises at least one or more of the following: an identifier of an event, an identifier of a certification authority node, the digital certificate of the destination node, the private key of the destination node, an indication of the time for which the digital certificate is valid and information on target.

7. The method according to one or more claims 2-6, wherein the digital certificate and the private key are stored in the blockchain network.

8. The method according to one or more claims 1-7, wherein the first connection is a first transport layer security, TLS, connection.

9. The method according to one or more claims 1-8, wherein the second connection is a second TLS connection.

10. The method according to one or more claims 1-9, wherein the core network node includes a user plane function, UPF, (106).

11. The method according to one or more claims 1-10, wherein the digital certificate is signed using a private key of a certification authority node.

12. The method according to one or more claims 1-11, wherein the first message is used to establish the first TLS connection and wherein the first message comprises a seed value for generating the first symmetric key.

13. The method according to claim 12, wherein the communicating (211) comprises decrypting (212) the application data traffic using the first symmetric key.

14. The method according to claims 13, wherein the communicating (211) comprises performing (213) on the application data traffic one or more of the following: data traffic classification, data traffic redirection, charging, policy routing.

15. The method according to claim 1, comprising receiving a digital certificate of the destination node; and sending the digital certificate to the UE, wherein the digital certificate comprises the public key of the destination node and wherein the digital certificate is signed by a certification authority node (104).

16. The method according to one or more claims 1-15, wherein the second message is used to establish the second TLS connection and wherein the second message comprises a seed value for generating the second symmetric key.

17. The method according to one or more claims 1-16, wherein the communicating (211) comprises encrypting (214) the application data traffic using the second symmetric key.

18. The method according to one or more claims 1-17, wherein the core network node comprises the blockchain node.

19. A method (300) performed by a destination node (105), for decrypting and encrypting communication between a user equipment (101) and the destination node via a core network node (102, 103, 106) in a telecommunication network (001), the method comprising: sending (301), to the core network node, a private key of the destination node; receiving (306), from the core network node, an encrypted message comprising information for generating a symmetric key to secure a connection between the core network node and the destination node, wherein the encrypted message was encrypted by the core network node using the public key of the destination node; decrypting (307) the encrypted message using the private key of the destination node; generating (308) the symmetric key based on the information; and communicating (309) application data traffic between the UE and the destination node using the connection secured with the symmetric key.

20. The method according to claim 19, wherein the sending comprises registering (303) the destination node and/or a certification authority node (104) in a blockchain network (003).

21. The method according to claim 20, wherein the sending comprises sending (304), to the core network node, the private key and a digital certificate of the destination node via the blockchain network (003), wherein the digital certificate of the destination node comprises the public key of the destination node and wherein the digital certificate is signed by the certification authority node (104).

22. The method according to claim 21, wherein the sending comprises sending (304a) the digital certificate and the private key via a blockchain node (103) comprised in the blockchain network (003).

23. The method according to one or more claims 20-22, comprising sending (305) an instruction to execute a smart contract on the blockchain network for managing the digital certificate and/or the private key.

24. The method according to claim 23, wherein the instruction comprises one of the following event identifiers: an event identifier to store the digital certificate and/or a private key of the destination node, an event identifier to renew the digital certificate and/or a private key of the destination node, and an event identifier to delete the digital certificate and/or the private key of the destination node.

25. The method according to one or more claims 23-24, wherein the smart contract comprises at least one or more of the following: an identifier of an event, an identifier of a certification authority node, the digital certificate of the destination node, the private key of the destination node, an indication of the time for which the digital certificate is valid and information on target.

26. The method according to one or more claims 19-25, wherein the sending comprises sending (302), to the core network node, a digital certificate of the destination node wherein the digital certificate comprises the public key of the destination node and wherein the digital certificate is signed by a certification authority node (104).

27. The method according to one or more claims 19-26, wherein the connection is a TLS connection.

28. The method according to one or more claims 19-27, wherein the information for generating the symmetric key comprises a seed value.

29. The method according to one or more claims 19-28, wherein the encrypted message is used to establish the TLS connection.

30. The method according to one or more claims 19-29, wherein the core network node includes a user plane function, UPF (106).

31. The method according to one or more claims 19-30, wherein the destination node comprises a blockchain node (103).

32. A core network node (102, 103, 106) in a telecommunication network (001) for decrypting and encrypting communication between a user equipment, UE, (101) and a destination node (105), the core network node comprising a memory (904) and processing circuitry (902), the memory comprising instructions which when executed on the processing circuitry, cause the core network node to: receive a private key of the destination node; decrypt using the private key, a first message, transmitted by the UE, wherein the first message is encrypted using a public key of the destination node; generate a first symmetric key to secure a first connection between the UE and the core network node using information decrypted from the first message; generate a second symmetric key to secure a second connection between the core network node and the destination node; encrypt a second message using the public key of the destination node, wherein the second message comprises information for generating the second symmetric key;

- transmit the encrypted second message to the destination node; and communicate application data traffic between the UE and the destination node using the first connection secured with the first symmetric key and the second connection secured with the second symmetric key.

33. The core network node (102, 103, 106) according to claim 32, the memory comprising instructions which when executed on the processing circuitry, cause the core network node to perform a method according to one or more claims 2-18.

34. A destination node (105), for decrypting and encrypting communication between a user equipment (101) and the destination node via a core network node (102, 103, 106) in a telecommunication network (001), the destination node comprising a memory (1012) and processing circuitry (1002), the memory comprising instructions which when executed on the processing circuitry, cause the destination node to: send, to the core network node, a private key of the destination node; receive, from the core network node, an encrypted message comprising information for generating a symmetric key to secure a connection between the core network node and the destination node, wherein the encrypted message was encrypted by the core network node using the public key of the destination node; decrypt the encrypted message using the private key of the destination node; generate the symmetric key based on the information; and communicate application data traffic between the UE and the destination node using the connection secured with the symmetric key.

35. The destination node (105) according to claim 34, the memory comprising instructions which when executed on the processing circuitry, cause the destination node to perform a method according to one or more claims 20-31.

36. A computer program (905) comprising instructions which, when executed on a core network node (102, 103, 106), cause the core network node to carry out a method according to one or more of claims 1-18.

37. A computer program product comprising a computer readable storage means on which the computer program (905) according to claim 36 is stored.

38. A computer program (1014) comprising instructions which, when executed on a destination node (105), cause the destination node to carry out a method according to one or more of claims 19-31.

39. A computer program product comprising a computer readable storage means on which the computer program according to claim 38 is stored.