bus system

Abstract

This invention provides a bus system. In this bus system, a memory element is electrically connected to a master element via a serial peripheral device interface bus. A plurality of slave elements are electrically connected to the master element via an enhanced serial peripheral device interface bus. Each slave element has a pin, and the pins of the plurality of slave elements are electrically connected together via a control line. After receiving program code from the memory element via the master element, a first slave element decrypts the program code according to a first security code and transmits the decrypted program code to the plurality of slave elements via the control line, so that the program code decrypted by the first security code is decrypted in a decryption order among the plurality of slave elements. This invention can increase the complexity of cracking firmware and improve the security of the bus system.

Description

Technical Field

[0001] This invention relates to a bus system, and more particularly to a security scheduling of a bus system having multiple slave elements. Background Technology

[0002] In the past, in computer systems, chipsets such as the southbridge chip connected to other circuit modules, such as system-on-a-chips (SoCs) with different functions, via a low pin count (LPC) interface. These external circuit modules connected through the LPC interface were assigned different independent addresses, allowing the southbridge chip to communicate with them in a one-to-many manner. However, in recent years, some newly proposed bus architectures, such as the Enhanced Serial Peripheral Interface (eSPI) bus, only allow communication between the chipset and external circuit modules in a one-to-one mechanism. Furthermore, in bus architectures, communication between multiple circuit modules needs to be secure to prevent data from being compromised during transmission.

[0003] Therefore, a bus system is needed that can provide secure scheduling for multiple circuit modules. Summary of the Invention

[0004] This invention provides a bus system. The bus system includes a master element, an enhanced serial peripheral device interface bus, a serial peripheral device interface bus, a memory element, and a plurality of slave elements. The memory element is electrically connected to the master element via the serial peripheral device interface bus. The plurality of slave elements are electrically connected to the master element via the enhanced serial peripheral device interface bus. Each slave element has a pin, and the pins of the plurality of slave elements are electrically connected together via a control line. After receiving program code from the memory element via the master element, a first slave element decrypts the program code according to a first security code and transmits the decrypted program code to the plurality of slave elements via the control line, so that the program code decrypted by the first security code is decrypted in a decryption order among the plurality of slave elements.

[0005] Furthermore, the present invention provides a bus system. This bus system includes a master element, an enhanced serial peripheral device interface bus, a serial peripheral device interface bus, a memory element, and a plurality of slave elements. The plurality of slave elements are electrically connected to the master element via the enhanced serial peripheral device interface bus. The memory element is electrically connected to the plurality of slave elements via the serial peripheral device interface bus. Each slave element has a pin, and the plurality of pins of the plurality of slave elements are electrically connected together via a control line. After receiving program code from the memory element, a first slave element of the plurality of slave elements decrypts the program code according to a first security code, and transmits the program code decrypted by the first security code to the plurality of slave elements via the control line, so that the program code decrypted by the first security code is decrypted in a decryption order among the plurality of slave elements.

[0006] This invention utilizes multiple slave elements to decrypt firmware stored in external memory, increasing the complexity of firmware cracking. For example, it is impossible to crack the stored firmware by monitoring only a single slave element. In other words, the decryption order required for each slave element is known to crack the firmware, thus improving the security of the bus system. In some embodiments, the decryption actions of each slave element can be performed simultaneously to increase the efficiency of decryption verification. Attached Figure Description

[0007] Figure 1 This illustrates a bus system according to some embodiments of the present invention.

[0008] Figure 2 This illustrates a bus system according to some embodiments of the present invention.

[0009] Figure 3 This invention illustrates a security scheduling control method for 3DES decryption of a bus system according to some embodiments of the present invention.

[0010] Figure 4 This illustrates the performance of a bus system according to some embodiments of the present invention. Figure 3 The message sequence diagram of the security scheduling control method.

[0011] Figure 5 This invention illustrates a security scheduling control method for multi-table encryption in a bus system according to some embodiments of the present invention.

[0012] Figure 6 This illustrates the performance of a bus system according to some embodiments of the present invention. Figure 5 The message sequence diagram of the security scheduling control method.

[0013] Figure 7This illustrates a security scheduling control method for salted encryption of a bus system according to some embodiments of the present invention.

[0014] Figure 8 This illustrates the performance of a bus system according to some embodiments of the present invention. Figure 7 The message sequence diagram of the security scheduling control method.

[0015] Figure 9 This diagram shows the connection configuration of a bus system according to some embodiments of the present invention.

[0016] Symbol explanation:

[0017] 1, 1A, 1B: Bus system

[0018] 10: Main control components

[0019] 12, 16: Bus

[0020] 14A-14D, 14_1-14_n: Slave elements

[0021] 20: Processing Module

[0022] 22: Memory

[0023] 24: Memory elements

[0024] 144_1-144_n: Safety Scheduling Controller

[0025] 146_1-146_n: eSPI scheduling controller

[0026] Alert_1-Alert_n: Alert handshake pins

[0027] ALERT_HAND: Warning handshake control line

[0028] BIOS: Basic Input / Output System

[0029] FW1-FWn: Firmware

[0030] IP1-IPn: Security Code

[0031] S302-S318, S502-S524, S710-S760: Steps

[0032] 410-460, 602-622, 802-850: Message sequence Detailed Implementation

[0033] To make the above and other objects, features, and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings:

[0034] Figure 1 This illustrates a bus system 1 according to some embodiments of the present invention. The bus system 1 includes a master element 10, a bus 12, and multiple slave elements 14A-14D. In some embodiments, the master element 10 is a chipset such as a southbridge chip. In some embodiments, the master element 10 may be electrically connected to a processing module 20 of a computer system (not shown) to access data with the slave elements 14A-14D via the bus 12 in response to instructions from the processing module 20. In some embodiments, the processing module 20 may be electrically connected to a memory 22 of the computer system to access the memory 22 according to the needs of different applications. In some embodiments, the bus 12 is an Enhanced Serial Peripheral Interface (eSPI) bus. The master element 10 is electrically connected to the slave elements 14A-14D via the bus 12. Furthermore, the master element 10 communicates with the slave elements 14A-14D via eSPI in a one-to-one mechanism, while the slave elements 14A-14D communicate with the master element 10 according to an arbitration mechanism. It is worth noting that the number of slave elements 14A-14D is merely an example and is not intended to limit the invention.

[0035] In some embodiments, bus 12 includes a reset signal line, a chip select signal line, a clock signal, and input / output signal lines (not shown). For example, master element 10 can communicate with slave elements 14A-14D in a one-to-one eSPI mechanism via the chip select signal line of bus 12. Furthermore, through an arbitration mechanism, slave elements 14A-14D can communicate with master element 10 via the input / output signal lines of bus 12 (e.g., to transfer data and instructions). When master element 10 communicates with slave elements 14A-14D via bus 12, the clock signal of bus 12 can be used as a reference clock.

[0036] Generally, based on the operation mechanism of the chip select signal line of bus 12, the master element 10 can only select a single slave element for eSPI communication. However, by using an arbitration mechanism, only one of the slave elements 14A-14D responds to the master element 10 at a time in bus system 1. Therefore, while the master element 10 still operates in a one-to-one communication mechanism, bus 12 can connect slave elements 14A-14D to perform eSPI communication according to the chip select signal line, thereby improving the scalability of bus system 1.

[0037] Figure 2This illustrates a bus system 1A according to some embodiments of the present invention. The master element 10 is electrically connected to slave elements 14_1-14_n via bus 12. As previously described, bus 12 is an eSPI bus. Furthermore, the master element 10 is electrically connected to memory element 24 via bus 16. Figure 2 In this configuration, bus 16 is an SPI bus, and memory element 24 is a flash memory. Furthermore, memory element 24 is used to store the Basic Input / Output System (BIOS) of the master control element 10 and the firmware FW1-FWn of the slave elements 14_1-14_n. In some embodiments, the BIOS of the master control element 10 and the firmware FW1-FWn of the slave elements 14_1-14_n are stored in different memory elements.

[0038] exist Figure 2 In this configuration, the Alert_1-Alert_n pins of slave components 14_1-14_n are electrically connected to each other on the Alert_HAND control line. In some embodiments, the Alert_HAND control line is electrically connected to power supply VDD (not shown) via a pull-up resistor (not shown) to set the Alert_HAND control line to a high voltage level (e.g., a high logic signal "H"). In some embodiments, the Alert_HAND control line is electrically connected to ground GND (not shown) via a pull-down resistor (not shown) to set the Alert_HAND control line to a low voltage level (e.g., a low logic signal "L"). In some embodiments, the Alert_1-Alert_n pins are bidirectional input / output pins and are open-drain in output mode.

[0039] exist Figure 2In this configuration, each slave element 14_1-14_n includes its own eSPI scheduling controller 146_1-146_n. Taking slave element 14_1 as an example, the eSPI scheduling controller 146_1 of slave element 14_1 can control slave element 14_1 to communicate with master element 10 via bus 12 using eSPI. For example, when slave element 14_1 communicates with master element 10, eSPI scheduling controller 146_1 can control slave element 14_1 to receive instructions and data from master element 10 via bus 12 and provide the corresponding data to master element 10. Furthermore, the eSPI scheduling controllers 146_1-146_n within the slave elements 14_1-14_n can drive the alert handshake control line ALERT_HAND by controlling the corresponding alert handshake pins Alert_1-Alert_n to a specific voltage level (e.g., low logic signal "L" or high logic signal "H"), thereby setting the alert handshake control line ALERT_HAND to a specific voltage level (e.g., low voltage level or high voltage level). Thus, each slave element 14_1-14_n can gain the right to actively communicate with the master element 10 by controlling the voltage level of the alert handshake control line ALERT_HAND.

[0040] Furthermore, each subordinate element 14_1-14_n further includes its own security scheduling controller 144_1-144_n and a corresponding security code IP1-IPn. In some embodiments, the security codes IP1-IPn are completely different. In some embodiments, some of the security codes IP1-IPn are the same.

[0041] Taking slave element 14_1 as an example, the security scheduling controller 144_1 of slave element 14_1 can control slave element 14_1 to conduct secure communication with other slave elements 14_2-14_n and / or peripheral elements (not shown) via the alert handshake control line ALERT_HAND. For example, in slave element 14_1, the security scheduling controller 144_1 can encrypt or decrypt data according to security code IP1, and then transmit the encrypted or decrypted data to the corresponding slave element via the alert handshake control line ALERT_HAND. In some embodiments, security codes IP1-IPn are pre-stored security codes, keys, or identification codes. Furthermore, slave elements 14_1-14_n can use known security algorithms to perform multiple encryption / decryption processes on the data.

