Storage area protection method and electronic equipment

Abstract

The embodiment of the invention provides a storage area protection method and electronic equipment, and is used for solving the problem that the security of data in a storage area cannot be guaranteed in the prior art. The method comprises the following steps of: acquiring an accessed address carried in an access request and an access end sending the access request after the access request is received due to the fact that a storage area comprises an ROM (Read Only Memory), an RAM (Random Access Memory) and a Flash Memory; if the access end is a pre-stored security end and the accessed address is the address of the security area of the ROM, acquiring a pre-stored identifier indicating whether the security area of the ROM is protected, and if the identifier indicates that the security area of the ROM is protected, determining that the access request is abnormal. The content leakage of the ROM key program area can be prevented, and the key data stored in the ROM safety area can be effectively prevented from being threatened by unauthorized access, so that the safety of the data is comprehensively improved.

Description

Technical Field

[0001] This application relates to the field of chip information security technology, and in particular to a storage area protection method and electronic device. Background Technology

[0002] In MCU applications, program code runs directly in memory, which may contain critical data. To prevent unauthorized reading and modification of program code and critical data, special code encryption methods are needed in MCU design to protect the program code from theft.

[0003] In existing technologies, key pairs are typically used to encrypt stored code or critical data; however, the code and critical data stored using existing methods are still not secure.

[0004] Therefore, how to reliably and efficiently improve the security of information stored in the memory space of an MCU has become an urgent problem for technicians in this field. Summary of the Invention

[0005] This application provides a method and electronic device for protecting storage areas, in order to solve the problem that the security of data in storage areas cannot be guaranteed in related technologies.

[0006] In a first aspect, embodiments of this application provide a method for protecting a storage area, wherein the storage area includes read-only memory (ROM), random access memory (RAM), and flash memory, and the ROM, RAM, and flash memory each contain a secure area. The method includes:

[0007] Receive an access request and obtain the accessed address and the accessing terminal that sent the access request carried in the access request;

[0008] If the accessing end is a pre-saved secure end, and the accessed address is the address of the secure region of the ROM, then a pre-saved identifier indicating whether the secure region of the ROM is protected is obtained. If the identifier indicates that the secure region of the ROM is protected, then the access request is determined to be abnormal.

[0009] Secondly, embodiments of this application provide an electronic device, which includes at least a processor and a memory, wherein the processor is configured to implement the steps of the storage area protection method as described in any of the preceding claims when executing a computer program stored in the memory.

[0010] In this embodiment, the storage area includes ROM, RAM, and Flash Memory. Upon receiving an access request, the ROM, RAM, and Flash Memory obtain the accessed address and the sending endpoint of the access request carried in the request. If the sending endpoint is a pre-saved secure endpoint, and the accessed address is the address of the ROM's secure area, a pre-saved flag indicating whether the ROM's secure area is protected is obtained. If the flag indicates that the ROM's secure area is protected, the access request is determined to be abnormal. This prevents the leakage of critical program area content in the ROM and effectively ensures that critical data stored in the ROM's secure area is protected from unauthorized access, thereby comprehensively improving data security. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This application provides a schematic diagram of a storage area protection process.

[0013] Figure 2 This is a schematic diagram of the storage architecture provided in an embodiment of this application;

[0014] Figure 3 This application provides a schematic diagram of a storage area protection process.

[0015] Figure 4 This is a schematic diagram illustrating another process for protecting storage areas provided in an embodiment of this application;

[0016] Figure 5 A schematic diagram illustrating the data decryption process provided in an embodiment of this application;

[0017] Figure 6 This is a schematic diagram of lifecycle state transitions provided in an embodiment of this application;

[0018] Figure 7 A detailed storage structure diagram is provided for an embodiment of this application;

[0019] Figure 8 This is a schematic diagram of a storage area protection device provided in an embodiment of this application;

[0020] Figure 9 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art are within the scope of protection of this application.

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] It should be noted that the terms "comprising" and "having" and their variations used in this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or device.

[0024] The terms "first" and "second" used in this document are for descriptive purposes only and should not be construed as indicating relative importance or implying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0025] The word “exemplary” as used below means “serving as an example, embodiment, or illustration.” Any embodiment illustrated as an “exemplary” need not be construed as superior to or better than other embodiments.

[0026] Before introducing the storage area protection method provided in the embodiments of this application, the technical background of the embodiments of this application will be introduced first for ease of understanding.

[0027] The technological background for storage protection in Internet of Things (IoT) products mainly involves technologies related to data security, privacy protection, and device management. These technologies include encryption, access control, firewalls, anonymization, de-identification, remote management, and firmware updates.

[0028] The current state of development of the Internet of Things is as follows:

[0029] 1. Data Security: With the widespread application of IoT devices, data security issues are becoming increasingly prominent. Currently, many technologies and methods are used to protect IoT data security, such as using encryption technology to encrypt data, using access control technology to restrict unauthorized access, and using firewall technology to prevent data tampering. However, due to the characteristics of IoT devices, such as limited device resources and complex network environments, the application of these technologies still faces many challenges.

[0030] 2. Privacy Protection: As IoT devices collect increasingly more data, privacy protection becomes increasingly important. Currently, many technologies and methods are used to protect the privacy of IoT users, such as using anonymization and de-identification techniques to prevent the leakage of personal information. However, due to the openness and complexity of the IoT, the application of these technologies still faces many challenges.

[0031] 3. Device Management: As the number of IoT devices increases, device management becomes increasingly important. Currently, many technologies and methods are used to manage IoT devices, such as remote management and firmware update technologies to ensure device security. However, due to the diversity and distributed nature of IoT devices, the application of these technologies still faces many challenges.

