CN117972703A

CN117972703A - Electronic circuit system and security authority releasing method thereof

Info

Publication number: CN117972703A
Application number: CN202211304216.8A
Authority: CN
Inventors: 郭晋廷; 王嘉伟; 吕鸿
Original assignee: Xinhua Technology Co ltd
Current assignee: Xinhua Technology Co ltd
Priority date: 2022-10-24
Filing date: 2022-10-24
Publication date: 2024-05-03

Abstract

The invention provides an electronic circuit system and a security authority releasing method thereof. The electronic circuitry includes a first host device, a second host device, a first security device, and a second security device. The first security device is connected to the first host device. The second security device connects the second host device and the first security device. The first security device performs an authentication operation on the second security device. If the second security device passes the authentication operation, the first security device enables the second security device to verify the executable image of the second host device. If the second security device fails the authentication operation, the first security device disables a function of the second security device, and the function includes verifying the executable image of the second host device. Therefore, the problem that the resources of a single security system chip in the existing trusted platform are insufficient can be solved.

Description

Electronic circuit system and security authority releasing method thereof

Technical Field

The present disclosure relates to a platform security protection method, and more particularly, to an electronic circuit system and a security authority issuing method thereof.

Background

With the rapid growth of firmware security requirements and rapid changes of application scenarios, the existing security system chip (secured SoC) or other security system chips with Platform firmware protection and restoration (Platform FIRMWARE RESILIENCY, PFR) mechanism cannot meet the actual requirements. It is anticipated that the resources or capabilities provided by these existing security system chips may become inadequate. For example, if the number of SPI hosts or I2C hosts on a motherboard increases, the required number of SPI channel monitors or I2C channel filter controllers in the security system chip also needs to increase. However, it is quite impractical to redesign or produce an entirely new security system chip for each different requirement.

Furthermore, the boot performance (boot performance) of the current PFR framework is a problem that needs to be addressed. After the system is powered up, the security system chip needs to read all executable images from all static memory (executable image) during the PFR T-1 phase. Before entering the PFR T0 phase, the security system chip needs an integrity check or image verification (image verification) of all executable images. However, when the data volume of the executable image is large, the security system chip needs to consume more time to complete the integrity check or image verification of the executable image. The time-consuming phenomenon described above will also become more serious as the amount of data in the executable image increases. The PFR T-1 phase herein refers to a period before the system is powered up until the host device reset (reset) is released, and the PFR T0 phase refers to a phase after the host device reset is released.

Disclosure of Invention

The embodiment of the invention provides an electronic circuit system and a security authority releasing method thereof, which can solve the technical problems.

The embodiment of the invention provides an electronic circuit system, which comprises a first host device, a second host device, a first safety device and a second safety device. The first security device is connected to the first host device. The second security device connects the second host device and the first security device. The first secure device performs an authentication operation (attestation process) with respect to the second secure device. If the second security device passes the authentication operation, the first security device enables the second security device to verify the executable image (executable image) of the second host device and subsequent monitoring of platform channel transmissions. If the second security device fails the authentication operation, the first security device disables a function of the second security device, the function including verifying the executable image of the second host device.

In some embodiments of the present invention, the electronic circuit system further includes a first memory device and a second memory device. The first storage device is connected to the first security device and stores an executable image of the first host device. The first security device validates the executable image of the first host device. The second storage device is connected to the second security device and stores an executable image of the second host device. The second security device validates the executable image of the second host device.

In some embodiments of the invention, the authentication operation includes: the first security device or the second security device generates a first random number; the first security device generates a first key according to the first original key and the first random number, and the second security device generates a second key according to the second original key and the first random number; the second security device encrypts a verification data by using the second key to generate encrypted verification data and transmits the encrypted verification data to the first security device; the first security device decrypts the encrypted verification data by using the first key to obtain decrypted verification data; and the first safety device judges whether the second safety device passes the authentication operation according to the decryption verification data. The keys described herein may be symmetric or asymmetric keys.

In some embodiments of the invention, the authentication operation includes: if the decryption verification data is not qualified, the first safety device judges that the second safety device fails the authentication operation; if the decryption verification data is qualified, the first safety device judges whether the device state information of the second safety device is qualified or not; if the device state information of the second safety device is unqualified, the first safety device judges that the second safety device does not pass the authentication operation; if the device state information of the second security device is qualified, the first security device determines that the second security device passes the authentication operation.

In some embodiments of the invention, the authentication operation includes: the second security device encrypts device state information of the second security device by using the second key to generate encrypted device state information; the second security device transmits the encryption device status information to the first security device; the first secure device decrypts the encrypted device state information using the first key to obtain the device state information for the second secure device.

In some embodiments of the present invention, the verification data includes a second random number generated by the first security device, the first security device transmits the second random number to the second security device, and the first security device determines whether the decrypted verification data is identical to the originally generated second random number, so as to determine whether the second security device passes the authentication operation.

In some embodiments of the invention, the authentication data includes credential data of the second security device. The first security device uses a public key to judge whether the certificate data of the second security device is qualified or not so as to judge whether the second security device passes the authentication operation or not.

In some embodiments of the present invention, the public key is recorded in root certificate data of the first security device, and the first security device collects the public key from the root certificate data after determining that the root certificate data is qualified.

In some embodiments of the present invention, the public key is recorded in a key list of the first secure device. And the first safety device acquires a list key of the key list after judging that the root certificate data is qualified, and verifies and acquires the key list by utilizing the list key. The key list also includes an image validation key to validate the executable image of the first host device.

In some embodiments of the present invention, the authentication operation further includes: the first safety device judges whether the using times of the first secret key is larger than a preset value; if the number of times of the first key is greater than the preset value, the first random number is regenerated by the first security device.

In some embodiments of the present invention, the first security device performs the authentication operation on the second security device periodically or non-periodically.

In some embodiments of the present invention, the first security device performs an authentication operation on the second security device in response to the electronic circuitry being powered on.

In some embodiments of the present invention, the electronic circuit system further includes a third host device and a third security device. The third security device connects the third host device and the second security device. If the second security device passes the authentication operation, the second security device performs the authentication operation on the third security device. If the third security device passes the authentication operation, the second security device enables the third security device to verify the executable image of the third host device and the subsequent monitoring of the platform channel transmission.

From another perspective, an embodiment of the present invention provides a method for issuing security rights, which is applicable to an electronic circuit system including a first host, a second host, a first security device, and a second security device, and includes the following steps. An authentication operation is performed by the first secure device on the second secure device. The first security device is connected with the first host device, and the second security device is connected with the second host device and the first security device. If the second security device passes the authentication operation, the first security device enables the second security device to verify the executable image of the second host device and the monitoring of the subsequent platform channel transmission. If the second security device fails the authentication operation, disabling, by the first security device, a function of the second security device, the function including verifying the executable image of the second host device.

