Secure Boot refers to a trusted platform startup process established for secure applications. It starts the system in an immutable sequence, and uses the trust chain mechanism and RSA encryption authentication method to verify the authenticity of the source of the software involved in the startup sequence. , thus preventing any unauthorized or maliciously modified software from running on the device.
The enabling of Secure Boot is realized through a set of hardware fuses. For the code to be executed, it must be signed (signed) by a trusted entity identified by the hardware fuse before Secure Boot is enabled. Boot on the device to run.
main effect:
- Trust chain and encrypted authentication mechanism to ensure the integrity and trustworthiness of the image
- Software version anti-rollback mechanism to avoid trusted old version bugs
- The JTAG debugging interface that can be turned off prevents malicious access to information
- Disable the read-write interface to cut off the possibility of leakage from the hardware level
Design ideas
The booting of a device consists of multiple stages, each stage's image performs a specific function, and each image is verified by the previous image. For example, APPSPBL→SBL→ARM®TrustZone, APPSPBL verifies SBL, SBL verifies TZ, and TZ verifies other subsystem images:
1. After power-on, the secure ROM Soc Bootloader (APPSPBL) in the chip starts first, and then verifies and starts the Flash Device Bootloader (SBL or XBL) of the main chip; 2. Next, the Flash Device Bootloader (SBL or XBL) loads and
verifies Check the OS of the security system. After passing, the security system (TrustZone OS) loads and verifies the Normal World Bootloader (Little Kernel) to ensure that the normal world main system is safe before starting (the TZ OS in the Qualcomm platform also loads and verifies the RPM) ;
3. Normal World Bootloader (Little Kernel) loads Normal World OS (Kernel), and performs SHA256 signature verification on the Signed Kernel, and transfers the execution right after passing;
During the entire boot process from power-on reset, the security of the next level is based on the verification of the previous level, and finally depends on the built-in OTP (one-time programming device) and security hardware of the chip, and the level-by-level verification constitutes the trust of the entire system chain. If any link in the chain of trust is destroyed, the entire system will be insecure.
The root of security and trust during system startup is APPSPBL, because it is a read-only firmware solidified in the chip ROM and cannot be modified. Before executing the next image in the boot process, that image is first loaded and authenticated to ensure it contains authorized software. For example, only after the APPSPBL successfully authenticates the SBL, the control right can be transferred to the SBL. The SBL that has obtained the control right is trusted because it has been authenticated, so it can authenticate the next image to be executed, and further establish the safe operating environment of the device through the functions realized by them.
Image signature and verification process
The Secure boot mechanism is based on the RSA algorithm, that is, private key encryption and public key decryption. The public key is programmed into the fuse register of the chip; the private key is used to sign the Hash value of the compiled binary file, and finally burn the signed binary file into the chip.
The verification process is shown in the figure below. When the chip is powered on each time, the APPSPBL solidified in the chip ROM is loaded, and the Secure Boot enable bit of the fuse register is detected.
If the detection result is enabled, APPSPBL will take out the OEM public key Hash from the fuse register of the chip; then use it as the root of trust to start decrypting the certificate chain of the SBL1 image, and obtain the final key for decrypting the code signature Public key Public verification Key; then use the final public key to decrypt the code signature to obtain the Original Signed digest. Secondly, APPSPBL will also recalculate the Hash value of the SBL1 image to be loaded, obtain the Flash digest, and compare the two. When the two are consistent, the verification is passed, and the execution right can be transferred from APPSPBL to SBL; otherwise, the startup process is terminated.
Certificate chain and its format
In general, Secure Boot uses a chain mechanism to verify the authenticity of an image:
- Take the OEM public key Hash in the fuse area as the root of trust, gradually verify the certificate chain, and obtain the public key used to decrypt the code signature;
- Use the public key of the code signature to decrypt the code signature of the image, and obtain the Hash value calculated for the image during compilation;
- After loading the image in DDR, calculate its Hash value, and compare it with the original Hash value obtained in step 2 to verify the authenticity of the source of the image;
The above process requires that the certificate chain of the verified image, such as APPSBL, be correctly constructed. Only when the certificate chain and image code signature are correct, the verification will get the correct result, and we can say that the source of the image is reliable and authentic. The format of the certificate chain is described below.
As shown in Figure 2-2, this is the three-certificate chain structure in the signed image. A signed image includes source code, code signature, and certificate chain, and Secure Boot verification is based on certificate chain verification and code signature verification.
It can be seen from the figure that the three-certificate chain contains three certificates, and each certificate contains its own signature and the public key of the next certificate. The signature of a certificate is generated by the private key of the previous certificate, and the public key of the previous certificate is used to verify the signature of this certificate. By analogy, a total of two certificate verifications are performed, and finally the certificate decrypts the signature with its public key. Image code signing. Note that the certificate signature of the Root CA is verified by the OEM public key Hash stored in the QFPROM. This area of the QFPROM is the so-called fuse area. Once the data is written, it cannot be changed to ensure security.
The three generated certificates all follow the ITU-T X.509 v3 specification; the three signatures Signature(I), Signature(A), and Signature(D) are all calculated by RSASSA-PKCS#1 v1.5 SHA-256 ; The Signature(R) of Root CA is the OEM public key Hash value calculated by SHA256 on itself. The relationship between them is as follows:
- When the Secure Boot function is enabled, write the OEM public key Hash value to the fuse area, which is consistent with Signature(R);
- Root CA generates Signature (I) through Private Key (R) and puts it in Attestation CA;
- Attestation CA generates Signature (A) through Private Key (I) and puts it in Attestation Certificate;
- Attestation Certificate generates Signature (D) through Private Key (A) and puts it in the signature image.
Version rollback protection Rollback Prevention
Version rollback protection, which is used to limit the image version burned into the chip so that it cannot be lower than the version specified in the Rollback prevention register. Even for signed authentication images, when the signature version is lower than the minimum required version, the system will also terminate its startup.
For example: our default initial version is 0, and later found that the 0 version has a risk of bugs that can be exploited or cracked by others. At this time, we can update a version and name it 1, and then set the rollback flag position in the fuse register to 1. After upgrading to version 1, if you want to flash back to version 0 later, the system will block this excluded signature version. Only when the signature version is higher than the version number of the system rollback flag can it be considered legal and valid.
Disable JTAG debugging
When Secure Boot is enabled, you can choose to fuse the Debug-related bits of the QFPROM_RAW_OEM_CONFIG_ROW0_MSB eFuse register to prevent external access to the processor of the device through the JTAG port. This ensures that the Secure Boot sequence at system startup cannot be bypassed.
Verify if fuse signature
There are two methods for testing whether a device has Secure Boot enabled.
- The first type is to read the fuse register for query when the module is running;
- The second category is to visually reflect the enabling situation by downloading the results of the image;
read register
Use devmem program to read QFPROM_RAW_OEM_SEC_BOOT_ROW0_LSB register, address 0x000A01D0 through adb shell : devmem 0xA01D0
1) If the read value is 0x00000000, the module is not fused:
2) If the read value is 0x00303030 , the module has been fused:
QPST download unsigned version
Modules with Secure Boot enabled cannot download unsigned versions.
For a module with Secure Boot enabled, use the QPST software download tool to download the unsigned version.
- Open the QPST tool, select the contents.xml file of the non-signature version and click the Start button
- At this time, QPST will enter the unresponsive state, and after about 1 minute, it will prompt that the download failed
QFIL download unsigned version
For a module with Secure Boot enabled, use the QFIL tool to download the unsigned version.
- Open the QFIL tool, select the non-signature version of the xml file and click the Download button
- At this time, QFIL will enter the unresponsive state, and after about 3 minutes, it will prompt that the download failed.
Error message:
ERROR: function: sahara_rx_data:276 Unable to read packet header. Only read 0 bytes.
ERROR: function: sahara_main:982 Sahara protocol error
ERROR: function: main:320 Uploading Image using Sahara protocol failed
Download Fail:Sahara Fail:QSaharaServer Fail:Process fail
This is because the module with Secure Boot enabled cannot download the unsigned version, and the verification of the image to be downloaded fails.
Precautions
For a module with Secure Boot enabled, downloading a non-signed image such as appsboot.mbn separately will cause the module to fail to boot;
At this time, the module can only run normally by entering the emergency download mode and re-downloading the signature version image.