[0032] In summary, the current state of IoT storage protection technology is such that, although many technologies and methods have been used to protect IoT data security and privacy, the application of these technologies still faces many challenges due to the characteristics of IoT.

[0033] To improve the security of data stored in the memory space corresponding to the MCU, this application provides a method, apparatus, device, and medium for protecting the storage area.

[0034] The method for protecting the storage area includes: receiving an access request, obtaining the accessed address and the accessing end that sent the access request carried in the access request; if the accessing end is a pre-saved secure end and the accessed address is the address of the secure area of ​​the ROM, then obtaining a pre-saved flag indicating whether the secure area of ​​the ROM is protected; if the flag indicates that the secure area of ​​the ROM is protected, then determining that the access request is abnormal.

[0035] Figure 1 This is a schematic diagram illustrating a storage area protection process provided in an embodiment of this application.

[0036] The storage area includes ROM, RAM, and Flash Memory, and each of the ROM, RAM, and Flash Memory contains a secure area. The method for protecting this storage area includes the following steps:

[0037] S101: Receive an access request and obtain the accessed address and the accessing terminal that sent the access request carried in the access request.

[0038] The storage area protection method provided in this application is applied to an electronic device, which may be a microcontroller unit (MCU) or other intelligent device.

[0039] In this embodiment, the electronic device receives access requests from various sources. These requests may be initiated directly by the Central Processing Unit (CPU), or transmitted via a Universal Serial Bus (USB) interface from external devices, or through Advanced Xtensible Interface (AXI), Advanced High Performance Bus (AHB), Engine, Ethernet, Secure Joint Test Action Group Interface (Secure JTAG), Debug Inter-Integrated Circuit Interface (DBGI2C), Debug Serial Peripheral Interface (DBG SPI), etc. This design ensures that the electronic device can flexibly respond to various data access requests from the internal processor and externally connected devices, thereby performing corresponding data processing or storage operations.

[0040] Upon receiving an access request, to enhance data storage security, the electronic device can obtain and analyze the explicitly specified access address in the request, ensuring the accuracy and targeting of data access. Furthermore, the electronic device will proactively identify and record the access source information, which may include a USB device, an internal CPU program, or any other access source.

[0041] S102: If the access terminal is a pre-saved secure terminal and the accessed address is the address of the secure region of the ROM, then obtain a pre-saved identifier indicating whether the secure region of the ROM is protected. If the identifier indicates that the secure region of the ROM is protected, then determine that the access request is abnormal.

[0042] To further enhance data security, a dedicated secure area is established within the ROM to store chip initialization code, critical configuration information, and other sensitive data. This secure area ensures that this core information is protected from unauthorized access. When the electronic device receives an access request, it ensures the legitimacy and security of the access.

[0043] Electronic devices can first determine whether the accessing endpoint is a pre-saved, legitimate, and trusted secure endpoint. If the accessing endpoint is a pre-saved secure endpoint, the electronic device checks whether the accessed address is located within the secure region of the ROM. This is done by comparing the accessed address with the address range of the secure region in the ROM. If the addresses do not match, it indicates that the access request is attempting to access an insecure region.

[0044] After confirming that the access terminal is legitimate and the accessed address is located in the ROM's secure region, the electronic device further queries a key identifier pre-stored in a secure location. This identifier explicitly indicates whether the ROM's secure region is currently under protection. The process of reading this identifier is itself subject to strict security controls to prevent tampering.

[0045] If this flag indicates that the ROM's security zone is protected, the electronic device will not directly allow the access request to proceed. Instead, it will determine that the access request is abnormal or a potential security threat. In this case, the electronic device can record the security event, send an alarm notification, or even immediately lock or shut down the relevant resources to prevent the leakage or damage of sensitive data.

[0046] In other words, the ROM space access protection in this application embodiment defines a secure user storage area in the ROM, namely, a secure area. This area can be accessed after power-on reset. The software can enable the protection function for this area by setting the corresponding register. Once the protection is enabled, the area will become completely inaccessible. This protection is effective throughout the entire chip power-on time and cannot be revoked until the next reset.

[0047] Figure 2 This is a schematic diagram of the storage architecture provided in an embodiment of this application.

[0048] Depend on Figure 2As can be seen, the architecture primarily includes secure and insecure access control on the bus master side, and storage access protection control on the bus slave side. The core architecture revolves around "Systeminterconnect." On the bus master side, secure and insecure access control mechanisms are designed to ensure the compliance and security of data flow. On the bus slave side, the focus is on protecting storage media, including critical storage components such as EFUSE, ROM, RAM, and Flash Memory. Notably, the system extensively integrates various access terminals, such as CPU, AXI, AHB, Engine, USB, Ethernet, Secure JTAG, DBGI2C, and DBG SPI. These interfaces collectively construct a multi-dimensional, multi-layered access protection network. Crucially, the system's built-in Master Secure Ctrl is responsible for identifying the source of each access request and determining whether it is a secure terminal, thereby ensuring that only authorized access terminals can access system resources, significantly improving the overall security of the system.

[0049] This application proposes a ROM proprietary program area protection method. After the chip powers on and completes the boot program, access is prohibited again to prevent leakage of the ROM's critical program area contents. This effectively ensures that critical data stored in the ROM's secure area is protected from unauthorized access, thereby comprehensively improving data security. The embodiments of this application essentially provide a solution for various memory access protection implementations based on industrial control MCUs.

