TECHNICAL FIELD

The disclosure relates generally to the field of communication networks, and, particularly, to secure communication in a communication network.

To this end, a Client Application (CA) entity and a corresponding method are disclosed for establishing a secure communication channel in a communication network. Furthermore, a Target Application (TA) entity and a corresponding method are disclosed for establishing a secure communication channel in a communication network. In particular, the CA entity, the TA entity, or both, may request an attestation, e.g., as a precondition for establishing the secure communication channel. Moreover, a Root of Trust (ROT) device and a corresponding method are disclosed for assisting the establishing of the secure communication channel in the communication network.

BACKGROUND

Currently, an ecosystem architecture is desired that connects multiple devices to realize Internet of Everything (loE). Network devices of an loE system may share computing tasks and may play a role in maintaining a health state of the ecosystem. Additionally, the network devices of the loE system may exchange sensitive data that may be an appealing target to an attacker.

A conventional architecture is based on operating an untrusted execution environment and a Trusted Execution Environment (TEE) from the same device. The design model may assume that a Client Application (CA) that is executed in a Rich Execution Environment (REE) and its trusted peers may share one platform, and therefore, they may share a same trust root. Furthermore, interconnected devices enable various use cases that work by leveraging on the features offered by their peers. Examples of such features are decentralized data processing, resource sharing, and access control management. Thus, it is generally desired to establish a secure and trustworthy communication channel between a client application and a trusted service or a trusted application running in two different computational environments.

A conventional method uses Public Key Infrastructure (PKI), which operates based on a certain level of implicit trust with a cloud service provider to use its crypto photographic services. However, cloud-based methods may not fulfill a requirement of loT use case, for example, when an loT device such as a smart lock needs to work offline.

Moreover, a conventional device may be based on an edge device that is equipped with computing power and a hardware (HW) assisted technology that may enable the conventional device to provide a robust security, for example, a robust security that is comparable to a security provided by using a cloud-based service

In summary, however, an issue of the conventional methods and devices is that they are designed for complex systems and may not function well for a device such as a microcontroller unit (MCU). Further, another issue of conventional methods and devices is that they are directly dependent on quality of seed used for key generation, which may not be supported by some of loE devices (e.g., light weight IOE devices).

SUMMARY

In view of the above-mentioned problems and disadvantages, the disclosure aims to improve the conventional devices and methods.

An objective of the disclosure is to enable a CA entity and a TA entity to establish a secure communication channel by using a ROT device. A further objective is to enable the CA entity and the TA entity to establish trust using a platform attestation. A further objective is to provide a trustworthy communication channel between the CA entity and the TA entity that may be executed in in a TEE. These and other objectives of the disclosure are achieved by the solution provided in the enclosed independent claims. Advantageous implementations of the disclosure are further defined in the dependent claims.

A first aspect of the disclosure provides a Client Application (CA) entity for establishing a secure communication channel in a communication network. The CA entity is configured to generate a key pair for the CA entity, the key pair comprising a public key of the CA entity and a private key of the CA entity, and further generate a first challenge indicating a public key of a Target Application entity in the communication network. The CA entity is further configured to send a message including the first challenge and the public key of the CA entity to a Root of Trust (ROT) device in the communication network, the message further comprising a request for an attestation from the ROT device, and receive, from the ROT device, a first attestation certificate comprising the first challenge, the public key of the CA entity, and network attestation information.

The CA entity may be an electronic device such as a personal computer, a laptop, a notebook, a mobile phone, a smartphone, an Internet of Thing (loT) device, an loE entity, etc. For example, the CA entity may be an electronic device such as a computer comprising hardware and/or software (e.g., an application running on the electronic device) that may access a service made available by the TA entity.

The TA entity may be an electronic device such as a trusted entity, a personal computer, a laptop, a notebook, a mobile phone, a smartphone, an loT device, an loE entity, etc. For example, the TA entity may be a trusted application entity comprising hardware and/or software (e.g., an application running on the electronic device) that may provide a service to a CA entity.

Without limiting the disclosure, in the following for ease of description, it is assumed that the TA entity is based on a trusted application running providing a service to the CA entity. For example, it may also be possible that the TA entity is any kind of entity that may establish a secure communication channel with another entity such as the CA entity.

The ROT device may be an electronic device such as a computer that may provide a security service to the CA entity and the TA entity. The CA entity may establish the secure communication channel between the CA entity and the TA entity, for example, a trustworthy communication between the CA entity and the TA entity may be established.

Furthermore, the TA entity may be executed in a TEE. Moreover, the CA may be executed in an REE. The TEE may be an environment that may be associated with a high level of trust. The REE may be an environment comprising at least one entity which may execute a client application. The REE and the TEE may reside on a same device or different devices. For example, in some embodiments, the TEE and the REE may reside in a same device. Further, the CA entity may obtain assurance that the TA and the TEE are genuine, i.e., they are trustworthy services which are authorized to execute mission critical tasks. For example, the TEE and the TA entity may assist managing user confidential information, sign authentication request on behalf of a user, etc.

