Semiconductor equipment

Abstract

By having a non-secure CPU handle MACsec key management, this semiconductor device provides a solution that compensates for the performance shortcomings of a secure CPU. [Solution] The semiconductor device comprises a RAM storing an encryption key, a secure CPU capable of accessing the encryption key stored in the RAM, and a first non-secure CPU connected to the RAM via a key access protection module and having a first user ID. The key access protection module stores user ID information of the non-secure CPU that is permitted to access the encryption key stored in the RAM, linked to the encryption key. When the first non-secure CPU attempts to access the encryption key stored in the RAM, the key access protection module grants the first non-secure CPU access to the encryption key if the stored user ID information matches the first user ID.

Description

Technical Field

[0001] This disclosure relates to semiconductor devices.

Background Art

[0002] In-vehicle IP (Intellectual Property) communicates with various modules inside the vehicle. It is required to protect data from eavesdropping by encrypting in-company communication. Conventionally, CAN (Controller Area Network) communication has been used for in-vehicle communication, but in recent years, the case of using Ethernet has been increasing.

[0003] In-vehicle Chips that perform CAN communication are equipped with a Secure CPU (Central Processing Unit) that specializes in security processing. The Secure CPU manages the encryption keys used for encrypting in-vehicle communication. CPUs other than the Secure CPU are called Non-Secure CPUs and communicate with each other.

[0004] In-vehicle Chips perform various processes. In-vehicle communication is used when obtaining necessary information from sensors and when issuing commands to control devices. This processing is carried out by multiple systems, and there may be cases where applications are developed by different companies. Separate CPUs are prepared for each system so that each system does not interfere with each other. The modules through which each CPU communicates with sensors and control devices are common resources within the in-vehicle chip. In CAN communication, the management of the keys used for communication encryption is not performed by each CPU (Non-Secure CPU), but by the Secure CPU.

[0005] On the other hand, the case of using Ethernet communication instead of CAN communication has been increasing. In Patent Document 1, a new standard for communication encryption called MACsec in Ethernet has been established.

Prior Art Documents

Non-Patent Documents

[0006] [Non-Patent Document 1] IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Security, IEEE Std 802.1AE(registered trademark)-2018 [Overview of the Initiative] [Problems that the invention aims to solve]

[0007] However, MACsec encrypted communication uses more keys than CAN communication, and key updates occur more frequently. In CAN communication, key management could be handled solely by the secure CPU, but applying similar processing to the MACsec standard would require insufficient processing power from the secure CPU. Increasing the performance of the secure CPU is difficult from a product cost perspective. Furthermore, the workload of the secure CPU has increased in addition to related technologies, so it cannot be increased by supporting MACsec. Therefore, the purpose of this disclosure is to provide a semiconductor device that satisfies the performance shortcomings of the secure CPU by having a non-secure CPU handle MACsec key management.

[0008] Other challenges and novel features will become apparent from the description and accompanying drawings in this specification. [Means for solving the problem]

[0009] According to one embodiment, when the first non-secure CPU attempts to access an encryption key stored in RAM, the key access protection module provides a semiconductor device that grants the first non-secure CPU access to the encryption key if the stored user ID information matches the first user ID. [Effects of the Invention]

[0010] According to the above embodiment, by having a non-secure CPU handle MACsec key management, a semiconductor device that satisfies the performance shortcomings of a secure CPU can be provided. [Brief explanation of the drawing]

