Overview
Technical Background
Flash XIP decryption is a security mechanism designed to protect chip firmware, aimed at preventing unauthorized reading of firmware. In embedded systems, firmware typically executes in place (XIP, eXecute In Place) from external Flash. If the firmware is not encrypted, attackers can physically read the firmware from Flash to crack and clone it, and copy it to other devices for execution. Such firmware leakage not only causes intellectual property loss but also introduces security risks. Traditional firmware protection schemes typically rely on software encryption or external security chips, but these approaches suffer from performance overhead, increased cost, or insufficient security.
The Ameba series ICs integrate a hardware RSIP (Runtime Secure Image Protection) real-time decryption module inside the chip, achieving firmware protection without affecting system performance.
Security Mechanism
RSIP uses the AES-256 algorithm to encrypt firmware in Flash, preventing firmware from being cracked. AES is a symmetric encryption algorithm where the same key is used for both encryption and decryption. The key is stored in the on-chip OTP area and is protected by read/write protection mechanisms to prevent the key from being extracted or tampered with.
The key and the chip are mutually bound: on one hand, the chip can only run firmware encrypted with the corresponding key; on the other hand, encrypted firmware can only run on a chip that has been programmed with the corresponding key. Even if the firmware is cloned to another device, it cannot run.
During chip operation, RSIP uses the OTP key to decrypt the Flash ciphertext and then provides the plaintext to the CPU. The entire process is automatically completed by hardware and has virtually no impact on system performance. RSIP contains multiple independent decryption channels (Entry), allowing different IV and algorithm modes to be configured for different firmware partitions (such as Bootloader, APP, etc.), achieving risk isolation.
Usage Workflow
The Ameba SDK provides a complete out-of-the-box Flash XIP decryption solution. All complex encryption and decryption mechanisms have been implemented in the SDK. Developers do not need to write code themselves; they only need to configure the SDK according to the user guide. The RSIP usage workflow can be divided into the following three stages:
Development and Production Stage: Developers first generate a random RSIP key, then compile the SDK to produce plaintext firmware, and then a script automatically uses the key to encrypt the plaintext firmware and output ciphertext firmware. Two operations need to be completed on the production line: programming the RSIP key into the chip’s OTP area, and then programming the ciphertext firmware into Flash. This process ensures that firmware is transmitted and stored in encrypted form, and that the key is bound to each chip.
Product Storage and Distribution Stage: After the product leaves the factory, encrypted firmware is stored in Flash. The key in OTP is read/write protected, effectively preventing key leakage. This achieves multiple protections including firmware confidentiality, firmware anti-replacement, and product anti-cloning.
Chip Operation Stage: When the chip powers on and runs, the CPU needs to read instructions and data. At this point, the RSIP module inside the chip uses the key stored in OTP to decrypt the ciphertext data in Flash into plaintext in real time and provide it to the CPU. The entire decryption process is automatically completed by hardware, completely transparent to software, and has virtually no impact on system performance.
RSIP Usage Workflow Diagram
RSIP supports two key usage modes: “one key per product model” and “one key per device”. The one-key-per-model approach is the recommended scheme, where all devices of the same product model share the same key, and firmware only needs to be encrypted once for mass production use. This scheme, based on the strong AES-256 encryption algorithm and OTP key protection mechanism, can effectively prevent firmware leakage and cloning, meeting the security requirements of the vast majority of application scenarios. Meanwhile, RSIP also supports the one-key-per-device scheme, where each chip uses an independent key and firmware is encrypted individually, suitable for application scenarios with special security level requirements.
