Hello! Welcome to Embedic!
This website uses cookies. By using this site, you consent to the use of cookies. For more information, please take a look at our Privacy Policy.
Home > Embedded Events > RAM, ROM Common Security Mechanisms

RAM, ROM Common Security Mechanisms

Date: 13-06-2022 ClickCount: 255

Stable and reliable memory data is the basis of safe MCU operation, but environmental factors and the physical characteristics of memory itself may cause memory data abnormalities. This article will introduce RAM & ROM common security mechanisms in detail.

The safety and reliability of memory (ROM, RAM) data is the basis for the stable operation of MCU. The memory-related safety mechanism is also one of the key points of the basic system guarantee in the design of automotive functional safety. Usually, different automotive chips have their memory verification mechanisms, and corresponding processing means to ensure the normal operation of the function. Some of the common processing mechanisms will be introduced below.

 

RAM's checksum error correction mechanism

The checksum mechanism of RAM is less compared to the checksum mechanism of ROM. The checksum mechanism is a feature of MCU itself, implemented through internal hardware and transparent to the user. It is transparent to the user. Generally, the user will not take the initiative to check the RAM when using it.

1. Parity BitParity Bit is a data verification mechanism often used to determine whether a bit error has occurred during data storage.

The Parity Bit is simple to compute and only requires an iso-or operation on the preceding byte: C = B7^ B6^ C.

C = B7^ B6^ B5^ B4^ B3^ B2^ B1^ B0Parity Bit was the most used error checking technology in RAM before ECC technology, but of course, now only in few CPUs are used because every 1 Byte of data requires 1 bit of check bits, which is not suitable for the already tight RAM of MCU. In addition, Parity Bit can only detect and cannot correct errors. 

2. ECC can know from the analysis of Parity Bit above that by adding 1 bit to the original data, 1 byte can be used to check the correctness of the current 1-byte data. If the data is 256 bytes, it needs 256 bits of check bits, and the erroneous data cannot be corrected. Due to the above disadvantages, ECC has emerged as a new mechanism for error checking and correction of storage.

The calculation process of ECC is a little more complicated than that of Parity Bit, so we will not describe it too much here. Only two main features of ECC are described.

ECC has a substantial error detection capability.

ECC has error correction capability. When there is only a single bit error in the data, ECC can repair the error, but it should be noted that when there are more than 2 bits of errors in the data generated at the same time, ECC may not be able to detect them, which is also the case with Parity Bit.

ROM's error checking mechanism

Compared with the complex RAM space, the ROM space is much simpler to operate. Therefore, users can choose different ROM verification methods according to different needs.

The ECC method can also be used for large-capacity ROMs such as Nand Flash. It is only necessary to satisfy a relatively unique mapping between the ROM content and the generated checksum.

However, the user-implemented ROM checksum mechanism has many drawbacks: no flexible measures to handle checksum failures, additional MCU resources are required for ROM checksum, etc.

HSE With the continuous upgrading of the automotive industry, the degree of car intelligence is also deepening, and more and more cars will achieve the personalized needs of customers using OTA. However, while OTA increases the convenience of car upgrades and maintenance, it also brings a new test to the security and reliability of data. The ROM verification implemented by the application developers themselves is not enough to meet the security requirements of automotive applications. A more flexible and better verification mechanism is needed to ensure the correct operation of MCU programs in automotive applications. The verification mechanism needs to ensure the reliability of data and the reliability of the verification mechanism itself. The following will describe how the NXP S32 series chips use its HSE security subsystem to support the reliability of ROM data and thus ensure the safe and stable operation of automotive applications.

HSE (Hardware Security Engine) is used to provide corresponding security services to applications with strict data reliability and confidentiality requirements. It has the following features.

Independent kernel, firmware, storage space.

The ability to provide secure hardware acceleration for encryption algorithms.

Support for firmware upgrades.

The most basic and main part of the HSE module is its Crypto Engine, which can realize the functions of encryption/decryption/MAC generation verification/signature verification through hardware. Because of HSE's comprehensive and perfect algorithm and key management mechanism, the HSE module can be used to verify the storage area set by the user and perform different operations according to the verification results. Of course, HSE can provide a reliable guarantee for OTA and secure the boot function of MCU. HSE can also offer comprehensive and reliable support for network protocols through hardware acceleration and perfect encryption and decryption algorithm library, which can realize TLS offload, and IP offload and reduce the communication delay of network protocols.

Conclusion

The above mentioned some common memory verification methods and NXP S32 series HSE security subsystem, of course, no matter which way, to achieve OTA and more and more network application functions, through the MCU to achieve a more secure and reliable data storage transmission is the trend now.

  • Qualcomm leads smartphone AP/SoC and baseband revenue with a 44% share.
  • Introduction to introductory knowledge of microcontroller developmen

Hot Products

  • ADSP21262SKBCZ200R

    Manufacturer: Analog Devices

    IC DSP CTLR 32BIT 136CSBGA

    Product Categories: 32bit DSP

    Lifecycle:

    RoHS:

  • TMS320C6748BZCE3

    Manufacturer: Texas Instruments

    IC DSP FIX/FLOAT POINT 361NFBGA

    Product Categories: DSP

    Lifecycle:

    RoHS:

  • PIC16F627-20/P

    Manufacturer: Microchip

    IC MCU 8BIT 1.75KB FLASH 18DIP

    Product Categories: 8bit MCU

    Lifecycle:

    RoHS:

  • CY8C21334-24PVXIT

    Manufacturer: Cypress

    IC MCU 8BIT 8KB FLASH 20SSOP

    Product Categories: 8bit MCU

    Lifecycle:

    RoHS:

Customer Comments

  • Looking forward to your comment

  • Comment

    Verification Code * 

Compare products

Compare Empty