[0011] [Figure 1] This is a block diagram showing the configuration of a related semiconductor device. [Figure 2] This figure shows an overview of the semiconductor device disclosed herein. [Figure 3] This is a block diagram showing the first configuration of a semiconductor device of the present disclosure. [Figure 4] This is a sequence diagram showing a first driving method for the semiconductor device of the present disclosure. [Figure 5] This block diagram shows the configuration of a semiconductor device corresponding to Figure 4. [Figure 6] This is a sequence diagram showing a second driving method for the semiconductor device of the present disclosure. [Figure 7] This block diagram shows the configuration of a semiconductor device corresponding to Figure 6. [Figure 8] This is a sequence diagram showing a third driving method for the semiconductor device of the present disclosure. [Figure 9] This block diagram shows the configuration of a semiconductor device corresponding to Figure 8. [Figure 10] This block diagram shows a second configuration of the semiconductor device of the present disclosure. [Figure 11] This is a block diagram showing a fourth driving method for the semiconductor device of the present disclosure. [Figure 12] This is a block diagram showing the configuration of a semiconductor device corresponding to Figure 11. [Figure 13] This is a block diagram showing a fifth driving method for the semiconductor device of the present disclosure. [Figure 14] This is a block diagram showing the configuration of a semiconductor device corresponding to Figure 13. [Modes for carrying out the invention]

[0012] For the sake of clarity of explanation, the following descriptions and drawings have been appropriately omitted and simplified. Also, each element described in the drawings as a functional block performing various processes can be constituted, for example, hardware-wise by a CPU (Central Processing Unit), memory, and other circuits, and software-wise by a program loaded into the memory, etc. Therefore, these functional blocks can be realized by hardware, software operating on the hardware, or a combination thereof. In each drawing, the same element is denoted by the same reference numeral, and duplicate explanations are omitted as necessary.

[0013] Also, the above-described program can be stored using various types of non-transitory computer readable media and supplied to a computer. Non-transitory computer readable media include various types of tangible storage media. Examples of non-transitory computer readable media include magnetic recording media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (e.g., magneto-optical disks), CD-ROM (Read Only Memory), CD-R, CD-R / W, semiconductor memories (e.g., mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (Random Access Memory)). Also, the program may be supplied to the computer by various types of transitory computer readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves. Transitory computer readable media can supply the program to the computer via wired communication paths such as electric wires and optical fibers, or wireless communication paths.

[0014] (Description of Related Semiconductor Devices) FIG. 1 is a block diagram showing the configuration of a related semiconductor device. The related semiconductor device will be described while referring to FIG. 1. The related semiconductor device is used, for example, for encryption used in CAN communication.

[0015] As shown in FIG. 1, the related semiconductor device 100 includes a Secure CPU (Central Processing Unit) 101, a first Non-Secure CPU 102, a second Non-Secure CPU 103, a third Non-Secure CPU 104, a memory 105, a BUS 106, an ID Protect 107, a KeyRAM (Random Access Memory) 108, an AES (Advanced Encryption Standard) engine 115, and a Network module 116.

[0016] The Secure CPU 101 is a CPU that performs security processing. The Secure CPU 101 cannot be used by the user. Only software verified and trusted by secure boot operates.

[0017] The first Non-Secure CPU 102, the second Non-Secure CPU 103, and the third Non-Secure CPU 104 are CPUs that can be used by the user. They control an automobile using CAN communication.

[0018] The BUS 106 connects each CPU and memory such as the KeyRAM 108, each semiconductor device component such as the AES engine 115 and the Network module 116.

[0019] The ID Protect 107 restricts the CPUs that can be accessed using the user ID. Here, access to the KeyRAM 108 is restricted to the Secure CPU.

[0020] KeyRAM108 is a module that manages the keys used for encryption. KeyRAM108 stores keys (Key0)110, (Key1)111, (Key2)112, (Key3)113, and (Key114) in RAM109. KeyRAM108 selects the key to output to the AES engine 115. KeyRAM108 cannot be accessed from a non-secure CPU.

[0021] The AES engine 115 encrypts unencrypted information and decrypts encrypted information. The non-secure CPU configures the AES engine 115 for encryption or decryption. The non-secure CPU sets the key address of the encryption key to be used for encryption or decryption in the AES engine 115. The AES engine 115 sends the key address to RAM 109 and receives key data. The AES engine 115 performs encryption or decryption using the received key data. At this point, the non-secure CPU cannot check whether it is using someone else's key stored in RAM 109.

