A trusted communication method and system based on an untrusted cloud FPGA

Abstract

The application provides a trusted communication method and system based on an untrusted cloud FPGA, relates to the technical field of secure communication, and specifically includes the following steps: when a remote user rents the use right of a cloud FPGA, the remote user obtains authentication information of a rented area from an FPGA manufacturer, including an authentication code of the rented area, a binary padding bit stream and a hash value calculated after padding; before the remote user communicates with the cloud FPGA, the remote user performs remote authentication based on the authentication information, and performs key agreement in the authentication process to generate a session key; the session key is used to upload private data to the rented area, and the remote user performs trusted communication with the cloud FPGA after remote authentication; the application performs remote authentication and key agreement on the untrusted cloud FPGA, uploads the private data to the authenticated FPGA through the session key obtained after the key agreement, and thus realizes trusted communication, thereby greatly enhancing the security of communication.

Description

Technical Field

[0001] This invention belongs to the field of secure communication technology, and in particular relates to a trusted communication method and system based on an untrusted cloud FPGA. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] With the advent of the big data era, the Internet releases massive amounts of data every moment. In order to extract useful information from this massive amount of data, people have begun to analyze and calculate this data to obtain the results they want. However, if you want to calculate this data, you must consider the cost of hardware and software equipment to ensure the flexibility and reliability of the calculation. Therefore, remote computing services have emerged.

[0004] Remote computing services provide the ability to run applications and process data on remote servers. Users can efficiently process large amounts of data by uploading the data they want to compute to the remote server after paying a certain fee. Although remote computing service providers have taken many measures to protect users' data security and privacy, there are still some attackers who will try to profit from the huge economic interests hidden behind the massive amounts of data through illegal means.

[0005] For example, in a software-as-a-service cloud, everything, including applications and remote user data, is managed by the cloud server. Under this computing model, the internal administrators of the remote server themselves are a threat, as they can have unrestricted access to users' private data. In this case, the internal personnel responsible for managing the remote computing server are untrustworthy. At the same time, malicious internal staff may also implant malicious code into the FPGA's configuration memory before the user uses the FPGA, turning the FPGA into a malicious hardware module.

[0006] Therefore, the untrusted cloud of remote computing service providers in the existing solutions still has vulnerabilities, faces malicious threats, and is difficult to protect users' data security and privacy. Summary of the Invention

[0007] To overcome the shortcomings of the prior art, this invention provides a trusted communication method and system based on an untrusted cloud FPGA. The method performs remote authentication and key negotiation on the untrusted cloud FPGA, and uploads private data to the authenticated FPGA through the session key obtained from the key negotiation, thereby achieving trusted communication and greatly enhancing the security of communication.

[0008] To achieve the above objectives, one or more embodiments of the present invention provide the following technical solutions:

[0009] The first aspect of this invention provides a trusted communication method based on an untrusted cloud FPGA.

[0010] A trusted communication method based on an untrusted cloud FPGA includes:

[0011] When a remote user leases the right to use an FPGA in the cloud, the user obtains the authentication information of the leased area from the FPGA manufacturer, including the authentication code of the leased area, the binary padding bitstream, and the hash value calculated after padding.

[0012] Before communicating with the cloud FPGA, remote users perform remote authentication based on authentication information. During the authentication process, key negotiation is also performed to generate a session key.

[0013] Using session keys, private data is uploaded to the leased area, enabling remote users to communicate reliably with remotely authenticated cloud FPGAs.

[0014] The remote authentication process involves a remote user sending a signed authentication code and a binary padding bitstream to a cloud FPGA. The cloud FPGA determines the leased area based on the authentication code, pads the area with the binary padding bitstream, calculates the hash value after padding, and sends it back to the remote user. The remote user compares the hash value provided by the FPGA manufacturer with the hash value sent back by the cloud FPGA to determine whether the FPGA is trustworthy, thus completing the remote authentication.

[0015] Furthermore, before the FPGA leaves the factory, the FPGA manufacturer divides the reconfigurable dynamic region inside the FPGA into several blocks. Each dynamic region block is physically and logically independent of each other, and each dynamic region block generates its own unique authentication code and binary padding bit stream.

[0016] The remote user's lease of cloud FPGA usage rights involves allocating dynamic region blocks from the divided dynamic regions to the remote user.

[0017] Furthermore, before the FPGA leaves the factory, the FPGA manufacturer will embed a master private key for encryption and decryption authentication inside the FPGA. Each FPGA board will correspond to a different master private key, which will be stored in the security agent SP.

[0018] Furthermore, the remote authentication and key negotiation of the remote user are both implemented through the security agent SP in the cloud FPGA. The remote user verifies the authenticity and integrity of the leased area with the SP, and the SP participates in the key negotiation process during the remote authentication process. After the remote user completes the authentication of the cloud FPGA, it obtains the session key for communication with it. Through this session key, the remote user transmits its local privacy data to the SP. The SP decrypts the privacy data using the session key and transmits the data to the leased area inside the FPGA. After the data enters the partition, the next step of calculation is performed.

[0019] Furthermore, the specific steps of the remote authentication are as follows:

[0020] After a remote user rents the right to use a cloud FPGA using their own ID, they generate their own public-private key pair using the SM2 algorithm and publish their public key to the FPGA manufacturer.

[0021] The security agent SP in the cloud FPGA loads the SP function and installs it in the static area through a secure bitstream loading mechanism; after the SP is installed, the SP automatically loads the master private key embedded in the SP by the FPGA manufacturer.