Based on the above, in the embodiment of the present invention, a plurality of security devices can be connected to each other to form a device topology (topology), and each of the security devices is connected to a corresponding host device, so as to solve the problem of insufficient resources of a single security system chip in the existing trusted platform. In addition, by using a plurality of security devices to verify executable images of a plurality of host devices at the same time, the electronic circuit system of the embodiment of the invention can reduce the time for verifying the executable images, thereby effectively improving the system performance.

Drawings

FIG. 1 is a block diagram of an electronic circuit system according to an embodiment of the invention;

FIG. 2 is a flow chart of a security right issuing method according to an embodiment of the present invention;

FIG. 3 is a flow chart of an authentication operation according to an embodiment of the present invention;

FIG. 4 is a block diagram of an electronic circuit system according to an embodiment of the invention;

FIG. 5 is a flow chart of an authentication operation according to an embodiment of the present invention;

FIGS. 6A and 6B are flowcharts illustrating an authentication operation according to an embodiment of the present invention;

FIG. 7 is a diagram illustrating verification of an executable image by a plurality of security devices according to one embodiment of the present invention;

FIGS. 8A and 8B are flowcharts illustrating an authentication operation according to an embodiment of the present invention;

FIG. 9 is a schematic diagram illustrating an authentication operation based on credential data according to one embodiment of the present invention;

FIG. 10 is a schematic diagram illustrating an authentication operation based on credential data according to one embodiment of the present invention;

FIG. 11 is a block diagram of an electronic circuit system according to an embodiment of the invention;

fig. 12A and 12B are schematic diagrams illustrating device topologies of a multi-security device according to an embodiment of the invention.

Description of the reference numerals

10,40,80: Electronic circuitry;

110,110_1 to 110_4, a first host device;

120,120_1 to 120_2;

130 a first security device;

140,140_1 to 140_3, a second safety device;

150,150_1 to 150_4;

160,160_1 to 160_2, a second memory device;

131_1 to 131_4,121_1 to 121_2;

ctr1, control signal;

L1-L8, a key list;

PK 1-PK 13 public key;

S1, S2, S3 and S4, digital signature;

71-78,91-98 parts of operation;

AK1_1 to AK1_n, AK1_ (n+1) to AK1_m, AK2_1 to AK2_p: image authentication key;

m1, M2 and M3 are one-time programmable memory;

RC1 root credential data;

C1, C2, credential data;

LK1, LK2, manifest key;

img 1-ImgP, executable image;

170,170_1 to 170_4, a third safety device;

180 a third host device;

a third storage device 190;

steps S202 to S208, S302 to S310, S3101 to S3104, S501 to S518, S601 to S630, and S801 to S831.

Detailed Description

Reference will now be made in detail to the exemplary embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings and the description to refer to the same or like parts.

FIG. 1 is a block diagram of an electronic circuit system according to an embodiment of the invention. Referring to fig. 1, the electronic circuit system 10 of the present embodiment includes a first host device 110, a second host device 120, a first security device 130, a second security device 140, a first storage device 150, and a second storage device 160. In some embodiments, electronic circuitry 10 may be implemented, for example, as a personal computer, a server, or other electronic device requiring a trusted platform module unit.

The first host device 110 and the second host device 120 are, for example, a central processing unit (Central Processing Unit, CPU), a microcontroller (Microcontroller, MCU), or a baseboard management controller (Board Management Controller, BMC), but are not limited thereto. In some embodiments, the first host device 110 and the second host device 120 may be implemented as serial peripheral interface (SERIAL PERIPHERAL INTERFACE, SPI) host devices. In other embodiments, the first host device 110 and the second host device 120 may be implemented as I2C (Inter-INTEGRATED CIRCUIT) host devices. That is, the first host device 110 may be connected with the first security device 130 via an SPI interface. Or the first host device 110 may be connected with the first security device 130 via an I2C interface.

The first storage device 150 and the second storage device 160 are Non-Volatile Memory (NVM) such as Flash Memory (Flash Memory) or random-access Memory (ROM), but not limited thereto. The first storage device 150 and the second storage device 160 are used for storing executable images of the electronic circuit system 10, for example, in the form of binary images (binary images) stored in the first storage device 150 and the second storage device 160. These executable images may also be referred to as firmware images. The first storage device 150 is used to store an executable image of the first host device 110, and the second storage device 160 is used to store an executable image of the second host device 120. The first storage device 150 is coupled to the first security device 130 and the second storage device 160 is coupled to the second security device 140.

The first security device 130 and the second security device 140 are, for example, but not limited to, a programmable general purpose or special purpose Microprocessor (MPU), a micro controller (Microcontroller, MCU), an Application SPECIFIC INTEGRATED Circuits (ASIC), a programmable logic device (Programmable Logic Device, PLD), or other similar devices or combinations of these devices. In some embodiments, the first security device 130 and the second security device 140 may be implemented as security system chips (secure socs) mounted on a motherboard, respectively. In some embodiments, the first security device 130 and the second security device 140 are, for example, platform firmware protection and recovery (Platform FIRMWARE RESILIENCY, PFR) modules.

In some embodiments, the first security device 130 and the second security device 140 may connect the first host device 110 and the second host device 120 through an SPI bus. Similarly, the first security device 130 and the second security device 140 may connect the first storage device 150 and the second storage device 160 through the SPI bus. In addition, the first safety device 130 is connected to the second safety device 140. For example, the first security device 130 and the second security device 140 may be connected via an I2C bus, but is not limited thereto. In addition, in some embodiments, the first security device 130 and the second security device 140 may be connected to other peripheral devices via buses, respectively.

After the electronic circuitry 10 is powered up, the first security device 130 and the second security device 140 will verify the integrity and validity, respectively, of the executable image to be executed on the platform. Moreover, the first security device 130 can monitor data traffic and transfer data between the first host device 110 and the first storage device 150 and other peripheral devices, and the second security device 140 can monitor data traffic and transfer data between the second host device 120 and the second storage device 160 and other peripheral devices. Accordingly, the first security device 130 and the second security device 140 may protect the electronic circuitry 10 from attacks by malware.

However, it should be noted that, for clarity of explanation of the operation principle of the embodiment of the present invention, the electronic circuit system 10 shown in fig. 1 is exemplified by a security device monitoring a host device and a storage device, but the present invention is not limited to the number of host devices and the number of storage devices monitored by a security device.

Fig. 2 is a flowchart of a security authority release method according to an embodiment of the invention. Referring to fig. 1 and 2, the method of the present embodiment is applicable to the electronic circuit system 10. The following describes the detailed steps of the security rights issuing method of the present embodiment along with the components of the electronic circuit system 10.