[0050] The above technical solution has the following advantages or beneficial effects: the storage area includes ROM, RAM, and Flash Memory. Upon receiving an access request, the ROM, RAM, and Flash Memory obtain the accessed address and the sending end of the access request carried in the request. If the sending end is a pre-saved secure end, and the accessed address is the address of the ROM's secure area, then a pre-saved flag indicating whether the ROM's secure area is protected is obtained. If the flag indicates that the ROM's secure area is protected, then the access request is determined to be abnormal. This can prevent the leakage of critical program area content in the ROM and effectively ensure that critical data stored in the ROM's secure area is protected from unauthorized access, thereby comprehensively improving data security.

[0051] To ensure the security of the storage area, based on the above embodiments, this embodiment of the application obtains a pre-saved identifier indicating whether the security area of ​​the ROM is protected, including:

[0052] Obtain the identifier stored at a preset location in the Electrically Programmable Read-Only Memory Fuse (EFUSE) that indicates whether the security area of ​​the ROM is protected.

[0053] EFUSE is used to implement one-time programmable security features at the hardware level. To enhance security, particularly for the protection of secure areas in ROM, EFUSE is designed to store specific security configuration information. An electronic device can retrieve a key identifier from a preset location on EFUSE that explicitly indicates whether protection mechanisms are enabled for the secure areas of the ROM.

[0054] Specifically, the electronic device performs a read operation to extract this security identifier from the specified address range of EFUSE. This identifier can be stored in binary form, usually as a simple flag bit, whose state (such as 0 or 1) directly reflects the protection status of the ROM's security area: if the flag is active (e.g., a value of 1), it means that the ROM's security area is protected, and any unauthorized access attempts will be blocked; conversely, if the flag is inactive (e.g., a value of 0), it may indicate that the area is currently unprotected or in a configurable state.

[0055] In this embodiment, taking advantage of the EFUSE's one-time write capability and to enhance the protection of critical configuration information within the chip, a storage protection method for EFUSE is proposed. Based on different chip lifecycle stages (chip manufacturing, equipment production, equipment deployment, equipment recycling), different flags indicating whether the ROM's secure areas are protected are stored in EFUSE, thus protecting critical information. EFUSE storage is used to store sensitive information for use by the entire industrial control MCU security system.

[0056] In this embodiment, the activation of the ROM's secure region can be set via the corresponding EFUSE bit of the chip. This is a static, irrevocable setting that takes effect automatically upon power-on and requires no additional software configuration. Enabling protection requires software enabling. A typical use of the secure region is to store code and data that run only once per power-on, such as secure boot code. Before jumping to the normal application area, the protection of the secure storage area can be enabled. After the program jumps, the secure boot code and critical data stored in the ROM's secure storage area become completely invisible, effectively isolating the ROM boot code from the application and preventing the application from accessing any sensitive code and data used during the boot process.

[0057] The above technical solution has the following advantages or beneficial effects: Based on the storage characteristic that EFUSE can only be written once, the flag indicating whether the ROM's security area is protected is recorded in EFUSE. This ensures that once the flag is set, it cannot be tampered with by software, thereby making the data protection mechanism of the ROM's security area more robust and irreversible, effectively preventing unauthorized access and tampering, and further improving the overall security of the system.

[0058] To ensure the security of the storage area, based on the above embodiments, in this embodiment, after determining that the access terminal is a pre-saved secure terminal, the method further includes:

[0059] If the accessed address is an address in the secure region of the RAM or the Flash Memory, then the access request is executed.

[0060] After confirming that the access endpoint is a pre-saved secure endpoint, and recognizing that the accessed address belongs to a designated secure region in RAM or Flash Memory, the electronic device can automatically execute the access request without requiring additional security verification steps. This optimized process not only improves the efficiency of accessing sensitive data areas but also reduces the burden by minimizing unnecessary verification processes.

[0061] By dividing RAM into secure and insecure regions, users can configure which regions can be accessed securely, which can be accessed insecurely, and which can be shared between the two. This prevents insecure access to sensitive data stored in RAM. Furthermore, applications running in secure access can use protected software interfaces to encrypt and decrypt data, further protecting sensitive data stored in RAM. The electronic device's ahb_SecurityAccessFilter (SAF) can detect and report any unauthorized access attempts, such as insecure attempts to access resources in secure space. ahb_SAF ensures that only verified firmware and software are loaded at device startup, preventing malware from being loaded into RAM during system boot.

[0062] This application proposes a method for protecting RAM access, which is mainly used to execute software programs. This method involves configuring attributes between the host and slave devices on the chip bus, including setting the host's security and non-security attributes, setting the slave's read and write access permissions, and setting the slave's access address.

[0063] In this embodiment, the CPU's operating modes are clearly distinguished into secure and insecure states. This approach allocates code and data stored in Flash and RAM to corresponding secure and insecure regions, ensuring that the CPU can only access content within its authorized regions in different states. Furthermore, the system extends the security boundaries beyond code and data management to include peripherals and other host devices connected to the CPU bus, all of which are assigned explicit security attribute identifiers. The system can strictly control which resources (including critical peripherals) can be accessed in secure mode and which are restricted to insecure mode. This mechanism builds a robust Trusted Execution Environment (TEE) on the MCU, providing a region protected from potential threats for critical code and sensitive operations. Even if the application software itself may have vulnerabilities, placing core functions within the TEE effectively isolates and protects the system's critical resources, thereby significantly improving the overall system security and stability.