[0022] Remote users use a digital signature algorithm to sign their own ID and request authentication information for the leased portion from the FPGA manufacturer. To prevent replay attacks, a timestamp needs to be added and sent to the FPGA end together.

[0023] FPGA manufacturers will lease the area D to remote users i Dmac authentication code i Binary stuffed bitstream BBA i The hash value calculated after padding is sent to the remote user for the user to authenticate the correctness and integrity of the cloud FPGA; secondly, the FPGA manufacturer will publish the public key of the master private key embedded on the cloud FPGA to the user.

[0024] The remote user encrypts the signed authentication code Dmac using the SP public key. i and its corresponding BBA i To prevent replay attacks, a timestamp also needs to be added when sending the message to the SP.

[0025] The SP authenticates remote users and decrypts their information using the master private key embedded in the SP, then locates their corresponding leased area D using the authentication code. i BBA (Binary Bit Stream) i Fill the region and calculate its filled Hash′. i value;

[0026] SP encrypts the hash' that is signed and authenticated by the remote user using the remote user's public key. i The value and timestamp are returned to the user.

[0027] Remote users compare the hash value provided by the FPGA manufacturer with the hash sent from the SP. i The value is compared to determine whether the FPGA is trustworthy.

[0028] Furthermore, the specific steps of the key negotiation are as follows:

[0029] Before formally entering the key negotiation process, all public parameters and raw data from the key negotiation process are included in the user's registered ID information, including elliptic curve parameters. The remote user terminal and the cloud FPGA's security agent SP generate random numbers of a certain secure length through a random number generator, namely r. A and r B ;

[0030] A remote user calculates their temporary key value R using a random number rA generated by a random number generator on their own client. A The encrypted message UFq is sent to the cloud FPGA by the user.

[0031] SP uses a random number generator to generate a random number rB, and then performs the same operation as the remote user to obtain its temporary key value R. B When the cloud-based FPGA receives the UFq message, it uses its own master private key to decrypt it and obtain the remote user's temporary key R. A SP gets R A Next, the temporary key is verified, and the shared key K is verified. B The computation and shared key K B The hash value S2 is calculated, and R is added to the ciphertext FKr after using the SM2 digital signature algorithm. B S2 and S2 are sent together to the remote user;

[0032] After receiving the message FKr value, the remote user decrypts the message using their private key and verifies whether it was sent by the cloud FPGA using a digital signature algorithm. When the remote user decrypts and obtains R... B After performing the same operations as the remote user, the shared key K agreed upon in the key exchange protocol is obtained. A And to verify the shared key K A The correctness hash value S1 is used by remote users to authenticate with the S1 sent by the cloud FPGA;

[0033] After the remote user successfully authenticates the cloud FPGA, the remote user further checks whether the hash value S1 obtained after key negotiation is the same as the hash value S2 sent by the cloud FPGA. If they are the same, the secure session key K is then used. AB =K A =K B It has also been completed.

[0034] Furthermore, the binary padding bitstream is generated based on the data stored on the dynamic region block. The region is filled by the binary padding bitstream, and the region is initialized using a secure erasable proof mechanism, thereby achieving the removal of malicious code.

[0035] A second aspect of the present invention provides a trusted communication system based on an untrusted cloud FPGA.

[0036] A trusted communication system based on an untrusted cloud FPGA includes a user leasing module, an authentication negotiation module, and a trusted communication module.

[0037] The user leasing module is configured to: when a remote user leases the right to use a cloud FPGA, obtain the authentication information of the leased area from the FPGA manufacturer, including the authentication code of the leased area, the binary padding bitstream, and the hash value calculated after padding.

[0038] The authentication negotiation module is configured to: before communicating with the cloud FPGA, remote users perform remote authentication based on authentication information, and simultaneously negotiate keys during the authentication process to generate session keys;

[0039] The trusted communication module is configured to: upload private data to the leased area using a session key, and enable trusted communication between remote users and remotely authenticated cloud FPGAs;

[0040] The remote authentication process involves a remote user sending a signed authentication code and a binary padding bitstream to a cloud FPGA. The cloud FPGA determines the leased area based on the authentication code, pads the area with the binary padding bitstream, calculates the hash value after padding, and sends it back to the remote user. The remote user compares the hash value provided by the FPGA manufacturer with the hash value sent back by the cloud FPGA to determine whether the FPGA is trustworthy, thus completing the remote authentication.

[0041] A third aspect of the present invention provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the steps of a trusted communication method based on an untrusted cloud FPGA as described in the first aspect of the present invention.

[0042] The fourth aspect of the present invention provides an electronic device including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of a trusted communication method based on an untrusted cloud FPGA as described in the first aspect of the present invention.

[0043] The above one or more technical solutions have the following beneficial effects:

[0044] To achieve trusted communication of privacy data between remote users and untrusted cloud FPGAs, this invention constructs a secure agent as a trusted computing party in the untrusted cloud FPGA. The secure agent SP is embedded in the FPGA at the factory to complete the authentication and communication process. Through secure remote authentication of malicious cloud FPGAs, a session key is obtained after key negotiation during the authentication process. Finally, trusted communication of privacy data is achieved through this session key.

[0045] This invention completes the key negotiation process during remote authentication, greatly reducing the number of communication rounds when remote users establish secure communication with cloud FPGAs; and it uses the national cryptographic SM2 encryption and decryption algorithm, digital signature algorithm, and key negotiation algorithm to complete the establishment of secure communication, greatly enhancing the security of secure communication.