In step S202, the first secure device 130 performs an authentication operation on the second secure device 140. In some embodiments, the first security device 130 may serve as a security control center of the platform or the entire electronic circuitry 10, i.e., as a root of trust (RoT). The first secure device 130 may perform an authentication operation on the second secure device 140 to determine whether to place the authority to maintain the firmware security on the second secure device 140. In other words, the first security device 130 may be a master security device, and the second security device 140 may be a slave security device controlled by the master security device. In the embodiment of the invention, the master security device performs authentication operation on the slave security device to determine whether to enable or disable the slave security device to perform platform firmware protection operation.

In step S204, the first security device 130 determines whether the second security device 140 passes the authentication operation. In some embodiments, the first security device 130 may perform an authentication operation on the second security device 140 using one or more cryptographic mechanisms to determine whether the second security device 140 passes the authentication operation. The cryptographic mechanism may include, but is not limited to, a symmetric encryption algorithm, an asymmetric encryption algorithm, a Hash (Hash) algorithm, a digital signature algorithm, or the like. In addition, in some embodiments, the first security device 130 may determine whether the second security device 140 passes the authentication operation according to the device status information provided by the second security device 140. In other words, the first security device 130 can determine whether the second security device 140 is trusted through the authentication operation.

In detail, please refer to fig. 3, which is a flowchart illustrating an authentication operation according to an embodiment of the present invention. In step S302, the first security device 130 or the second security device 140 generates a first random number. When the first secure device 130 generates the first random number, the first secure device 130 may transmit the first random number to the second secure device 140 via the bus. When the second security device 140 generates the first random number, the second security device 140 can transmit the first random number to the first security device 130 through the bus. The first random parameter may be a pseudorandom random number (pseudo randomnumber) or a true random number (true random number), as the invention is not limited in this regard.

In step S304, the first secure device 130 generates a first key according to the first original key and the first random number, and the second secure device 140 generates a second key according to the second original key and the first random number. The first key and the second key may be asymmetric keys or symmetric keys, which the present invention is not limited to. In detail, the first original key may be embedded in the one-time programmable memory of the first secure device 130, the first original key being unalterable and only allowing access by the encryption engine circuitry inside the first secure device 130. Similarly, the second original key may be embedded in one-time programmable memory of the second security device 140, the second original key being unalterable and only allowing access by encryption engine circuitry internal to the second security device 140. The one-time programmable memory may include a cache, an electronic fuse (eFuse), or the like, as the invention is not limited in this respect. Thus, the first secure device 130 can perform the authentication operation on the second secure device 140 by determining whether the second original key inside the second secure device 140 is identical to the first original key inside itself. If the second original key is different from the first original key, the first secure device 130 may determine that the second secure device 140 fails the authentication operation, i.e., is an untrusted device.

Thus, in some embodiments, to avoid exposing the first original key and the second original key, the encryption engine circuit of the first secure device 130 and the encryption engine circuit of the second secure device 140 may generate the first key and the second key according to the first random number and the respective first original key and second original key, respectively, based on the asymmetric encryption algorithm or the symmetric encryption algorithm. The second secure device 140 encrypts the data using the second key and the corresponding first secure device 130 decrypts the data using the first key.

In step S306, the second secure device 140 encrypts the authentication data using the second key to generate encrypted authentication data, and transmits the encrypted authentication data to the first secure device 130. In some embodiments, the authentication data may include a random number generated by the first security device 130. Or in other embodiments, the authentication data may include credential data of the second security device 140. In step S308, the first secure device 130 decrypts the encrypted verification data using the first key to obtain decrypted verification data. Next, in step S310, the first secure device 130 determines whether the second secure device 140 passes the authentication operation according to the decryption verification data.

Step S310 may be implemented as steps S3101 to S3104. In step S3101, the first secure device 130 determines whether the decryption verification data is qualified (valid). In some embodiments, the first secure device 130 may determine whether the decryption verification data is identical to the random number generated by the first secure device 130, so as to determine whether the decryption verification data is acceptable. In some embodiments, the first secure device 130 may determine whether the credential data in the decrypted authentication data passes the authentication, so as to determine whether the decrypted authentication data is qualified. In some embodiments, the first secure device 130 may determine whether the credential content in the decryption verification data meets the expectations, so as to determine whether the decryption verification data is qualified. In some embodiments, if the decrypted authentication data is acceptable, the second original key representing the inside of the second secure device 140 is the same as the first original key of the inside of the first secure device 130. Or in some embodiments, if the decryption verification data is acceptable, the credential data provided on behalf of the second security device 140 is acceptable and the credential content is acceptable.

If the decryption verification data is not acceptable (no in step S3101), in step S3104, the first secure device 130 determines that the second secure device 140 does not pass the authentication operation. On the other hand, if the decryption verification data is acceptable (yes in step S3101), in step S3102, the first secure device 130 further determines whether the device status information of the second secure device 140 is acceptable. The device status information of the second security device 140 may include a value recorded in the otp memory, a current temperature, a voltage/current value, a CPU frequency, an executable image measurement, or a memory usage status. The second security device 140 has hardware components present to collect these device state information. By determining whether the device status information of the second security device 140 is acceptable, the first security device 140 can determine whether the second security device 140 is operating in an expected state. If the device status information of the second security device 140 is acceptable, it represents that the second security device 140 is operating in the expected state.

For example, the first security device 130 may determine whether the second security device 140 has the capability of connecting to an external network according to the value recorded by the otp memory provided by the second security device 140, so as to determine whether the second security device 140 is trusted. The first security device 130 determines that the device status information of the second security device is acceptable when the value recorded by the one-time programmable memory provided by the second security device 140 indicates that the second security device 140 does not have the capability of being connected to an external network. Conversely, when the value recorded in the otp memory provided by the second security device 140 indicates that the second security device 140 has the capability of connecting to an external network, the first security device 130 determines that the device status information of the second security device 140 is not acceptable.

In addition, in some embodiments, the second security device 140 may encrypt the device state information of the second security device 140 using the second key to generate encrypted device state information. Then, the second secure device 140 transmits the encrypted device status information to the first secure device 130. The first secure device 130 decrypts the encrypted device state information using the first key to obtain device state information for the second secure device 140.

If the device status information of the second security device 140 is acceptable, in step S3103, the first security device 130 determines that the second security device 140 passes the authentication operation. If the device status information of the second security device is not acceptable, in step S3104, the first security device 130 determines that the second security device 140 fails the authentication operation. That is, the first secure device 130 determines that the second secure device 140 passes the authentication operation when the decryption verification data is qualified and the device state information of the second secure device 140 is qualified. When the decryption verification data is failed or the device state information of the second secure device 140 is failed, the first secure device 130 determines that the second secure device 140 fails the authentication operation.

Next, referring back to fig. 2, if the second security device 140 passes the authentication operation (yes in step S204), the first security device 130 enables the second security device 140 to verify the executable image of the second host device 120. In addition, in some embodiments, if the second security device 140 passes the authentication operation (yes in step S204), the first security device 130 may also enable the second security device 140 to perform other platform firmware protection operations. Further, in some embodiments, after the electronic circuit system 10 is powered up, the first security device 130 performs an authentication operation on the second security device 140 when both the second host device 120 and the second security device 140 are still in a reset (reset) state. More precisely, the second security device 140 only has a minimum functionality that enables the second security device 140 to perform authentication interactions with the first security device 130. If the second security device 140 passes the authentication operation, the first security device 130 can use the control signal to release the self-reset state of the second security device 140, i.e. the second security device 140 is switched to operate in the enabled state, so that the second security device 140 starts to operate. Then, after the second security device 140 starts to operate, the second security device 140 verifies the integrity and legitimacy of the executable image in the second storage device 160. In addition, the second security device 140 reads the executable image from the second storage device 160 when the second host device 120 is in the reset state, and can verify the integrity and legitimacy of the executable image of the second host device 120 using a hash algorithm and a digital signature.

In some embodiments, if the executable image in the second storage device 160 is verified successfully, the second security device 140 releases the self-reset state of the second host device 120, i.e. the second host device 120 transitions to the enabled state, so that the second host device 120 can read and execute the executable image in the second storage device 160. Otherwise, if the validation of the executable image in the second storage device 160 fails, the second security device 140 controls the second host device 120 to remain in the reset state to terminate the execution of the executable image in the second storage device 160. And, the second security device 140 may inform the system administrator to handle executable images that failed validation.

On the other hand, if the second security device 140 fails the authentication operation (no in step S204), the first security device 130 disables a function of the second security device 140, and the disabled function includes verifying the executable image of the second host device 120. In some implementations, if the second security device 140 fails the authentication operation (no in step S204), the first security device 130 may disable all functions of the second security device 140, i.e. deactivate the second security device 140. Further, if the second security device 140 fails the authentication operation, the first security device 130 controls the second security device 140 to be kept in the reset state through the control signal, that is, the authority of maintaining the firmware security is not given to the second security device 140, so as to disable the second security device 140 to verify the executable image in the second storage device 160.

It can be seen that if the second security device 140 passes the authentication operation, the time for the electronic circuit system 10 to operate in the PFR T-1 stage can be reduced because the first security device 130 and the second security device 140 can synchronously perform verification of the executable image. In addition, through the arrangement of the second security device 140, the problem of insufficient resources of the existing security system chip can be effectively solved. Thus, even if the number of host devices on the motherboard increases, there will be no need to redesign a new security system chip by adding one or more slave security devices in addition to the master security device. That is, the embodiments of the present invention provide a more flexible and practical approach.

FIG. 4 is a block diagram of an electronic circuit system according to an embodiment of the invention. Referring to fig. 4, it is assumed that the electronic circuitry 40 includes 6 host devices. Since the first security device 130 includes 4 monitoring circuits 131_1 to 131_4, the requirements of 6 host devices cannot be satisfied. However, in the present embodiment, the electronic circuit system 40 may include the first security device 130 and the second security device 140 connected to each other. After the electronic circuitry 40 is powered up, the first security device 130, which is the primary security device, may perform an authentication operation on the second security device 140, which is the secondary security device. When the second security device 140 passes the authentication operation, the first security device 130 can release the second security device 140 from the reset state through the control signal Ctr1 to issue the authority of verifying the executable image to the second security device 140.

In detail, as shown in fig. 4, the electronic circuit system 40 includes 4 first host devices 110_1 to 110_4 connected to the first security device 130 and 2 second host devices 120_1 to 120_2 connected to the second security device 140. The 4 monitor circuits 131_1 to 131_4 of the first security device 130 are used to verify the integrity and legitimacy of the executable images in the first storage devices 150_1 to 150_4, respectively. When the second security device 140 passes the authentication operation, the 2 monitoring circuits 141_1-141_2 of the second security device 140 are used to verify the integrity and legitimacy of the executable images in the second storage devices 160_1-160_2, respectively. Accordingly, the second security device 140 can solve the technical problem that the resource of the first security device 130 cannot cope with a large number of host devices. Monitor circuits 131_1-131_4, 141_1-141_2 may be, for example, SPI channel monitors or I2C channel filters. In addition, in some embodiments, the second security device 140 can also report the monitoring result of the monitoring circuits 141_1 to 141_2 to the first security device 130 via a dedicated transmission path.

FIG. 5 is a flow chart of an authentication operation according to an embodiment of the present invention. Referring to fig. 5, the method of the present embodiment is applicable to the electronic circuit system 10 or 40 described above. It should be noted that fig. 5 illustrates an example in which the authentication datagram includes a random number generated by the first secure device 130 and a symmetric key is applied.

In step S501, the first security device 130 generates a first random number. In step S502, the first secure device 130 transmits a first random number to the second secure device 140. In step S503, the first secure device 130 generates a first key using the first random number and the first original key. In step S504, the second secure device 140 generates a second key using the first random number and the second original key. Details of the implementation of step S501 to step S504 are described in the embodiment shown in fig. 3, and are not repeated here.

In step S505, the first security device 130 generates a second random number. In step S506, the first secure device 130 transmits the second random number to the second secure device 140. In step S507, the second security device 140 encrypts the second random number using the second key to obtain encrypted verification data. In step S508, the second secure device 140 transmits the encrypted authentication data to the first secure device 130. In step S509, the first secure device 130 decrypts the encrypted authentication data using the first key to obtain decrypted authentication data. In step S510, the first secure device 130 compares the decryption verification data with the original second random number, and determines whether the decryption verification data is identical to the original second random number. Specifically, in this embodiment, the verification data may include the second random number generated by the first security device 130. If the decryption verification data is the same as the original second random number, the decryption verification data is qualified. If the decryption verification data is different from the original second random number, the decryption verification data is not qualified.

Accordingly, in step S511, if the decrypted verification data is different from the second random number, the first secure device 130 determines that the second secure device fails the authentication operation, and disables the second secure device to perform a function, and the disabled function may include performing a platform firmware protection operation. On the other hand, if the decryption verification data is the same as the original second random number, the first secure device 130 will continuously determine whether the device status information of the second secure device 140 meets the expectations.

In step S512, the hardware in the second security device 140 directly collects the device status information of the current second security device 140. In step S513, the second secure device 140 encrypts the device status information of the second secure device 140 using the second key. In step S514, the second secure device 140 transmits the encrypted device status information to the first secure device 130. In step S515, the first secure device 130 decrypts the encrypted device state information using the first key to obtain the device state information of the second secure device 140. In step S516, the first security device 130 determines whether the device status information of the second security device 140 is acceptable. Details of the implementation of step S512 to step S516 are described in the embodiment shown in fig. 3, and are not repeated here.