[0022] The encryption key is updated when the secure CPU 101 sends the new encryption key and the address of the RAM 109 that stores the encryption key to the KeyRAM 108 via the bus.

[0023] Using a non-secure CPU for key management presents the following security problems: First, unlike a secure CPU where only verified and trusted software runs, a non-secure CPU runs a wide variety of software. This creates a risk of malicious software being introduced or code in memory being overwritten and executed through glitches. Second, if malicious software can freely read encryption keys in KeyRAM through a non-secure CPU, it can lead to key leakage. Furthermore, if the keys used for encryption are leaked, the security of communications is compromised. Communication data is at risk of interception or tampering.

[0024] (Description of the semiconductor device according to the embodiment) Figure 2 is a diagram illustrating the overview of the semiconductor device of this disclosure. The semiconductor device according to the embodiment will be described with reference to Figure 2.

[0025] The semiconductor device 200 according to this embodiment reduces the burden on the secure CPU by assigning MACsec key management to the non-secure CPU. As shown in Figure 2, a key access protect module 218, which is an access protection mechanism, is added. The first non-secure CPU 202, the second non-secure CPU 203, and the third non-secure CPU are connected to the RAM 209 via the key access protect module 218. Therefore, security is ensured by preventing unauthorized access to other users' encryption keys by the non-secure CPUs.

[0026] The key access protection module 218 has the following functions. First, it identifies the ID of the non-secure CPU that accessed KeyRAM 208. Therefore, it identifies that User A 222 accessed it using CPU 202 (219).

[0027] Next, there is a function to associate and store the user ID information of non-secure CPUs that are permitted to access each encryption key stored in KeyRAM208 with the encryption key. Furthermore, there is a function to restrict the setting of non-secure CPU IDs that can access each encryption key to secure CPUs only. As a result, Key210 (Key 0) is proven to be the encryption key of user A222 (220), and access is permitted (221).

[0028] Furthermore, the key access protection module 218 has a function to verify that a non-secure CPU has the authority to access the encryption key when that non-secure CPU updates the encryption key. When the first non-secure CPU attempts to access the encryption key stored in KeyRAM 208, the key access protection module grants the first non-secure CPU access to the encryption key if the stored user ID information matches the first user ID.

[0029] With the above configuration, by having the non-secure CPU handle MACsec key management, it is possible to provide a semiconductor device that compensates for the performance shortcomings of the secure CPU.

[0030] (Description of the semiconductor device according to the first embodiment) Figure 3 is a block diagram showing the first configuration of the semiconductor device of the present disclosure. Figure 4 is a sequence diagram showing the first driving method of the semiconductor device of the present disclosure. Figure 5 is a block diagram showing the configuration of the semiconductor device corresponding to Figure 4. Figure 6 is a sequence diagram showing the second driving method of the semiconductor device of the present disclosure. Figure 7 is a block diagram showing the configuration of the semiconductor device corresponding to Figure 6. Figure 8 is a sequence diagram showing the third driving method of the semiconductor device of the present disclosure. Figure 9 is a block diagram showing the configuration of the semiconductor device corresponding to Figure 8. The semiconductor device according to the first embodiment will be described with reference to Figures 3 to 9.

[0031] The semiconductor device 300 according to the first embodiment includes a secure CPU 201, a first non-secure CPU 202, a second non-secure CPU 203, a third non-secure CPU 204, a memory 205, a bus 206, an ID protect 207, a KeyRAM 208, an AES engine 215, and a network 216.

[0032] The functions of the secure CPU 201, the first non-secure CPU 202, and the second non-secure CPU 203, which are not described here, are the same as those of the secure CPU 101, the first non-secure CPU 102, and the second non-secure CPU 103. Also, the functions of the third non-secure CPU 204, memory 205, bus 206, and ID protect 207, which are not described here, are the same as those of the third non-secure CPU 104, memory 105, bus 106, and ID protect 107. Furthermore, the functions of the KeyRAM 208, AES engine 215, and network 216, which are not described here, are the same as those of the KeyRAM 108, AES engine 115, and network module 116.