[0064] In this embodiment, determining abnormal access requests includes access protection isolation, such as protection control for AXI interface access to the critical program area of ​​ROM, FlexRAM, TCM, FMC, and OCTOSPI Flash Memory, and protection control for AHB interface access to RAM1, 2, 3, and Backup RAM. It mainly supports the following functions: security configuration, which can configure the processor's memory mapping according to security policies to divide it into secure and insecure regions and define access permissions for secure regions; security domain switching, which supports dynamically switching the processor's security state according to runtime requirements. It can control the switching between secure and insecure states using specific registers; exception handling, which can capture and handle exceptions in both secure and insecure states and perform corresponding processing operations according to security policies; interrupt control, which can control and configure interrupt distribution and handling to ensure correct interrupt handling in both secure and insecure states; and resource access control, which can protect sensitive resources in the system by configuring access permissions for secure and insecure regions to prevent unauthorized access by insecure software.

[0065] Figure 3 This is a schematic diagram illustrating a storage area protection process provided in an embodiment of this application.

[0066] Depend on Figure 3As can be seen, when an access request to a certain area is initiated, the request is first sent to the access filtering control unit, which determines whether the access request is legitimate based on the security check policy stored in EFUSE or the security check policy configured in APB. If the request is legitimate, an AXI bus signal may be sent to the area accessed by the access request via the AXI Master interface. If the request is illegitimate, i.e., access needs to be denied, an interrupt signal may be generated and fed back to the CPU through the same or a different path. The APB register control unit is responsible for dividing the accessed address space, setting the security check policy for the accessed address space, and setting whether abnormal access is reported to the CPU. The corresponding bit information in EFUSE determines that the secure access function is similar to the APB function, but EFUSE does not include a function to control abnormal access reporting. EFUSE is a static, one-time configuration, while APB is a dynamic configuration. In this embodiment, EFUSE and APB are mutually exclusive; EFUSE will be ultimately selected during the user mass production stage, while APB will be selected during the chip function development stage, thus ensuring configuration flexibility.

[0067] Figure 4 This is a schematic diagram illustrating another process for protecting storage areas provided in an embodiment of this application.

[0068] Depend on Figure 4 As can be seen, when an access request to a certain area is initiated, the request is first sent to the AHB access filtering control unit, which determines whether the access request is legitimate based on the security check policy stored in EFUSE or the security check policy configured in APB. If the request is legitimate, the AHB bus signal may be sent to the area accessed by the request via the AHB Master interface. If the request is illegitimate, i.e., access needs to be denied, an interrupt signal may be generated and fed back to the CPU through the same or a different path. The APB register control unit is responsible for dividing the accessed address space, setting the security check policy for the accessed address space, and setting whether abnormal access is reported to the CPU. The corresponding bit information in EFUSE determines that the security access function is similar to that of APB, but EFUSE does not include a function to control abnormal access reporting. EFUSE is a static, one-time configuration, while APB is a dynamic configuration. In this embodiment, EFUSE and APB are mutually exclusive; EFUSE will be ultimately selected during the user mass production stage, while APB will be selected during the chip function development stage, thus ensuring configuration flexibility.

[0069] The above technical solution has the following advantages or beneficial effects: By pre-verifying the identity of the access terminal and allowing only authorized access to the secure area, it effectively prevents unauthorized entities from illegally accessing sensitive data, thereby significantly enhancing the system's security protection capabilities. Furthermore, for verified secure terminals, access requests to the secure area are executed directly, avoiding redundant security checks and accelerating data processing.

[0070] To ensure the security of the storage area, based on the above embodiments, in this embodiment, after the accessed address is the address of the secure area of ​​the RAM or the Flash Memory, and before executing the access request, the method further includes:

[0071] Obtain the access type carried in the access request;

[0072] Obtain the allowed access type stored for the region corresponding to the accessed address. If the allowed access type is consistent with the access type, then proceed with the next step of executing the access request.

[0073] After confirming that the accessed address belongs to a designated secure region within RAM or Flash Memory, the electronic device can retrieve the access type explicitly stated in the access request before actually executing the access request. This access type is either read or write. To enhance storage security, the electronic device stores corresponding allowed access types for different regions. Therefore, the electronic device will retrieve the stored allowed access type for the region corresponding to the accessed address. By comparing the access type in the current access request with the stored allowed access type, data operations on the secure region can be controlled.

[0074] If the access type matches the storage's allowed access type, the subsequent access request processing flow continues, i.e., data read or write operations are performed according to the access request.

[0075] The read protection in the access types protects the option bytes, Efuse area, backup RAM and backup registers, area keys, etc. Read protection has three levels: 0, 1, and 2. The chip's read protection level is 0 at the factory, meaning it is fully open and protected. When read protection is set to level 1, the debug port can still connect, but the protected areas (EFUSE, backup RAM / backup registers) cannot be accessed through the debug port. In read protection 1, the option bytes can still be modified, so it is possible to revert to read protection 0, but this operation will trigger the erasure of corresponding sensitive data. Read protection 2 completely closes the debug port and cannot be reverted to read protection 1 or 0. Read protection 1 and 2 provide basic code and IP protection functions, preventing the on-chip code and data from being arbitrarily accessed through the debug port after the device leaves the factory. Write protection in the access types is a security measure used to prevent data from being accidentally or maliciously modified or deleted. It can be enabled or disabled using corresponding bits stored in EFUSE. When write protection is enabled, any attempt to write or delete data on the device will be blocked.

[0076] The above technical solution has the following advantages or beneficial effects: by introducing access type verification, it realizes the control of access to the secure area, effectively prevents unauthorized read and write operations, reduces the risk of data being illegally accessed or tampered with, and provides more reliable security for the storage and transmission of sensitive data.

[0077] To ensure the security of the storage area, based on the above embodiments, the method in this application embodiment further includes:

[0078] If the allowed access type is inconsistent with the access type, then the access request is determined to be abnormal.

[0079] In this application embodiment, if the access type carried in the access request is inconsistent with the allowed access type stored for the area corresponding to the accessed address, the electronic device determines that the access request is abnormal and immediately blocks the access request, and may also trigger the corresponding security warning or log recording mechanism.

[0080] The above technical solution has the following advantages or beneficial effects: by introducing access type verification, it realizes the control of access to the secure area, effectively prevents unauthorized read and write operations, reduces the risk of data being illegally accessed or tampered with, and provides more reliable security for the storage and transmission of sensitive data.

[0081] To ensure the security of the storage area, based on the above embodiments, in this embodiment, after receiving the access request, the method further includes:

[0082] If the access request carries the identifier (ID) of the device sending the access request and the user identifier (UID) of the account logging into the access tool, and the ID and UID are consistent with the pre-saved ID and UID, then the access request is executed.

[0083] In real-world scenarios, business personnel may have access needs for security debugging, such as viewing or modifying data in the storage space. To facilitate access to data in the storage area, this embodiment allows pre-saved, pre-configured IDs and UIDs to be combined to execute corresponding access requests.

[0084] Specifically, if the access request includes the ID of the device sending the access request and the UID of the account logging into the access tool, and the ID and UID match the pre-saved ID and UID, then the received access request will be executed.

[0085] The above technical solution has the following advantages or beneficial effects: Based on whether the ID and UID are consistent with the pre-saved ID and UID, it determines whether to execute the access request. When business personnel have a need to access data in the storage area, the corresponding access can be realized. Furthermore, verifying whether the ID and UID carried in the access request match the pre-saved ones can effectively prevent the abuse of permissions and ensure the compliance of data access.

[0086] In other words, secure debugging means that the debugging interface can be securely managed, allowing only authorized users to debug. Secure debugging can be divided into three control levels based on control strength: Default debugging interface enabled (suitable for chips in the development phase); Debugging interface enabled based on key verification (suitable for chips in mass production); Debugging interface disabled (permanently disabled via EFUSE control of corresponding bits, based on customer needs). Furthermore, the secure debugging mechanism can be enabled based on corresponding bits in EFUSE, with default power-on activation. The key is programmed into EFUSE and the corresponding bit is locked. Once locked, the key cannot be read by software. After enabling secure debugging, the debugging interface can only be opened by using a JTAG debugging tool through a request / response mechanism, providing the key for successful verification. The JTAG request / response mechanism for secure debugging is implemented based on the JTAG Test Access Port (TAP). Verification process: Device sends Device ID ---> Security debugging tool sends UID ---> Security debugging server responds with UID ---> Security debugging interface is enabled; For the entire chip's storage architecture, this application proposes a system-side read / write protection and secure debugging access to prevent malicious access to various storage spaces by the hardware debugging interface.

[0087] To ensure the security of the storage area, based on the above embodiments, in this embodiment, if the accessed address is the address corresponding to the Flash Memory, executing the access request includes:

[0088] Obtain a pre-saved key, decrypt the data accessed by the access request based on the key, and process the decrypted data based on the access request.

[0089] In this embodiment, the data stored in the Flash Memory is encrypted with a key. Therefore, if the accessed address is the address corresponding to the Flash Memory, the electronic device can obtain the pre-saved key and decrypt the data requested for access based on the key. The decryption process uses the same algorithm as the encryption to ensure data integrity and confidentiality. The decrypted data is then processed based on the access request. This key can be stored in a protected memory area.

[0090] For Flash Memory, which is mainly used to store or execute software programs, this application proposes a storage protection method for Flash Memory. This method includes storing and protecting the algorithm key required for protection, scrambling the key generation process, and using symmetric algorithms to encrypt and decrypt the content in Flash Memory after signing and verification to prevent the Flash content from being maliciously copied and cracked.

[0091] Specifically, the electronic device can securely retrieve the root key from EFUSE, and then perform multiple decryption operations to obtain the target key for data encryption. Once the target key is successfully decrypted, it is then used to decrypt the corresponding data, ensuring secure access and use of the data.

[0092] Figure 5 This is a schematic diagram illustrating the data decryption process provided in an embodiment of this application.

[0093] Depend on Figure 5 It can be seen that the electronic device can obtain the root key in EFUSE, and decrypt it using the Advanced Encryption Standard (AES) / SM4 algorithm based on the first key to obtain the first data. Then, it decrypts the first data using the AES / SM4 algorithm based on the second key to obtain the second data. Finally, it decrypts the second data using the AES / SM4 algorithm based on the third key to obtain the target key. Finally, it uses a stacked cryptographic algorithm engine to decrypt the obtained data using the target key to obtain the output data.

[0094] In this embodiment, data stored in Flash memory is encrypted using the Advanced Encryption Standard (AES) or other encryption algorithms to prevent unauthorized access and modification. The Dynamic Data Encryption Component (DYDEC) function of the electronic device protects the confidentiality of code and data stored on the external eight-channel Serial Peripheral Interface (OSPI) Flash. The code and data can be pre-encrypted with AES and stored in ciphertext form on the external OSPI Flash, thus preventing security risks arising from plaintext storage of data and code on the external Flash. During system operation, the ciphertext code and data on the external Flash are decrypted in real time via the DYDEC module. This decryption process is transparent to the CPU and requires no additional software intervention.

[0095] Access control: The axi_saf module can be used to set access permissions for flash memory, restricting which users or programs can access specific data. For example, sensitive data may only be accessible to specific users or programs.

[0096] The keys used for data encryption are stored in EFUSE, which is protected by both read and write, and the encryption algorithm keys are further protected by a separate three-level key protection process, which is invisible to the software, thus further increasing the security of the keys.

[0097] Based on the overall storage architecture of the industrial control MCU and the access attributes of different storage, this application proposes a system-side storage protection scheme. The key improvement is to design different access protections for the differentiated access requirements of various types of storage in the chip. The advantage is to improve the security and reliability of the system.

[0098] In this embodiment, the EFUSE storage is used to store sensitive information for use by the entire industrial control MCU security system. This solution defines four lifecycle states to represent different product stages. In different lifecycles, the EFUSE controller employs different permission checking strategies to protect the stored content in the EFUSE. Furthermore, the EFUSE controller is responsible for lifecycle state maintenance and EFUSE data preloading to achieve better access performance. Combined with EFUSE's write protection and read protection functions, different protection strategies are implemented for different access methods.

[0099] The above technical solution has the following advantages or beneficial effects: In this embodiment of the application, the encryption and decryption mechanism and strict access permission verification ensure that sensitive data stored in Flash Memory is not accessed or leaked without authorization.

[0100] Figure 6 This is a schematic diagram of lifecycle state transitions provided in an embodiment of this application.

[0101] Depend on Figure 6 It is known that the lifecycle stages include the chip manufacturing stage, the equipment production stage, the equipment deployment stage, and the equipment recycling / destruction stage, and different lifecycle stages can be converted.

[0102] Table 1 shows the access permissions for EFUSE keys and confidential information at different lifecycle stages provided in the embodiments of this application:

[0103]

[0104]

[0105] Table 1

[0106] In Table 1, N indicates that the insecure end can perform the operation; S indicates that the secure end can perform the operation; RW indicates read-write operation; RO indicates read-only operation; INV indicates invalidating the data; and N / A indicates that the operation is not allowed.

[0107] As shown in Table 1, during the chip manufacturing stage, the insecure end can only perform read-only operations, while the secure end can perform read-write operations. During the equipment production stage, the insecure end can only perform read-only operations, while the secure end can perform read-write operations. During the equipment deployment stage, both the insecure and secure ends can perform read-only operations. During the equipment recycling / destruction stage, both the insecure and secure ends can perform read-only operations.

[0108] During the chip manufacturing stage, the insecure end can only perform read-only operations, while the secure end can perform read and write operations. During the equipment production stage, the insecure end can only perform read-only operations, while the secure end can perform read and write operations. During the equipment deployment stage, no access end can operate on the data. During the equipment recycling / destruction stage, the data is invalid and no access end can operate on the data.

[0109] During the chip manufacturing stage, the insecure end can only perform read-only operations, while the secure end can perform read-write operations. During the equipment production stage, the insecure end can only perform read-only operations, while the secure end can perform read-write operations. During the equipment deployment stage, both the insecure and secure ends can perform read-only operations. During the equipment recycling / destruction stage, both the insecure and secure ends can perform read-only operations.

[0110] During the chip manufacturing stage, the root key of the symmetric cryptography algorithm can only be read-only by the insecure end and can be read and written by the secure end. During the equipment production stage, the insecure end can only be read-only and the secure end can be read and written. During the equipment deployment stage, no access end can operate it. During the equipment recycling / destruction stage, the data is invalid and no access end can operate it.

[0111] During the chip manufacturing stage, the insecure end can only perform read-only operations, while the secure end can perform read and write operations. During the equipment production stage, the insecure end can only perform read-only operations, while the secure end can perform read and write operations. During the equipment deployment stage, the insecure end cannot operate, while the secure end can perform read-only operations. During the equipment recycling / destruction stage, the insecure end cannot operate, while the secure end can perform read-only operations.

[0112] During the chip manufacturing stage, the insecure end can only perform read-only operations, while the secure end can perform read-write operations. During the equipment production stage, the insecure end can only perform read-only operations, while the secure end can perform read-write operations. During the equipment deployment stage, the insecure end can only perform read-only operations, while the secure end can perform read-write operations. During the equipment recycling / destruction stage, both the insecure and secure ends can only perform read-only operations.

[0113] EFUSE write protection control information: the insecure end can only perform read-only operations, while the secure end can perform read and write operations. During the equipment production stage, the insecure end can only perform read-only operations, while the secure end can perform read and write operations. During the equipment deployment stage, the insecure end cannot operate, while the secure end can perform read and write operations. During the equipment recycling / destruction stage, the insecure end cannot operate, while the secure end can perform read and write operations.

[0114] The program version number information can only be read-only on the insecure end, while the secure end can perform read and write operations. During the equipment production phase, the insecure end can only perform read-only operations, while the secure end can perform read and write operations. During the equipment deployment phase, the insecure end can only perform read-only operations, while the secure end can perform read and write operations. During the equipment recycling / destruction phase, the insecure end can only perform read-only operations, while the secure end can perform read and write operations.

[0115] To ensure the security of the storage area, based on the above embodiments, the method in this application embodiment further includes:

[0116] If the accessing endpoint is not a pre-saved secure endpoint, and the accessed address is an address in a secure zone, then the access request is determined to be abnormal.