[0046] This invention designs an FPGA hardware framework and uses a secure erasable proof mechanism to verify the trustworthiness of the FPGA's built-in modules, completely preventing malicious internal personnel or previous tenants from performing a series of malicious operations on the FPGA's internal components.

[0047] In this invention, after key negotiation, remote users communicate with a security agent of the cloud FPGA using a symmetric session key. The security agent SP has exclusive access to the user's leased area, and private data or applications installed in the leased area communicate with the remote user only through the SP in an encrypted manner. Because the session key K after key negotiation is secure, remote users can also perform remote calculations using the cloud FPGA.

[0048] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0049] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0050] Figure 1 This is a flowchart of the method in the first embodiment.

[0051] Figure 2This is a diagram showing the relationship between the FPGA manufacturer, remote user, and cloud FPGA in the first embodiment.

[0052] Figure 3 This is a timing diagram for remote authentication and key negotiation in the first embodiment. Detailed Implementation

[0053] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0054] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0055] Existing research indicates that the way to protect data from insider attacks is to build a Trusted Execution Environment (TEE). Currently, TEEs are mainly used on CPUs, such as Intel's SGX. However, CPUs are not capable of performing data-intensive computations, so CPUs with TEEs struggle to handle highly parallel workloads.

[0056] Hardware devices suitable for highly parallel computing include GPUs, FPGAs, and ASICs. The biggest problem with GPUs is their high power consumption; even mid-performance GPUs typically consume over 200W. FPGAs, on the other hand, have significant advantages in both performance and power consumption. FPGAs feature efficient pipelined parallel computing, allowing them to process multiple tasks simultaneously in a pipelined manner when handling small amounts of data. Therefore, their computational latency is far lower than that of GPUs, and their flexibility compared to ASICs is undeniable. Thus, implementing privacy-preserving machine learning on cloud-based FPGA hardware is a crucial area, both in terms of security and performance.

[0057] Definitions:

[0058] Partial Reconfiguration: Partial reconfiguration is a feature that allows for the reconfiguration of specific logic resources within an FPGA at runtime, without requiring a complete reconfiguration of the entire chip. This enables designers to dynamically modify or update the circuitry functionality of specific areas without halting the entire system. Partial reconfiguration divides the FPGA's internal structure into static and dynamic regions. Static regions typically refer to fixed areas within the FPGA whose logic is determined during FPGA design and cannot be reconfigured at runtime. Dynamic regions, on the other hand, allow for changes to a portion of the device while other parts of the FPGA are still functioning normally. Each dynamic region contains a set of logic resources and associated interconnects, and can be reconfigured individually. The connection paths between reconfigured regions remain unchanged, thus enabling the reconfiguration of a specific region. Therefore, because the functionality of dynamic regions can be modified and upgraded as needed, the dynamic regions of a cloud-based FPGA can be made available to remote users.

[0059] Secure Erase Proof Mechanism: The Secure Erase Proof mechanism for FPGAs is a mechanism to protect sensitive information in FPGAs. It ensures that the original configuration bitstream or sensitive data cannot be recovered after the FPGA chip has been erased. When an FPGA chip needs to be destroyed or reconfigured, conventional erasure operations cannot completely guarantee data security. This is because, in some cases, even after an erasure operation is performed, it is still possible to recover the original configuration bitstream or sensitive data through physical analysis or other technical means. To address this issue, the Secure Erase Proof mechanism was introduced. This mechanism involves adding additional hardware or software functionality to the FPGA chip to ensure that not only is the configuration bitstream deleted during the erasure process, but it can also be proven that it has been securely erased. Through the Secure Erase Proof mechanism, higher data security and protection can be provided, ensuring that sensitive information cannot be recovered or illegally obtained.

[0060] Secure Bitstream Loading Mechanism: The secure bitstream loading mechanism for FPGAs is a mechanism to protect the FPGA configuration bitstream from unauthorized access and tampering. In an FPGA, the configuration bitstream contains information describing logic and interconnect resources, determining the FPGA's functionality and behavior. Due to the importance of the configuration bitstream, ensuring its integrity and security is crucial to preventing malicious attacks and unauthorized access. The secure bitstream loading mechanism enables a secure boot process, ensuring that only configuration bitstreams from trusted sources are loaded into the FPGA. This prevents malicious attackers from performing unauthorized operations by replacing the configuration bitstream.

[0061] Example 1

[0062] In one or more embodiments, a trusted communication method based on an untrusted cloud FPGA is disclosed, such as... Figure 1 As shown, it includes the following steps:

[0063] Step S1: When a remote user rents the right to use an FPGA in the cloud, the user obtains the authentication information of the rented area from the FPGA manufacturer, including the authentication code of the rented area, the binary padding bitstream, and the hash value calculated after padding.

[0064] Step S2: Before communicating with the cloud FPGA, the remote user performs remote authentication based on the authentication information. During the authentication process, key negotiation is also performed to generate a session key.

[0065] Step S3: Upload private data to the rental area using the session key, enabling trusted communication between the remote user and the remotely authenticated cloud FPGA;

[0066] The remote authentication process involves a remote user sending a signed authentication code and a binary padding bitstream to a cloud FPGA. The cloud FPGA determines the leased area based on the authentication code, pads the area with the binary padding bitstream, calculates the hash value after padding, and sends it back to the remote user. The remote user compares the hash value provided by the FPGA manufacturer with the hash value sent back by the cloud FPGA to determine whether the FPGA is trustworthy, thus completing the remote authentication.