[0033] KeyRAM208 comprises a key access protection module 218, an arbitration circuit 304, and RAM 209.

[0034] The key access protect module 218 includes an access protect register 301 with an access protect table 302 and a user ID checker 1 303.

[0035] Each CPU has a user ID. For example, secure CPU 201 has user ID 0A. The first non-secure CPU has user ID 00. The second non-secure CPU has user ID 01. The third non-secure CPU has user ID 02.

[0036] The user ID is transmitted via bus 206 along with the address or data. Therefore, it is possible to determine which CPU is accessing it via bus 206. The CPU cannot verify or change the ID.

[0037] The first user ID checker, user ID checker 303, checks the access protect register 301 to see if a user ID exists for the non-secure CPU when the non-secure CPU attempts to access the encryption key stored in RAM 209, and determines whether to allow access based on the result of this check. User ID checker 1(303) compares the CPU's user ID with the ID in the access protect table 302. If the IDs match, user ID checker 1(303) allows access to RAM. User ID checker 1(303) prevents tampering by monitoring key updates.

[0038] The access protect register 301 sets the user ID information of non-secure CPUs that are permitted to access the encryption keys stored in RAM 209. The access protect register 301 is a register that sets the user ID of the CPU that is permitted to access each key. The user IDs are stored in the access protect table 302. The access protect table 302 can only be configured by secure CPUs.

[0039] ID Protect 207 restricts the CPUs that can access the Access Protect Register 301 and KeyRAM 208 using the user ID to the Secure CPU 201.

[0040] Memory 205 holds the programs that the CPU executes.

[0041] Figures 4 and 5 show how to update the access protection table 302. The access protection table has registers that allow you to set the CPU user IDs that are permitted to access for each encryption key, as follows: [Table 1]

[0042] Referring to Figures 4 and 5, we will explain how to update the settings of the access protection table 302 using a secure CPU. 1. Issue a write transaction on Secure CPU 201 to update Access Protect Table 302. This transfers the Key No. of the key whose settings are to be updated and the Permitted ID (User ID 0) which is the user ID authorized to access the key. When issuing a transaction in this way, the User ID 0A assigned to Secure CPU is also transferred.

[0043] 2. Access protection table 302 is protected by ID protection 207 on bus 206 so that only secure CPU 201 can access it. Here, the user ID transferred with the transaction is checked to determine that it is a secure CPU.

[0044] Enter branch (ALT) 401 here. 3. ID Protect 207 verifies the user ID, and if it matches the ID of the Secure CPU, a write transaction is issued and the Access Protect Table 302 is updated. If they do not match, the write transaction will not be issued and an error will be returned.

[0045] With the above configuration, the secure CPU updates the access protection table settings.

[0046] Figures 6 and 7 show how to update the key on a non-secure CPU. The access protection table 302 stores the key address and the ID of the CPU that is authorized to access it, as shown below. [Table 2]

[0047] Referring to Figures 6 and 7, we will explain how to update keys using a non-secure CPU. 1. The address of Key0 and the encryption key are transferred from CPU0, which is the first non-secure CPU 202, to KeyRAM 208. At the same time, the first user ID, which is the user ID of CPU0, is also transferred.

[0048] 2. The user ID checker 1 (303) queries the access protection table 302 of the key access protection module 218, which stores user ID information, for the address of Key0, and receives the user ID (Permitted ID) of the CPU that is permitted to access Key0.

[0049] 3. The User ID Checker 1 (303) compares the User ID of CPU0 with the User ID of the CPU that is allowed to access Key0.

[0050] Enter branch (ALT) 601 here. 4. If the IDs match, grant the first non-secure CPU 202 access to the encryption key, transfer the key address and encryption key, and write them to RAM 209. 5. If the IDs do not match, an error will be output.

[0051] With the above configuration, the key is updated using a non-secure CPU.