In step S517, if the device status information of the second security device is not acceptable, the first security device 130 determines that the second security device fails the authentication operation, and disables a function of the second security device 140, including performing the platform firmware protection operation. In step S518, if the device status information of the second security device is acceptable, the first security device 130 determines that the second security device passes the authentication operation, and enables the second security device to perform the platform firmware protection operation. The platform firmware protection operation may include verifying the executable image and monitoring transmission data between the host device (e.g., the first host device 110 and the second host device 120) and other peripheral devices.

Further, in some embodiments, the first security device 130 may repeat the authentication operation on the second security device 140 at regular or irregular times. Or in some embodiments, the first security device 130 performs an authentication operation on the second security device 140 in response to powering up the electronic circuitry 10 or 40.

Fig. 6A and 6B are flowcharts illustrating an authentication operation according to an embodiment of the present invention. Referring to fig. 6A and 6B, the method of the present embodiment is applicable to the electronic circuit system 10 or 40 described above. In the examples of fig. 6A and 6B, the verification data includes the random number generated by the first secure device 130 and the symmetric key is used as an example.

In step S601, the first secure device 130 determines whether the first key and the third key exist. In this embodiment, the first security device 130 decrypts the data using the first key and encrypts the data using the third key. If the first key and the third key exist (yes in step S601), in step S602, the first security device 130 determines whether the number of times of using the first key or the third key is greater than a preset value, so as to determine whether the first key and the third key need to be updated to improve security.

If the number of times of the first key usage is greater than the preset value (yes in step S602) or if the first key and the third key are not present (no in step S601), the first secure device 130 and the second secure device 140 will execute the key generation procedure. That is, when the first secure device 130 has not generated the first and third keys or the first or third keys have been used many times, the first secure device 130 and the second secure device 140 will execute the key generation procedure. Therefore, in step S603, the first security device 130 generates a third random number. In step S604, the second security device 140 generates a first random number. If the number of times of the first key usage is not greater than the preset value (no in step S602), the first security device 130 and the second security device 140 may omit the key generation procedure, and the first security device 130 continues to execute step S628. In step S628, the first secure device 130 sends a notification message to notify the second secure device 140 to omit the execution of the key generation procedure, and then step S622 is performed. Correspondingly, before step S604, in step S629, the second security device 140 determines whether to execute the key generation procedure. If the notification message sent by the first secure device 130 is not received, the second secure device 140 determines to execute the key generation procedure (yes in step S629), and then proceeds to step S604. In contrast, if the notification message sent by the first secure device 130 is received, the second secure device 140 determines not to execute the key generation procedure (no in step S629), and proceeds to step S619.

In step S605, the first secure device 130 transmits a third random number to the second secure device 140. In step S606, the second security device 140 receives the third random number. In step S607, the second secure device 140 transmits the first random number to the first secure device 130. In step S608, the first security device 130 receives the first random number.

In step S609, the first secure device 130 generates a first key using the first random number and the first original key, and generates a third key using the third random number and the first original key. In step S610, the second secure device 140 generates a second key using the first random number and the second original key, and generates a fourth key using the third random number and the second original key. In this embodiment, the second security device 140 encrypts the data transmitted to the first security device 130 using the second key, and the second security device 140 decrypts the data received from the first security device 130 using the fourth key. That is, the first key used by the first secure device 130 for decryption is paired with the second key used by the second secure device 140 for encryption, and the third key used by the first secure device 130 for encryption is paired with the fourth key used by the second secure device 140 for decryption.

In step S611, the first secure device 130 generates a second random number. In step S612, the first secure device 130 transmits the second random number. In step S613, the second security device 140 receives the second random number. In step S614, the second secure device 140 encrypts the second random number using the second key to obtain encrypted verification data. In step S615, the second secure device 140 transmits the encrypted authentication data. In step S616, the first secure device 130 receives the encrypted authentication data. In step S617, the first secure device 130 decrypts the encrypted verification data using the first key to obtain decrypted verification data. In step S618, the first secure device 130 determines whether the decryption verification data is identical to the second random number, so as to determine whether the second secure device 140 passes the authentication operation.

On the other hand, in step S619, the second security device 140 collects device status information of the second security device 140. In step S620, the second secure device 140 encrypts the device status information of the second secure device 140 using the second key to obtain encrypted device status information. In step S621, the second secure device 140 transmits the encrypted device status information to the first secure device 130.

If yes in step S618, the first secure device 130 receives the encryption device status information in step S622. In step S623, the first secure device 130 decrypts the encrypted device state information using the first key. In step S624, the first security device 130 determines whether the device status information is acceptable. If yes in step S624, in step S625, the first security device 130 increases the number of times of use of the first key. In step S626, the first secure device 130 determines that the second secure device 140 is authenticated. If step S618 or step S624 determines no, in step S630, the first security device 130 increases the number of times of use of the first key. Next, in step S627, the first security device 130 determines that the second security device 140 fails the authentication operation.

FIG. 7 is a schematic diagram of a plurality of secure devices validating an executable image in accordance with an embodiment of the present invention. It is assumed that M executable images of M host devices need to be validated. Referring to fig. 7, an encryption Engine (Crypto Engine) circuit of the first secure device 130 can read the public key PK1 from the one-time programmable memory M1. In operation 71, the first secure device 130 may decrypt the digital signature S1 of the key list L1 using the public key PK1. The key list L1 includes N image verification keys ak1_1 through ak1_n for verifying N executable images associated with N host devices, respectively, where N is less than or equal to M. For example, in the embodiment of fig. 4, M is equal to 6 and N is equal to 4.

In operation 72, the first secure device 130 may perform a hash process according to the key list L1 to obtain a hash value. In operation 73, the first secure device 130 compares the hash value with the decrypted data of the digital signature S1. In operation 74, the first security device 130 determines whether the key list L1 is verified according to the comparison result. If the key list L1 is verified, the first security device 130 can verify the integrity and legitimacy of the N executable images by using the image verification keys ak1_1 through ak1_n, respectively.

On the other hand, in the event that the second security device 140 passes the authentication operation, the first security device 130 may enable the second security device 140 to verify the executable image. The encryption engine circuit of the second secure device 140 may then read the public key PK2 in the one-time programmable memory M2. In operation 75, the second secure device 140 may decrypt the digital signature S2 of the key list L2 using the public key PK2. The key list L2 includes (M-N) image verification keys AK1_ (N+1) -AK1_M for verifying (M-N) executable images associated with (M-N) host devices, respectively.