[0042] In bus system 1A, slave element 14_1 can first drive the alert handshake control line ALERT_HAND via the Alert_1 pin to gain the right to actively communicate with master element 10. Next, slave element 14_1 sends an interrupt request to master element 10 via bus 12, requesting master element 10 to retrieve the encrypted firmware FW1 from memory element 24 and send the encrypted firmware FW1 to slave element 14_1. After receiving the encrypted firmware FW1 via bus 12, the security scheduling controller 144_1 of slave element 14_1 decrypts the encrypted firmware FW1 according to security code IP1 and performs subsequent decryption (or decoding) processes. For example, for firmware FW1 from master element 10, security scheduling controller 144_1 will transmit the firmware FW1, decrypted by security code IP1, to a specific slave element via the alert handshake control line ALERT_HAND for further decryption. Next, the firmware FW1, which has been decrypted by security code IP1, is received from slave element 14_1. The security scheduling controller of this specific slave element will use its own security code to decrypt the firmware FW1 and then transmit the decrypted firmware FW1 to other slave elements through the alert handshake control line ALERT_HAND for further decryption.

[0043] It is worth noting that the order in which firmware FW1 is transmitted between slave elements 14_1-14_n via the ALERT_HAND control line is determined by the encryption order of firmware FW1. Furthermore, the decryption order is the reverse of the encryption order, and the encryption / decryption order will be described later. Additionally, the encryption / decryption order can be adjusted according to the actual application. Finally, the multi-decrypted firmware FW1 is transmitted back to slave element 14_1 via the ALERT_HAND control line. Slave element 14_1 then uses security code IP1 to perform a final decryption of the received firmware FW1 to reply with firmware FW1. After completing the decryption of firmware FW1, slave element 14_1 stores firmware FW1 and performs corresponding operations based on firmware FW1.

[0044] Similarly, other slave elements 14_2-14_n can also issue interrupt requests to the master element 10 to request it to transmit its own firmware. This firmware is also transmitted and decrypted between slave elements 14_1-14_n in a specific decryption order via the ALERT_HAND control line. Thus, all slave elements 14_1-14_n will eventually obtain the multi-decrypted firmware FW1-FWn.

[0045] In the embodiments of the present invention, the transmission of encrypted and / or decrypted data by slave elements 14_1-14_n on the ALERT_HAND control line is merely an example. In other embodiments, slave elements 14_1-14_n may transmit encrypted and / or decrypted data on other signal lines, such as serial signal lines like I2C, UART, and SPI.

[0046] The following examples illustrate various encryption algorithms used in bus system 1A. It should be noted that the algorithms described below are for illustrative purposes only, and the present invention is not limited to the algorithms illustrated.

[0047] Triple Data Encryption Standard (3DES), also known as Triple Data Encryption Algorithm (TDEA), is a symmetric-key encryption algorithm. The 3DES algorithm encrypts data using the DES algorithm three times, with a different key for each encryption, resulting in higher encryption security than the standard DES algorithm. The operation of the 3DES algorithm can be expressed as the following formula (1):

[0048] Y = E3(E2(E1(X))) (1)

[0049] Where E represents the encryption action, X represents the original data, and Y represents the encrypted data after the 3DES algorithm is applied. Furthermore, the encryption order of 1, 2, 3 is merely illustrative and not intended to limit the scope of this invention.

[0050] In some embodiments, in order to use different security IPs for encryption and ultimately return the firmware to its original owner, equation (1) can be rewritten as the following equation (2):

[0051] Y1=E1(E3(E1(X1))) (2)

[0052] Here, it is assumed that slave element 14_1 represents the slave element corresponding to the firmware (e.g., firmware FW1), and slave element 14_3 represents another slave element that assists in performing encryption (hereinafter also referred to as a specific slave element). Thus, the encryption order is from slave element 14_1 to slave element 14_3, and then back to slave element 14_1. In other words, the encrypted firmware FW1 (i.e., Y1) stored in memory element 24 is generated by encrypting firmware X1 of slave element 14_1 with security code IP1 of slave element 14_1, then with security code IP3 of slave element 14_3, and then with security code IP1 of slave element 14_1 again. Therefore, the encrypted firmware FW1 stored in memory element 24 can be decrypted by the following formula (3):

[0053] X1=D1(D3(D1(Y1))) (3)

[0054] Where D represents the decryption action. In other words, the encrypted firmware FW1 (i.e. Y1) stored in memory element 24 needs to be decrypted by the security code IP1 of slave element 14_1, then by the security code IP3 of slave element 14_3, and finally by the security code IP1 of slave element 14_1 again before the firmware FW1 (i.e. Y1) can be restored to the original firmware X1 of slave element 14_1.

[0055] Figure 3 This illustrates a security scheduling control method for 3DES decryption of a bus system 1A according to some embodiments of the present invention. Figure 3 The safety scheduling control method can be executed by each safety scheduling controller 144_1-144_n of the slave elements 14_1-14_n in the bus system 1A.

[0056] First, in step S302, one of the slave elements receives the encrypted firmware. Next, in step S304, the slave element determines whether the encrypted firmware was provided by the master element 10 via bus 12. In some embodiments, in step S304, the slave element determines whether the encrypted firmware originates from memory element 24. If the encrypted firmware was provided by the master element 10, the slave element decrypts the received encrypted firmware according to its own security code IP (step S306), and transmits the firmware decrypted by the security code IP to a specific slave element (e.g., the Kth slave element) according to the decryption order (step S308) for subsequent decryption. If the encrypted firmware was not provided by the master element 10, the slave element further determines whether the encrypted firmware was provided by a specific slave element (step S310). If the encrypted firmware is provided by another slave element (e.g., the Mth slave element) via the ALERT_HAND control line, that slave element will decrypt the received firmware according to its own security code IP (step S312), and transmit the decrypted firmware back to other slave elements (e.g., back to the Mth slave element) according to the decryption order (step S314) for subsequent decryption procedures. Conversely, if the encrypted firmware is provided by a specific slave element via the ALERT_HAND control line, that slave element will decrypt the received encrypted firmware according to its own security code IP (step S316). Thus, all firmware decryption steps are completed, and the restored firmware is stored in the slave element (step S318). Next, the slave element will perform corresponding operations based on the stored firmware.