[0052] Figures 8 and 9 illustrate the method of encryption using an encryption key with the AES engine. The method of encryption using an encryption key with the AES engine will be explained with reference to Figures 8 and 9. Here, we assume that the first non-secure CPU 202 performs encryption using Key0.

[0053] 1. The first non-secure CPU 202 sets the key to be used for encryption in the control register of the AES engine 215 and sets the encryption operation start bit.

[0054] 2. The AES engine 215 retrieves the corresponding encryption key (key data) by sending the encryption key address set in the control register to the KeyRAM 208 in order to perform the encryption calculation. After the key retrieval is complete, the AES engine 215 sends a signal to the first non-secure CPU indicating that encryption is ready.

[0055] 3. The non-secure CPU 202 transfers the plain text stored in memory to the AES engine 215.

[0056] 4. The AES engine 215 performs encryption once the plaintext is ready. After encryption is complete, the AES engine 215 sends a signal to the non-secure CPU 202 indicating that the ciphertext is ready.

[0057] 5. The non-secure CPU 202 transfers the ciphertext from the AES engine 215 to memory. Then it transfers the ciphertext from memory to the communication module.

[0058] Encryption is performed using the above configuration.

[0059] (Description of the semiconductor device according to the second embodiment) Figure 10 is a block diagram showing the second configuration of the semiconductor device of the present disclosure. Figure 11 is a block diagram showing the fourth driving method of the semiconductor device of the present disclosure. Figure 12 is a block diagram showing the configuration of the semiconductor device corresponding to Figure 11. Figure 13 is a block diagram showing the fifth driving method of the semiconductor device of the present disclosure. Figure 14 is a block diagram showing the configuration of the semiconductor device corresponding to Figure 13. The semiconductor device according to the second embodiment will be described with reference to Figures 10 to 14.

[0060] The semiconductor device 1000 according to the second embodiment differs from the semiconductor device 300 according to the first embodiment in that it includes a second user checker, which is a user ID checker 2(1001).

[0061] The key access protection module 218 includes a user ID checker 2(1001) that determines whether a non-secure CPU has access to an encryption key when the non-secure CPU uses the encryption key. The user ID checker 2(1001) compares the CPU's user ID with the ID in the access protection table and allows access to RAM 209 if they match. The user ID checker 2(1001) prevents impersonation by monitoring key usage.

[0062] Figures 11 and 12 show how to use the key in RAM 209 with the AES engine 215. Referring to Figures 11 and 12, the method of encryption using the encryption key with the AES engine 215 will be explained. Here, we assume that the first non-secure CPU 202 performs encryption using Key0.

[0063] 1. The non-secure CPU 202 sets the key to be used for encryption in the control register of the AES engine 215 and sets the encryption operation start bit.

[0064] 2. The AES engine 215 transfers the address of the encryption key set in the control register and the user ID transferred during the write transaction to the control register to the KeyRAM 208 in order to perform cryptographic calculations.

[0065] 3. The user ID checker 2 (1001) forwards the key address requested by the AES engine 215 to the access protection table 302 and receives the user ID (Permitted ID) of the CPU that was authorized to access that key.

[0066] 4. The User ID Checker 2 compares the User ID of non-secure CPU 202 with the User ID of the CPU that is allowed to access Key0.

[0067] This is where we enter branch 1101. 5. If the IDs match, the user ID checker 2 (1001) retrieves the encryption key (key data) from RAM 209 and passes it to the AES engine 215. The AES engine 215 then performs encryption using the encryption key.

[0068] 6. If the IDs do not match, an error will be output.

[0069] Figures 13 and 14 illustrate how the second non-secure CPU 203, which has been hijacked by malicious software, performs encryption using Key0, which is not normally available. The method for preventing impersonation will be explained with reference to Figures 13 and 14.

[0070] 1. The second non-secure CPU 203 sets the key Key0 used for encryption in the AES engine's control register and sets the encryption operation start bit. The user ID (ID:02) transferred during this write transaction cannot be viewed or modified by the second non-secure CPU 203.