[0067] The following is a detailed description of the implementation process of a trusted communication method based on an untrusted cloud FPGA in this embodiment, involving three parties: the FPGA manufacturer, the remote user, and the cloud FPGA. The specific relationships are as follows: Figure 2 As shown.

[0068] To address the threat posed by internal administrators of remote computing service providers, this embodiment uses a cloud-based FPGA as a trusted execution environment. Only authorized users can authenticate with the cloud FPGA and obtain a session key to send encrypted data to the FPGA and then use its resources for computation after decryption. First, a secure authentication protocol is designed, allowing authorized remote users to remotely authenticate the cloud FPGA. Second, a novel FPGA architecture is provided, and a secure erasable proof mechanism ensures the trustworthiness of the FPGA's built-in partitioning modules. Finally, a secure session key is established through key negotiation between the remote user and the cloud FPGA. This session key ensures that the remote user securely loads the privacy-preserving computation data bitstream onto the FPGA.

[0069] For the security authentication protocol designed in this embodiment, a secure proxy (SP) is designed on the cloud FPGA. The SP has an internal SM2 national cryptographic algorithm module to communicate securely with authorized remote users through encryption and decryption. Through the interaction of this authentication protocol, remote users can verify the authenticity and integrity of the leased FPGA area with the SP. In addition, the SP also participates in the session key negotiation process during the authentication process with the remote user, which greatly reduces the amount of communication during the interaction. After the remote user completes the authentication of the cloud FPGA, it will also obtain a session key for communication. With this session key, the remote user can securely transmit its local privacy computing data to the SP. The SP decrypts the privacy computing data using the session key and transmits the data to the user's leased partition inside the FPGA. After the data enters the partition, the next step of computation is performed.

[0070] This embodiment assumes that the internal staff of the cloud service provider are untrustworthy, and that the built-in modules of the FPGA may also be untrustworthy due to malicious code or applications left behind by internal staff or previous tenants. Therefore, this embodiment proposes a novel FPGA architecture that allows remote users to verify the trustworthiness of the FPGA partitions they lease. Regarding the internal structure of the cloud FPGA, this embodiment employs a partial reconfiguration mechanism. First, the static area of ​​the FPGA is set small enough to only accommodate the security agent SP described above. The remaining portion is the dynamic reconfigurable area of ​​the FPGA. By setting the static area of ​​the FPGA to only accommodate the running SP, malicious personnel are prevented from loading untrusted bitstreams into the static area, thus affecting the secure operation of the FPGA. All messages in the dynamic area of ​​the FPGA are encrypted and transmitted to the remote user through the SP. Therefore, the SP has exclusive access to each partition of the dynamic area, and no communication can occur between partitions.

[0071] This embodiment assumes only that the FPGA manufacturer is trustworthy. The FPGA manufacturer divides the reconfigurable dynamic region into several blocks at the factory. Each dynamic partition is physically and logically independent. During independent partitioning, a unique authentication code (DMAC) is generated for each block, and a corresponding Binary Bitstream Authentication (BBA) is generated based on the size of each dynamic region. A secure, erasable proof mechanism ensures the trustworthiness of the FPGA's built-in modules. This bitstream can completely initialize its corresponding dynamic region, and malicious code can be removed by overwriting that region. Each dynamic region can be leased by a remote user and supports multiple users sharing it. The cloud only needs to set a price based on the amount of computing resources and lease the FPGA dynamic blocks to remote users. The FPGA stores the region authentication code (DMAC) and the BBA in the manufacturer's server. Only authorized users can access this information and use it to authenticate the FPGA in the cloud. Simultaneously, the FPGA manufacturer also stores the DMAC of each dynamic region in the SP (Service Provider). The SP uses the DMAC to identify the region leased by the remote user. Secondly, before an FPGA leaves the factory, a master private key for encryption and decryption authentication is embedded inside the FPGA. Each FPGA board corresponds to a different master private key, which is the key to this protocol. The master private key is stored in the security agent SP. As long as the SP can be securely loaded, the master private key is secure. The master private key never leaves the SP, and the SP has exclusive access to the master private key. The public key corresponding to each master private key is also stored in the FPGA manufacturer's server. Only authorized users can obtain the public key.

[0072] To prevent malicious access or unauthorized modification of the bitstream loaded by the SP (Service Provider), the SP bitstream is loaded into the FPGA's static area through a secure bitstream loading mechanism. This mechanism stores the SP bitstream in encrypted form in non-volatile memory. The secure bitstream is loaded when the FPGA starts up; once loaded, it covers the entire static area. It's important to note that remote users only communicate with the SP in encrypted form. Furthermore, the SP has exclusive access to any data or programs loaded in the dynamic area leased by the remote user. Data in the dynamic area can only be communicated to the remote user through the SP in encrypted form.

[0073] In summary, the security proxy (SP) for the FPGA in the cloud provides remote verification of the FPGA's authenticity and integrity, and enables secure communication between the remote user and the FPGA. It's important to note that this solution relies on the FPGA manufacturer's trust. Based on this trust, the FPGA manufacturer securely transmits the DMAC (Digital Identity Authentication Code) of the leased area to the remote user. i BBA and the hash calculated after BBA is filled. i Send it to the remote user so that the remote user can complete a secure remote authentication.