[0057] Figure 4 The bus system 1A according to some embodiments of the present invention is performing... Figure 3 The message sequence chart (MSC) of the security scheduling control method.

[0058] Also refer to Figure 3 and Figure 4First, slave element 14_1 sends an interrupt request to master element 10 to obtain the encrypted firmware Y1 (i.e., FW1) stored in memory element 24 via master element 10, as shown in reference numeral 410. Since the encrypted firmware Y1 comes from master element 10 / memory element 24 (step S304), slave element 14_1 will use security code IP1 to decrypt firmware Y1 for the first time (step S306) to obtain firmware D1 (Y1), as shown in reference numeral 420. Next, according to the decryption order, the specific slave element can be identified as slave element 14_3, so slave element 14_1 will transmit firmware D1 (Y1) to slave element 14_3 via the alert handshake control line ALERT_HAND (step S308), as shown in reference numeral 430. Next, corresponding to the received firmware D1(Y1), slave element 14_3 uses security code IP3 to perform a second decryption of firmware D1(Y1) (step S312) to obtain firmware D3(D1(Y1)), as shown in label 440. Then, according to the decryption sequence, slave element 14_3 transmits firmware D3(D1(Y1)) back to slave element 14_1 via the ALERT_HAND control line (step S314), as shown in label 450. When slave element 14_1 receives firmware D3(D1(Y1)) transmitted from slave element 14_3, slave element 14_1 uses security code IP1 to perform a final decryption of firmware D3(D1(Y1)) (step S316) to obtain the decrypted firmware X1, as shown in label 460. Thus, firmware Y1 has completed all the necessary decryption procedures and is restored to firmware X1. Next, the slave element 14_1 stores the firmware X1 in its own storage (e.g., memory) and performs the corresponding operation according to the stored firmware X1.

[0059] Polyalphabetic cipher is a substitution cipher algorithm that uses a different cipher table for each substitution, and these cipher tables are used in a specific order. When the number of substitutions exceeds the limit set by the specific order, the specific order is used again to replace the cipher, so as to achieve a higher level of security than general substitution algorithms. The operation of polyalphabetic cipher can be represented by the following formula (4):

[0060] Y=…E1(E3(E2(E4(E1(X)))))… (4)

[0061] Where E represents the encryption action, X represents the original data, and Y represents the encrypted data after the multi-table encryption algorithm is applied. Furthermore, the encryption order of 1, 4, 2, 3, 1 is merely an example and not intended to limit the scope of this invention.

[0062] In some embodiments, in order to use different security IPs for encryption and ultimately return to the original owner of the firmware, equation (4) can be rewritten as the following equation (5):

[0063] Y1=E1(…E1(E3(E2(E4(E1(X1)))))…) (5)

[0064] │←Loop t times→│

[0065] Here, it is assumed that slave element 14_1 represents the slave element corresponding to the firmware (e.g., firmware FW1), while slave elements 14_2-14_4 represent other slave elements that assist in performing encryption. In other words, the encrypted firmware FW1 (i.e., Y1) stored in memory element 24 is encrypted by the firmware X1 of slave element 14_1 through the security code IP1 of slave element 14_1, and then sequentially through the security code IP4 of slave element 14_4, the security code IP2 of slave element 14_2, and the security code IP3 of slave element 14_3 (i.e., the specific slave element), and then through the security code IP1 of slave element 14_1. After looping t times, it is finally encrypted again through the security code IP1 of slave element 14_1 to obtain the encrypted firmware Y1, where t can be any integer. In some embodiments, the number of loops can be determined according to the actual application. Therefore, the encrypted firmware FW1 stored in memory element 24 can be decrypted by the following formula (6):

[0066] X1=D1(…D1(D4(D2(D3(D1(Y1)))))…) (6)

[0067] │←Loop t times→│

[0068] Where D represents the decryption action. In other words, the encrypted firmware FW1 (i.e., Y1) stored in memory element 24 needs to be decrypted by security code IP1 of slave element 14_1, then sequentially by security code IP3 of slave element 14_3, security code IP2 of slave element 14_2, and security code IP4 of slave element 14_4, and this process is repeated t times. Finally, after being decrypted by security code IP1 of slave element 14_1, firmware FW1 (i.e., Y1) can be restored to the original firmware X1 of slave element 14_1.

[0069] Figure 5 This illustrates a security scheduling control method for multi-table encryption in a bus system 1A according to some embodiments of the present invention. Figure 5 The safety scheduling control method can be executed by each safety scheduling controller 144_1-144_n of the slave elements 14_1-14_n in the bus system 1A.

[0070] First, in step S502, one of the slave elements receives the encrypted firmware. Then, in step S504, the slave element determines whether the encrypted firmware is provided by the master element 10 via the bus 12 (step S504). In some embodiments, in step S504, the slave element determines whether the encrypted firmware comes from the memory element 24. If the encrypted firmware is provided by the master element 10, the slave element decrypts the received encrypted firmware according to its own security code IP (step S506), and resets the count value CO to 0 (step S508), that is, CO=0. Then, the slave element transmits the firmware decrypted by the security code IP to the next slave element according to the decryption sequence (step S510), so as to perform a subsequent decryption process. Conversely, if the encrypted firmware is not provided by the master element 10, the slave element further determines whether the encrypted firmware is provided by a specific slave element (step S512). If the encrypted firmware is provided by another slave element via the alert handshake control line ALERT_HAND, that is, not provided by a specific slave element, the slave element decrypts the received firmware according to its own security code IP (step S514), and transmits the firmware decrypted by the security code IP to the next slave element according to the decryption sequence (step S516), so as to perform a subsequent decryption process. Conversely, if the encrypted firmware is provided by a specific slave element via the alert handshake control line ALERT_HAND, the received encrypted firmware is decrypted according to its own security code IP (step S518). Then, the count value CO is incremented by one to update the count value CO (step S520), that is, CO=CO+1, and it is determined whether the updated count value CO is equal to the cycle number t (step S522). If the count value CO is not equal to the cycle number t (for example, CO<t), the slave element transmits the firmware decrypted by the security code IP to the next slave element according to the decryption sequence (step S510), so as to perform a subsequent decryption process. If the count value CO is equal to the cycle number t (that is, CO=t), all decryption steps of the firmware are completed, and the restored firmware is stored in the slave element (step S524). Then, the slave element performs corresponding operations according to the stored firmware.

[0071] Figure 6 shows a sequence diagram executed by the bus system 1A according to some embodiments of the present invention Figure 5 of the security scheduling control method.

[0072] referring simultaneously to Figure 5 and Figure 6First, slave element 14_1 sends an interrupt request to master element 10 to obtain the encrypted firmware Y1 (i.e., FW1) stored in memory element 24 via master element 10, as shown in reference numeral 602. Since the encrypted firmware Y1 comes from master element 10 / memory element 24 (step S504), slave element 14_1 decrypts firmware Y1 using security code IP1 (step S506) to obtain firmware D1 (Y1), as shown in reference numeral 604. Next, slave element 14_1 resets the counter value CO to 0 (step S508), i.e., CO = 0, and transmits firmware D1 (Y1) to slave element 14_3 via the alert handshake control line ALERT_HAND according to the decryption order (step S510), as shown in reference numeral 606. Next, for slave element 14_3, since slave element 14_1 is not the corresponding specific slave element, slave element 14_3 will use security code IP3 to decrypt firmware D1(Y1) (step S514) to obtain firmware D3(D1(Y1)), as shown in reference numeral 608. Then, according to the decryption sequence, slave element 14_3 will transmit firmware D3(D1(Y1)) to slave element 14_2 via the alert handshake control line ALERT_HAND (step S516), as shown in reference numeral 610. Next, slave element 14_2 will use security code IP2 to decrypt firmware D3(D1(Y1)) (step S514) to obtain firmware D2(D3(D1(Y1))), as shown in reference numeral 612.

