An important aspect of ensuring device security in IoT is to ensure the integrity of the code, preventing malicious code from affecting the normal logic of the business. Generally speaking, it is to timely repair the vulnerabilities faced by the existing attack surface, such as browsers, Bluetooth, and debugging interfaces; on the other hand, it is necessary to ensure that even if malicious code obtains execution permissions, it cannot modify the system image for persistence. The security scheme constructed for this point is usually called Secure Boot.
Secure Boot
As the name suggests, Secure Boot is a secure startup, ensuring that the code loaded and executed after the device starts is trustworthy. There are two main concepts involved: trust chain and trust root. The former guarantees the reliable handover of the execution process, while the latter ensures the credibility of the initial trusted code.
Chain Of Trust
A core idea of trusted boot is to perform integrity verification of the loaded code before the current boot code loads the next level code, and to verify it using PKI public key infrastructure. These boot codes can usually be divided into several stages (stage), such as in ARM:
- BL1: The first piece of code executed after the CPU reset, that is, the position pointed to by the reset vector. This position is usually in ROM, and during the execution process, it copies its own data to SRAM, performs minimal initialization, such as register and CPU initialization operations, and then loads and executes the BL2 code.
- BL2: The main task is to perform architecture and platform-related initialization, such as configuring the MMU to complete memory address and permission mapping, and completing external memory initialization. Then load and execute the BL3 code.
- BL3: Perform runtime initialization operations and load and execute the kernel.
Root Of Trust
The function of the trust chain is to verify the code to be executed in the next stage, which brings us back to a question: who verifies the initial code? As mentioned above, the initial code, i.e., the BL1 code, is stored in the BootROM and cannot be modified after factory burning. Therefore, the BootROM code needs to be as simple as possible, only performing necessary initialization operations.
In this way, the trust root becomes the chip manufacturer that can burn the BootROM code. Trust is transferable, and the chip manufacturer, as the trust root, transfers the code execution authority to the next level, such as the OEM manufacturer. The lower-level code then has the ownership of the trust chain, which means that the lower-level code becomes the new trust root. However, the space of ROM is limited, so OTP (One-Time-Programmable) is usually used to store the signature information of different stages. OTP is a hardware that supports one-time programming, such as poly-silicon fuses, which cannot be recovered after being burned, ensuring that the written content cannot be tampered with.
uboot boot kernel
Option One: AVB
AVB is short for Android Verified Boot, a firmware verification process designed by Google, mainly used for verifying boot system and other firmware.
During the entire AVB verification process, the vbmeta partition is required, and the vbmeta partition and vbmeta.img image need to be added.
You can use the tools provided by avbtool to view the content of the compiled vbmeta.img image:
Code: Select all
$ ./scripts/avbtool info_image --image out/vbmeta.img
Minimum libavb version: 1.0
Header Block: 256 bytes
Authentication Block: 576 bytes
Auxiliary Block: 4480 bytes
Algorithm: SHA256_RSA4096
Rollback Index: 0
Flags: 0
Release String: 'avbtool 1.1.0'
Descriptors:
Hash descriptor:
Image Size: 12744704 bytes
Hash Algorithm: sha256
Partition Name: boot
Salt: f5612dab28bd643de91d2aded2ea06148668da7bd5fc25405a09cc03896603fd
Digest: beefe6ffe61e85daedeabe543f1eac1a5de12768c206d125ef9fea583f698303
Flags: 0vbmeta partition description content:
Brief description of the encryption and decryption process of the vbmeta image:
- Encryption process
Generate a private key based on the digest information, use the private key to generate a public key with extra, and use the private key to sign the vbmeta image (signature), and write the public key and calculated hash to the header of the vbmeta image. - Decryption process
First, verify whether the public key is issued by the platform (public key comparison, to prevent the public key and signature of the vbmeta image from being tampered with), and then use the public key to decrypt the signature.
The encryption and decryption process of boot.img image in AVB:
When compiling and making the boot.img, signing is done by first obtaining a hash value digest (hexadecimal length of 64) through the SHA-256 algorithm, then encrypting this digest with a private key with RSA algorithm, and generating a signature and adding it to the image's footer along with the public key. The digest is also stored in the vbmeta.img image during compilation.
When loading the boot image in the bootloader, the boot descriptor's digest is first read from the vbmeta.img image partition, and then the public key in the boot image is used to decrypt and calculate a digest, which is compared with the digest obtained from the SHA-256 calculation;
If the digests are equal, it means that the boot.img is signed by the platform compilation. If they are not equal, the boot.img may have been tampered with, and the boot will fail.
Finally, the hash of the boot image content is calculated again to see if it is equal. If the hash is not equal, the boot will also fail.
The kernel's cmdline will also print the digest.
Code: Select all
androidboot.vbmeta.digest=51424ad5d01cefe1cb5a4d1b8d1fd94e86f7ee247bfd071225a77c86d9eea481Option Two: FIT
FIT (flattened image tree) is a new firmware boot scheme supported by U-Boot, which supports packaging and verification of any number of images. FIT uses its (image source file) to describe image information, and finally generates itb (flattened image tree blob) image through mkimage tool. Its files use DTS syntax rules, which are very flexible and can be used directly with libfdt library and related tools.
In simple terms, it is to store some signature information and summary values of boot.img in its file.
Code: Select all
signature {
hashed-strings = <0x00000000 0x000000da>;
// 指定被签名内容
hashed-nodes = "/", "/configurations/conf", "/images/fdt",
"/images/fdt/hash", "/images/optee", "/images/optee/hash", "/images/uboot",
"/images/uboot/hash";
// 进行签名的时间、签名者、版本
timestamp = <0x5e9427b4>;
signer-version = "2017.09-g8bb63db-200413-dirty #cjh";
signer-name = "mkimage";
// 签名结果！！(采用sha256+rsa2048)
value = <0x78397d5d 0xb9219a0b 0xa7cb91a7 0xe1f32867 0x62719d9b
0x8901200c 0xfcbac03a 0x1295ccc8 0x1cff9608 0xdf5f69d2 0x21391225 0x7af10ca7
0x5527864f 0xb13f527e 0xddf9ee62 0xea50199d 0x00000003 0x35362c72 0x00000004
0x00000017 0x77617265 0x00000002 0x00000009 0x23616464 0x6d616765 0x73006172
0x6f6e006c 0x72790064 0x61636b2d 0x7265006c 0x006b6579 0x69676e2d 0x706f7369
0x7a650074 0x75650073 0x69676e65 0x73686564 0x642d7374 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000>;
algo = "sha256,rsa2048";
key-name-hint = "dev";
sign-images = "fdt", "firmware", "loadables";
};Kernel boot file system DM-V
One of the prerequisites for using the DM-V principle is that the boot.img must be secure. This scheme will package a ramdisk in the boot.img, the security of the ramdisk is guaranteed by AVB, and the ramdisk will use the veritysetup tool to verify the subsequent mounted firmware.
The advantage of DM-V is that the verification speed is fast, and the larger the firmware, the more obvious the effect.
The disadvantage is that DM-V is suitable for read-only file systems, and the volume of Boot and rootfs will increase.
The basic principle is to use Device-Mapper-Verity technology, which divides the verification firmware into 4K segments and calculates the hash for each 4K data slice, iterates multiple layers, and generates the corresponding Hash-Map (within 30M) and Root-Hash. When creating a virtual partition based on DM-V, the Hash-Map will be verified to ensure that the Hash-Map is correct.
After the partition is mounted, when the data is accessed, a separate HASH check will be performed on the 4K partition where the data is located. When the check fails, an I/O error will be returned, and the corresponding location cannot be used, just like when the file system is damaged.
ramdisk verification process of rootfs: