Zero-trust end user solution for FPGA-based cloud architecture

Abstract

A hardware device (200) includes an accelerator enclave (230) and a hardware security module (210), HSM, the HSM (210) including a first true random number generator, TRNG, (211). The accelerator enclave (230) includes a second TRNG (231) and an accelerator (235). The HSM (210) is configured to: generate a first session key using the first TRNG (211); establishing a first secure communication channel (CH1) with the cloud user using the first session key; receiving the encrypted hardware configuration bitstream over a first secure communication channel (CH1); decrypting the hardware configuration bit stream; function blocks in at least one accelerator are configured based on the hardware configuration bitstream. The accelerator enclave (230) is configured to: generate a second session key using a second TRNG (231); establishing a second secure communication channel (CH2) with the cloud user using the second session key as an encryption key; receiving encrypted input data over a second secure communication channel (CH2); decrypting the encrypted input data; input data is processed using a functional block.

Description

Technical Field

[0001] Various example embodiments are generally directed to hardware devices, cloud user's apparatus, cloud provider's apparatus, and corresponding methods for implementing a zero-trust end-user solution for a hardware-based cloud architecture. Background Art

[0002] Due to the rising computational complexity of applications such as AI / ML and telecommunications, cloud computing solutions and environments are in high demand. Public cloud solutions allow users to take advantage of a readily available and flexible cloud acceleration environment. Users aim to meet their performance requirements and provide high-quality services for their solutions.

[0003] Several types of hardware resources may be used in a cloud computing environment: CPU (central processing unit), GPU (graphics processing unit), FPGA (field programmable gate array), ASIC (application-specific integrated circuit), or more generally SoC (system on a chip), which represents any type of integrated circuit (IC) design that combines many or all of the high-level functional elements of an electronic device onto a single chip.

[0004] FPGA-based cloud acceleration is a possible solution to achieve the performance requirements. FPGA is a reprogrammable hardware device with excellent parallelization and pipelining capabilities. Due to its performance and power efficiency, FPGA is more efficient than general-purpose CPUs and GPUs. Therefore, FPGAs are highly relevant to cloud-based accelerators. Their flexibility allows versatility, reconfiguration, and acceleration of various acceleration functions. Today, FPGAs are easier to use. High-level synthesis (HLS) tools bring FPGA capabilities to SW designers.

[0005] FPGA is deployed in the cloud, and the associated development kit is provided to cloud users by the cloud provider (CP). Cloud users can use the provided FPGA interface and follow the workflow provided by the CP.

[0006] However, there is no standard architecture and tools for FPGAs, and FPGA manufacturers can use different libraries and development environments to design and configure FPGAs. The lack of standardization in FPGAs makes security more challenging because security solutions are specific to FPGA vendors. In FPGAs, functional blocks are often referred to as IP cores (Intellectual Property). IP cores are logical function blocks (e.g., RAN cores, LDPC functions, etc.) that can be configured and used through inputs and outputs, as APIs in the software world. IP cores can be shared or private, available from the market to accelerate FPGA design, or implemented through internal design. Summary of the invention

[0007] The scope of protection is set forth by the independent claims. Embodiments, examples, and features described in this specification that do not belong to the scope of protection (if any) should be interpreted as examples that help understand various embodiments or examples that belong to the scope of protection.

[0008] According to a first aspect, a hardware device comprises: an accelerator enclave and a hardware security module HSM, the HSM comprising a first true random number generator TRNG; the accelerator enclave comprising a second TRNG, and at least one accelerator; the HSM is configured to: generate a first session key using the first TRNG; establish a first secure communication channel with a cloud user using the first session key as an encryption key; receive an encrypted hardware configuration bitstream through the first secure communication channel; decrypt the hardware configuration bitstream; configure a functional block in at least one accelerator based on the hardware configuration bitstream; the accelerator enclave is configured to: generate a second session key using the second TRNG; establish a second secure communication channel with the cloud user using the second session key as an encryption key; receive encrypted input data through the second secure communication channel; decrypt the encrypted input data; process the input data using the functional block; and send encrypted output data generated by the functional block based on the encrypted input data through the second secure communication channel.

[0009] The HSM may be configured to: receive an encrypted access token defining: authorization granted by a cloud provider to a cloud user for a functional block in at least one accelerator; decrypt the encrypted access token; and initialize the functional block based on the authorization defined in the access token.

[0010] To establish a first secure communication channel, the HSM may be configured to: encrypt a first session key using a public key associated with the cloud user to generate a first encryption key; generate a first signature for the first encryption key; and send the first encryption key and the first signature to the cloud user.

[0011] To establish a second secure communication channel, the accelerator enclave is configured to: encrypt a second session key using a public key associated with the cloud user to generate a second encryption key; generate a second signature for the second encryption key; and send the second encryption key and the second signature to the cloud user.

[0012] According to another aspect, a method involving a hardware device is disclosed. The hardware device includes: an accelerator enclave and a hardware security module HSM, the HSM includes a first true random number generator TRNG; the accelerator enclave includes a second TRNG and at least one accelerator; the HSM is configured to: generate a first session key using the first TRNG; use the first session key as an encryption key to establish a first secure communication channel with a cloud user; receive an encrypted hardware configuration bitstream through the first secure communication channel; decrypt the hardware configuration bitstream; configure a functional block in at least one accelerator based on the hardware configuration bitstream; the accelerator enclave is configured to: generate a second session key using the second TRNG; use the second session key as an encryption key to establish a second secure communication channel with the cloud user; receive encrypted input data through the second secure communication channel; decrypt the encrypted input data; use the functional block to process the input data; and send encrypted output data generated by the functional block based on the encrypted input data through the second secure communication channel.

[0013] According to a second aspect, an apparatus for use by a cloud user is disclosed. The apparatus includes components for: establishing a first secure communication channel with a hardware security module in a hardware device in the cloud using a first session key as an encryption key; sending an encrypted hardware configuration bitstream through the first secure communication channel, the hardware configuration bitstream being suitable for configuring a functional block in at least one accelerator in an accelerator enclave in the hardware device; establishing a second secure communication channel with the accelerator enclave in the hardware device; sending encrypted input data to be processed using the functional block through the second secure communication channel; and receiving encrypted output data generated by the functional block based on the encrypted input data through the second secure communication channel.

[0014] The apparatus may include means for performing mutual authentication with the hardware device, wherein if the mutual authentication with the hardware device is successful, the first secure communication channel is established.

[0015] The apparatus may include means for sending an encrypted access token to the hardware security module, the access token defining authorization granted to the cloud user for a functional block in the at least one accelerator.

[0016] The apparatus may include components for: sending a cloud user's certificate and a request for hardware resources to a cloud provider; receiving a certificate signed by the cloud provider; performing mutual authentication with a trusted authority; receiving an access token from the trusted authority and a signature of the access token generated by the trusted authority using a secret shared between the trusted authority and a hardware security module of the hardware device.

[0017] The access token may include: a public key of the cloud user, an authorization granted to the cloud user by the cloud provider, and a public key of the hardware device.

[0018] The components for establishing a first secure communication may include components for: receiving a first encryption key that encrypts a first session key, and a first signature of the first encryption key; decrypting the first encryption key using a private key associated with the cloud user to obtain a first session key; and verifying the first signature using the decrypted first session key.

[0019] The components for establishing a second secure channel may include components for: receiving a second encryption key for encrypting a second session key, and a second signature for the second encryption key; decrypting the second encryption key using a private key associated with the cloud user to obtain a second session key; and verifying the second signature using the decrypted second session key.

[0020] According to a second aspect, the component of the device may include a circuit system configured to perform one or more or all functions defined for the device. The component may include: at least one processor and at least one memory, the at least one memory storing instructions, which when executed by at least one processor, causes the device to perform one or more or all functions defined for the device.

[0021] According to another aspect regarding a cloud user, a method includes: establishing a first secure communication channel with a hardware security module in a hardware device in the cloud using a first session key as an encryption key; sending an encrypted hardware configuration bitstream through the first secure communication channel, the hardware configuration bitstream being suitable for configuring a functional block in at least one accelerator in an accelerator enclave in the hardware device; establishing a second secure communication channel with the accelerator enclave in the hardware device; sending encrypted input data to be processed using the functional block through the second secure communication channel; and receiving encrypted output data generated by the functional block based on the encrypted input data through the second secure communication channel.

[0022] The method may include performing mutual authentication with the hardware device, wherein if the mutual authentication with the hardware device is successful, a first secure communication channel is established.

[0023] The method may include sending an encrypted access token to the hardware security module, the access token defining authorization granted to the cloud user for a functional block in the at least one accelerator.

[0024] The method may include: sending a cloud user's certificate and a request for hardware resources to a cloud provider; receiving a certificate signed by the cloud provider; performing mutual authentication with a trusted authority; receiving an access token from the trusted authority and a signature of the access token generated by the trusted authority using a secret (FSS) shared between the trusted authority and a hardware security module of the hardware device.

[0025] The access token may include: a public key of the cloud user, an authorization granted to the cloud user by the cloud provider, and a public key of the hardware device.

[0026] Establishing the first secure communication may include: receiving a first encryption key that encrypts a first session key, and a first signature of the first encryption key; decrypting the first encryption key using a private key associated with the cloud user to obtain a first session key; and verifying the first signature using the decrypted first session key.

[0027] Establishing the second secure channel may include: receiving a second encryption key that encrypts a second session key, and a second signature of the second encryption key; decrypting the second encryption key using a private key associated with the cloud user to obtain a second session key; and verifying the second signature using the decrypted second session key.

[0028] According to another aspect regarding a cloud user, a non-transitory computer-readable medium includes program instructions stored thereon for causing an apparatus to perform at least the following items: using a first session key as an encryption key, establishing a first secure communication channel with a hardware security module in a hardware device in the cloud; sending an encrypted hardware configuration bitstream through the first secure communication channel, the hardware configuration bitstream being suitable for configuring a functional block in at least one accelerator in an accelerator enclave in the hardware device; establishing a second secure communication channel with the accelerator enclave in the hardware device; sending encrypted input data to be processed using the functional block through the second secure communication channel; and receiving encrypted output data generated by the functional block based on the encrypted input data through the second secure communication channel.

[0029] According to a third aspect, a cloud provider apparatus is disclosed. The apparatus includes components for: receiving a cloud user's certificate and a request for hardware resources from a cloud user; signing the cloud user's certificate; sending the cloud user the certificate signed by the cloud provider; sending to a trusted authority an authorization granted to the cloud user based on the request and the certificate signed by the cloud provider; and redirecting the cloud user to the trusted authority.

[0030] The component of the device according to the third aspect may include a circuit system configured to perform one or more or all functions defined for the device. The device may include at least one processor and at least one memory, the at least one memory storing instructions, which when executed by at least one processor, causes the device to perform one or more or all functions defined for the device.

[0031] According to another aspect regarding a cloud provider, a method includes: receiving a cloud user's certificate and a request for hardware resources from a cloud user; signing the cloud user's certificate; sending the cloud user the certificate signed by the cloud provider; sending to a trusted authority an authorization granted to the cloud user based on the request and the certificate signed by the cloud provider; and redirecting the cloud user to the trusted authority.

[0032] According to another aspect regarding a cloud provider, a non-transitory computer-readable medium includes program instructions stored thereon for causing a device to perform at least the following: receiving a cloud user's certificate and a request for hardware resources from a cloud user; signing the cloud user's certificate; sending the cloud user a certificate signed by the cloud provider; sending an authorization granted to the cloud user based on the request and the certificate signed by the cloud provider to a trusted authority; and redirecting the cloud user to the trusted authority.

[0033] According to a fourth aspect, a device for use by a trusted authority is disclosed. The device includes components for: installing a certificate of a hardware device in a hardware security module of the hardware device, wherein the hardware device is deployed in a cloud managed by a cloud provider; storing the certificate of the hardware device in association with a hardware device identifier; performing mutual authentication with a cloud user; receiving the hardware device identifier from the cloud provider, and authorization granted to the cloud user; sending to the cloud user: an access token including the authorization, and a signature of the access token generated by the trusted authority using a secret (FSS) shared between the trusted authority and the hardware security module of the hardware device.

[0034] The component of the device according to the fourth aspect may include a circuit system configured to perform one or more or all functions defined for the device. The device may include at least one processor and at least one memory, the at least one memory storing instructions, which when executed by at least one processor, causes the device to perform one or more or all functions defined for the device.

[0035] According to another aspect regarding a trusted authority, a method may include: installing a certificate of a hardware device in a hardware security module of the hardware device, wherein the hardware device is deployed in a cloud managed by a cloud provider; storing the certificate of the hardware device in association with a hardware device identifier; performing mutual authentication with a cloud user; receiving the hardware device identifier from the cloud provider, and authorization granted to the cloud user; and sending to the cloud user: an access token including the authorization, and a signature of the access token generated by the trusted authority using a secret shared between the trusted authority and the hardware security module of the hardware device.

[0036] According to another aspect regarding a trusted authority, a non-transitory computer-readable medium includes program instructions stored thereon for causing an apparatus to perform at least the following: installing a certificate of a hardware device in a hardware security module of the hardware device, wherein the hardware device is deployed in a cloud managed by a cloud provider; storing the certificate of the hardware device in association with a hardware device identifier; performing mutual authentication with a cloud user; receiving the hardware device identifier from the cloud provider, and authorization granted to the cloud user; and sending to the cloud user: an access token including the authorization, and a signature of the access token generated by the trusted authority using a secret shared between the trusted authority and the hardware security module of the hardware device. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Example embodiments will become more fully understood from the detailed description given below and the accompanying drawings, which are given by way of illustration only and thus do not limit the present disclosure.

[0038] Figure 1 The architecture of hardware security management in O-RAN and open cloud platform according to an embodiment is illustrated.

[0039] Figure 2 A security framework for using hardware devices deployed in the cloud according to an embodiment is illustrated.

[0040] Figure 3 A flow chart of a method for deploying certificates for hardware devices in the cloud according to an embodiment is shown.

[0041] Figure 4 A flow chart of a method for generating an access token for a hardware device in the cloud according to an embodiment is shown.

[0042] Figure 5 A flow chart of a method for using a target hardware device in a cloud according to an embodiment is shown.

[0043] Figure 6 Illustrated are aspects of a security protocol for using hardware devices in the cloud according to an embodiment.

[0044] Figure 7Illustrated are aspects of a security protocol for using hardware devices deployed in the cloud, according to an embodiment.

[0045] Figure 8 The software / hardware architecture of a hardware device deployed in the cloud according to an embodiment is illustrated.

[0046] Fig. 9 A flow chart of a method for implementing a security protocol according to one or more example embodiments is shown.

[0047] Fig.10 A flow chart of a method for implementing a security protocol according to one or more example embodiments is shown.

[0048] Fig.11 A flow chart of a method for implementing a security protocol according to one or more example embodiments is shown.

[0049] Fig.12 A flow chart of a method for implementing a security protocol according to one or more example embodiments is shown.

[0050] Fig.13 is a block diagram illustrating an exemplary hardware structure of an apparatus according to an example.

[0051] It should be noted that these figures are intended to illustrate various aspects of the apparatus, methods, and structures used in the example embodiments described herein.The use of similar or identical reference numerals in the various drawings is intended to indicate the presence of similar or identical elements or features. DETAILED DESCRIPTION

[0052] Detailed example embodiments are disclosed herein. However, the specific structural and / or functional details disclosed herein are representative only for the purpose of describing the example embodiments and providing a clear understanding of the basic principles. However, these example embodiments can be practiced without these specific details. These example embodiments can be embodied in a variety of alternative forms, with various modifications, and should not be interpreted as being limited to the embodiments described herein. In addition, the drawings and descriptions may have been simplified to illustrate elements and / or aspects related to a clear understanding of the present invention, while for clarity, many other elements that may be well-known in the art or irrelevant to understanding the present invention have been eliminated.

[0053] Security and privacy issues have been identified in existing public cloud environments and workflows. For example, cloud users may require privacy and security when using public cloud solutions. Cloud users may need to protect valuable data and hardware configuration bitstreams while using third-party acceleration resources and environments (for example, hardware configuration bitstreams may include bitstreams for configuring functional blocks in an accelerator of an FPGA and / or data to be processed by an accelerator of a hardware device).

[0054] In this context, a cloud user may be any communication entity (eg, a NIC card, any specific module in the cloud, a user device, another stakeholder, etc.) and will be referred to herein simply as a user or cloud user.

[0055] From the perspective of public cloud users, CPs (cloud providers) may have undesirable privileges over cloud environments and shared resources. Currently, some existing solutions and methods deployed by CPs are considered to be intrusive to cloud users. For example, cloud users must use proprietary methods provided by CPs. These proprietary methods are not open source and cannot be verified or trusted by users.

[0056] For example, a CP may need to verify a cloud user's hardware configuration bitstream to check whether there are malicious and harmful designs targeting its infrastructure and hardware. This verification process does not allow the confidentiality of the hardware configuration bitstream to be protected.

[0057] In fact, in order to use hardware resources like FPGA, CP may require cloud users to disclose the FPGA's accelerator design netlist. In the netlist, the connection of each instantiated block of the FPGA is described. The netlist is encrypted during transmission between the cloud user and the CP. However, the netlist verification is performed on plain text data. CP may reverse engineer the cloud user's netlist and steal proprietary IP. This is harmful to the cloud user's data privacy.

[0058] In addition, the CP deploys a custom FPGA shell to provide users with external memory, features, and custom interfaces for communication purposes. The user function blocks configured inside the accelerator are connected to the CP interface inside the FPGA so that they can establish communication with the hardware resources of the FPGA, send commands, and use the hardware acceleration environment as expected.

[0059] The FPGA shell has a master interface and a slave interface, and the user configures the user function blocks (these user function blocks are sometimes referred to as "user IPs") based on the hardware configuration bitstream. Therefore, the FPGA shell can initiate unauthorized communication with the user function blocks to obtain valuable information (such as IP valuable information). This is possible because the communication with the user / *IP* / function blocks is not authenticated. If the cloud user fails to implement any encryption logic independently of the CP, the CP can intercept the data passing through these interfaces. As a result, the cloud user's privacy of the user function blocks, hardware configuration bitstreams, and input / output data may be compromised.

[0060] Cloud users cannot simply implement cryptographic functionality and protect user data. Embedding any secrets (e.g., cryptographic keys) in the accelerator is unsafe because the cloud provider has methods to obtain plaintext information at various levels (e.g., device reconfiguration, device shell, etc.). Since the CP cannot be trusted, the confidentiality of cloud user data needs to be guaranteed without relying on mechanisms provided by the CP. The cloud provider has privileged access to the deployed hardware. The FPGA shell and interface should be considered as a vulnerability against the user, and security measures appear to be necessary.

[0061] For example, cloud end users should be able to:

[0062] - Protect their data without using any third-party interfaces, software or tools set up by the cloud provider within the hardware resources;

[0063] - Ensure the use of zero-trust network architecture;

[0064] - Protect data confidentiality and create isolation for CP.

[0065] A solution is proposed to ensure isolation between the end user, the CP and the hardware configuration bitstream and / or the user application. The solution will be described and illustrated in the context of a use case in the telecommunication domain.

[0066] In the following, different exemplary embodiments will be described using a radio access architecture based on Long Term Evolution Advanced (LTE Advanced, LTE-A) or New Radio (NR, 5G) as an example of an access architecture to which the exemplary embodiments can be applied, without limiting the exemplary embodiments to such an architecture.

[0067] In general, the embodiments disclosed herein can be used in various radio telecommunication systems, including fifth generation (5G) networks or 6G networks. As disclosed herein, it may involve earlier or later generations of radio communication systems.

[0068] Cloud providers will be a core component of the 5G Open RAN (O-RAN) architecture. 5G is constantly evolving to support new network solutions. O-RAN is one of the largest 5G evolutions, expanding the ecosystem of mobile and RAN players in the 5G network market. Open interfaces between 5G network elements allow multi-vendor interoperability. As a result, telecom operators will build multi-vendor 5G network solutions in different network domains (RAN, core network (CN)).

[0069] To achieve latency and performance constraints for 5G O-RAN networks, hardware accelerators (e.g., using GPUs, Field Programmable Gate Arrays (FPGAs), etc.) are embedded in different O-RAN network elements. Hardware accelerators allow reducing the number of required CPU cores, especially for L1 processing and compute-intensive workloads (AI / ML, cryptographic applications, etc.). Hardware accelerators can use different hardware resources, including FPGAs, ASICs, and GPUs. FPGAs were initially embedded to accelerate AI / ML applications and are a relevant candidate execution platform for O-RAN.

[0070] O-RAN openness enables accelerated innovation compared to on-premises network solutions where the operator owns its own private network. O-RAN can use shared networks, including commercial cloud environments. O-RAN brings new security challenges, which are critical in 5G networks. The O-RAN Security Working Group (or WG11) has been created to ensure the security of the O-RAN system. The O-RAN WG11 security requirements are presented in [2]. O-RAN security threat modeling and remediation analysis are highlighted in [1]. The risk assessment in Table 7-2 from [1] presents the O-RAN risk, impact, severity, and likelihood levels. Several threats are related to the use of hardware accelerators.

[0071] FPGA usage in the context of O-RAN is similar to FPGA cloud computing solutions. FPGAs are used in cloud environment networks, where resources are shared between end users (operators) and evolve over time (through reconfiguration).

[0072] A key issue associated with the use of FPGAs or other hardware resources in a cloud context is the lack of integrity solutions to ensure security.

[0073] It is proposed to provide a solution to provide data protection and confidentiality in an accelerated cloud environment, such as in an O-RAN FPGA accelerated cloud context. For example, for FPGA accelerators in a cloud environment, end users expect security and confidentiality. O-RAN based networks typically access accelerator capabilities through a cloud provider (CP).

[0074] As mentioned before, in this scheme, there are currently security limitations. The CP has access to the data exchanged between the end user and the accelerator. There is no encryption implemented between the hardware accelerator and other entities within the cloud infrastructure. The interface of the hardware accelerator is not encrypted. The application and the hardware accelerator manager are sending and receiving plain text data from the accelerator. This is not specific to O-RAN: in public clouds, data going in and out of hardware accelerators is exposed. The cloud provider deploys, for example, FPGAs by developing its customized software and hardware layers. These layers can include monitoring, management and logging mechanisms, logical hardware shells. The shell implements management and application functions (for example, PCI communication and OpenCL API calls are handled by the shell). Due to the lack of transparency, the whereabouts of the cloud provider are unknown. The cloud end user does not have any mechanism to verify the confidentiality and security of their acceleration environment.

[0075] Figure 1 Figure 1 illustrates an overview of hardware security management in the O-RAN and Open Cloud (i.e., O-Cloud) platforms.

[0076] O-Cloud is an open cloud environment where virtual instances 106 can be deployed: for example, applications (i.e., Apps), virtual network functions (i.e., VNFs), and containerized network functions (i.e., CNFs).

[0077] In O-RAN, trust policies for applications and VNFs are defined by the system manager (i.e., "manager") in the attestation server (i.e., AS) 101. The attestation server 101 may be located in the SMO ((Service Management and Orchestration) 110). Attestations are generated by the AS for each module using the policies described above. Attestations are deployed for various module deployments within the O-Cloud. These attestations describe the authorization and capabilities of each module.

[0078] The management platform 125 exists in the O-Cloud, where the trust agent 102 is deployed. Measurements of the root of trust (i.e., RoT) and the virtual RoT (i.e., vRoT) can be collected periodically. RoT is a form of trust embedded inside the hardware, such as a firmware version, a hash of software, or an imprinted device key. In the O-RAN security requirements, the trust chain starts from the hardware logic in the hardware resources 103 and passes through the virtualization layer 105, while forming a proof chain with the virtualization layer 104 and the App / VNF / CNF layer 106. If one layer of the proof chain is compromised, the entire system is considered untrustworthy and compromised. If the trust chain measurement is invalid when it is verified in the proof server, the RoT is re-established to protect the system. This can protect the O-Cloud from tampering and malicious behavior.

[0079] One disadvantage is the lack of data confidentiality between the low-level hardware resources 103 (e.g., hardware accelerators) and the higher-level layers 104, 105, 106. The communication channel with the hardware resources is not secure. Therefore, the virtualization layer 104 and the virtual machines can obtain information from the hardware accelerators 103 and the virtual resources 105. For example, they can create logs and monitor the ongoing applications / VNFs / CNFs. This can be done without tampering with the trust chain. Therefore, the measurements are not modified and the authentication server 103 does not issue any flags.

[0080] Therefore, there is a security limitation because the data confidentiality of the communication between the low-level hardware resources 103 and other modules cannot be ensured.

[0081] This article discloses a zero-trust end-user solution for FPGA-based cloud architecture in an O-RAN context, which can achieve isolation between end users, cloud providers (CPs), and hardware resources such as hardware accelerators.

[0082] Zero Trust solution or model or process in this article means that the cloud provider, or more generally, the cloud environment does not need to be trusted. Such a zero trust solution ensures minimal exposure to entities to establish a secure acceleration environment. The zero trust model can strengthen the confidentiality and privacy of cloud users. The model provides better security and requires less TTP and exposure of the cloud provider.

[0083] For example, in FPGA accelerated cloud computing, the cloud provider may not be trusted because the cloud provider has physical access to the cloud infrastructure. The CP can deploy malicious tools to monitor cloud users. The cloud provider owns the hardware and the acceleration environment. This grants many privileges to the hardware shared with the cloud user. The cloud provider has tools to destroy the data and confidentiality of the cloud user. Software and solutions deployed in the cloud infrastructure can be used to interfere with the calculations and operations of the cloud user. In FPGA, the cloud user uses the hardware configuration bitstream to configure the (multiple) functional blocks (e.g., logic blocks) of the hardware accelerator.

[0084] Cloud users may need to establish authenticated and encrypted communications for hardware configuration bitstreams deployed within an FPGA acceleration cloud environment without the use of third-party interfaces or software. Cloud users may require input / output data protection and hardware configuration bitstream protection from cloud providers to protect their interests. In order to ensure the security of users and hardware configuration bitstreams deployed within FPGAs, authenticated and encrypted channels are provided. Encryption keys and algorithms are deployed independently of cloud providers to ensure isolation and minimize exposure. In addition, access control rules can be established and enforced to control cloud users' access to target functional blocks in the accelerator. Cloud users are the only entities that can access their functional blocks. Security mechanisms are implemented so that cloud providers do not have the ability to modify rules and interfere with user acceleration sessions.

[0085] Since the hardware resources (e.g., FPGA) are integrated in the cloud environment, we assume that the cloud environment is untrusted. Therefore, any information beyond the hardware accelerator will be encrypted to ensure data confidentiality. In order to protect the encryption key from attacks by the cloud provider, the encryption key can be encrypted using the public key corresponding to the communicating entity.

[0086] In this threat model, the goal of the attacker is to compromise the confidentiality of data processed inside a hardware resource (e.g., FPGA). We assume that the adversary has physical access to the hardware resource (e.g., FPGA) and that any memory to which the data owner has access can be compromised. We assume that the CP and TTP can be malicious. Therefore, the solutions, protocols, and software provided by these entities (except the HSM) can be malicious and need to be protected. For example, any FPGA shell or interface provided by the CP to the user function block can be considered untrusted. We assume that the shell is capable of logging and storing communications and data belonging to the cloud user. Although both the CP and TTP can be considered malicious, the CP and TTP will not cooperate to compromise the cloud user's data. However, the CP is not interested in denial of service (i.e., DoS) attacks and attacks that can damage the CP infrastructure.

[0087] For hardware resources like FPGA, there is no operating system or runtime environment in the FPGA fabric. Therefore, software-based attack vectors are not effective in this case. The cloud provider cannot predict and access the random keys generated in the FPGA because the cloud provider will not have an interface with the element responsible for the secure channel establishment.

[0088] Figure 2 The illustrated authentication and access delegation framework for using a target hardware device deployed in the cloud and describes the software / hardware architecture of the target hardware device (eg, FPGA) 200. The architecture is used to implement several security mechanisms, also referred to herein as security protocols.

[0089] The security protocol disclosed in this article consists of three main phases, which are described in detail below: Deployment Phase A (see Figure 3 ), access generation phase B (see Figure 4 ), and hardware use phase C (see Figure 5 ).

[0090] The authentication and access delegation framework for the present security protocol involves the target hardware device 200 , a cloud provider 250 (eg, a cloud provider's apparatus 250 ), a deployment server 240 of the target hardware device 200 , and a trusted authority (TA) 290 .

[0091] The hardware device 200 includes at least one accelerator 235 integrated into a secure acceleration environment 230, also referred to herein as an accelerator enclave or a secure computing enclave. For an FPGA, the accelerator enclave 230 may be a shielded accelerator enclave, and the hardware device 200 corresponds to an FPGA structure.

[0092] According to one or more example embodiments, the target hardware device 200 further includes a hardware security module (i.e., HSM) 210. The HSM 210 is configured to perform access control enforcement and authentication of a user requesting to use the target hardware device (e.g., FPGA) (block 215). Block 215 may be configured to perform mutual authentication between the hardware device and the cloud user 220. The HSM 210 may be compared to a trusted platform module (i.e., TPM), in which cryptographic functions, random number generation, and various security mechanisms are implemented.

[0093] The hardware device 200 located in the cloud is managed by a software layer included in a host device or system 240, referred to herein as a deployment server 240. The deployment server 240 may include various functions for accessing, using, and managing the hardware device 200 through the cloud, as well as providing virtualization to the upper layers of the cloud.

[0094] The deployment server 240 may host and execute (multiple) user applications 241. Each user application 241 is configured to communicate with a cloud user 220 (e.g., a device 220 of the cloud user). Communication (e.g., data communication) between the user application 241 and the user device 220 is established through a communication port 243 (e.g., an Ethernet port) of the deployment server 240 and using a secure link 260 (e.g., a tunnel 260 (e.g., a TLS (Transport Layer Security) tunnel)). Before establishing the secure link 260, mutual authentication between the cloud user 220 and the deployment server 240 may be performed.

[0095] The communication (e.g., data communication) between the user application 241 and the hardware device is established through the interface 242 (HW / SW ITF, hardware and / or software interface) between the deployment server 240 and the hardware device 200. These interfaces may include hardware and / or software components. These interfaces may include AXI bus or PCIe interface. Although these interfaces are Figure 2 200 , but this is merely a simplified conceptual view: one or more functions and / or components of these interfaces may be included in deployment server 240 and / or hardware device 200 .

[0096] TA ensures the identity of cloud users, establishes access control rules, and grants access to hardware devices (e.g., FPGA fabric) deployed in the cloud. In the proposed security protocol, TA 290 involves different mechanisms and requirements. In fact, after the accelerator is deployed, TA does not need to access the hardware devices deployed in the cloud.

[0097] In addition, both the HSM 210 and the accelerator enclave 230 include key generation modules 211, 231 that use a TRNG (True Random Number Generator) to generate cryptographic keys.

[0098] The encryption keys can be used by the hardware accelerator or HSM without the involvement of the cloud provider 250. A hardware-based protocol independent of the CP is used to create isolation from other cloud users and protect user data within the target hardware device (e.g., FPGA). In fact, the cloud provider 250 owns the hardware, infrastructure, and is responsible for deploying the target hardware device (e.g., FPGA) in the cloud computing environment. The cloud provider 250 deploys a proprietary hardware shell (including interface 242) to ensure communication and interface with the user application 241. This may harm the interests of the cloud user by interfering with the HSM and / or hardware acceleration environment. By generating encryption keys inside the hardware accelerator, optimal security and isolation can be ensured.

[0099] A true random number generator (i.e., TRNG) is a device configured to generate cryptographic keys. A TRNG can be a logic circuit that uses the physical randomness of FPGA semiconductors to generate random outputs. A TRNG cannot intentionally reproduce a specific output because it is unpredictable. A target hardware device (e.g., FPGA) that includes a TRNG does not require any external entropy source for the TRNG. The TRNG can be implemented inside the target hardware device (e.g., FPGA), and the TRNG can work independently without any requirements. Existing TRNG solutions have different characteristics, such as ease of implementation, bandwidth, and logic resource consumption.

[0100] Regarding the generation of session keys, the TRNG is configured to generate completely random keys. An internal control signal can start the key generation process. According to NIST recommendations, the TRNG output should not be used as is for encryption purposes. Instead, NIST recommends using the TRNG key as a seed for a deterministic random bit generator (i.e., DRBG). To this end, the security protocol can include an algorithm for implementing the NIST recommendations. The DRBG recommended by NIST is based on a hash function. According to NIST, a 440-bit TRNG-generated seed is required to generate a 256-bit symmetric encryption key.

[0101] The encryption keys used as session keys (HSK, FSK) and which may be created in accordance with NIST recommendations are protected inside the hardware device using asymmetric encryption (eg, RSA) before sending these encryption keys to the cloud user.

[0102] Additionally, both the HSM 210 and the accelerator enclave 230 include cryptographic blocks 212, 232 for encrypting / decrypting data, generating signatures, and / or verifying signatures using cryptographic keys.

[0103] To provide security for the hardware acceleration environment, TA is responsible for deploying a hardware security module (HSM) for each FPGA. The HSM can be open source because it does not contain any secrets.

[0104] The security protocols disclosed in this paper address the hardware accelerator threats in O-RAN regarding data confidentiality and protection. They mitigate the threat IDs T-HW-01; T-HW-02, T-HW-AAL, TO-RAN-01, TO-RAN-02 in O-RAN Working Group 11 (Security Working Group), as defined in the O-RAN Security Threat Modeling and Remediation Analysis document [1].

[0105] The security protocol will be described in detail in the context of its application to a target hardware device (FPGA), but the protocol is also applicable to other types of target hardware devices deployed in the cloud.

[0106] The security protocol disclosed in this paper implements zero-trust online key generation, zero-trust encrypted channels between cloud users and FPGAs located in the cloud ( Figure 2 In this protocol, asymmetric encryption (eg, RSA, ECC, etc.) may be used.

[0107] The security protocol will refer to Figures 3 to 5 The following encryption keys can be used:

[0108] -TAPubKey: public key of TA 290;

[0109] -TAPrivKey: private key of TA 290;

[0110] -CPPubKey: CP 250 public key;

[0111] -CPPrivKey: private key of CP 250;

[0112] -UserPubKey: public key of user 220;

[0113] -UserPrivKey: private key of user 220;

[0114] -FPGAPubKey: the public key of FPGA 200;

[0115] -FPGAPrivKey: private key of FPGA 200.

[0116] TAPubKey and TAPrivKey are generated by TA outside of the security protocol and used to generate its own certificate. CPPubKey and CPPrivKey are generated by CP outside of the security protocol and used to generate its own certificate.

[0117] UserPubKey and UserPrivKey are generated by the user outside of the security protocol and are used to generate the user's certificate, which will be signed by the CP (in the OAuth2 phase, see step 2, Figure 4 ) and verified by the hardware device (see step 14, Figure 5 ).

[0118] FPGAPubKey and FPGAPrivKey are generated by the TA and used to generate the FPGA certificate, which will be signed by the TA during the deployment phase (see Figure 3 0) and verified by the cloud user (see Figure 5 Step 12).

[0119] FPGA deployment server Figures 3 to 5 In the FPGA, it is identified by “FPGA DS”.

[0120] Figure 3 A flow chart of a method for deploying certificates for a target hardware device (here, FPGA) is shown. The method corresponds to the deployment phase A of the security protocol. The steps of the method are implemented by TA, FPGA DS and HSM, as described below.

[0121] Although the steps are described in a sequential manner, those skilled in the art will appreciate that certain steps may be omitted, combined, performed in a different order, and / or performed in parallel.

[0122] In summary, deployment phase A is performed offline from the other phases of the security protocol. During deployment phase A, TA and the cloud provider perform the following operations:

[0123] -The cloud provider uses the deployment framework to deploy FPGAs in the cloud;

[0124] -The cloud provider can implement a solution to verify the integrity of the HSM inside the FPGA;

[0125] -TA deploys certificates for FPGA;

[0126] -TA deploys HSM on the FPGA structure and generates a shared secret FSS;

[0127] -TA stores the FPGA identifier and FSS for each FPGA deployed in the cloud.

[0128] refer to Figure 3 In step 0, the TA is responsible for the generation and deployment of a certificate for the FPGA device, for example during the initialization of the FPGA. The certificate identifies the FPGA and is generated using a pair of keys FPGAPubKey, FPGAPrivKey generated by the TA. The certificate is sent to the FPGA (i.e., in the hardware device 200) and stored in a trusted memory in the FPGA for future access by the FPGA. The certificate is signed by the TA using its private key TAPrivKey, and anyone connecting to the FPGA can verify this certificate to ensure that a legitimate FPGA approved by the TA is being used.

[0129] exist Figure 3 , the only time that TA communicates with FPGA is from step 0.1 to step 0.4. In step 0.1, the HSM is deployed by TA in the reconfigurable area reserved by the HSM. To this end, the FPGA deployed by CP in the cloud has a communication interface 242, which can be used to send messages from the accelerator to the interface 242 (and vice versa), and to send messages from the HSM to the interface 242 (and vice versa). In addition, the TA requests the HSM to generate a secret FSS (FPGA shared secret) to be shared between the TA and the HSM. In step 0.2, at the request of the TA, the FSS is generated by the HSM using the TRNG of the HSM.

[0130] FSS will be used by the security protocol disclosed in this article. TA will use FSS (see Figure 4 Step 10 in ) signs the user's connection information (i.e., access token AT) to access the FPGA. The HSM is then configured to use the FSS to verify the authenticity and integrity of the connection information (see Figure 5 14 in the previous step).

[0131] After key generation, in step 0.3, FSS is encrypted using TA's public key (i.e., TAPubKey) to generate an encryption key C0=Enc(FSS, TAPubKey), which itself is signed to generate a signature (e.g., HMAC signature) Sig0=HMAC(C0, FSS) used for message integrity and authenticity. Thus, TA can ensure that FSS is not from a malicious entity. The encryption key C0 and signature Sig0 are sent to TA for verification.

[0132] In step 0.4, TA generates a decryption key M0=Dec(C0, TAPrivKey) from the encryption key C0 using the TA private key, and verifies the integrity of the signature Sig0 by verifying HMAC(M0, FSS)=Sig0.

[0133] The TA is configured to store the FPGA identifier, FPGA certificate, and shared secret FSS for each FPGA. These data are stored in association for further use. The TA does not need to store a lot of information about a specific FPGA and communicate with it repeatedly.

[0134] Furthermore, during the access generation phase B of the security protocol, the TA communicates only with the cloud provider and cloud users, not with the FPGA. This allows involving the TA with minimal security risk and ensures low-latency FPGA access during the hardware usage phase C. The processing time of user data is not affected by this framework, which is the main advantage of using FPGAs in cloud computing. Acceleration resources and software resources are independent and do not affect each other's performance. In addition, cloud users can benefit from enhanced isolation of the CP without exposure to the TA. The TA cannot communicate with the FPGA and cannot obtain sensitive data after the deployment phase (e.g., FSS key initialization).

[0135] The HSM can be considered as part of the FPGA shell for cloud computing. Cloud users are able to verify the integrity of the HSM through attestation mechanisms (e.g., verifying the TA signature of the HSM). Unlike the shell, the HSM is either open source, deployed by another trusted entity, or both. This ensures the confidentiality of the data by establishing a trusted and verifiable block in a secure hardware computing environment. The hardware security module is more robust than a software solution because it is much less exposed. Unless the physical hardware interface is explicitly implemented for future use, it is not possible to communicate or interfere with the computation inside the HSM. Compared to software vulnerabilities, hardware-level attacks are more difficult to set up and the severity of the attack has a lesser impact.

[0136] The access generation phase B of the security protocol involves an authorization and access token generation framework that can be implemented by adapting the OAuth2 protocol for FPGA and cloud contexts.

[0137] OAuth 2 is an open standard authorization framework that enables third parties to gain limited access to HTTP services on behalf of resource owners (i.e., cloud providers). Using OAuth2.0 to share cloud-based FPGAs instead of certificates allows authentication of all cloud users of a given hardware acceleration environment in the cloud. It also provides token-based low-latency access to cloud-based FPGAs. In the security framework disclosed in this article, the HSM is responsible for access token validation and access control enforcement for the FPGA fabric to provide isolation between cloud users.

[0138] The access token has three parts: header, payload, and signature. The token header may include metadata about the access token, such as the method and algorithm used for token creation. The payload may include information about the access given to the cloud user. This information may include: token validity period, FPGA ID, user certificate, memory allocation size related to the memory allocated within the accelerator enclave, etc. The signature part of the access token is a message digest or hash of the header and payload using a signature algorithm (e.g., HMAC). As a signing key for the message digest, the encryption key FSS (generated in step 0.2 and shared between the CP and TA) is used to ensure the authenticity of the signature and allow the access token to be bound to the CP.

[0139] Additionally, the HSM provides security mechanisms and token-based operations to ensure confidentiality and integrity of user data. Involving the TA splits CP privileges into cloud deployments. The TA is responsible for HSM and security deployment. Isolation and access control are created using a token-based FPGA access scheme with mutual TLS authentication mechanisms.

[0140] The FPGA accelerator can only be accessed if both the TA and the CP give their authorization (i.e., the access token is signed by the TA and the user certificate is signed by the CP). Therefore, the framework can rely on the TA having an acceptable exposure. The CP cannot access the FPGA because an access token signed by the TA is required. The TA cannot access the FPGA either because a signed certificate from the CP is required, which the TA does not have. The TA and the CP cannot access the FPGA without the knowledge and consent of each other. This is a major improvement for using the TA in the FPGA cloud security framework. Even if the TA is trusted, our security exposure to the CP is given to the TA. In the framework, the TA is used by minimizing exposure to the client to provide a zero-trust cloud FPGA framework.

[0141] Figure 4A flow chart of an access token generation method for a target hardware device (here FPGA) is shown. The method corresponds to the access generation phase B of the security protocol. The steps of the method are implemented by the TA, the cloud provider CP and the user, as described below.

[0142] Although the steps are described in a sequential manner, those skilled in the art will appreciate that certain steps may be omitted, combined, performed in a different order, and / or performed in parallel.

[0143] The deployment phase may be based on the OAuth 2.0 protocol. Another framework or protocol that allows the generation of access tokens for managing access to resources may be used. OAuth 2.0 is here adapted to the hardware devices used in the cloud to provide a practical and secure solution.

[0144] The deployment phase includes mutual authentication of cloud users and access token generation. This allows low-latency token-based access to cloud-based FPGAs. The access token AT is a practical tool for mandatory access control and user authentication.

[0145] The access generation phase B can be summarized as follows:

[0146] - The cloud provider signs the user's certificate (e.g., using its private key);

[0147] -TA generates an access token AT based on the access authorization given by the cloud provider to the functional block in the accelerator enclave;

[0148] - The access token AT is signed by the TA and includes the user's certificate signed by the cloud provider;

[0149] - Mutual TLS authentication occurs between all entities (i.e., between TA and user, between CP and user, and between CP and TA).

[0150] From step 1 to step 3, the cloud user sends a hardware resource request to the CP (step 1) and sends a user certificate to be signed (e.g., an X509 certificate). The CP then signs the user certificate using its private key CPPrivKey and sends the signed user certificate back to the cloud user (step 2).

[0151] Finally, the CP sends (step 3) the authorization granted to the cloud user (eg, authorization list) and the identifier of the hardware device to the TA. The CP sends the cloud user the user's certificate signed by the CP.

[0152] From step 4 to step 7, the user's certificate is checked and registered by the TA (step 4), the user is redirected by the CP (step 5) to the TA, and mutual authentication (e.g., mTLS) occurs (step 6) between the user and the TA. For example, when using mTLS, each entity uses its own certificate (a pair of public and private keys). If mutual authentication is successful, the TA sends (step 7) an authorization code AC to the user.

[0153] In step 8, the user verifies the authorization obtained by the user through the hardware accelerator in the hardware device deployed in the cloud. The user sends the authorization code AC to the TA, and mutual authentication is performed again in step 9. Then, the TA verifies the authorization code AC and generates an access token AT using the authorization given by the CP. The access token includes the UserPublicKey, the authorization, and the FPGA public key. The TA uses the authorization code AC obtained in the deployment phase A (see Figure 3 ) to generate the signature ATsig=HMAC(AT,FSS) of the access token AT using the FSS created in step 0.2 during the authentication process. This ensures the integrity and authenticity of the access token, since the access token AT cannot be generated without the knowledge of the FSS. The access token AT is sent to the user in step 11.

[0154] One aspect of this resource sharing process is the signing of the user certificate by the CP in step 2. The TA is the only entity that can create access tokens, but without a signed user certificate from the CP, the cloud user cannot take advantage of FPGA authentication. Therefore, the connection will be rejected by the FPGA. In addition, the authorization given by the CP is associated with the authorization code generated by the TA. The CP can detect forged authorization codes and revoke access. For these reasons, the TA cannot create tokens for itself or others for malicious FPGA access.

[0155] At this point, the cloud user 220 (eg, the cloud user's device 220) can communicate with the FPGA accelerator. Figure 2 As shown in , the FPGA is connected to a deployment server 240 via an interface 242. To communicate with the FPGA, a cloud user 220 connects to the deployment server 240 (eg, through a secure link 260 over Ethernet).

[0156] Figure 5 A flow chart of a method for using a hardware device (e.g., FPGA) in a cloud is shown. The method corresponds to the hardware usage phase C of the security protocol. The steps of the method are implemented by a cloud user, a deployment server for the hardware device, an HSM in the hardware device, and an accelerator enclave according to any embodiment described herein.

[0157] Although the steps are described in a sequential manner, those skilled in the art will appreciate that some steps may be omitted, combined, performed in a different order, and / or performed in parallel.

[0158] At the first connection to the user's FPGA, FPGA configuration and secure channel establishment are performed. Hardware usage phase C can be summarized as follows:

[0159] - Cloud users need a user certificate signed by CP and an access token AT signed by TA to communicate with FPGA;

[0160] - The HSM checks the access token AT to initialize the user authorization for the FPGA fabric;

[0161] -HSM enforces access control policies for FPGA logic;

[0162] -HSM generates online encryption keys with the cloud user (i.e., FSS) to establish the first secure communication channel CH1 and protect the confidentiality of the hardware configuration bitstream;

[0163] - After configuring the FPGA, the function block configured for the user in the accelerator uses the session key as an encryption key to establish a second secure communication channel CH2 with the cloud user for user data transmission to or from the hardware accelerator.

[0164] Session key generation is implemented inside the hardware device (e.g. FPGA): by the HSM for the first secure communication channel CH1 and by the accelerator enclave for the second secure communication channel CH2. The key generation protocol works independently of any third-party framework to set up a zero-trust encrypted channel (through secure channels CH1, CH2) with external modules or entities. This allows protecting data communications with the hardware accelerator from higher layers (e.g. hypervisor, virtual instances). The encryption key is generated by the TRNG in the FPGA fabric and encrypts the data communication using a specific public key associated with the cloud user requesting the secure channel.

[0165] In the security protocol disclosed in this article, there is no need to store any secrets in the hardware accelerator, nor is there any need to involve any trusted third party in the communication protocol or set up a secure communication channel. Therefore, the security protocol is simple, secure, has low latency, and can be considered zero trust. In addition, the implementation results show low overhead and are suitable for scalable FPGA-based cloud acceleration environments. These mechanisms are suitable for cloud environments where cloud users are unstable. TTP only stores a small amount of information about the hardware devices deployed in the cloud environment and the cloud users who use those devices.

[0166] The security protocol disclosed in this article is based on a zero-trust key generation and secure channel establishment protocol for hardware-based cloud computing. Zero-trust solutions are particularly suitable for multi-user environments such as O-RAN and FPGA acceleration in public clouds.

[0167] See also Figure 5 In step 12, in order to achieve mutual authentication between the cloud user and the hardware device (e.g. using mTLS): the hardware device needs to check whether the cloud user's certificate is signed by the CP, and the cloud user checks whether the FPGA certificate is signed by the TA. If the FPGA certificate is valid, in step 13, the user access token AT is sent by the cloud user to the HSM via the FPGA DS.

[0168] In step 14, mutual authentication between the cloud user and the hardware device is done: the hardware device (eg, block 215 in the HSM) receives the user's certificate and checks whether the cloud user's certificate is signed by the CP.

[0169] If the mutual authentication is successful, the cloud user is authorized to access the hardware device. To this end, in step 14, the cloud user's access token AT is verified in the HSM. First, the integrity of the signature ATsig of the access token AT is verified by calculating HMAC(AT,FSS) and comparing it with ATsig, and the FSS key is used as the signing key. If the token signature and the calculated signature match, the HSM parses the payload of the access token to extract the authorization granted to the cloud user and initializes the cloud user's authorization within the FPGA fabric.

[0170] Then, a first secure communication channel CH1 is established between the cloud user and the HSM. The HSM generates a session key (HSM session key, designated by HSK) (the last part of step 14). HSK can be generated using the same key generation protocol as the FSS in step 0.2.

[0171] In step 15, the HSM uses the public key of the cloud user (i.e., UserPubKey) to encrypt HSK to generate an encryption key C1 = Enc (HSK, UserPubKey), and generates a signature Sig1 of the encryption key C1 (e.g., using HMAC), so that Sig1 = HMAC (C1, HSK). Then, the HSM sends the encryption key C1 together with the signature Sig1 to the cloud user.

[0172] In step 16, the cloud user uses its private key to decrypt the encryption key C1 by calculating M1=Dec(C1, UserPrivKey) and verify the integrity and authenticity of the signature Sig1, for example by calculating HMAC(M1, HSK) and comparing the result with Sig1. If the verification is successful, the HSM and the cloud user now share a secret symmetric encryption key HSK, which is used as the session key. Now, the cloud user and the HSM can securely send encrypted data over the first secure communication channel CH1.

[0173] The session key HSK may be used by the cloud user in step 17 to encrypt the hardware configuration bitstream Bit, and the HSK obtained in step 16 may be used to generate an encrypted hardware configuration bitstream EB=Enc(Bit,HSK) to achieve confidentiality.

[0174] The HSK has been generated inside the HSM using a zero-trust online protocol, and the CP and TA are unaware of such a key. The HSK is encrypted using the cloud user's public key and signed (e.g., message digest or hash), such as using HMAC. Therefore, the HSK cannot be generated or stolen or replaced by another key. This session key HSK is a shared secret between the HSM and the cloud user. The HSM is configured to not retain the hardware configuration bitstream in plain text, and the HSM is configured to be accessible by other modules outside the HSM without the session key.

[0175] In step 17, the cloud user sends the encrypted hardware configuration bitstream EB encrypted using the session key HSK and the encrypted bitstream token (i.e., EBT) to the FPGA. EBT is a token containing the user hardware configuration bitstream and the signature HMAC (EB, HSK) of the hardware configuration bitstream for integrity and authenticity verification, which is generated using the session key HSK.

[0176] A first secure communication channel between the cloud user 220 and the hardware device 200 can be established through the user application 241 hosted in the FPGA DS (more precisely, the cloud user 220 communicates with the user application 241 through a secure link 260, such as a tunnel 260 (e.g., based on TLS)), so that the user application 241 receives an encrypted hardware configuration bit stream EBT from the cloud user 220 and transmits the encrypted hardware configuration bit stream EBT to the HSM in step 18.

[0177] In step 19, the HSM decrypts (e.g., using encryption block 212) the encrypted bitstream EBT using the session key HSK and verifies the signature of the hardware configuration bitstream. If valid, the HSM checks whether the cloud user has the right to reconfigure the FPGA based on the access token AT received in step 14. The user authorization is initialized in step 14 based on the content of the access token AT generated by the TA. If the cloud user is allowed to reconfigure the FPGA, the HSM reconfigures the functional blocks of the accelerator enclave (e.g., shielded enclave in the FPGA fabric) assigned to the cloud user using the internal configuration access port (i.e., ICAP).

[0178] Once the FPGA fabric is reconfigured based on the cloud user's hardware configuration bitstream, a second secure, confidential and encrypted channel CH2 is set up between the cloud user and the functional blocks of the accelerator enclave that the user is authorized to access (see steps 21 to 22).

[0179] To set up this second channel CH2, an online key generation protocol is used to generate another session key, designated as a shielded session key (i.e., SSK) in step 20. The SSK is generated by a TRNG within the accelerator enclave. Thus, the session key SSK is generated within the accelerator enclave (e.g., a shielded enclave of an FPGA fabric) and is independent of any external entity.

[0180] In step 21, the session key SSK is encrypted with the public key of the cloud user to generate an encryption key C2=Enc(SSK, UserPubKey), and a signature of the encryption key C2 is generated, for example, by using HMAC to calculate the signature Sig2=HMAC(C2, SSK). The encryption key C2 and the signature Sig2 are included in the message sent to the cloud user via the FPGA DS to ensure authenticity and integrity.

[0181] In step 22, the cloud user decrypts the encryption key C2 using its private key UserPrivKey and generates a decryption key M2 = Dec(C2, UserPrivKey). The user then verifies the integrity and authenticity of the decryption key M2 by using the signature Sig2, for example by using HMAC and comparing it with HMAC(M2, SSK). If the cloud user verifies and confirms the integrity and authenticity of the SSK, the received session key SSK can be used as a symmetric encryption key between the user functional block in the accelerator and the cloud user to communicate in an encrypted manner over the second secure communication channel CH2. Since the session key SSK is generated independently of the HSM, CP and TA, the cloud user has a private and confidential communication channel CH2 for any other communication and data exchange with the functional blocks in the accelerator configured for the cloud user.

[0182] A second secure communication channel CH2 may be established with a user application 241 hosted in the FPGA DS, such that the user application 241 receives encrypted input data from the cloud user 220 (e.g., from the cloud user's device) via a secure link 260 and transmits the encrypted input data to the accelerator enclave for processing. The encrypted input data is decrypted by the accelerator enclave (e.g., through the encryption block 232) using the session key SSK and processed by the accelerator 235 (e.g., through a functional block configured for the cloud user).

[0183] In response, output data may be generated by the accelerator 235 (e.g., by a functional block configured for the cloud user) based on the input data and encrypted by the accelerator enclave (e.g., by the encryption block 232) using the session key SSK. The accelerator enclave is configured to send the encrypted output data to the user application 241 hosted in the FPGA DS via the second secure communication channel CH2. The user application 241 is configured to forward the encrypted output data to the cloud user 220 (e.g., to the cloud user's device) using the secure link 260. The encrypted output data may be decrypted by the cloud user using the session key SSK.

[0184] The function of the user application 241 is to serve as an interface (or communication relay) between the accelerator and the cloud user to support the establishment of a secure communication channel (CH1, CH2 and secure link 260 through the communication port 243 of the deployment server). Another function of the user application 241 is to execute user-specific software code (for example, in PaaS mode or IaaS mode).

[0185] like Figure 6 As shown in , Phase C of the security protocol with zero-trust encryption key generation may include the following steps between the HSM and the cloud user.

[0186] In the framework proposed above, it is used inside the HSM and inside the accelerator (by a functional block configured for cloud users in the accelerator). The key generation protocol does not require the OAuth 2.0 framework, access tokens, or any other specific framework or environment for cloud-based FPGAs to work. The implementation and logic of the proposal are described below.

[0187] In step 600, the cloud user sends an access token AT and a signature of the access token to the HSM.

[0188] In step 601, the integrity of the access token AT is verified based on the signature.

[0189] In step 602, a session key HSK for a first secure communication channel CH1 is generated using a TRNG.

[0190] In step 603, the session key HSK is encrypted and signed.

[0191] In step 604 , the encrypted session key HSK and its signature are sent to the relevant cloud user 620 .

[0192] The distribution of the user public key (to be used to encrypt HSK and SSK) to the FPGA can be performed by the cloud user 220 through the secure link 260, or the public key can be embedded in the user application 241 and sent to the FPGA via the interface 242.

[0193] The public and private keys of the FPGA are securely generated and deployed by the TA (not the cloud provider). The public and private keys of the FPGA are stored in the hardware device 200 (e.g., in an HSM) to prevent any unnecessary access and establish isolation from the cloud provider.

[0194] In step 604, the encrypted session key HSK is sent along with the signature of the cloud user's encryption key to ensure encryption key integrity. The signature can be calculated using a hash function such as SHA-256 and is calculated within a shielded area of ​​the FPGA structure. For higher security, SHA-384 and SHA-512 algorithms can also be implemented. However, the overhead of hardware resource usage and latency will be higher.

[0195] After receiving the message with the session key HSK and its signature, the cloud user is configured to use its private key to decrypt the encrypted session key received by the FPGA in step 605. The cloud user is then configured to verify the signature of the encrypted key. To verify the session key integrity, the cloud user is configured to implement the same hash algorithm used inside the HSM.

[0196] The integrity verification of the signature and the decryption of the session key are performed without exposing the data and results to the cloud provider. If the verification is performed in the deployment server, the security zone technology of ARM TrustZone or Intel SGX can be used to ensure that the data is protected from attacks by the cloud provider. However, software security zones still have vulnerabilities. Hardware computing is still considered safer due to the lack of a runtime environment, thereby reducing the attack vector. If the verification is performed within a hardware accelerator (such as an FPGA), the data is protected by keeping sensitive information within the FPGA structure without exposing it to external interfaces.

[0197] If the key signature verification succeeds, the HSM and the cloud user have established a zero-trust confidential channel CH1, which can be used to transmit hardware configuration bitstreams.

[0198] Any other communication will be encrypted using symmetric encryption and isolated from the cloud provider.

[0199] Symmetric encryption algorithms (such as AES) can be implemented inside the FPGA to achieve zero-trust confidential encrypted communication. Cloud users are also configured with corresponding AES capabilities to communicate securely with the hardware accelerator. The session key HSK can be renegotiated periodically or on demand to add another layer of security.

[0200] like Figure 7 As shown in , Phase C of the security protocol with zero-trust encryption key generation can include the following steps between the accelerator enclave and the cloud user.

[0201] In step 701, a session key SSK for a second secure communication channel CH2 is generated using a TRNG.

[0202] At the end of step 701, the session key SSK may be stored in the enclave memory. The enclave memory is a type of memory with a strict access control policy. This enclave memory is only written by NIST compliant blocks and read by cryptographic functions. No other blocks may access this enclave memory.

[0203] In step 702, the session key SSK is encrypted and signed.

[0204] In step 703 , the encrypted session key SSK and its signature are sent to the relevant cloud user 620 .

[0205] After receiving the message with the session key SSK and its signature, the cloud user is configured to decrypt the encrypted session key using its private key in step 704. Then, the cloud user is configured to verify the signature of the session key.

[0206] If the key signature verification succeeds, the accelerator enclave and the cloud user have established a zero-trust confidential channel CH2, which can be used to transmit (step 705) encrypted input data to be processed by the accelerator, where the session key SSK is used as the encryption key.

[0207] The session key SSK may be renegotiated periodically, or on demand, to add another layer of security.

[0208] Algorithms that can be used in security protocols include:

[0209] -TRNG, used to generate seeds (step 601);

[0210] - Session key generator in a hardware HSM (such as the NIST recommended implementation)

[0211] ), for generating (step 602) a session key from a seed;

[0212] - A public key encryption algorithm (e.g., RSA, ECC) for encrypting the session key using the cloud user's public key (steps 603, 604, 605) and decrypting the session key using the cloud user's private key

[0213] Encryption key;

[0214] - Message digest function (e.g., HMAC) for key integrity and authenticity (step 605);

[0215] - A symmetric key algorithm (e.g., AES) that uses the session key SSK to communicate securely with the cloud user;

[0216] - Public key sharing mechanism (e.g., embedding or public key sharing).

[0217] These algorithms are implemented by the cloud user independently from the cloud provider to benefit from the security protocols.

[0218] In summary, the security protocol disclosed in this article has the following advantages:

[0219] - Data confidentiality is achieved between hardware devices (e.g. FPGA) located in a multi-user cloud and any user communication entity (e.g. NIC card, any specific module in the cloud, user devices, other types of stakeholders, etc.).

[0220] -The security protocol generates low latency and low overhead, and provides good scalability for accelerated cloud computing using FPGA or other hardware devices.

[0221] -Encryption keys are generated by the hardware device (e.g., FPGA) itself, rather than embedding them within a hardware accelerator.

[0222] - A zero-trust, confidential and encrypted channel is set up between the cloud accelerator and the cloud user,

[0223] No cloud provider involvement is required.

[0224] Figure 8 The software / hardware architecture of a target hardware device (eg, FPGA) 200 deployed in the cloud is shown.

[0225] and Figure 2 In comparison, additional blocks are shown, including:

[0226] a block “token parsing” configured to parse the access token to extract the authorization granted to a functional block in the access accelerator of the user (e.g. the identity of the functional block to which access is granted) and to initialize the user policy based on the authorization; and a block “token validation”;

[0227] - a block “Token verification”, configured to verify the integrity of the access token based on its signature;

[0228] - Block "ICAP" (Internal Configuration Access Port): This is a hardware block that receives a hardware configuration bitstream as input and implements a functional block of an accelerator in a hardware device that is configured based on the hardware configuration bitstream;

[0229] - a block "BS Verification" configured to decrypt the encrypted hardware configuration bitstream and verify the integrity of the hardware configuration bitstream based on the signature of the encrypted hardware configuration before using the hardware configuration bitstream for accelerator configuration via the ICAP block;

[0230] - the block "Policy Storage" is a hardware block that stores policy information needed to perform access control to the accelerator; the Policy Storage is used to store authorizations granted to users;

[0231] - a block "Memory Manager" for receiving the memory authorization contained in the access token (the "Token Parsing" block reads this information); the "Memory Manager" block determines a random memory address and reserves a memory size for a given user (based on the information read from the access token);

[0232] - Block “DDR ITF” (DDR Interface): This is the interface that the accelerator accesses through the HSM to communicate with the FPGA device or RAM memory that may be available on the deployment server; This is the interface used to communicate with the RAM memory.

[0233] In addition, for illustrative purposes, Figure 8 A plurality of function blocks FB1 , FB2 , FB3 , FB4 are shown which can be respectively assigned to a user (usually one function block is assigned to only one user).

[0234] Fig. 9 A flow chart of a method for implementing a security protocol according to one or more example embodiments is shown. The steps of the method may be implemented by a hardware device 200 according to any example described herein.

[0235] The hardware device may include an accelerator enclave 230 and a hardware security module HSM 210 , the HSM including a first TRNG. The accelerator enclave may include a second TRNG and at least one hardware accelerator 235 .

[0236] Although the steps are described in a sequential manner, those skilled in the art will appreciate that some steps may be omitted, combined, performed in a different order, and / or performed in parallel.

[0237] In step 910, the HSM generates a first session key (HSK) using a first TRNG.

[0238] In step 915 , the HSM establishes a first secure communication channel ( CH1 ) with the cloud user using the first session key as an encryption key.

[0239] To establish the first secure communication channel, the HSM may be configured to:

[0240] - encrypting the first session key using a public key associated with the cloud user to generate a first encryption key;

[0241] - generating a first signature of a first encryption key;

[0242] -Sending the first encryption key and the first signature to the cloud user.

[0243] In step 920, the HSM receives an encrypted hardware configuration bitstream through a first secure communication channel.

[0244] In step 925, the HSM decrypts the hardware configuration bitstream.

[0245] In step 930 , the HSM configures the functional blocks in the accelerator based on the hardware configuration bitstream.

[0246] In step 950, the accelerator enclave generates a second session key (SSK) using a second TRNG.

[0247] In step 955, the accelerator enclave establishes a second secure communication channel (CH2) with the cloud user using the second session key as an encryption key.

[0248] To establish a second secure communication channel, the accelerator enclave can be configured to:

[0249] -encrypting the second session key using a public key associated with the cloud user to generate a second encryption key;

[0250] - generating a second signature for a second encryption key;

[0251] - Sending the second encryption key and the second signature to the cloud user.

[0252] In step 960, the accelerator enclave receives the encrypted input data via the second secure communication channel.

[0253] In step 965, the accelerator enclave decrypts the encrypted input data;

[0254] In step 970, the accelerator enclave processes the input data using the function block.

[0255] In step 975, the accelerator enclave transmits the encrypted output data generated by the functional block based on the encrypted input data over the second secure communication channel.

[0256] The HSM can also be configured to perform one or more of the following steps:

[0257] - receiving an encrypted access token defining: authorization granted by the cloud provider to the cloud user for the function block in the accelerator;

[0258] -decrypting the encrypted access token; and

[0259] - Initialize the functional block based on the authorization defined in the access token.

[0260] The hardware device may be configured to perform other steps and / or functions described herein with respect to the hardware device (eg, FPGA).

[0261] Fig.10 A flow chart of a method for implementing a security protocol according to one or more example embodiments is shown. The steps of the method may be implemented by an apparatus 220 used by a cloud user according to any example described herein.

[0262] Although the steps are described in a sequential manner, those skilled in the art will appreciate that some steps may be omitted, combined, performed in a different order, and / or performed in parallel.

[0263] In step 1010, the apparatus 220 uses the first session key as an encryption key to establish a first secure communication channel with a hardware security module in a hardware device in the cloud.

[0264] Establishing the first secure communication may include one or more of the following steps:

[0265] - receiving a first encryption key for encrypting a first session key, and a first signature of the first encryption key;

[0266] - decrypting the first encryption key using a private key associated with the cloud user to obtain a first session key;

[0267] - Using the decrypted first session key, verify the first signature.

[0268] In step 1020, the apparatus 220 transmits an encrypted hardware configuration bitstream through a first secure communication channel, the hardware configuration bitstream being suitable for configuring functional blocks in one or more accelerators in an accelerator enclave in the hardware device;

[0269] In step 1030, the apparatus 220 establishes a second secure communication channel with the accelerator enclave in the hardware device;

[0270] Establishing the second secure communication may include one or more of the following steps:

[0271] - receiving a second encryption key for encrypting a second session key, and a second signature of the second encryption key;

[0272] - decrypting the second encryption key using a private key associated with the cloud user to obtain a second session key;

[0273] - Using the decrypted second session key, verify the second signature.

[0274] In step 1040, the device 220 transmits the encrypted input data to be processed using the function block through the second secure communication channel.

[0275] In step 1050 , the device 220 receives encrypted output data generated by the function block based on the encrypted input data through the second secure communication channel.

[0276] The apparatus 220 may also perform mutual authentication with the hardware device, wherein if the mutual authentication with the hardware device is successful, a first secure communication channel is established.

[0277] The device 220 may also send an encrypted access token to the hardware security module, the access token defining the authorization granted to the cloud user for the functional block in the accelerator.

[0278] The device 220 may also send the cloud user's certificate and the request for the hardware resource to the cloud provider, and receive a certificate signed by the cloud provider;

[0279] Device 220 may also perform mutual authentication with a trusted authority.

[0280] The device 220 may also receive an access token from a trusted authority, and a signature of the access token generated by the trusted authority using a secret (FSS) shared between the trusted authority and the hardware security module of the hardware device. The access token may include a public key of the cloud user, an authorization granted to the cloud user by the cloud provider, and a public key of the hardware device.

[0281] The apparatus 220 for use by the cloud subscriber may be configured to perform the other steps and / or functions described herein for the cloud subscriber 220 .

[0282] Fig.11 A flow chart of a method for implementing a security protocol according to one or more example embodiments is shown. The steps of the method can be implemented by the cloud provider 250 according to any example described herein.

[0283] Although the steps are described in a sequential manner, those skilled in the art will appreciate that some steps may be omitted, combined, performed in a different order, and / or performed in parallel.

[0284] In step 1110 , the device 250 receives a cloud user's credentials and a request for hardware resources from the cloud user.

[0285] In step 1120, device 250 signs the received certificate.

[0286] In step 1130 , the device 250 sends the certificate signed by the cloud provider to the cloud user.

[0287] In step 1140 , the device 250 sends to the trusted authority the authorization granted to the cloud user based on the request and the certificate signed by the cloud provider.

[0288] In step 1150 , the device 250 redirects the cloud user to the trusted authority. The device 250 used by the cloud provider may be configured to perform the other steps and / or functions described herein for the cloud provider 250 .

[0289] Fig.12 A flow chart of a method for implementing a security protocol according to one or more example embodiments is shown. The steps of the method may be implemented by an apparatus 290 used by a trusted authority 290 according to any example described herein.

[0290] Although the steps are described in a sequential manner, those skilled in the art will appreciate that some steps may be omitted, combined, performed in a different order, and / or performed in parallel.

[0291] In step 1210 , the apparatus 290 installs a certificate of the hardware device in a hardware security module of the hardware device, wherein the hardware device is deployed in a cloud managed by a cloud provider.

[0292] In step 1220, the apparatus 290 stores the certificate of the hardware device in association with the hardware device identifier.

[0293] In step 1230, device 290 performs mutual authentication with the cloud user.

[0294] In step 1240, the apparatus 290 receives the hardware device identifier and the authorization granted to the cloud user from the cloud provider.

[0295] In step 1250 , the apparatus 290 sends to the cloud user: an access token including the authorization and a signature of the access token generated by the trusted authority using the secret FSS shared between the trusted authority and the hardware security module of the hardware device.

[0296] The apparatus 290 used by the trusted authority may be configured to perform the other steps and / or functions described herein for the trusted authority 290 .

[0297] Those skilled in the art will appreciate that any functions, engines, block diagrams, flow charts, state transition diagrams, flow charts and / or data structures described herein represent conceptual views of illustrative circuit systems that embody the principles of the present invention. Similarly, it will be appreciated that any flow charts, flow charts, state transition diagrams, pseudocodes, etc. represent various processes.

[0298] Although a flowchart may describe operations as a sequential process, many of the operations may be performed in parallel, concurrently, or simultaneously. In addition, some operations may be omitted, combined, or performed in a different order. A process may terminate when its operations are completed, but may also have additional steps not disclosed in the diagram or description. A process may correspond to a method, function, procedure, subroutine, subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

[0299] Each function, engine, block, step described herein may be implemented in hardware, software, firmware, middleware, microcode, or any suitable combination thereof.

[0300] When implemented in software, firmware, middleware or microcode, the instructions for performing the necessary tasks may be stored in a computer-readable medium, which may be included in a host device or a host system, or may not be included in a host device or a host system. Instructions may be sent and loaded onto a host device or a host system via a computer-readable medium. Instructions are configured to cause a host device or a host system to perform one or more functions disclosed herein. For example, as described above, according to one or more examples, at least one memory may include or store instructions, and at least one memory and instructions may be configured to cause a host device or a host system to perform one or more functions together with at least one processor. In addition, processors, memories and instructions are used as components that provide or cause a host device or a host system to perform one or more functions disclosed herein.

[0301] The host device or host system may be a general purpose computer and / or computing system, a special purpose computer and / or computing system, a programmable processing device and / or system, a machine, etc. The host device or host system may be or include or be part of: a user device, a client device, a mobile phone, a laptop, a computer, a network element, a data server, a network resource controller, a network device, a router, a gateway, a network node, a computer, a cloud-based server, a web server, an application server, a proxy server, etc.

[0302] Fig.13 An example embodiment of an apparatus 9000 is illustrated.

[0303] The device 9000 may be used to perform one or more or all steps of the method disclosed herein. The device 9000 may be a device for performing one or more steps and / or functions disclosed herein for a trusted authority, or for a cloud user, or for a cloud provider.

[0304] As schematically represented in the figure, the device 9000 may include at least one processor 9010 and at least one memory 9020. The device 9000 may include one or more communication interfaces 9040 (e.g., a network interface for accessing a wired / wireless network, including an Ethernet interface, a WIFI interface, etc.) connected to the processor and configured to communicate via (multiple) wired / wireless communication links. The device 9000 may include a user interface 9030 (e.g., a keyboard, a mouse, a display screen, etc.) connected to the processor. The device 9000 may also include one or more media drives 9050 for reading computer-readable storage media (e.g., a digital storage disk 9060 (CD-ROM, DVD, Blu-ray, etc.), a USB key 9080, etc.). The processor 9010 is connected to each of the other components 9020, 9030, 9040, 9050 to control their operation.

[0305] The memory 9020 may include random access memory (RAM), cache memory, non-volatile memory, backup memory (e.g., programmable or flash memory), read-only memory (ROM), hard disk drive (HDD), solid-state drive (SSD), or any combination thereof. The ROM of the memory 9020 may be configured to store one or more computer program codes of an operating system and / or one or more software applications of the storage device 9000, etc. The RAM of the memory 9020 may be used by the processor 9010 to temporarily store data.

[0306] The processor 9010 can be configured to store, read, load, execute and / or otherwise process instructions 9070 stored in computer-readable storage media 9060, 9080 and / or memory 9020, so that when the instructions are executed by the processor, the device 9000 performs one or more or all steps of the method described herein for the relevant device 9000.

[0307] An instruction may correspond to a program instruction or a computer program code. An instruction may include one or more code segments. A code segment may represent any combination of a process, function, subprogram, program, routine, subroutine, module, software package, class or instruction, data structure or program statement. A code segment may be coupled to another code segment or hardware circuit by transmitting and / or receiving information, data, parameter, parameter or memory content. Information, parameters, parameters, data, etc. may be transmitted, forwarded or sent via any suitable technology, including memory sharing, message passing, token passing, network transmission, etc.

[0308] When provided by a processor, the function may be provided by a single dedicated processor, by a single shared processor, or by a plurality of separate processors, some of which may be shared. The term "processor" should not be interpreted as referring only to hardware capable of executing software, and may implicitly include one or more processing circuits, whether programmable or not. A processor or similar processing circuit may correspond to a digital signal processor (DSP), a network processor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a system on a chip (SoC), a central processing unit (CPU), an arithmetic logic unit (ALU), a programmable logic unit (PLU), a processing core, programmable logic, a microprocessor, a controller, a microcontroller, a microcomputer, a quantum processor, any device capable of responding and / or executing instructions in a defined manner and / or according to defined logic. Other hardware (conventional or custom) may also be included. A processor or processing circuit may be configured to execute instructions suitable for causing a host device or a host system to perform one or more functions disclosed herein for a host device or a host system.

[0309] A computer-readable medium or computer-readable storage medium may be any tangible storage medium suitable for storing instructions readable by a computer or processor. More generally, a computer-readable medium may be any storage medium capable of storing and / or containing and / or carrying instructions and / or data. A computer-readable medium may be a non-transitory computer-readable medium. The term "non-transitory" as used herein is a limitation of the medium itself (i.e., tangible, not a signal), not a limitation of data storage persistence (e.g., RAM vs. ROM).

[0310] The computer readable medium may be a portable or fixed storage medium. The computer readable medium may include one or more storage devices, such as permanent mass storage devices, magnetic storage media, optical storage media, digital storage disks (CD-ROM, DVD, Blu-ray, etc.), USB keys or dongles or peripheral devices, and memories suitable for storing instructions readable by a computer or processor.

[0311] A memory suitable for storing computer or processor readable instructions may be, for example, a read-only memory (ROM), a permanent mass storage device such as a disk drive, a hard disk drive (HDD), a solid-state drive (SSD), a memory card, core memory, flash memory, or any combination thereof.

[0312] In the present specification, the wording "component configured to perform one or more functions" or "component for performing one or more functions" may correspond to one or more functional blocks, which include a circuit system suitable for performing or configured to perform (multiple) related functions. The block may perform this function by itself, or may cooperate and / or communicate with other one or more blocks to perform this function. "Component" may correspond to or be implemented as "one or more modules", "one or more devices", "one or more units", etc. The component may include at least one processor and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to cause the device or system to perform (multiple) related functions together with the at least one processor.

[0313] As used in this application, the term "circuitry" may refer to one or more or all of the following:

[0314] (a) hardware circuit implementation only (such as implementation in analog and / or digital circuitry only) and

[0315] (b) a combination of hardware circuitry and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuitry and software / firmware; and (ii) any portion of hardware processor(s) (including digital signal processor(s)), software and memory(s) with software, which work together to enable a device (such as a mobile phone or server) to perform various functions, and

[0316] (c) Hardware circuit(s) and / or processor(s) that require software (e.g., firmware) to operate, such as microprocessor(s), or portions of microprocessor(s), but where the software is not required for operation, the software may not be present.

[0317] This definition of circuitry applies to all uses of the term in this application, including in any claims. As a further example, as used in this application, the term circuitry also encompasses an implementation of only a hardware circuit or processor (or processors), or a portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. For example, and if applicable to a particular claim element, the term circuitry also encompasses a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in a server, cellular network device, or other computing or network device.

[0318] The term circuit system may encompass digital signal processor (DSP) hardware, network processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc. The circuit system may be or include, for example, hardware, programmable logic, a programmable processor that executes software or firmware, and / or any combination thereof (e.g., a processor, a control unit / entity, a controller) to execute instructions or software and control the transmission and reception of signals, and a memory for storing data and / or instructions.

[0319] The circuit system may also make decisions or determinations, generate frames, packets, or messages for transmission, decode received frames or messages for further processing, and other tasks or functions described herein. The circuit system may control the transmission of signals or messages over a radio network, and may control the reception of signals or messages via one or more communication networks, etc.

[0320] Although the terms "first", "second", etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, without departing from the scope of the present disclosure, the first element may be referred to as the second element, and similarly, the second element may be referred to as the first element. As used herein, the term "and / or" includes any and all combinations of one or more associated listed items.

[0321] The terms used herein are for the purpose of describing specific embodiments only and are not intended to be limiting. As used herein, the singular forms "a", "an", and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises", "comprising", "includes", and / or "including" when used herein specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0322] Although aspects of the present disclosure have been particularly shown and described with reference to the above embodiments, it will be appreciated by those skilled in the art that various additional embodiments may be conceived by modifying the disclosed machines, systems, and methods without departing from the scope of the disclosure. It should be understood that such embodiments are within the scope of the present disclosure as determined based on the claims and any equivalents thereof.

[0323] References cited

[0324] [1] O-RAN Working Group 11 (Security Working Group). O-RAN Security Threat Modeling and Remediation Analysis

[0325] [2] O-RAN Working Group 11 (Security Working Group) Security Requirements Specifications v5.00

[0326] List of main abbreviations

[0327] AI

[0328] ASIC Application-Specific Integrated Circuit

[0329] CNF containerized network functions

[0330] CP Cloud Provider

[0331] CPU Central Processing Unit

[0332] DRBG Deterministic Random Bit Generator

[0333] FPGA Field Programmable Gate Array

[0334] GPU Graphics Processing Unit

[0335] L1 Layer 1 (physical layer) of the 5G protocol stack

[0336] ML Machine Learning

[0337] NIC Network Interface Card

[0338] NIST National Institute of Standards and Technology

[0339] O-Cloud Open Cloud

[0340] O-RAN Open Radio Access Network

[0341] RAN Radio Access Network

[0342] TRNG True Random Number Generator

[0343] TTP Trusted Third Party

[0344] VNF Virtual Network Function

Claims

1. A hardware device (200), comprising an accelerator enclave (230) and a hardware security module (210) HSM, wherein the HSM (210) comprises a first true random number generator TRNG (211); the accelerator enclave (230) comprises a second TRNG (231), and at least one accelerator (235); The HSM (210) is configured to: Based on a request from a trusted authority (290), using the first TRNG (211), generating a shared secret FSS; Sending the shared secret FSS to the trusted authority (290); receiving an encrypted access token signed by the trusted authority (290), wherein the access token is signed using the shared secret FSS, the encrypted access token defining: authorization granted by the cloud provider (250) to the cloud user for a functional block in the at least one accelerator (235); decrypting the encrypted access token; Using the shared key FSS, verifying the authenticity and integrity of the access token; Initializing a functional block based on the authorization defined in the access token; receiving a user certificate signed by the cloud provider (250); Using the first TRNG (211), generating a first session key; Using the first session key as an encryption key, establishing a first secure communication channel (CH1) with the cloud user (220); receiving an encrypted hardware configuration bitstream via the first secure communication channel (CH1); decrypting the hardware configuration bitstream; configuring the functional blocks in the at least one accelerator (235) based on the hardware configuration bitstream; The accelerator (235) enclave is configured as: Using the second TRNG (231), generating a second session key; Using the second session key as an encryption key, establishing a second secure communication channel (CH2) with the cloud user (220); receiving encrypted input data via the second secure communication channel (CH2); decrypting the encrypted input data; Using the function block, processing the input data; The encrypted output data generated by the function block based on the encrypted input data is transmitted through the second secure communication channel (CH2).

2. The hardware device (200) according to claim 1, wherein in order to establish the first secure communication channel (CH1), the HSM (210) is configured to: encrypting the first session key using a public key associated with the cloud user (220) to generate a first encryption key; generating a first signature of the first encryption key; The first encryption key and the first signature are sent to the cloud user (220).

3. The hardware device according to claim 1 or 2, wherein in order to establish the second secure communication channel (CH2), the accelerator enclave (230) is configured to: encrypting the second session key using the public key associated with the cloud user (220) to generate a second encryption key; generating a second signature for the second encryption key; The second encryption key and the second signature are sent to the cloud user (220).

4. An apparatus for use by a cloud user (220), the apparatus comprising: - at least one processor; - at least one memory storing instructions which, when executed by the at least one processor, cause the apparatus to perform a method comprising: sending the cloud user's credentials and a request for hardware resources to a cloud provider (250); receiving a certificate signed by the cloud provider (250); performing mutual authentication with a trusted authority (290); receiving an access token from the trusted authority and a signature of the access token generated by the trusted authority (290) using a secret shared between the trusted authority (290) and the hardware security module (210) of the hardware device (200); Sending an encrypted access token to the hardware security module (210), the encrypted access token defining: authorization granted to the cloud user (220) for the functional block in the at least one accelerator (235); Sending the certificate signed by the cloud provider (250) to the hardware security module (210); Based on the access token and the certificate, using the first session key as an encryption key, establishing a first secure communication channel (CH1) with the hardware security module (210) in the hardware device in the cloud; sending, via the first secure communication channel (CH1), an encrypted hardware configuration bitstream, the hardware configuration bitstream being suitable for configuring a functional block in the at least one accelerator in the accelerator enclave (230) in the hardware device (200); establishing a second secure communication channel with the accelerator enclave in the hardware device; sending, via said second secure communication channel (CH2), encrypted input data to be processed using said function block; The encrypted output data generated by the function block based on the encrypted input data is received through the second secure communication channel (CH2).

5. The apparatus according to claim 4, wherein the method further comprises: Mutual authentication is performed with the hardware device (200), wherein if the mutual authentication with the hardware device (200) is successful, the first secure communication channel (CH1) is established.

6. The apparatus according to claim 4 or 5, wherein the access token comprises: The public key of the cloud user (220), the authorization granted to the cloud user (220) by the cloud provider (250), and the public key of the hardware device (200).

7. The apparatus of claim 4 or 5, wherein establishing the first secure communication comprises: receiving a first encryption key for encrypting the first session key and a first signature of the first encryption key; decrypting the first encryption key using a private key associated with the cloud user to obtain the first session key; Using the decrypted first session key, the first signature is verified.

8. The apparatus according to claim 4 or 5, wherein establishing the second secure communication comprises: receiving a second encryption key for encrypting the second session key, and a second signature for the second encryption key; decrypting the second encryption key using a private key associated with the cloud user to obtain the second session key; Using the decrypted second session key, the second signature is verified.

9. A cloud provider device, comprising: - at least one processor; - at least one memory storing instructions which, when executed by the at least one processor, cause the apparatus to perform a method comprising: receiving from a cloud user a credential of the cloud user (220) and a request for hardware resources; signing the certificate of the cloud user (220); sending the certificate signed by the cloud provider (250) to the cloud user (220); sending to a trusted authority (290) an authorization granted to the cloud user (220) based on the request and the certificate signed by the cloud provider (250); The cloud user (220) is redirected to the trusted authority (290).

10. An apparatus for use by a trusted authority (290), the apparatus comprising: - at least one processor; - at least one memory storing instructions which, when executed by the at least one processor, cause the apparatus to perform a method comprising: Sending a request for providing a shared secret FSS to a hardware device (200); Receiving the shared secret FSS from the hardware device (200); Installing a certificate of the hardware device (200) in a hardware security module (210) of the hardware device (200), wherein the hardware device (200) is deployed in a cloud managed by a cloud provider (250); storing the certificate of the hardware device (200) in association with a hardware device identifier; performing mutual authentication with the cloud user (220); receiving the hardware device identifier and authorization granted to the cloud user (220) from the cloud provider (250); Sending to the cloud user (220): an access token including the authorization; and a signature of the access token generated by the trusted authority (290) using the shared secret FSS shared between the trusted authority (290) and the hardware security module (210) of the hardware device (200).

Images