Furthermore, the secure communication channel may be used for performing a trustworthy communication. The trustworthy communication may be a communication satisfying one or more of:

• The TEE having adequate security level, for example, the TEE may pass certain standard such as a Federal Information Processing Standards (FIPS) standard or a standard at a common criteria certification levels,

• The TEE is not hosting any malicious applications,

• The TEE and the TA entity may not fake,

• The TEE and the TA entity are authorized to provide trusted service for the CA entity,

• The TEE is implemented using desired Hardware technology, for example, it is based on a discrete security co-processor,

• A secure boot of the REE may validate that a boot image in the REE is not tampered,

• An integrity of the REE is not tampered on run-time (for example, the device that REE is running on it, is not rooted).

The CA entity of the first aspect may be able to establish a secure communication channel by performing cryptographic key agreement with the TA and by requesting the TA to attest itself. Upon successful validation of the TA’s attestation, the CA entity may gain assurance that the session key resulting from the key agreement satisfies a security policy and can therefore be used e.g. for trustworthy communication.

The CA entity may comprise a circuitry. The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a nonvolatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.

In an implementation form of the first aspect, the CA entity is further configured to send the first attestation certificate to the TA entity, and send a request for initiating a session over the secure communication channel to the TA entity.

The first attestation certificate may be based on any known format. For example, the first attestation may be encoded using a specified X.509 format, or using a JavaScript Object Notation (JSON) format, or using a Concise Binary Object Representation (CBOR) format.

Furthermore, the first attestation certificate may be cryptographically bound to at least one of the public key of the CA entity, an identifier of the CA entity, a claim about the CA entity, a client challenge (e.g., the first challenge), a claim about a user’s authentication information, e.g., evaluating whether a user provided a PIN or biometrics to prove his or her presence, one or more claims about the platform executing the CA entity (such as a secure boot status, a hash of firmware components, a measurement about a system health status, or the like).

The binding may be done with a private key of the ROT device. The private key of the ROT device may be certified and may be associated with a certificate of a device (e.g., the CA entity, the TA entity) that may be provisioned. For example, the certificate may be signed and attested with a private part of an attestation key (also known as an attestation key of the device). Moreover, the association may be done during a secure manufacturing stage or at a later stage. For example, the ROT keys and the attestation keys may be written to an immutable memory of the device and may be securely provisioned. This may be done during manufacturing process of the device, and may be accessed by an access control mechanisms and may never leave the device. The recipient may be the TA entity which may be able to validate trustworthiness of above mentioned cryptographic binding.

For example, the secure communication channel between the CA entity and the TA entity may be established which may be based on an ROT assisted platform attestation. The ROT assisted platform attestation may allow a trusted device to present reliable evidence to remote parties about the platform and a software the entities are running on.

In a further implementation form of the first aspect, the CA entity is further configured to receive, in response to the request for initiating the session, a second attestation certificate from the TA entity, wherein the second attestation certificate comprises the first challenge, or the second attestation certificate comprises a second challenge that indicates the first challenge.

For example, the ROT device may attest the establishment of the secure communication channel between the CA entity and the TA entity. The ROT device may have an ability to assess a state of the CA entity and the TA entity and/or the platform that the CA entity and the TA entity are running on. For example, the attestation claims may comprise a hash digest of a static memory layout of the service requesting process. This may enable the CA entity and the TA entity, i.e., two logically distant communicating services to verify each other’s state against a common security policy.

Hence, in some embodiments, it may be possible that the CA entity and the TA entity using the ROT device establish a trustworthy communication. The trustworthy communication may be based on a public key cryptography.

In a further implementation form of the first aspect, the CA entity is further configured to verify the second attestation certificate based on the public key of the TA entity and the first challenge, and obtain a session key based on the private key of the CA entity, the public key of the TA entity, and session information. The atestation request may comprise cryptographic information for performing a key agreement between the CA entity and the TA entity. This may enable the CA entity and the TA entity to get assurance signed by the ROT device which may represent that the key agreement satisfies a security policy.

In a further implementation form of the first aspect, the CA entity is further configured to perform a mutual key validation procedure in cooperation with the TA entity, and establish the session over the secure communication channel.

For example, a mutual authentication procedure may be performed between the CA entity and the TA entity. Moreover, the secure communication channel may be established, e.g., on the top of mutual end point assessment, which may not be based on specific key management solutions.

In a further implementation form of the first aspect, establishing the session comprises using the obtained session key as a Secure Channel Protocol (SCP) key, in particular, as a Transport Layer Security Pre-Shared Key (TLS-PSK).

For example, in some embodiments, a session key may be agreed, and the session may be established. For example, the session key may be used directly or indirectly as secure channel protocol key. Secure channel protocols may be TLS-PSK or some variant of SCP.

In a further implementation form of the first aspect, the network atestation information comprises one or more of: configuration information of the communication network; a trusted execution environment (TEE) certificate; a platform state information.

In a further implementation form of the first aspect, the generated key pair is based on an ephemeral asymmetric key pair comprising the public key of the CA entity and the private key of the CA entity. This may increase a security of an established communication channel in a heterogeneous device environment having varying security capabilities such as the REE and the TEE. For example, it may be possible to enhance a security of provisioning of keys, enclave migration, etc.

A second aspect of the disclosure provides a Target Application entity for establishing a secure communication channel in a communication network, the TA entity being configured to receive, from a Client Application (CA) entity in the communication network, a first attestation certificate comprising a first challenge, a public key of the CA entity, and network attestation information, the first attestation certificate indicating a request for initiating a session over the secure communication channel; generate a key pair for the TA entity, the key pair comprising a public key of the TA entity and a private key of the TA entity; send a message that indicates the first challenge and the public key of the CA entity to a Root of Trust (ROT) device in the communication network, the message comprising a request for an attestation; and receive, from the ROT device, a second attestation certificate comprising the first challenge , the public key of the CA entity and the network attestation information.

The TA entity of the second aspect may be an electronic device such as a personal computer, a laptop, a notebook, a mobile phone, a smartphone, an Internet of Thing (loT) device, etc. For example, the TA entity may be an electronic device such as a computer comprising hardware and/or software that may provide a service that may be accessed by the CA entity.

The TA entity may establish the secure communication channel between the CA entity and the TA entity. For example, the TA entity may assist obtaining trust through platform attestation supported by the ROT device. The TA entity may verify the attestation before establishing the secure communication channels to provide secure services. Furthermore, the attestation provided by the ROT device may not need an MCU to be always online for running complex protocols. Moreover, the TA may support an attestation and a key agreement procedure which may be performed, simultaneously, and may enable these procedure to be efficient and minimalistic. The TA entity may comprise a circuitry. The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a nonvolatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.

In an implementation form of the second aspect, the TA entity is further configured to generate a second challenge based on the first challenge and the public key of the CA entity, and wherein the sent message indicates the second challenge comprising the first challenge.

For example, the ROT may attest the establishment of the secure communication between the CA and the TA. Moreover, this may enable the CA and the TA, i.e., two logically instant communicating services to verify each other state against a common security policy.

In a further implementation form of the second aspect, the TA entity is further configured to verify, before generating the key pair of the TA entity, the first attestation certificate using the public key of the CA entity.

In a further implementation form of the second aspect, the TA entity is further configured to send, in response to the request for initiating the session, the second attestation certificate to the CA entity.

In a further implementation form of the second aspect, the TA entity is further configured to obtain a session key based on the private key of the TA entity, the public key of the CA entity, and session information.

For example, the TA entity may use cryptographic information to perform a key agreement between the CA entity and the TA entity. This may enable the TA entity and the CA entity to get assurance signed by the ROT device that the key agreement was done between peers satisfying security policy. In a further implementation form of the second aspect, the TA entity is further configured to perform a mutual key validation procedure in cooperation with the CA entity; and establish the session over the secure communication channel.

For example, a mutual authentication procedure may be performed between the TA entity and the CA entity. This may assist establishing the secure communication channel between the TA entity and the CA entity.

In a further implementation form of the second aspect, establishing the session comprises using the obtained session key as a key in SCP or as a PSK in TLS.

For example, in some embodiments, a session key may be agreed, and the session may be established. For example, the session key may be used directly or indirectly as secure channel protocol key. Secure channel protocols may be TLS-PSK or some variant of SCP.

In a further implementation form of the second aspect, the network attestation information comprises one or more of: configuration information of the communication network; a trusted execution environment, TEE, certificate; a platform state information.

In a further implementation form of the second aspect, the generated key pair is based on an ephemeral asymmetric key pair comprising the public key of the TA entity and the private key of the TA entity.

This may increase a security of an established communication channel in a heterogeneous device environment having varying security capabilities such as the REE and the TEE. For example, it may be possible to enhance a security of provisioning of keys, enclave migration, etc.

A third aspect of the disclosure provides a Root of Trust (ROT) device for assisting a secure communication channel in a communication network, the ROT device being configured to receive a message comprising a challenge and a public key of an entity in the communication network, the message further comprising a request for an attestation; generate an attestation certificate comprising the challenge, the public key of the entity and network attestation information; and provide the attestation certificate to the entity.

The ROT device may be an electronic device such as a computer that may provide a security service to the CA and the TA.

The ROT device may comprise a circuitry. The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a nonvolatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.

A fourth aspect of the disclosure provides a method for a Client Application (CA) entity for establishing a secure communication channel in a communication network, the method comprising generating a key pair for the CA entity, the key pair comprising a public key of the CA entity and a private key of the CA entity, and further generating a first challenge indicating a public key of a Target Application (TA) entity in the communication network, sending a message including the first challenge and the public key of the CA entity to a Root of Trust (ROT) device in the communication network, the message further comprising a request for an attestation from the ROT device, and receiving, from the ROT device, a first attestation certificate comprising the first challenge, the public key of the CA entity, and network attestation information.

In an implementation form of the fourth aspect, the method further comprises sending the first attestation certificate to the TA entity, and sending a request for initiating a session over the secure communication channel to the TA entity.

In a further implementation form of the fourth aspect, the method further comprises receiving, in response to the request for initiating the session, a second attestation certificate from the TA entity, wherein the second attestation certificate comprises the first challenge, or the second attestation certificate comprises a second challenge that indicates the first challenge. In a further implementation form of the fourth aspect, verifying the second attestation certificate based on the public key of the TA entity and the first challenge, and obtaining a session key based on the private key of the CA entity, the public key of the TA entity, and session information.

In a further implementation form of the fourth aspect, the method further comprises performing a mutual key validation procedure in cooperation with the TA entity, and establishing the session over the secure communication channel.

In a further implementation form of the fourth aspect, establishing the session comprises using the obtained session key as a key in SCP or as a PSK in TLS.

In a further implementation form of the fourth aspect, the network attestation information comprises one or more of: configuration information of the communication network; a trusted execution environment (TEE) certificate; a platform state information.

In a further implementation form of the fourth aspect, the generated key pair is based on an ephemeral asymmetric key pair comprising the public key of the CA entity and the private key of the CA entity.

A fifth aspect of the disclosure provides a method for a Target Application entity for establishing a secure communication channel in a communication network, the method comprising receiving, from a Client Application (CA) entity in the communication network, a first attestation certificate comprising a first challenge, a public key of the CA entity, and network attestation information, the first attestation certificate indicating a request for initiating a session over the secure communication channel; generating a key pair for the TA entity, the key pair comprising a public key of the TA entity and a private key of the TA entity; sending a message that indicates the first challenge and the public key of the CA entity to a Root of Trust (ROT) device in the communication network, the message comprising a request for an attestation; and receiving, from the ROT device, a second attestation certificate comprising the first challenge, the public key of the CA entity and the network attestation information. In an implementation form of the fifth aspect, the method further comprises generating a second challenge based on the first challenge and the public key of the CA entity, and wherein the sent message indicates the second challenge comprising the first challenge.

In a further implementation form of the fifth aspect, the method further comprises verifying, before generating the key pair of the TA entity, the first attestation certificate using the public key of the CA entity.

In a further implementation form of the fifth aspect, the method further comprises sending, in response to the request for initiating the session, the second attestation certificate to the CA entity.

In a further implementation form of the fifth aspect, the method further comprises obtaining a session key based on the private key of the TA entity, the public key of the CA entity, and session information.

In a further implementation form of the fifth aspect, the method further comprises performing a mutual key validation procedure in cooperation with the CA entity; and establishing the session over the secure communication channel.

In a further implementation form of the fifth aspect, the establishing of the session comprises using the obtained session key as a SCP key, in particular as a TLS-PSK.

In a further implementation form of the fifth aspect, the network attestation information comprises one or more of: configuration information of the communication network; a trusted execution environment , TEE, certificate; a platform state information.

In a further implementation form of the fifth aspect, the generated key pair is based on an ephemeral asymmetric key pair comprising the public key of the TA entity and the private key of the TA entity. A sixth aspect of the disclosure provides a method for a Root of Trust (ROT) device for assisting a secure communication channel in a communication network, the method comprising receiving a message comprising a challenge and a public key of an entity in the communication network, the message further comprising a request for an attestation; generating an attestation certificate comprising the challenge, the public key of the entity and network attestation information; and providing the attestation certificate to the entity.

A seventh aspect of the disclosure provides a computer program comprising a program code for performing the method according to one of the fourth to sixth aspect or any of their implementation forms.

An eighth aspect of the disclosure provides a non-transitory storage medium storing executable program code which, when executed by a processor, causes the method according to one of the fourth to sixth aspect or any of their implementation forms.

It has to be noted that all devices, elements, units and means described in the disclosure could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the disclosure as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms of the disclosure will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which FIG. 1 depicts a schematic view of a CA entity for establishing a secure communication channel in a communication network, according to an exmaple of the embodiments of the disclosure;

FIG. 2 depicts a schematic view of a TA entity for establishing a secure communication channel in a communication network, according to an example of the embodiments of the disclosure;

FIG. 3 depicts a schematic view of an ROT device for assisting a secure communication channel in a communication network, according to an example of the embodiments of the disclosure;

FIG. 4 shows a diagram illustrating the CA entity, the TA entity and the ROT device establishing a secure communication channel;

FIG. 5 shows a diagram illustrating a method for establishing a secure communication channel between the CA entity and the TA entity;