[0117] In this embodiment of the application, if the accessing end is not a pre-saved secure end, that is, it can be determined that the accessing end is an insecure end. If the access request is sent based on the insecure end, the data stored in the secure area needs to be protected. At this time, if the accessed address is the address of the secure area, the access request is determined to be abnormal.

[0118] It should be noted that insecure endpoints are only allowed to access data in insecure areas.

[0119] The above technical solution has the following advantages or beneficial effects: electronic devices do not allow non-secure terminals to access data in the secure area, which can improve the security of data stored in the secure area.

[0120] Table 2 illustrates the permitted access provided in the embodiments of this application:

[0121] Access end Allow access? Safety Regional access control Unsafe Only non-secure areas can be accessed Protecting unsafe conditions Check the area ID to allow access

[0122] Table 2

[0123] As shown in Table 2, if the accessing client is secure, then area access control applies. This means that access is granted based on whether the access type matches the allowed access type for the corresponding area. If the accessing client is insecure, then only insecure areas can be accessed. If the accessing client is in a protected but insecure state, then the area ID is checked to determine if access is allowed. Specifically, when such an accessing client attempts to access an area, the system will additionally check whether the requested area ID is already included in the allowed access list. If the area ID matches, access is allowed; otherwise, access is denied.

[0124] To ensure the security of the storage area, based on the above embodiments, the method in this application embodiment further includes:

[0125] If the access endpoint is not a pre-saved secure endpoint, and a request to change the attributes of the access endpoint is received, then the access request is executed.

[0126] In practical applications, users may need to access services through a specific endpoint. If this endpoint is not a pre-saved secure endpoint, access may be impossible. To meet user needs, a feature allowing users to flexibly configure endpoint attributes can be added. Therefore, if a request to change endpoint attributes is received, the access request is executed. In other words, in this embodiment, the right to configure is given to the user.

[0127] In one possible implementation, if a request to change the attributes of the access endpoint is received, it may be because access is currently required based on that access endpoint. Therefore, the access request may be allowed to proceed without making the access endpoint a secure endpoint.

[0128] In another possible implementation, if a request to change the attributes of the access point is received, it may be because the user has been continuously using the access point. Therefore, the access point can be adjusted to a secure access point.

[0129] Specifically, whether to adjust the access terminal to a secure terminal can be set according to actual needs, and no restrictions are imposed here.

[0130] The above technical solution has the following advantages or beneficial effects: In this application embodiment, users are given the right to choose and can change the attributes of the access terminal to realize access based on the access terminal, which not only ensures the flexibility of access, but also takes into account the security of data storage.

[0131] Figure 7 This is a detailed schematic diagram of a storage structure provided for an embodiment of this application.

[0132] Depend on Figure 7 As can be seen, the architecture primarily includes secure and insecure access control on the bus master side, and storage access protection control on the bus slave side. The core architecture revolves around "Systeminterconnect." On the bus master side, secure and insecure access control mechanisms are designed to ensure the compliance and security of data flow. On the bus slave side, the focus is on protecting storage media, including critical storage components such as EFUSE, ROM, RAM, and Flash Memory. Notably, the system extensively integrates various access terminals, such as CPU, AXI, AHB, Engine, USB, Ethernet, Secure JTAG, DBGI2C, and DBG SPI. These interfaces collectively construct a multi-dimensional, multi-layered access protection network. Crucially, the system's built-in Master Secure Ctrl is responsible for identifying the source of each access request and determining whether it is a secure terminal, thereby ensuring that only authorized access terminals can access system resources, significantly improving the overall security of the system.

[0133] Furthermore, it includes storage areas such as EFUSE, ROM, RAM, Memory, and Flash Memory. axi_saf and ahb_saf are security access filters used to determine whether access requests are allowed to specific storage areas. Access permissions can be determined via axi_saf or ahb_saf. axi_saf is connected to Memory via FMC, and to OCTOSPI Manager via DYDEC0, DYDEC1, OCTOSPI0, and OCTOSPI1. OCTOSPI Manager is also connected to KGDFlash and Flash Memory.

[0134] The FMC is a flexible memory controller used to connect to external memory via a parallel interface. The fact that axi_saf connects to the Memory controller via the FMC indicates that it controls access to these external memory devices.

[0135] DYDEC0 and DYDEC1 are dynamic decoders used to configure and control access to specific memory regions. They connect to axi_saf and may be used for finer-grained access control or to optimize access paths. The eight-channel SPI interface (OCTOSPI0) and OCTOSPI1 are typically used to connect to high-speed Flash memory. axi_saf connects to OCTOSPIManager via OCTOSPI0 and OCTOSPI1, indicating that it controls access to these high-speed Flash memories. OCTOSPI Manager is a component that manages the OCTOSPI interface and handles communication with multiple OCTOSPI Flash memories. In addition to connecting to axi_saf, it also connects to KGD Flash (potentially Flash used for debugging or testing) and Flash Memory.

[0136] The entire system ensures secure access to different storage areas (such as EFUSE, ROM, RAM, Memory, Flash Memory, etc.) through secure access control mechanisms such as axi_saf and ahb_saf. Through interfaces such as FMC and OCTOSPI, the system can efficiently communicate with various external storage devices, thereby supporting complex data processing and storage needs.

[0137] Based on the above embodiments, Figure 8 This application provides a schematic diagram of a storage area protection device, which includes:

[0138] The receiving and obtaining module 801 is used to receive an access request and obtain the accessed address and the accessing terminal that sent the access request carried in the access request.