[0071] 2. The AES engine 215 transfers the address of the encryption key (Key0) and the user ID (ID:02) transferred during the write transaction to the control register to the KeyRAM 208.

[0072] 3. User ID checker 2 (1001) compares the user ID of the CPU performing the encryption (ID:02) with the Permitted ID (ID:00) that is authorized to access Key0.

[0073] 4. Since the user ID does not match, user ID checker 2 (1001) determines that an unauthorized encryption key is being used and returns an error. This prevents impersonation.

[0074] With the above configuration, when a second non-secure CPU 203 having a second user ID attempts to access an encryption key stored in RAM 209, if the second user ID is not present in the user ID information, access to the encryption key is prohibited for the second non-secure CPU 203.

[0075] The present invention has been described in detail above based on embodiments, but it goes without saying that the present invention is not limited to the embodiments already described, and various modifications are possible without departing from the spirit of the invention. [Explanation of symbols]

[0076] 100 Semiconductor device, 101 Secure CPU, 102 First non-secure CPU, 104 Third non-secure CPU, 105 Memory, 106 Bus, 107 ID protect, 108 KeyRAM, 109 RAM, 110 Key, 111 Key, 112 Key, 113 Key, 114 Key, 115 AES engine, 116 Network module 200 Semiconductor device, 201 Secure CPU, 202 First non-secure CPU, 203 Second non-secure CPU, 204 Third non-secure CPU, 205 Memory, 206 Bus, 207 ID protect, 208 KeyRAM, 209 RAM, 218 Key access protect module, 222 User A, 223 User B, 224 User C, 300 Semiconductor device, 301 Access protect register, 302 Access protect table, 303 User ID checker 1, 1000 Semiconductor device, 1001 User ID checker 2

Claims

1. RAM (Random Access Memory) that stores the encryption key, A secure CPU (Central Processing Unit) capable of accessing the encryption key stored in the RAM, The RAM is connected via a key access protection module and comprises a first non-secure CPU having a first user ID, The key access protection module stores user ID information of non-secure CPUs that are permitted to access the encryption key stored in the RAM, associated with the encryption key. A semiconductor device which, when the first non-secure CPU attempts to access the encryption key stored in the RAM, grants the first non-secure CPU access to the encryption key if the stored user ID information matches the first user ID.

2. In the semiconductor device described in claim 1, The aforementioned key access protection module is An access protection register for setting the user ID information of the non-secure CPU that is permitted to access the encryption key stored in the RAM, A semiconductor device comprising: a first user ID checker that, when the non-secure CPU attempts to access the encryption key stored in the RAM, checks whether the user ID of the non-secure CPU exists in the access protection register and determines whether to allow access according to the result of the check.

3. In the semiconductor device described in claim 2, It also features an AES (Advanced Encryption Standard) engine that has the capability to encrypt unencrypted information and decrypt encrypted information, The first non-secure CPU is a semiconductor device that connects to the RAM via the AES engine, thereby allowing the AES engine to use the encryption key.

4. In the semiconductor device described in claim 3, The key access protection module further comprises a second user ID checker that determines whether the first non-secure CPU can access the encryption key when the first non-secure CPU uses the encryption key, in a semiconductor device.

5. In the semiconductor device described in claim 1, The RAM is connected to the second non-secure CPU having a second user ID via the key access protection module, and comprises: The key access protection module is a semiconductor device that, when the second non-secure CPU attempts to access the encryption key stored in the RAM, prohibits the second non-secure CPU from accessing the encryption key if the second user ID is not present in the user ID information.

6. In the semiconductor device described in claim 1, The aforementioned secure CPU has a 0th user ID, The secure CPU and the first non-secure CPU are each connected to the access protect register of the key access protect module and the RAM via ID protect. A semiconductor device in which the ID protection allows the CPU having the 0 user ID to access the access protection register and the RAM, thereby enabling the secure CPU to access the access protection register and the RAM.

7. In the semiconductor device described in claim 3, A semiconductor device comprising a network module that transmits ciphertext encrypted by the aforementioned AES engine.

Images