FIG. 6 shows a diagram illustrating a illustrating a method for establishing a secure communication channel between the CA entity and the TA entity using a cryptographic process;

FIG. 7 depicts a flowchart of a method for a CA entity for establishing a secure communication channel in a communication network, according to an example of the embodiments of the disclosure;

FIG. 8 depicts a flowchart of a method for a TA entity for establishing a secure communication channel in a communication network, according to an example of the embodiments of the disclosure; and

FIG. 9 depicts a flowchart of a method for an ROT device for assisting a secure communication channel in a communication network, according to an example of the embodiments of the disclosure. DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 depicts a schematic view of a C A entity 100 for establishing a secure communication channel in a communication network 1, according to an embodiment of the disclosure.

The CA entity 100 may be a computer, for example, a client application running on the computer.

The CA entity 100 is configured to generate a key pair 10 for the CA entity 100. The key pair 10 comprises a public key 101 of the CA entity 100 and a private key 102 of the CA entity 100. The CA entity 100 is further configured to generate a first challenge 103, wherein the challenge 103 indicates a public key 201 of a TA entity 200 in the communication network 1.

The C A entity 100 is further configured to send a message 104 including the first challenge 103 and the public key 101 of the CA entity 100 to an ROT device 110 in the communication network 1. The message 104 further comprises a request for an attestation from the ROT device 110.

The CA entity 100 is further configured to receive, from the ROT device 110 in response to the message 104, a first attestation certificate 111. This first attestation certificate 111 comprises the first challenge 103, the public key 101 of the CA entity 100, and network attestation information 105.

For instance, the ROT device 110 may attest (i.e., sign claims with its private key) data received from the CA entity 100 which is the attestation requestor. The signed data includes the first challenge 103, the public key 101 of the CA entity 100, and additional information added by the ROT device 100. Moreover, the data received from the CA entity 100 may not change, and the ROT device 100 may only add the additional data which is the network attestation information 105. The network attestation information 105 may potentially describe the attestation requestor and the platform in which requestor is operating on it.

The CA entity 100 may be able to establish the secure communication channel based on the request for the attestation and by using the attestation information. Further, the CA entity 100 and the TA entity 200 may obtain assurance signed by the ROT device 200 that the key agreement was done between peers satisfying security policy.

The CA entity 100 may comprise processing circuitry (not shown in FIG. 1) configured to perform, conduct or initiate the various operations of the CA entity 100 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multipurpose processors. In one embodiment, the processing circuitry comprises one or more processors and anon-transitory memory connected to the one or more processors. The non- transitory memory may carry executable program code which, when executed by the one or more processors, causes the CA entity 100 to perform, conduct or initiate the operations or methods described herein.

FIG. 2 depicts a schematic view of a TA entity 200 for establishing a secure communication channel in a communication network 1, according to an embodiment of the disclosure.

The TA entity 200 may be a trusted application running on a computer.

The TA entity 200 is configured to receive, from a CA entity 100 in the communication network 1, a first attestation certificate 111. The first attestation certificate 111 comprises a first challenge 103, a public key 101 of the CA entity 102, and network attestation information 105. Further, the first attestation certificate 111 indicates a request for initiating a session over the secure communication channel.

The TA entity 200 is further configured to generate a key pair 20 for the TA entity 200. The key pair 20 comprises a public key 201 of the TA entity 200 and a private key 202 of the TA entity 200.

The TA entity 200 is further configured to send a message 204 that indicates the first challenge 103 and the public key 101 of the CA entity 100 to an ROT device 110 in the communication network 1. The message 204 comprises also a request for an attestation. The TA entity 200 is further configured to receive, from the ROT device 110, a second attestation certificate 211 comprising the first challenge 103, the public key 101 of the CA entity 100 and the network attestation information 205.

The TA entity 200 may comprise processing circuitry (not shown in FIG. 2) configured to perform, conduct or initiate the various operations of the TA entity 200 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multipurpose processors. In one embodiment, the processing circuitry comprises one or more processors and anon-transitory memory connected to the one or more processors. The non- transitory memory may carry executable program code which, when executed by the one or more processors, causes the TA entity 200 to perform, conduct or initiate the operations or methods described herein.

FIG. 3 depicts a schematic view of an ROT device 110 for assisting a secure communication channel in a communication network 1 , according to an embodiment of the disclosure.

The ROT device 110 is configured to receive a message 104, 204 comprising a challenge 103, 203 and a public key 101, 201 of an entity 100, 200 in the communication network. The message 104, 204 further comprises a request for an attestation.

The ROT device 110 is further configured generate an attestation certificate 111, 211 comprising the challenge 103, 203, the public key 101, 201 of the entity 100, 200 and network attestation information 105, 205.

The ROT device 110 is further configured to provide the attestation certificate 111, 211 to the entity 100, 200.