[0074] The cryptographic scheme in this embodiment uses the Chinese national cryptographic algorithm SM2. Both the public and private key pairs generated by the user and those embedded within the FPGA manufacturer's SP use the SM2 algorithm to generate keys. Furthermore, the digital signature in the remote authentication process, and the session key negotiation between the remote user and the cloud FPGA, also utilize the digital signature algorithm and key negotiation protocol within the SM2 algorithm.

[0075] This embodiment is mainly divided into two parts: remote authentication and key negotiation. The remote authentication part primarily involves communication between the remote user, the FPGA manufacturer, and the cloud FPGA to achieve the remote authentication process. The key negotiation part mainly involves negotiation between the remote user and the cloud FPGA. This embodiment suggests that key negotiation can be performed directly during the remote authentication process, thus significantly reducing the amount of communication required in the initial preparation work. If the remote authentication process between the remote user and the cloud FPGA fails, the user can directly terminate communication with the FPGA. If authentication is successful, the user can use the negotiated key to securely communicate directly with the cloud FPGA. After the remote authentication and key negotiation phases are completed, the FPGA can execute the specific application sent by the remote user.

[0076] Figure 3 This is a timing diagram for remote authentication and key negotiation. Steps 1-① to 1-⑧ represent the eight steps in the remote authentication process, and steps 2-① to 2-④ represent the four steps in the key negotiation process. The dashed line in the diagram indicates the end of communication with the FPGA manufacturer and the formal start of remote authentication and key negotiation.

[0077] like Figure 3 As shown, the specific process of remote authentication is as follows:

[0078] 1. After registering and purchasing the right to use the cloud FPGA with their own ID, remote users generate their own public-private key pair using the SM2 algorithm and publish their public key to the FPGA manufacturer.

[0079] 2. The security agent SP (hereinafter referred to as SP) in the cloud FPGA loads the SP functionality and installs it in the static area through a secure bitstream loading mechanism. After the SP is installed, the SP automatically loads the master private key embedded in the SP by the FPGA manufacturer.

[0080] 3. Remote users use a digital signature algorithm to sign their own ID information and request authentication information for the leased portion from the FPGA manufacturer. To prevent replay attacks, a timestamp needs to be added and sent to the FPGA side.

[0081] 4. FPGA manufacturers will lease the user's area D i Dmac authentication code i Binary stuffed bitstream BBA i The hash value calculated after padding is sent to the user's end for authentication of the correctness and integrity of the cloud FPGA. Secondly, the FPGA manufacturer will disclose the public key of the master private key embedded in the cloud FPGA to the user.

[0082] 5. The user encrypts the signed and authenticated DMAC using the SP public key. i and its corresponding BBA i When sending to the SP, a timestamp also needs to be added to prevent replay attacks.

[0083] 6. The SP authenticates the user and decrypts the user's information using the master private key embedded in the SP, then locates the corresponding dynamic module D through a security proxy. i The code will be filled in BBA. i Fill the region and calculate its filled Hash′. i value.

[0084] 7. SP encrypts the hash' that it has signed and authenticated using the user's public key. i The value and timestamp are returned to the user.

[0085] 8. The user compares the hash value provided by the FPGA manufacturer with the hash sent by the SP. i The value is compared to determine whether the FPGA is trustworthy.

[0086] The above steps are described in detail below:

[0087] In step 1, after renting the right to use the cloud FPGA, the user obtains their own user ID information. The user then uses the SM2 key generation algorithm (a national cryptographic standard) on their PC to generate their own public-private key pair (UK). Priv UK Pub ), and give your public key UK Pub This information is released to FPGA manufacturers and security agents (SPs) within cloud-based FPGAs.

[0088] In step 2, the SP loads its functionality and installs it in the static area via a secure bitstream loading mechanism. The SP is stored in encrypted form in the FPGA's non-volatile memory when the FPGA is not powered on. Once the FPGA is powered on, the SP is loaded, ensuring that even if a malicious user attacks the SP at this time, they cannot compromise the privacy data within the FPGA. After installation, the SP automatically loads the master private key FK embedded in the SP by the FPGA manufacturer. Priv It's important to note that FKpriv in the SP never leaves the SP; the SP only communicates with authorized users in encrypted form.

[0089] In step 3, the user signs the lease using the SM2 digital signature algorithm, along with the timestamp (Time) used to prevent replay attacks. i Send to the FPGA manufacturer, i.e., UMq = Sign(ID|Time) i In order to request D. i Authentication information.

[0090] In step 4, the FPGA manufacturer authenticates user information and obtains the dynamic region D leased by the user through the user ID information. i Because the FPGA is designed with the authentication code Dmac for each dynamic region according to the cloud provider's requirements at the factory, and generates a padding code BBA and its padded hash to verify the integrity and security of each dynamic region, when the FPGA manufacturer receives the request information, the FPGA manufacturer will use the user's leased region Dmac... i Dmac authentication code i Binary stuffed bitstream BBA i and its corresponding hash i In addition to sending the value to the user's terminal, the FPGA manufacturer also needs to disclose to the user the public key FK of the master private key embedded on the cloud FPGA. Pub Users need this to complete remote authentication of the cloud-based FPGA. That is, MU r =UK Pub (Dmac i BBA i Hash i Time i )+FK Pub Therefore, region D in the FPGA is... i The authentication information is sent to the user's client. Similarly, only the user's UK... Priv If the FPGA is not leaked, malicious users will not be able to obtain its critical information.