In operation 76, the second security device 140 may obtain a hash value according to the image verification keys AK1_ (n+1) -AK 1_m in the key list L2. In operation 77, the second secure device 140 compares the hash value with the decrypted data of the digital signature S2. In operation 78, the second security device 140 determines whether the key list L2 is verified according to the comparison result. If the key list L2 is verified, the second security device 140 can verify the integrity and legitimacy of the (M-N) executable images by using the image verification keys ak1_ (n+1) -ak1_m, respectively.

Fig. 8A and 8B are flowcharts illustrating an authentication operation according to an embodiment of the present invention. Referring to fig. 8A and 8B, the method of the present embodiment is applicable to the electronic circuit system 10 or 40 described above. In the examples of fig. 8A and 8B, the verification data includes the credential data of the second security device 140 and the symmetric key is applied as an embodiment.

In step S801, the first secure device 130 determines whether the first key and the third key exist. If yes in step S801, in step S802, the first security device 130 determines whether the number of times of using the first key or the third key is greater than a preset value. If step S802 is negative, in step S829, the first security device 130 sends a notification message to notify the second security device 140 that the key generation procedure is omitted, and then step S813 is performed. Correspondingly, before step S804, in step S830, the second security device 140 determines whether to execute the key generation procedure. If the notification message sent by the first secure device 130 is not received, the second secure device 140 determines to execute the key generation procedure (yes in step S830), and then proceeds to step S804. In contrast, if the notification message sent by the first secure device 130 is received, the second secure device 140 determines not to execute the key generation program (no in step S830), and proceeds to step S811. If the determination in step S801 is negative or the determination in step S802 is positive, in step S803, the first security device 130 generates a third random number. In step S804, the second security device 140 generates a first random number.

In step S805, the first secure device 130 transmits the third random number to the second secure device 140. In step S806, the second security device 140 receives the third random number. In step S807, the second security device 140 transmits the first random number to the first security device 130. In step S808, the first security device 130 receives the first random number. In step S809, the first secure device 130 generates a first key using the first random number and the first original key, and generates a third key using the third random number and the first original key. In step S810, the second secure device 140 generates a second key using the first random number and the second original key, and generates a fourth key using the third random number and the second original key. The steps S801 to S810 are similar to the steps S601 to S610 in the foregoing embodiments, and thus the details thereof are not repeated here.

Unlike the previous embodiments, the authentication data includes credential data of the second security device 140. Therefore, in step S811, the second security device 140 encrypts the credential data of the second security device 140 using the second key to obtain encrypted verification data. The credential data of the second security device 140 is, for example, an x.509 credential (i.e., SSL credential). In some embodiments, the credential data for each secure device in the system (e.g., the second secure device 140) may include a SoC identifier, a manufacturer identifier (Manufacture vendor ID), a credential version, a key manifest version, a public key for the key manifest, a credential version of the slave secure device, and one or more keys for the slave secure device.

In step S812, the second secure device 140 transmits the encrypted authentication data to the first secure device 130. In step S813, the first secure device 130 receives the encrypted verification data. In step S814, the first secure device 130 decrypts the encrypted authentication data using the first key to obtain the credential data of the second secure device 140.

In step S815, the first secure device 130 verifies the credential data of the second secure device 140 using a public key. In detail, the first secure device 130 may decrypt the digital signature in the credential data of the second secure device 140 using a public key. In step S816, the first security device 130 determines whether the credential data of the second security device 140 is acceptable, so as to determine whether the second security device 140 passes the authentication operation. Specifically, the first secure device 130 can verify whether the credential data of the second secure device 140 is qualified by comparing the decryption result of the digital signature in the credential data of the second secure device 140 with the hash value generated according to the credential content.

It should be noted that, in some embodiments, the public key used to verify the credential data of the second security device 140 may be recorded in a piece of credential data of the first security device 130. Alternatively, in other embodiments, the public key used to verify the credential data of the second security device 140 may be recorded in the key list of the first security device 130.

FIG. 9 is a schematic diagram illustrating an authentication operation based on credential data according to one embodiment of the present invention. Referring to fig. 9, a public key PK4 for verifying the credential data C1 of the second secure device 140 is recorded in a piece of credential data RC1 of the first secure device 130. The first secure device 130 needs to verify its root credential data RC1 before verifying the credential data C1 of the second secure device 140 using the public key PK 4. The encryption and decryption engine circuit of the first secure device 130 may read the public key PK3 from the one-time programmable memory M3. In operation 91, the first secure device 130 may decrypt the digital signature S3 of the root certificate data RC1 using the public key PK3.

In operation 92, the first secure device 130 may obtain a hash value according to the credential content of the root credential data RC 1. In operation 93, the first secure device 130 compares the hash value with the decrypted data of the digital signature S3. In operation 94, the first security device 130 determines whether the root certificate data RC1 is acceptable or unacceptable according to the comparison result. The first secure device 130 may obtain the public key PK4 from the root credential data RC1 after determining that the root credential data RC1 is qualified. Then, if the root certificate data RC1 is qualified, the first secure device 130 decrypts the digital signature S4 of the certificate data C1 of the second secure device 140 using the public key PK4 in the root certificate data RC1 in operation 95. In operation 96, the first secure device 130 may obtain a hash value according to the credential content of the credential data C1. In operation 97, the first secure device 130 compares the hash value with the decrypted data of the digital signature S4. In operation 98, the first security device 130 determines whether the credential data C1 is acceptable or unacceptable according to the comparison result, and can then determine whether the information in the credential data C1 is correct.

FIG. 10 is a schematic diagram illustrating an authentication operation based on credential data according to one embodiment of the present invention. Referring to fig. 10, a public key PK4 for verifying the credential data of the second secure device 140 is recorded in the key list L3 of the first secure device 130. The first secure device 130 may verify the root certificate data RC1 using the public key PK3 in the one-time programmable memory M3. The verification process of the root certificate data RC1 is similar to the example shown in fig. 9, and is not repeated here. The first security device 130 may obtain the list key LK1 of the key list L3 from the root certificate data RC1 after determining that the root certificate data RC1 is qualified, and verify the key list L3 by using the list key LK1 to obtain the key list L3. It should be noted that the key list L3 may further include an image verification key (not shown) for verifying the executable image of the first host device 110. Then, the first secure device 130 may obtain the public key PK4 from the key list L3, and verify the credential data C1 of the second secure device 140 using the public key PK 4. The verification process of the credential data C1 is similar to that of the example shown in FIG. 9, and is not repeated here.

In addition, as shown in fig. 10, if the second security device 140 passes the authentication operation, the second security device 140 may obtain the list key LK2 from the credential data C1, and verify the key list L4 with the list key LK2 to obtain the key list L4. The key list L4 includes P image verification keys ak2_1 through ak2_p for verifying the P executable images Img1 through ImgP. For example, the image verification key AK2_1 may be used to verify the executable image Img1, the image verification key AK2_2 may be used to verify the executable image Img2, and the image verification key AK2_p may be used to verify the executable image ImgP. In addition, the key list L4 may further include a public key PK5 for verifying the credential data C2 of the third secure device 170.