The ROT device 110 may comprise processing circuitry (not shown in FIG. 3) configured to perform, conduct or initiate the various operations of the ROT device 110 described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multipurpose processors. In one embodiment, the processing circuitry comprises one or more processors and anon-transitory memory connected to the one or more processors. The non- transitory memory may carry executable program code which, when executed by the one or more processors, causes the ROT device 110 to perform, conduct or initiate the operations or methods described herein.

Reference is now made to FIG. 4, which shows a diagram illustrating the CA entity 100, the TA entity 200 and the ROT device 200 establishing a secure communication channel.

For example, the secure communication channel may be established between the CA entity 100, which may be a service beneficiary, and the TA entity 200, which may provide the service in the secure execution environments. The channel may be established under a condition that the CA entity 100 and the TA entity 200 may comply with a security policy. Moreover, the first challenge 103 of the C A entity 100 and the second challenge 203 of the TA entity 200 may be used to prevent an anti-replay protection. For instance, the CA entity 100 and the TA entity 200 may communicate to establish the secure communication channel.

In FIG. 3, two ROT devices 110 are shown, wherein a first ROT device 110 (i.e., ROTI) is configured to measure EE1 and ensure identity of an application. Moreover, a second ROT device 110 (i.e., ROT2) is configured to measure EE2 and ensure identity of an application.

The ROTI 110 and the ROT2 110 may be logically distinct, however, the ROTI 110 and the ROT2 110 may also be the same device, or may be under the same public key, or may share the same secret key.

A cryptographic binding of key agreement procedure may be performed betweent the CA entity 100 and the TA entirty 200, and a mutual trust assessment may be obtainined, in which the CA entity 100 and the TA entirty 200 are the service beneficiary and the trusted Service, respectively. Further, the secure comunnication channel may be established between the the CA entity 100 and the TA entirty 200 such that at least one of the following conditions is satisfied.

• Trust assessment is based on validation of an attestation statement. The statement comprises request for attesttaion about the the CA entity 100 and the TA entirty 200, and the statement is signed by the ROT 110 which is locally accessible by the CA entity 100 and the TA entirty 200.

• Cryptographic key material data such as ephemeral public keys is used for key agreement are bound to attestation.

• The attestation statement can be either key attestation or platform state attestation. In a typical configuration, the service beneficiary that is the the CA entity 100 is supported by platform attestation, and the trusted service that is the TA entirty 200 is supported by key attestation.

• The CA entity 100 and the TA entirty 200 crosswise validate signatures of each other’s attestation statements.

• The CA entity 100 and the TA entirty 200 validate whether an attested security capability of the other peer complies to locally required security policy as a condition of key agreement.

The CA entity 100 and the TA entirty 200 may have a local policy that authorizes usage of service aggregation together with a local or a remote peer(s). The policy enforcement can be done by utilizing security capabilities provided by the operating system hosting the local peer.

The session key may be obtained and the agreement may be used only once, and only to establish a secure session between the CA entity 100 and the TA entirty 200. This enables secure routing and messaging between beneficiaries and services, both locally in a single device or among multiple devices.

Establishing the secure communication channel by using the first challenge 103 and the second challenge 203 may enable the CA entity 100 and the TA entity 200 to provide a robust security, which guarantees that they are the same or near the security of a cloud service. Furthermore, the CA entity 100 and the TA entity 200 may achieve, locally at ecosystem level, a security guarantee, for example, without being connected online to an internet connection. Moreover, the CA entity 100 and the TA entity 200 may be able to remove a cloud arbitration.

In addition, by locally performing the operations related to establishing the secure communication channel at the CA entity 100 and the TA entity 200, it may possible to increase a computation power of the CA entity 100 and the TA entity 200. For instance, it may be possible to mitigate a cloud-based computing, or transmitting data, and thus, a risk related to privacy of a user data may be decreased.

Reference is now made to FIG. 5, which shows a diagram illustrating a method 500 for establishing a secure communication channel between the CA entity 110 and the TA entity 200.

The method 500 may partially be performed by the CA entity 110 and the TA entity 200 and the ROT device 110. For example, the CA entity 110 and the TA entity 200 and the ROT device 110 may each perform one or more steps of the method 500.

At step 501, the CA entity 100 may operate in the REE and may generate an ephemeral asymmetric key pair. For example, the CA entity 100 may generate the key pair 10 comprising the public key 101 of the CA entity and the private key 102 of the CA entity. The key pair 10 may be based on any known key pair such as the as a Rivest-Shamir- Adleman (RS A) key pair, an Elliptic-curve cryptography (ECC) key pair, an X25519 X25519 key exchange, El Gamal or an NTRUEncrypt public key cryptosystem key pair.

At 502, the CA entity 100 may send a message 104 including the first challenge 103 and the public key 101 of the CA entity 100 to the ROT device 110. The message 104 further comprising a request for an attestation from the ROT device 110.

For example, the CA entity 100 may request the ROT device 110 to attest and bind the first challenge 103 with its public key 101. At 503, the ROT device 110 may generate an attestation certificate 111, 211. The attestation certificate 111, 211 may comprise the challenge 103, 203, the public key of the CA entity 101 or the public key of the TA entity 201 and network attestation information 105, 205.