[0091] In step 5, after obtaining the authentication information of the Di region in the authentication cloud FPGA, the user uses the public key FK sent by the FPGA manufacturer. Pub Encryption D i The authentication information, namely: UFq=FK Pub (Sign(ID)|Dmac i BBA i Time i The Sign(ID) field represents the user signing their ID information using a digital signature algorithm to prove that it was indeed sent by the real user, and a timestamp (Time) is also added. i To prevent replay attacks, the encrypted information UFq is sent to the security agent SP on the cloud FPGA. This is because the SP generates the private key Fk. Priv It will not leave the SP, so as long as the private key is not leaked, the above information is safe.

[0092] In step 6, once the SP obtains the information UFq, it will use its own master private key Fk. Priv Decrypt the message. When SP obtains the Dmac... i After verifying the information, a table is created within the SP to store the user information ID and DMAC. i This is then linked to the session keys that will be generated later, as shown in the figure. Afterwards, the SP will fill in the proof code BBA. i Load to D i The corresponding region, and its hash value Hash′ is calculated after filling. i Finally, the hash is stored in the table that was just created.

[0093] In step 7, SP also uses a digital signature algorithm to transfer the Hash′. i The signature is performed and encrypted using the remote user's public key, then returned to the remote user, i.e.: FKr = UK Pub (Sign(Hash′ i Time i SP uses a digital signature algorithm to sign in order to ensure that the sender is a real cloud FPGA, and adds a timestamp to prevent replay attacks.

[0094] In step 8, the hash provided by the FPGA manufacturer is calculated and compared. i The value is the Hash sent from the SP. i Whether the values ​​are the same, i.e., Hash i ==Hash′ i The system checks whether the hash values ​​are true or false to determine if the FPGA is trustworthy. If the two hash values ​​are the same, the remote user can confirm that the cloud FPGA is the area they leased; otherwise, it is not.

[0095] This concludes the remote authentication section.

[0096] like Figure 3 As shown, the specific process of key negotiation is as follows:

[0097] The other part involves secure communication between the remote user and the cloud FPGA, which can only occur after a session key is established. This embodiment uses key negotiation in the national cryptographic standard SM2 to establish the session key. In this embodiment, the key negotiation process is assumed to occur during the remote authentication process; therefore, the key negotiation process is considered to begin from step 5 above and end at step 8 above.

[0098] The detailed process is as follows:

[0099] Before formally entering the key negotiation process, all public parameters and raw data occurring during the key negotiation process are contained in the user's registered ID information, including elliptic curve parameters, z... A , z B d A d B P A P B Both the remote user terminal and the security agent SP of the cloud FPGA will generate random numbers of a certain secure length using a random number generator, namely r. A and r B .

[0100] In step 5 above, to simultaneously implement the remote proof and key negotiation process, the remote user uses a random number generator to generate a random number r on their client. A Calculate its temporary key value R A That is: R A =[r A G = (x1, y1). Then, in R... A Extract the field element x1 from the data, and then extract... Convert the data type of x1 to an integer. Finally, calculate... This is for use in subsequent calculations. Users generate their own temporary key value R on their client machines. A The user sends an encrypted message (UFq) to the cloud FPGA. The encrypted UFq message can prevent attacks from malicious individuals when communicating in an insecure channel, and the digital signature algorithm can prevent man-in-the-middle attacks in this process.

[0101] In step 6 above, the SP side uses a random number generator to generate a random number r. B Then, perform the same operation as on the remote user terminal to obtain its temporary key value R. BThe field element x2 is calculated to obtain t. B When the cloud-based FPGA receives the UFq message, it uses its own master private key to decrypt it and obtain the remote user's temporary key R. A SP gets R A Then, the following operations are performed: First, in the SM2 algorithm module, the temporary key R is first... A Verify whether it satisfies the equation of an ellipse. Next, take R... A x1 in the equation, and calculate... Then, using the previously calculated t B And what I just received Calculate the points of the elliptic curve Then, the shared key K agreed upon in the key exchange protocol is calculated using the key derivation function KDF(). B That is: K B =KDF(x v |y v |z A |z B (klen). Finally, to verify the shared key K B To verify the correctness of the hash value S2, it is used for remote user authentication. In step 6 described above, SP will establish a one-to-one correspondence table, and this calculation will also share the key K. B The hash value S2 is stored in the table corresponding to the user ID.

[0102] In step 7 above, SP calculates Hash′. i Afterwards, due to the temporary key value R previously calculated by SP... B And the hash value S2. After using the SM2 digital signature algorithm, add R to the ciphertext FKr. B S2 and S2 are sent together to the remote user terminal, i.e.: FKr = UK Pub (Sign(Hash′ i Time i |R B |S2).

[0103] In step 8 above, after receiving the message FKr value, the user decrypts the message using their private key and verifies its authenticity using a digital signature algorithm to prevent man-in-the-middle attacks. When the remote user decrypts and obtains R... B After performing the same operations as the remote user, the shared key K agreed upon in the key exchange protocol is obtained. A And to verify the shared key K A The correctness hash value S1 is used by remote users to authenticate with the S1 sent by the cloud FPGA.

[0104] Finally, after the remote user's remote authentication on the cloud FPGA is successful, i.e., Hash... i ==Hash′ i Then, the remote user further determines whether the hash value S1 obtained after key negotiation is the same as the hash value S2 sent by the cloud FPGA. If they are the same, the secure session key K is then... AB =K A =K B It has also been completed.

[0105] At this point, remote authentication and session key establishment between the remote user and the cloud FPGA have been successfully achieved.

[0106] Because FPGAs have significant advantages in both performance and power consumption, and because they possess parallel processing capabilities, they can execute multiple operations or tasks simultaneously. This is highly advantageous for intensive computation and data processing, such as encryption, decryption, and hash function operations in privacy-preserving computing, and intensive computational tasks like matrix operations and convolution operations in machine learning. When a remote user wants to use the computing resources of a cloud FPGA to compute privacy-preserving machine learning data, the remote user authenticates the authenticity and security of the cloud FPGA through the eight steps mentioned above, and establishes a negotiation key by supplementing the above eight steps. After the remote user authenticates the cloud FPGA and confirms the negotiation key, the remote user uses the negotiation key K... AB The remote user transmits their privacy-protected data. The remote user encrypts their privacy-protected data using this session key and sends it to the security agent SP on the FPGA. The SP decrypts the privacy data using the confirmed negotiated key K and proceeds to the next step.

[0107] By designing the framework of this embodiment, all messages are transmitted in encrypted form, and adding timestamps effectively prevents man-in-the-middle attacks. Using the Chinese national cryptographic SM2 key negotiation algorithm, and performing key negotiation in an encrypted manner, only the remote user and the cloud FPGA security agent ultimately obtain the negotiated key K. AB Therefore, the opponent is also unable to extract K. AB However, privacy data is being acquired. Since previous tenants or malicious adversaries may have left malicious code or programs inside the FPGA after their last lease of the cloud FPGA area, turning it into a malicious module, this embodiment uses a secure erasure proof mechanism to remove the filling bitstream BBA. iFilling the leased area and calculating hash values ​​for verification can effectively remove residual malicious bitstreams. Finally, malicious attackers may also inject faults or launch side-channel attacks on the FPGA itself. We believe cloud service providers should protect their cloud-based FPGAs against such attacks, but these attacks are not within the scope of this embodiment. For remote users, if they cannot securely protect their own private data, they can use a secure and trusted execution environment such as SGX for CPUs to communicate with the cloud-based FPGA service provider.

[0108] Example 2

[0109] In one or more embodiments, a trusted communication system based on an untrusted cloud FPGA is disclosed, including a user leasing module, an authentication negotiation module, and a trusted communication module:

[0110] The user leasing module is configured to: when a remote user leases the right to use a cloud FPGA, obtain the authentication information of the leased area from the FPGA manufacturer, including the authentication code of the leased area, the binary padding bitstream, and the hash value calculated after padding.

[0111] The authentication negotiation module is configured to: before communicating with the cloud FPGA, remote users perform remote authentication based on authentication information, and simultaneously negotiate keys during the authentication process to generate session keys;

[0112] The trusted communication module is configured to: upload private data to the leased area using a session key, and enable trusted communication between remote users and remotely authenticated cloud FPGAs;

[0113] The remote authentication process involves a remote user sending a signed authentication code and a binary padding bitstream to a cloud FPGA. The cloud FPGA determines the leased area based on the authentication code, pads the area with the binary padding bitstream, calculates the hash value after padding, and sends it back to the remote user. The remote user compares the hash value provided by the FPGA manufacturer with the hash value sent back by the cloud FPGA to determine whether the FPGA is trustworthy, thus completing the remote authentication.

[0114] Example 3

[0115] The purpose of this embodiment is to provide a computer-readable storage medium.

[0116] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of a trusted communication method based on an untrusted cloud FPGA as described in Embodiment 1 of this disclosure.

[0117] Example 4

[0118] The purpose of this embodiment is to provide an electronic device.

[0119] An electronic device includes a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of a trusted communication method based on an untrusted cloud FPGA as described in Embodiment 1 of this disclosure.

[0120] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A trusted communication method based on an untrusted cloud FPGA, characterized in that, include: When a remote user leases the right to use an FPGA in the cloud, the user obtains the authentication information of the leased area from the FPGA manufacturer, including the authentication code of the leased area, the binary stuffed bitstream, and the hash value calculated after stuffing. Before communicating with the cloud FPGA, remote users perform remote authentication based on authentication information. During the authentication process, key negotiation is also performed to generate a session key. Using session keys, private data is uploaded to the leased area, enabling remote users to communicate reliably with remotely authenticated cloud FPGAs. The remote authentication process involves a remote user sending a signed authentication code and a binary padding bitstream to a cloud FPGA. The cloud FPGA determines the leased area based on the authentication code, pads the area with the binary padding bitstream, calculates the hash value after padding, and sends it back to the remote user. The remote user compares the hash value provided by the FPGA manufacturer with the hash value sent back by the cloud FPGA to determine whether the FPGA is trustworthy, thus completing the remote authentication. The specific steps of the remote authentication are as follows: Remote users can lease the right to use a cloud-based FPGA using their own ID. The algorithm generates its own public-private key pair and publishes its public key to the FPGA manufacturer. The security agent SP in the cloud FPGA loads the SP function and installs it in the static area through a secure bitstream loading mechanism; after the SP is installed, the SP automatically loads the master private key embedded in the SP by the FPGA manufacturer. Remote users use a digital signature algorithm to sign their own ID and request authentication information for the leased portion from the FPGA manufacturer. To prevent replay attacks, a timestamp needs to be added and sent to the FPGA end together. FPGA manufacturers will lease areas from remote users Authentication code Binary stuffed bitstream The hash value calculated after padding is sent to the remote user for the user to authenticate the correctness and integrity of the cloud FPGA; secondly, the FPGA manufacturer will publish the public key of the master private key embedded on the cloud FPGA to the user. The remote user encrypts the signed authentication code using the SP public key. and its corresponding To prevent replay attacks, a timestamp also needs to be added when sending the message to the SP. SP authenticates remote users and decrypts their information using the master private key embedded in the SP, then uses the authentication code to locate their corresponding rental area. Fill the bit stream with binary data Fill the region and calculate its filled state. value; SPs are encrypted using the remote user's public key and authenticated by their signature. The value and timestamp are returned to the user. Remote users compare the hash value provided by the FPGA manufacturer with the one sent by the SP (Service Provider). The value is compared to determine whether the FPGA is trustworthy.

2. The trusted communication method based on an untrusted cloud FPGA as described in claim 1, characterized in that, Before the FPGA leaves the factory, the FPGA manufacturer divides the reconfigurable dynamic region inside the FPGA into several blocks. Each dynamic region block is physically and logically independent, and each dynamic region block generates its own unique authentication code and binary padding bit stream. The remote user's lease of cloud FPGA usage rights involves allocating dynamic region blocks from the divided dynamic regions to the remote user.

3. The trusted communication method based on an untrusted cloud FPGA as described in claim 1, characterized in that, Before the FPGA leaves the factory, the FPGA manufacturer will embed a master private key for encryption and decryption authentication inside the FPGA. Each FPGA board will have a different master private key, which will be stored in the security agent SP.

4. The trusted communication method based on an untrusted cloud FPGA as described in claim 1, characterized in that, The remote authentication and key negotiation of the remote user are both implemented through the security agent SP in the cloud FPGA. The remote user verifies the authenticity and integrity of the leased area with the SP, and the SP participates in the key negotiation process during the remote authentication process. After a remote user completes authentication with the cloud FPGA, they obtain a session key to communicate with it. Using this session key, the remote user transmits their local privacy data to the SP. The SP decrypts the privacy data using the session key and transmits the data to the leased area within the FPGA. The data is then partitioned before the next step of computation is performed.

5. A trusted communication method based on an untrusted cloud FPGA as described in claim 1, characterized in that, The specific steps for key negotiation are as follows: Before formally entering the key negotiation process, all public parameters and raw data from the key negotiation process are included in the user's registered ID information, including elliptic curve parameters. The remote user terminal and the cloud FPGA's security agent SP generate random numbers of a certain secure length through a random number generator. and ; Remote users generate random numbers using a random number generator on their own clients. Calculate its temporary key value Through user-encrypted messages Send them together to the cloud FPGA; SP uses a random number generator to generate random numbers. Then, perform the same operation as on the remote user terminal to obtain its temporary key value. When the cloud FPGA receives After receiving the message, the user decrypts it using their own master private key to obtain the remote user's temporary key. SP gets Next, the temporary key is verified, and the shared key is verified. Computation and shared key of value The calculation, in use Ciphertext after digital signature algorithm Add and Send it to the remote user together; Remote users receive messages After decrypting the message using their private key, the user verifies its authenticity using a digital signature algorithm. The message is then sent from the cloud-based FPGA. After performing the same operations as the remote user, the shared key agreed upon in the key exchange protocol is obtained. And for verifying the shared key Correctness value For remote users to send data to the cloud FPGA. Perform authentication; After the remote user successfully authenticates the cloud FPGA, the remote user further verifies the hash value obtained after key negotiation. Hash value sent from the cloud FPGA Are they the same? If they are the same, then the secure session key... It has also been completed.

6. The trusted communication method based on an untrusted cloud FPGA as described in claim 1, characterized in that, The binary padding bitstream is generated based on the data stored on the dynamic region block. The region is filled by the binary padding bitstream, and the region is initialized by using a secure erasure proof mechanism, thereby achieving the removal of malicious code.

7. A trusted communication system based on an untrusted cloud FPGA, characterized in that, The trusted communication method as described in any one of claims 1-6 includes a user leasing module, an authentication negotiation module, and a trusted communication module. The user leasing module is configured to: when a remote user leases the right to use a cloud FPGA, obtain the authentication information of the leased area from the FPGA manufacturer, including the authentication code of the leased area, the binary padding bitstream, and the hash value calculated after padding. The authentication negotiation module is configured to: before communicating with the cloud FPGA, remote users perform remote authentication based on authentication information, and simultaneously negotiate keys during the authentication process to generate session keys; The trusted communication module is configured to: upload private data to the leased area using a session key, and enable trusted communication between remote users and remotely authenticated cloud FPGAs; The remote authentication process involves a remote user sending a signed authentication code and a binary padding bitstream to a cloud FPGA. The cloud FPGA determines the leased area based on the authentication code, pads the area with the binary padding bitstream, calculates the hash value after padding, and sends it back to the remote user. The remote user compares the hash value provided by the FPGA manufacturer with the hash value sent back by the cloud FPGA to determine whether the FPGA is trustworthy, thus completing the remote authentication.

8. An electronic device, characterized in that it comprises: Memory is used to store computer-readable instructions in a non-transitory manner. as well as Processor, for executing the computer-readable instructions, When the computer-readable instructions are executed by the processor, they perform the method described in any one of claims 1-6.

9. A storage medium characterized in that it non-transitory stores computer-readable instructions, wherein, When the non-transitory computer-readable instructions are executed by a computer, the instructions of the method according to any one of claims 1-6 are executed.

Images