Referring back to fig. 8, if yes in step S816, in step S817, the first security device 130 determines whether the information in the credential data of the second security device 140 is correct. For example, the first secure device 130 may determine whether the SoC identifier or manufacturer identifier (Manufacture vendor ID) in the credential data of the second secure device 140 is correct. If the credential data of the second secure device 140 is acceptable and the information in the credential data is correct, the first secure device 130 determines that the decryption verification data is acceptable. If the credential data of the second secure device is not acceptable or the information within the credential data is incorrect, the first secure device 130 determines that the decryption validation data is not acceptable.

On the other hand, in step S818, the second security device 140 collects the device status information of the second security device 140. In step S819, the second security device 140 encrypts the device state information of the second security device 140 using the second key to obtain encrypted device state information. It should be noted that, in step S820, the second secure device 140 generates the encrypted hash value of the encrypted device status information. For example, the second security device 140 may generate the encrypted hash value using the second key and the encrypted device state information according to a hash-based MAC (HMAC) algorithm. In step S821, the second secure device 140 transmits the encrypted device status information and the encrypted hash value to the first secure device 130.

If the determination in step S816 and step S817 is yes, the first secure device 130 receives the encrypted device status information and the encrypted hash thereof in step S822. In step S823, the first secure device 130 determines whether the cryptographic hash value of the cryptographic device state information is acceptable. In detail, since the cryptographic hash value is generated according to the second key, the first secure device 130 will verify whether the cryptographic hash value is qualified using the corresponding first key.

If yes in step S823, the first secure device 130 decrypts the encrypted device state information using the first key in step S824. In step S825, the first security device 130 determines whether the device status information is acceptable. If step S825 determines yes, in step S826, the first security apparatus 130 increases the number of times of use of the first key. In step S827, the first security device 130 determines that the second security device is authenticated. If step S816, step S817, step S823 or step S825 determines no, in step S831, the first security apparatus 130 increases the number of times the first key is used. Next, in step S828, the first secure device 130 determines that the second secure device 140 fails the authentication operation.

The above embodiments are mainly described by taking two safety devices as examples, but the present invention is not limited thereto. In some embodiments, the electronic circuitry may include more than two security devices. FIG. 11 is a schematic diagram of an electronic circuit system according to an embodiment of the invention. Referring to fig. 11, the electronic circuit system 80 may further include a third host device 180, a third storage device 190 and a third security device 170 in addition to the first host device 110, the second host device 120, the first security device 130, the second security device 140, the first storage device 150 and the second storage device 160. The third security device 170 connects the third host device 180, the third storage device 190, and the second security device 140.

The first secure device 130, which is the root of trust, may first perform an authentication operation as described in the previous embodiments with respect to the second secure device 140. If the second security device 140 passes the authentication operation, the second security device 140 also performs the authentication operation on the third security device 170 before verifying the executable image of the second host device 120. In other words, the second safety device 140 acts as a slave safety device to the first safety device 130 and at the same time as a primary safety device to the third safety device 170. The operation of the second security device 140 to perform the authentication operation on the third security device 170 is similar to the operation of the first security device 130 to perform the authentication operation on the second security device 140.

If the third security device 170 passes the authentication operation, the second security device 140 enables the third security device 170 to verify the executable image of the third host device 180. If the third security device 170 fails the authentication operation, the second security device 140 disables a function of the third security device 170, and the function includes verifying the executable image of the third host device 180. That is, the second security device 140 may determine whether to place the authority for performing the platform firmware protection operation on the third security device 170. In addition, in some embodiments, where the credential data is used for authentication operations, the public key used to verify the credential data of the third security device 170 may be recorded in the credential data or key list of the second security device 140 to reduce the amount of one-time programmable memory used to record the public key over the device lifecycle. In addition, the use of the credential data or the key list can also achieve the effect of a key delegation mechanism, thereby improving the efficiency of key management in an organization.

It should be noted that the number of safety devices and the topology of the devices formed may be set according to actual requirements. For example, fig. 12A and 12B are schematic diagrams of device topologies of a multi-security device according to an embodiment of the invention. Referring to fig. 12A and 12B, the first security device 130 at level 1, which is used as a root of trust, can be connected to 3 second security devices 140_1 to 140_3, and performs authentication operation on the second security devices 140_1 to 140_3 at level 2. In addition, the second security device 140_1 may be connected to the third security device 170_1, and perform an authentication operation on the third security device 170_1 of the 3 rd order. The second security device 140_2 may be connected to the third security device 170_2 and perform an authentication operation on the third security device 170_2 of the 3 rd order. The second security device 140_3 may be connected to 2 third security devices 170_3 to 170_4, and perform authentication operations on the third security devices 170_3 to 170_4 of the 3 rd order.

In the device topologies of fig. 12A and 12B, the first security device 130 has the highest security priority level as the root of trust. In addition, the ith security device with higher security priority may be used to authenticate and control the jth security device with lower security priority, where i < j and i and j are integers greater than 0. In some embodiments, after the jth security device with a lower security priority level passes the authentication operation, the jth security device with a higher security priority level may provide the public key or public data to the jth security device with a lower security priority level. In addition, in some embodiments, the jth security device with a lower security priority level may report a security report message or interrupt event back to the ith security device with a higher security priority level.

It should be noted that, in addition to the image verification key used to verify the executable image, the key list of the security device may also include one or more public keys used to verify the credential data of the slave security device. Referring to fig. 12B, the credential data of the first secure device 130 as the root of trust may be referred to as root credential data, and the first secure device 130 needs to verify the root credential data with the public key PK6 in the otp memory to obtain the key list L5. The key list L5 includes two image verification keys and three public keys PK 7-PK 9. Three public keys PK7 to PK9 in the key list L5 are used to verify the credential data of the three second secure devices 140_1 to 140_3, respectively.

The key list L6 of the second secure device 140_1 includes the public key PK10 for verifying the credential data of the third secure device 170_1. Similarly, the key list L7 of the second secure device 140_2 includes the public key PK11 for verifying the credential data of the third secure device 170_2. The key list L8 of the second secure device 140_3 includes public keys PK12, PK13 to authenticate credential data of the third secure device 170_3, 170_4. Operations for verifying the credential data and obtaining the key list using the public key are described in the foregoing embodiments, and are not repeated here. Based on all the foregoing descriptions, a person of ordinary skill in the art can deduce how a master security device authenticates its slave security device.