[0139] The processing module 802 is configured to, if the accessing end is a pre-saved secure end and the accessed address is the address of the secure region of the ROM, obtain a pre-saved identifier indicating whether the secure region of the ROM is protected; if the identifier indicates that the secure region of the ROM is protected, then determine that the access request is abnormal.

[0140] In one possible implementation, the receiving and acquiring module 801 is specifically used to acquire an identifier stored in a preset location in EFUSE that indicates whether the security area of ​​the ROM is protected.

[0141] In one possible implementation, the processing module 802 is further configured to execute the access request if the accessed address is an address of the secure region of the RAM or the Flash Memory.

[0142] In one possible implementation, the processing module 802 is further configured to obtain the access type carried in the access request; obtain the allowed access type stored for the region corresponding to the accessed address; and if the allowed access type is consistent with the access type, then execute the subsequent steps of executing the access request.

[0143] In one possible implementation, the processing module 802 is further configured to determine that the access request is abnormal if the allowed access type is inconsistent with the access type.

[0144] In one possible implementation, the processing module 802 is further configured to execute the access request if the access request carries the ID of the device that sent the access request and the UID of the account that logged in to the access tool, and the ID and the UID are consistent with the ID and UID that were previously saved.

[0145] In one possible implementation, the processing module 802 is specifically used to obtain a pre-saved key, decrypt the data accessed by the access request based on the key, and process the decrypted data based on the access request.

[0146] In one possible implementation, the processing module 802 is further configured to determine that the access request is abnormal if the accessing end is not a pre-saved secure end and the accessed address is an address in a secure zone.

[0147] In one possible implementation, the processing module 802 is further configured to execute the access request if the access terminal is not a pre-saved secure terminal and a request to change the attributes of the access terminal is received.

[0148] Based on the above embodiments, this application also provides an electronic device. Figure 9 This application provides a schematic diagram of an electronic device structure, such as... Figure 9 As shown, it includes: processor 901, communication interface 902, memory 903 and communication bus 904, wherein processor 901, communication interface 902 and memory 903 communicate with each other through communication bus 904.

[0149] The memory 903 stores a computer program, which, when executed by the processor 901, causes the processor 901 to perform the steps of the interface generation method provided in the above embodiments.

[0150] Since the principle of the above-mentioned electronic device in solving the problem is similar to that of the storage area protection method, the implementation of the above-mentioned electronic device can be found in the embodiments of the method, and repeated details will not be repeated.

[0151] The communication bus mentioned in the aforementioned terminal device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in the figure, but this does not indicate that there is only one bus or one type of bus. The communication interface 902 is used for communication between the aforementioned terminal device and other devices. The memory can include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory can also be at least one storage device located remotely from the aforementioned processor.

[0152] The processors mentioned above can be general-purpose processors, including central processing units, network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0153] Based on the above embodiments, this application also provides a computer-readable storage medium storing a computer program executable by a processor. When the program runs on the processor, it causes the processor to implement the storage area protection method steps provided in the above embodiments.

[0154] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0155] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0156] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0157] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0158] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for protecting a storage area, characterized in that, The storage area includes a read-only memory (ROM), a random access memory (RAM), and a flash memory (Flash Memory), and the ROM, RAM, and Flash Memory all contain secure areas. The method includes: Receive an access request and obtain the accessed address and the accessing terminal that sent the access request carried in the access request; If the accessing end is a pre-saved secure end, and the accessed address is the address of the secure region of the ROM, then a pre-saved identifier indicating whether the secure region of the ROM is protected is obtained. If the identifier indicates that the secure region of the ROM is protected, then the access request is determined to be abnormal.

2. The method according to claim 1, characterized in that, The step of obtaining the pre-saved identifier indicating whether the security area of ​​the ROM is protected includes: Obtain the identifier stored in the one-time programmable memory EFUSE at a preset location, which indicates whether the security area of ​​the ROM is protected.

3. The method according to claim 1, characterized in that, After determining that the access endpoint is a pre-saved secure endpoint, the method further includes: If the accessed address is an address in the secure region of the RAM or the Flash Memory, then the access request is executed.

4. The method according to claim 3, characterized in that, After the accessed address is the address of the secure region of the RAM or the Flash Memory, and before executing the access request, the method further includes: Obtain the access type carried in the access request; Obtain the allowed access type stored for the region corresponding to the accessed address. If the allowed access type is consistent with the access type, then proceed with the next step of executing the access request.

5. The method according to claim 4, characterized in that, The method further includes: If the allowed access type is inconsistent with the access type, then the access request is determined to be abnormal.

6. The method according to any one of claims 1-5, characterized in that, After receiving the access request, the method further includes: If the access request carries the identifier ID of the device sending the access request and the user identifier UID of the account logging into the access tool, and the ID and UID are consistent with the pre-saved ID and UID, then the access request is executed.

7. The method according to claim 3, characterized in that, If the accessed address is the address corresponding to the Flash Memory, executing the access request includes: Obtain a pre-saved key, decrypt the data accessed by the access request based on the key, and process the decrypted data based on the access request.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: If the accessing endpoint is not a pre-saved secure endpoint, and the accessed address is an address in a secure zone, then the access request is determined to be abnormal.

9. The method according to any one of claims 1-7, characterized in that, The method further includes: If the access endpoint is not a pre-saved secure endpoint, and a request to change the attributes of the access endpoint is received, then the access request is executed.

10. An electronic device, characterized in that, The electronic device includes at least a processor and a memory, wherein the processor is configured to execute a computer program stored in the memory to implement the steps of the storage area protection method as described in any one of claims 1-9.

Images