At 504, the CA entity 110 may send the first attestation certificate 111 to the TA entity 200, and may further send a request for initiating a session over the secure communication channel to the TA entity 200.

At 505, the TA entity 200 may verify, before generating the key pair 20 of the TA entity 200, the first attestation certificate 111 using the public key 101 of the CA entity 100.

At 506, the TA entity 200 may send a message 204 that indicates the first challenge 103 and the public key 101 of the CA entity 100 to the ROT device 110 in the communication network 1. For example, the message 204 may comprise a request for an attestation.

At 507, the TA entity 200 may send, in response to the request for initiating the session, the second attestation certificate 211 to the CA entity 100.

At 508, the CA entity 100 and the TA entity 200 may perform a mutual key validation procedure and may further establish the session over the secure communication channel.

Reference is made to FIG. 6, which shows a diagram illustrating a illustrating a method 600 for establishing a secure communication channel between the CA entity 110 and the TA entity 200 using a cryptographic process.

The method 600 may partially be performed by the CA entity 110 and the TA entity 200 and the ROT device 110. For example, the CA entity 110 and the TA entity 200 and the ROT device 110 may each perform one or more steps of the method 600.

The method 600 may comprise generating a challenge, obtaining a challenge from TA, or peers need to store challenges to prevent usage of previously used challenges. For ease of the description, the method 600 of FIG. 6, is exemplary discussed using an X25519 key exchange. In the discussion of FIG. 6, ephermal X25519 public keys are exchanged as apart of attestation certificates. The public keys are embedded into attestation certificate information. Furthermore, the attestation certificates are presented in a form of X509 certificates and are signed with a private key of the ROT device 110, without limiting the disclosure to these specific formats of cryptography. For example, in some other embodiemtns, a key exchange may be used using another format such as a JSON Web Tokens (JWT), a CBOR, a Object Signing and Encryption (COSE), or a RFC8125, or the like. For example, any attestation tokens (certificates, JWT, COSE) may be used that can provide attestation and can allow a public key exhange to other peer. If other peer complies with the security policy, then the peers may perform a key agreement procedure such as X25519, ECDH, etc. In some embodiment, key material for session key may also be delivered in an encrypted form using other peers public key.

At step 601, the CA entity 100 may generate the first challenge 103, and may further generate a key pair 10 for the CA entity 100.

For example, The CA entity 100 may generate a random challenge (the first challenge 103) and embed it as a request in the attestation certificates of the CA entity 100. This may enable the CA entity 100, when receives the attestation certificate from the TA entity 200, to verify that the first challenge 103 is in that certificate.

An example of an X25519 based format for genratng the first channelge 103 and the key pair 10 may be “generate_challenge X25519_genkey (CA_pubKey, CA_privKey)”.

The first challenge 103 may comprise information from the CA entity 100 and the TA entity 200, for example, the first challenge 103 is in form of: challenge = challenge_C A| | challenge_TA.

At 602, the CA entity 100 may send a message 104 including a request for an attestation.

For example, the CA entity 100 may send the public key of the CA entity 100 and the first challenge 103 to the ROT device 110. The ROT device may sign it, i.e., the ROT device 100 may issue an attestation certificate, which has the public key of the CA entity 100 as its subject and further comprises the first challenge 103.

At 603, the ROT device 110 of the CA entity 100 may generate an attestation certificate 111 comprising the first challenge 103, the public key 101 of the CA entity 100 and the network attestation information 105.

For example, the ROT device 110 of the CA entity 100 may generate the attestation certificate 111 based on the X25519 format, which may be “obtain_client_status() Issue cert = TBS||ed25519-oid||ed25519_sign(TBS, Priv_RoT_client)”.

At 604, the ROT 110 of the CA entity 100 may send the attestation certificate 111 to the CA entity 100. For example, the ROT device 110 of the CA entity 100 may send a message to the CA entity 100, the message may comprise the attestation certificate 111, a full PKI chain of certificates such as a certificate for the ROT Public Key and root CA certificate.

At 605, the CA entity 100 may send the first attestation certificate 111 to the TA entity 200. Moreover, the CA entity 100 may send a request for initiating a session over the secure communication channel.

Moreover, the TA entity 200 may obtain the first challenge 103, the public key of the CA entity 100, the request for initiating the session which are in the first attestation certificate 111.

At 606, the TA entity 200 may verify the first attestation certificate 111.

For example, the TA entity 200 may verify whether the request for initiating the session, which is in the first attestation certificate 111, complies with the policy or not. The TA entity 200 may compare the request with an access control rule specified by the policy.

Furthermore, in the case that the TA entity 200 verifies the request, it goes to step 607. Moreover, in the case that the request is not verified, the TA entity 200 aborts the operation.