In summary, in the embodiment of the present invention, by providing multiple security devices and performing authentication operations, the multiple trusted security devices can perform verification of executable images and other firmware security maintenance tasks. Therefore, the security of the platform and the executable image can be ensured, the executable image can not be maliciously tampered, and the problem that the resources of the existing security SoC are limited can be solved. In addition, because the device topology of the multi-safety device can be designed based on actual requirements, the chip of the verification safety system does not need to be redesigned, and the application flexibility can be greatly improved. In addition, since the multiple security devices can synchronously verify multiple executable images, the time of the security system chip operating in the phase of the PFR T-1 can be reduced, and the system start-up efficiency can be improved.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and not for limiting the same; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the invention.

Claims

1. An electronic circuit system, comprising:

a first host device;

A second host device;

A first security device connected to the first host device; and

A second security device connecting the second host device and the first security device,

Wherein the first secure device performs an authentication operation with the second secure device,

If the second security device passes the authentication operation, the first security device enables the second security device to verify the executable image of the second host device,

If the second security device fails the authentication operation, the first security device disables the second security device from verifying the executable image of the second host device.

2. The electronic circuitry of claim 1, further comprising:

a first storage device coupled to the first security device, storing an executable image of the first host device, wherein the first security device validates the executable image of the first host device; and

And the second storage device is connected with the second security device and stores the executable image of the second host device.

3. The electronic circuitry of claim 1, wherein the authentication operation comprises:

the first security device or the second security device generates a first random number;

The first security device generates a first key according to a first original key and the first random number, and the second security device generates a second key according to a second original key and the first random number;

The second security device encrypts a verification data by using the second key to generate encrypted verification data, and transmits the encrypted verification data to the first security device;

The first security device decrypts the encrypted authentication data using the first key to obtain decrypted authentication data; and

The first security device judges whether the second security device passes the authentication operation according to the decryption verification data.

4. The electronic circuitry of claim 3, wherein the authentication operation comprises:

if the decryption verification data is not qualified, the first safety device judges that the second safety device fails the authentication operation;

if the decryption verification data is qualified, the first safety device judges whether the device state information of the second safety device is qualified or not;

If the device state information of the second security device is not qualified, the first security device judges that the second security device fails the authentication operation; and

And if the device state information of the second safety device is qualified, the first safety device judges that the second safety device passes the authentication operation.

5. The electronic circuitry of claim 4, wherein the authentication operation comprises:

The second secure device encrypts the device state information of the second secure device using the second key to generate encrypted device state information;

the second secure device transmitting the encrypted device status information to the first secure device;

the first secure device decrypts the encrypted device state information using the first key to obtain the device state information for the second secure device.

6. The electronic circuit system of claim 3, wherein the verification data includes a second random number generated by the first secure device, the first secure device transmitting the second random number to the second secure device, the first secure device determining whether the decrypted verification data is identical to the second random number to determine whether the second secure device passes the authentication operation.

7. The electronic circuitry of claim 3, wherein the verification data includes credential data of the second security device, the first security device verifying whether the credential data of the second security device is acceptable using a public key to determine whether the second security device passes the authentication operation.

8. The electronic circuit system of claim 7, wherein the public key is recorded in root certificate data of the first security device, and wherein the public key is collected from the root certificate data after the first security device determines that the root certificate data is acceptable.

9. The electronic circuitry of claim 7, wherein the public key is recorded in a key list of the first security device, the first security device obtaining a list key of the key list after determining that the root credential data is acceptable, and obtaining the key list using the list key, the key list further comprising an image verification key to verify an executable image of the first host device.

10. The electronic circuitry of claim 3, wherein the authentication operation further comprises:

The first safety device judges whether the using times of the first secret key is larger than a preset value or not; and

And if the number of times of using the first secret key is larger than the preset value, the first security device or the second security device generates the first random number.

11. The electronic circuit system of claim 1, wherein the first security device performs the authentication operation on the second security device periodically or non-periodically.

12. The electronic circuitry of claim 1, wherein the first security device performs the authentication operation on the second security device in response to the electronic circuitry being powered up.

13. The electronic circuitry of claim 1, further comprising:

The third host device is configured to receive the first data,

A third security device connecting the third host device and the second security device,

If the second secure device passes the authentication operation, the second secure device performs the authentication operation on the third secure device,

If the third security device passes the authentication operation, the second security device enables the third security device to verify the executable image of the third host device.

14. A security rights issuing method applicable to an electronic circuit system including a first host, a second host, a first security device, and a second security device, the method comprising:

Performing an authentication operation on the second security device by the first security device, wherein the first security device is connected to the first host device and the second security device is connected to the second host device and the first security device;

If the second security device passes the authentication operation, enabling the second security device to verify the executable image of the second host device by the first security device; and

If the second security device fails the authentication operation, disabling the second security device by the first security device validates the executable image of the second host device.

15. The secure rights method of claim 14, wherein the step of performing the authentication operation by the first secure device on the second secure device comprises:

Generating a first random number by the first security device or the second security device;

Generating a first key by the first security device according to a first original key and the first random number, and generating a second key by the second security device according to a second original key and the first random number;

encrypting, by the second secure device, a verification data using the second key to generate encrypted verification data, and transmitting the encrypted verification data to the first secure device;

decrypting, by the first secure device, the encrypted authentication data using the first key to obtain decrypted authentication data; and

And judging whether the second safety device passes the authentication operation or not according to the decryption verification data by the first safety device.

16. The secure rights issuing method according to claim 15, wherein the step of determining, by the first secure device, whether the second secure device passes the authentication operation based on the decryption verification data comprises:

If the decryption verification data is qualified, judging whether the device state information of the second security device is qualified or not by the first security device;

And if the device state information of the second safety device is qualified, judging that the second safety device passes the authentication operation by the first safety device.

17. The method of claim 15, wherein the authentication data includes a second random number generated by the first security device,

Wherein the step of determining, by the first secure device, whether the second secure device passes the authentication operation based on the decryption verification data includes:

transmitting, by the first secure device, the second random number to the second secure device; and

Determining, by the first secure device, whether the decryption verification data is identical to the second random number to determine whether the second secure device passes the authentication operation.

18. The method of claim 15, wherein the authentication data includes credential data of the second security device,

Verifying, by the first secure device, whether the credential data of the second secure device is acceptable using a public key to determine whether the second secure device passes the authentication operation.

19. The method of claim 18, wherein the public key is recorded in a piece of credential data of the first secure device, and the step of verifying, by the first secure device, that the credential data of the second secure device is acceptable using the public key comprises:

the first security device collects the public key from the root certificate data after judging that the root certificate data is qualified.

20. The security rights issuing method of claim 18, wherein the public key is recorded in a key list of the first security device, the key list further comprising an image verification key used to verify an executable image of the first host device,

Wherein verifying, by the first secure device, whether the credential data of the second secure device is acceptable using the public key comprises:

and acquiring a list key of the key list after the first safety device judges that the root certificate data is qualified, and verifying and acquiring the key list by utilizing the list key.