[0073] Next, according to the decryption sequence, slave element 14_2 transmits firmware D2(D3(D1(Y1))) to slave element 14_4 via the ALERT_HAND control line (step S516), as shown in label 614. Next, slave element 14_4 decrypts firmware D2(D3(D1(Y1))) using security code IP4 (step S514) to obtain firmware D4(D2(D3(D1(Y1)))), as shown in label 616. Next, according to the decryption sequence, slave element 14_4 transmits firmware D4(D2(D3(D1(Y1)))) to slave element 14_1 via the ALERT_HAND control line (step S516), as shown in label 618. When slave element 14_1 receives firmware D4(D2(D3(D1(Y1)))) from slave element 14_4 (a specific slave element), slave element 14_1 uses security code IP1 to decrypt firmware D4(D2(D3(D1(Y1)))) to obtain firmware D1(D4(D2(D3(D1(Y1)))) (step S518), and updates the count value CO to 1 (step S520). Since the count value CO is not equal to the loop count t (step S522), slave element 14_1 will transmit firmware D1(D4(D2(D3(D1(Y1))))) to slave element 14_3 according to the decryption order (step S510) to perform the next loop of decryption, until the count value CO equals the loop count t. Thus, firmware Y1 has completed all the necessary decryption procedures and is restored to firmware X1, as shown by label 622. Next, the slave element 14_1 stores the firmware X1 in its own storage (e.g., memory) and performs the corresponding operation according to the stored firmware X1.

[0074] Salt encryption is an algorithm used for encrypting data multiple times. It adds a different salt value before each encryption, making the encrypted data more complex and harder to crack, thus providing higher security than general multiple encryption algorithms. The operation of salt encryption can be represented by the following formula (7):

[0075] Y=E1(E1(…E1(E1(X+S1)+S2)…)+S t (7)

[0076] Where E represents the encryption action, X represents the original data, and Y represents the encrypted data after applying the salt encryption algorithm. Furthermore, S represents the salt value added during encryption, and t represents the number of encryption attempts.

[0077] In some embodiments, the salt value S can be set as the next subordinate element that needs to be known during decryption, and the last time, a salt value of S of 0 is required to determine that decryption is complete. In other words, the decryption order can be determined by the salt value S. In other embodiments, salt values ​​S with different functions can be designed in a suitable manner.

[0078] In some embodiments, in order to use different security IPs for encryption and ultimately return to the original owner of the firmware, equation (7) can be rewritten as the following equation (8):

[0079] Y1=E1(E3(…E4(E1(E3(E2(E4(E4(E1(X1+0)+1)+4)+2)+3)+1)…)+3) (8)

[0080] It is assumed that slave element 14_1 represents the slave element corresponding to the firmware (e.g., firmware FW1), while slave elements 14_2-14_4 represent other slave elements assisting in the encryption process. Furthermore, the encryption order 1, 4, 2, 3, 1 is merely illustrative and not intended to limit the invention. Additionally, the initial salt value S is set to 0, which can be used to determine whether decryption is complete. In other words, the encrypted firmware FW1 (i.e., Y1) stored in memory element 24 is encrypted by adding a salt value (0) to firmware X1 of slave element 14_1, i.e., salt value S = 0, and then encrypting it using the security code IP1 of slave element 14_1. Next, after adding a salt value (1), i.e., salt value S = 1, it is encrypted using the security code IP4 of slave element 14_4. Then, after adding a salt value (4), i.e., salt value S = 4, it is encrypted using the security code IP2 of slave element 14_2. Next, after adding salt value (2), i.e., salt value S = 2, it is encrypted by security code IP3 of slave element 14_3. Next, after adding salt value (3), i.e., salt value S = 3, it is encrypted by security code IP1 of slave element 14_1. Similar to the multi-table encryption method, the salting encryption algorithm can also be looped a specific number of times, i.e., the number of loops t. After looping t times, the data encrypted by security code IP3 of slave element 14_3 will be added with salt value (3). Finally, it is encrypted by security code IP1 of slave element 14_1 to obtain the encrypted firmware Y1, where t can be any integer. In some embodiments, the number of loops can be determined according to the actual application. Therefore, the encrypted firmware FW1 stored in memory element 24 can be decrypted by the following formula (9):

[0081] X1=D1(D4(…D3(D1(D4(D2(D3(D1(Y1)-3)-2)-4)-1)-3)…)-1)-0 (9)

[0082] Where D represents the decryption action.

[0083] In other words, the encrypted firmware FW1 (i.e., Y1) stored in memory element 24 needs to be decrypted by the security code IP1 of slave element 14_1 to obtain a salt value (3), so that the firmware after being decrypted by security code IP1 can be transmitted to slave element 14_3 corresponding to the salt value (3). Similarly, after being decrypted by the security code IP3 of slave element 14_3, a salt value (2) can be obtained, and then the firmware after being decrypted by security code IP3 can be transmitted to slave element 14_2 corresponding to the salt value (2), and so on. Finally, after being decrypted by the security code IP1 of slave element 14_1, a salt value (0) can be obtained, so that firmware FW1 (i.e., Y1) can be restored to the original firmware (X1) of slave element 14_1.

[0084] Figure 7 This illustrates a salted encryption security scheduling control method for a bus system 1A according to some embodiments of the present invention. Figure 7 The safety scheduling control method can be executed by each safety scheduling controller 144_1-144_n of the slave elements 14_1-14_n in the bus system 1A.

[0085] First, in step S710, one of the slave elements receives the encrypted firmware. Next, the slave element decrypts the received firmware using its own security code IP (step S720) and obtains / extracts the salt value S from the decrypted firmware (step S730). In some embodiments, the salt value S is obtained from specific bits of the firmware. Next, in step S740, the slave element determines whether the salt value S is 0. If the salt value S is not 0, the slave element transmits the firmware decrypted by the security code IP to the slave element corresponding to the salt value S (step S750) for subsequent decryption. If the salt value S is 0, all decryption steps of the firmware are completed, and the restored firmware is stored in the slave element (step S760). Then, the slave element performs corresponding operations based on the stored firmware.

[0086] Figure 8 The bus system 1A according to some embodiments of the present invention is performing... Figure 7 The message sequence diagram of the security scheduling control method.

[0087] Also refer to Figure 7 and Figure 8First, slave element 14_1 sends an interrupt request to master element 10 to obtain the encrypted firmware Y1 (i.e., firmware FW1) stored in memory element 24 via master element 10, as shown in reference numeral 802. Next, slave element 14_1 decrypts firmware Y1 using security code IP1 (step S720) to obtain firmware D1 (Y1), and obtains a salt value S of 3 from firmware D1 (Y1) (step S730), as shown in reference numeral 804. Then, slave element 14_1 transmits firmware D1 (Y1) to slave element 14_3 via the alert handshake control line ALERT_HAND based on the salt value S of 3 (step S750), as shown in reference numeral 806. Next, slave element 14_3 uses security code IP3 to decrypt firmware D1(Y1) with the known salt value S removed (step S720) to obtain firmware D3(D1(Y1)-3), and obtains the salt value S as 2 from the firmware (step S730), as shown by reference numeral 808. In some embodiments, each slave element first removes the known salt value S from the firmware, and then transmits the salt-removed firmware to the next slave element.

[0088] Next, slave element 14_3 transmits firmware D3(D1(Y1)-3) to slave element 14_2 via the alert handshake control line ALERT_HAND based on a salt value S of 2 (step S750), as shown in reference numeral 810. Next, slave element 14_2 decrypts firmware D3(D1(Y1)-3) with the known salt value S of 2 removed using security code IP2 to obtain firmware D2(D3(D1(Y1)-3)-2), and obtains a salt value S of 4 from this firmware, as shown in reference numeral 812. Next, slave element 14_2 transmits firmware D2(D3(D1(Y1)-3)-2) to slave element 14_4 via the alert handshake control line ALERT_HAND based on a salt value S of 4, as shown in reference numeral 814. Next, slave element 14_4 uses security code IP4 to decrypt firmware D2(D3(D1(Y1)-3)-2) with the known salt value S=4 removed, obtaining firmware D4(D2(D3(D1(Y1)-3)-2)-4), and obtains a salt value S=1 from this firmware, as shown in label 816. Then, slave element 14_4 transmits firmware D4(D2(D3(D1(Y1)-3)-2)-4) to slave element 14_1 via the alert handshake control line ALERT_HAND, based on the salt value S=1, as shown in label 818. Next, slave element 14_1 uses security code IP1 to decrypt firmware D4(D2(D3(D1(Y1)-3)-2)-4) with the known salt value S removed (which is 1) to obtain firmware D1(D4(D2(D3(D1(Y1)-3)-2)-4)-1), and obtains a salt value S of 3 from this firmware, as shown in label 820. This process continues until slave element 14_1 obtains a salt value of 0 from the decrypted firmware. Thus, firmware Y1 has completed all the necessary decryption procedures and is restored to firmware X1, as shown in label 850. Slave element 14_1 then stores firmware X1 in its own storage (e.g., memory) and performs corresponding operations based on the stored firmware X1.

[0089] Figure 9 This diagram shows the connection configuration of the bus system 1B according to some embodiments of the present invention. The master control element 10 is electrically connected to the slave elements 14_1-14_n via bus 12. As previously described, bus 12 is an eSPI bus. Furthermore, the slave elements 14_1-14_n are electrically connected to the memory element 24 via bus 16. As previously described, the memory element 24 is used to store the BIOS of the master control element 10 and the firmware FW1-FWn of the slave elements 14_1-14_n, etc.

[0090] Similarly, in bus system 1B, each security scheduling controller 144_1-144_n of slave elements 14_1-14_n can perform... Figure 3 , Figure 5 and Figure 7 The security scheduling control method performs multiple decryptions on the BIOS and firmware FW1-FWn stored in memory element 24.

[0091] Compared to Figure 2 The bus system 1A, in Figure 9 In the bus system 1B, the master control element 10 is not electrically connected to the memory element 24. Therefore, before the master control element 10 accesses the BIOS, firmware FW1-FWn, or other data stored in the memory element 24, the slave elements 14_1-14_n can perform multiple security decryption verifications on the BIOS and firmware FW1-FWn. Finally, one of the slave elements 14_1-14_n transmits the security-verified BIOS to the master control element 10 via bus 12, so that the master control element 10 can perform the boot procedure.

[0092] In this embodiment of the invention, decrypting firmware stored in an external memory element using multiple slave elements increases the complexity of cracking the firmware. For example, it is impossible to crack the stored firmware by monitoring only a single slave element. In other words, the decryption order required for each slave element is known to crack the firmware, thus improving the security of the bus system. In some embodiments, the decryption actions of each slave element can be performed simultaneously to increase the efficiency of decryption verification. Furthermore, each slave element transmits encrypted / decrypted data via the ALERT_HAND control line, thus not affecting the efficiency of communication between the slave element and the master element.

[0093] Although the present invention has been described above with reference to preferred embodiments, it is not intended to limit the invention. Anyone skilled in the art, including those skilled in the art, may make some modifications and refinements without departing from the spirit and scope of the invention. Therefore, the scope of protection of the present invention shall be determined by the claims.

Claims

1. A bus system, characterized in that, include: One main control component; An enhanced serial peripheral device interface bus; A series of peripheral device interface buses; A memory element is electrically connected to the main control element via the peripheral device interface bus of the sequence; as well as Multiple slave components are electrically connected to the master control component via the enhanced sequence peripheral device interface bus; The plurality of slave elements have a plurality of pins, and each slave element corresponds to each pin, and the plurality of pins of the plurality of slave elements are electrically connected together via a control line; Each of these subordinate elements includes: A first scheduling controller, configured to control the control line to a specific voltage level via the corresponding pin, so that the slave element can communicate with the master element via the enhanced sequence peripheral device interface bus; and A second scheduling controller is configured to control the control line to transmit or receive data via the corresponding pin, so that the slave element can communicate with other slave elements via the control line; Wherein, after the first scheduling controller of a first slave element of the plurality of slave elements controls the control line to the specific voltage level and obtains a program code from the memory element via the master control element, the first slave element decrypts the program code according to a first security code, and controls the control line via the second scheduling controller to transmit the program code decrypted by the first security code to the plurality of slave elements, so that the program code decrypted by the first security code is decrypted in the plurality of slave elements in a decryption order.

2. The bus system as described in claim 1, characterized in that, When the first slave element receives program code decrypted by a second slave element from the plurality of slave elements via the control line, the first slave element decrypts the program code decrypted by the second security code again according to the first security code, and stores the decrypted program code as the firmware of the first slave element.

3. The bus system as described in claim 1, characterized in that, When a third slave element of the plurality of slave elements receives the program code that has been decrypted by the first security code from the first slave element via the control line, the third slave element decrypts the program code that has been decrypted by the first security code according to a third security code, and transmits the program code that has been decrypted by the third security code to the other plurality of slave elements via the control line according to the decryption order.

4. The bus system as described in claim 3, characterized in that, When the first slave element receives the program code, which has been decrypted by the third security code, from the third slave element via the control line, the first slave element decrypts the program code, which has been decrypted by the third security code, according to the first security code, and counts the number of times the program code is decrypted again using the first security code.

5. The bus system as described in claim 4, characterized in that, When the number of loops reaches a specific value, the first slave element stores the re-decrypted program code as the firmware of the first slave element. When the number of loops does not reach the specific value, the first slave element transmits the re-decrypted program code to the plurality of slave elements via the control line, so that the program code that has been re-decrypted by the first security code is decrypted in the plurality of slave elements in the order of decryption.

6. The bus system as described in claim 1, characterized in that, The first slave element obtains a first salt value from the program code that has been decrypted by the first security code, and transmits the program code that has been decrypted by the first security code to the slave element corresponding to the first salt value via the control line. When the first slave element receives the program code that has been decrypted by a second slave element from the plurality of slave elements via the control line, the first slave element decrypts the program code that has been decrypted by the second security code again according to the first security code and obtains a second salt value.

7. The bus system as described in claim 6, characterized in that, When the second salt value is 0, the first slave element stores the decrypted program code as the firmware of the first slave element, and when the second salt value is not equal to 0, the first slave element transmits the decrypted program code to the slave element corresponding to the second salt value via the control line.

8. The bus system as described in claim 1, characterized in that, The first subordinate element decrypts the program code using a triple data encryption algorithm, a multi-table encryption algorithm, or a salted encryption algorithm.

9. A bus system, characterized in that, include: One main control component; An enhanced serial peripheral device interface bus; Multiple slave components are electrically connected to the master control component via the enhanced sequence peripheral device interface bus; A series of peripheral device interface buses; as well as A memory element is electrically connected to the plurality of slave elements via the sequence of peripheral device interface buses; The plurality of slave elements have a plurality of pins, and each slave element corresponds to each pin, and the plurality of pins of the plurality of slave elements are electrically connected together via a control line; Each of these subordinate elements includes: A first scheduling controller, configured to control the control line to a specific voltage level via the corresponding pin, so that the slave element can communicate with the master element via the enhanced sequence peripheral device interface bus; and A second scheduling controller is configured to control the control line to transmit or receive data via the corresponding pin, so that the slave element can communicate with other slave elements via the control line; Wherein, after the first scheduling controller of a first slave element of the plurality of slave elements controls the control line to the specific voltage level and obtains a program code from the memory element, the first slave element decrypts the program code according to a first security code, and controls the control line via the second scheduling controller to transmit the program code decrypted by the first security code to the plurality of slave elements, so that the program code decrypted by the first security code is decrypted in the plurality of slave elements in a decryption order.

10. The bus system as described in claim 9, characterized in that, When the first slave element receives program code decrypted by a second slave element from the plurality of slave elements via the control line, the first slave element decrypts the program code decrypted by the second security code according to the first security code, and transmits the decrypted program code to the master element via the enhanced serial peripheral device interface bus, so as to serve as a basic input / output system of the master element.

11. The bus system as described in claim 9, characterized in that, When the first slave element receives program code decrypted by a second slave element from the plurality of slave elements via the control line, the first slave element decrypts the program code decrypted by the second security code again according to the first security code, and stores the decrypted program code as the firmware of the first slave element.

12. The bus system as described in claim 9, characterized in that, When a third slave element of the plurality of slave elements receives the program code that has been decrypted by the first security code from the first slave element via the control line, the third slave element decrypts the program code that has been decrypted by the first security code according to a third security code, and transmits the program code that has been decrypted by the third security code to the other plurality of slave elements via the control line according to the decryption order.

13. The bus system as described in claim 12, characterized in that, When the first slave element receives the program code, which has been decrypted by the third security code, from the third slave element via the control line, the first slave element decrypts the program code, which has been decrypted by the third security code, according to the first security code, and counts the number of times the program code is decrypted again using the first security code.

14. The bus system as described in claim 13, characterized in that, When the number of loops reaches a specific value, the first slave element transmits the re-decrypted program code to the master element via the enhanced sequence peripheral device interface bus, serving as a basic input / output system of the master element. When the number of loops does not reach the specific value, the first slave element transmits the re-decrypted program code to the plurality of slave elements via the control line, so that the program code re-decrypted by the first security code is decrypted in the plurality of slave elements according to the decryption order.

15. The bus system as described in claim 13, characterized in that, When the number of loops reaches a specific value, the first slave element stores the re-decrypted program code as the firmware of the first slave element. When the number of loops does not reach the specific value, the first slave element transmits the re-decrypted program code to the plurality of slave elements via the control line, so that the program code that has been re-decrypted by the first security code can be decrypted in the plurality of slave elements in the order of decryption.

16. The bus system as described in claim 9, characterized in that, The first slave element obtains a first salt value from the program code that has been decrypted by the first security code, and transmits the program code that has been decrypted by the first security code to the slave element corresponding to the first salt value via the control line. When the first slave element receives the program code that has been decrypted by a second slave element from the plurality of slave elements via the control line, the first slave element decrypts the program code that has been decrypted by the second security code again according to the first security code and obtains a second salt value.

17. The bus system as claimed in claim 16, characterized in that, When the second salt value is 0, the first slave element transmits the decrypted program code to the master element via the enhanced sequence peripheral device interface bus to serve as a basic input / output system of the master element. When the second salt value is not equal to 0, the first slave element transmits the decrypted program code to the slave element corresponding to the second salt value via the control line.

18. The bus system as claimed in claim 16, characterized in that, When the second salt value is 0, the first slave element stores the decrypted program code as the firmware of the first slave element, and when the second salt value is not equal to 0, the first slave element transmits the decrypted program code to the slave element corresponding to the second salt value via the control line.

19. The bus system as described in claim 9, characterized in that, The program code is either a basic input / output system of the master control element or the firmware of the multiple slave elements.

20. The bus system as described in claim 9, characterized in that, The first subordinate element decrypts the program code using a triple data encryption algorithm, a multi-table encryption algorithm, or a salted encryption algorithm.

Images