At 607, the TA entity 200 may generate a key pair 20 for the TA entity 200. An example of an X25519 based format for generating the key pair 20 may be “X255 I9_genkey( TA_pubKey, TA_privKey) SessionKey= X25519(CA_PubKey, TA PrivKey) Create_key_attestation(TA_pubKey, challenge)”.

At 608, the ROT 110 of the TA entity 200 may generate the attestation certificate 211 comprising the challenge 203, the public key 201 of the TA entity 200, and the network attestation information 205.

For example, the ROT 110 of the TA entity 200 may obtain the network attestation information 205 (platform status), and obtain the public key of the TA entity (the client identification information). Moreover, the ROT 110 of the TA entity 200 may issue the attestation certificate 211 according to the X25519 format as “obtain_client_identification() Issue cert = TBS||ed25519-oid||ed25519_sign(TBS, Priv RoT TA) SubjectPublicKey of cert is TA PubKey”.

At 609, the ROT 110 of the TA entity 200 may send the attestation certificate 211 to the TA entity 200.

At 610, the TA entity 200 may send the attestation certificate 211 to the CA entity 100.

At 611, the CA entity 100 may verify the second attestation certificate 211 based on the public key 201 of the TA entity 200 and the first challenge 103.

For example, the CA entity 100 may verify whether the second attestation certificate 211, complies with the policy or not. The CA entity 100 may determine whether the second attestation certificate 211 includes the public key of the TA entity 200.

Further, the CA entity 100 may determine the validity of the first challenge 103. For example, the CA entity 100 may determine whether the first challenge 103 is used before by the CA entity 100.

At 612, the CA entity 100 may obtain a session key based on the private key 101 of the CA entity 100, the public key 201 of the TA entity 200, and session information. At 613, the CA entity 100 and the TA entity establish the secure communciation channel, when the session key is agreed, it can be used directly or indirectly as secure channel protocol key. Secure channel protocols can be TLS-PSK or some variant of SCP (Secure Channel Protocol). The CA entity 100 and the TA entity may establish a secure channel protocol using the session key. Protocol is selected based on Claims in TBS. For example GP SCP70 or TLS-PSK, where SessionKey is used as PSK.

FIG. 7 shows a method 700 according to an embodiment of the disclosure for a CA entity 100 for establishing a secure communication channel in a communication network. The method 700 may be carried out by the CA entity 100, as it is described above.

The method 700 comprises a step 701 of generating a key pair 10 for the CA entity 100, the key pair 10 comprising a public key 101 of the CA entity and a private key 102 of the CA entity, and further generate a first challenge 103 indicating a public key 201 of a Target Application, TA, entity 200 in the communication network 1.

The method 700 further comprises a step 702 of sending a message 104 including the first challenge 103 and the public key 101 of the CA entity 100 to a Root of Trust, ROT, device 110 in the communication network 1, the message 104 further comprising a request for an attestation from the ROT device 110.

The method 700 further comprises a step 703 of receiving, from the ROT device 110, a first attestation certificate 111 comprising the first challenge 103, the public key 101 of the CA entity 100, and network attestation information 105.

FIG. 8 shows a method 800 according to an embodiment of the disclosure for a TA entity 200 for establishing a secure communication channel in a communication network 1. The method 800 may be carried out by the TA entity 200, as it is described above.

The method 800 comprises a step 801 of receiving, from a Client Application, CA, entity 100 in the communication network 1, a first attestation certificate 111 comprising a first challenge 103, a public key 101 of the CA entity 102, and network attestation information 105, the first attestation certificate 111 indicating a request for initiating a session over the secure communication channel.

The method 800 further comprises a step 802 of generating a key pair 20 for the TA entity 200, the key pair 20 comprising a public key 201 of the TA entity 200 and a private key 202 of the TA entity 200.

The method 800 further comprises a step 803 of sending a message 204 that indicates the first challenge 103 and the public key 101 of the CA entity 100 to a Root of Trust, ROT, device 110 in the communication network 1, the message 204 comprising a request for an attestation.

The method 800 further comprises a step 804 of receiving, from the ROT device 110, a second attestation certificate 211 comprising the first challenge 103, the public key 101 of the CA entity 100 and the network attestation information 205.

FIG. 9 shows a method 900 according to an embodiment of the disclosure for an ROT device 110 for assisting a secure communication channel in a communication network 1. The method 900 may be carried out by the ROT device 110, as it is described above.

The method 900 comprises a step 901 of receiving a message 104, 204 comprising a challenge 103, 203 and a public key 101, 201 of an entity 100, 200 in the communication network, the message further comprising a request for an attestation.

The method 900 further comprises a step 902 of generating an attestation certificate 111, 211 comprising the challenge 103, 203, the public key 101, 201 of the entity 100, 200 and network attestation information 105, 205.

The method 900 further comprises a step 903 of providing the attestation certificate 111, 211 to the entity 100, 200.

The disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the disclosure, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.