Rockchip Linux Secure Boot Developer Guide
:::info 文档信息
文档标识：RK-KF-YF-379 · 发布版本：V2.0.1 · 发布日期：2020-8-10 · 页数：20 · 语言：英文
原始文档：Rockchip_Developer_Guide_Linux_Secure_Boot_EN.pdf
:::
章节大纲
- Rockchip Linux Secure Boot Developer Guide（P1）
- Secure Boot Introduction（P4）
- Secure Boot Process（P4）
- Secure Boot Secure Storage（P4）
- Reference Resources（P5）
- Base Secure Boot（P6）
- Signature Tools（P7）
- UI tool (Windows)（P7）
- Command Line Tool（P8）
- Secure Information Flashing（P8）
- OTP（P8）
- eFuse（P9）
- Verify（P10）
- Signature Tools（P7）
- AVB（P10）
- Notice（P11）
- Firmware Configuration（P11）
- AVB Key（P12）
- Generate vbmeta.sh（P14）
- Flashing Process（P15）
- AVB Lock & Unlock（P15）
- DM-V（P16）
- Sign Firmware（P17）
- Partition Encryption（P18）
- rootfs Encryption（P18）
- Non System Firmware Encryption（P18）
- About mkdm.sh（P19）
- Secure Boot Introduction（P4）
在线预览
若预览无法显示，请直接下载 PDF 后用本地阅读器打开。
1. Secure Boot Introduction
1.1 Secure Boot Process
As shown in the above figure, starting from BootRom, a reliable security verification solution is established step by step on Linux platform. And it is divided into three parts in order. Customers can choose verification contents according to their own need.
Base Secure Boot: start with BootRom and verify Miniloader/Trust/Uboot step by step.
AVB: start with Uboot and verify Boot and Recovery (Optional).
DM-V: verify or decrypt system partition by Ramdisk tool that is packaged in Boot.
Note: the main difference between the above process and Android platform is DM-V process. Android takes fs_mgr mechanism to implement DMV verification in kernel. But Linux uses Ramdisk to verify.
1.2 Secure Boot Secure Storage
The following secure storage areas are included in Linux platform:
| Storage area | Note |
|---|---|
| OTP / eFuse | Located in SOC, it is a fuse mechanism and irreversible flashing. OTP can be flashed by Miniloader but eFuse can only be flashed by PC tool (Refer to Section 2.2 Secure Information Flahing). Medias are different in different SOC. Currently, Linux platforms mainly includes: eFuse: RK3399 / RK3288 OTP： RK3308 / RK3326 / PX30 / RK3328 (See Section 1.3 Reference Resources Rockchip-Secure-Boot-Application-Note-V1.9.pdf） |
| RPMB | It is a physical partition of eMMC, and it is not available in file system and requires SOC authorizing access (that is, it can only be accessed by TEE). Generally it is considered to be a secure area. |
| Security Partition | The logical partition of storage medium is a temporary partition added to supplement the absence of RPMB on Flash. The partition contents are encrypted and stored and cannot be mounted, but may be forcibly erased. It can only be accessed by TEE (if you force to erase, TEE access will fail and Secure Boot will not start properly). |
Note: Since OTP (eFuse) is mainly used internally by Rockchip, for security information, customers should give priority to other areas such as RPMB/Security. If you have a special needs, please apply for related materials by business.
Secure information and storage location of each process:
| Security Information | Storage area |
|---|---|
| Base Secure Boot | Public Key Hash is stored in OTP/eFuse |
| AVB | In OTP device： permanent attributes.bin is stored in OTP _ In eFuse device： permanent attributes.bin is stored in RPMB/Security Partition _ permanent attributes cer.bin is stored in RPMB/Security Partition _ _ (permanent attributes.bin is verified by Base Secure Boot Key) _ |
| DM-V | Root Hash is stored in Boot's Ramdisk, and Boot contents are verified by AVB to ensure accurate |
1.3 Reference Resources
Reference documents are located in SDK/docs/Develop reference documents/SECURITY/ directory:
Rockchip-Secure-Boot-Application-Note-V1.9.pdf
Rockchip-Secure-Boot2.0.pdf SDK/tools/linux/Linux_SecurityAVB/Readme.md
SDK/kernel/ Documentation/device-mapper/
https://android.googlesource.com/platform/external/avb/+/master/README.md
https://source.android.google.cn/security/verifiedboot/dm-verity
Linux Secure Boot tools:
Link of enterprise network disk: https://eyun.baidu.com/s/3qZwY9FQ password: OubV
(Tool’s version is backward compatible, please use the high version tool first)
2. Base Secure Boot
Base Secure Boot provides basic security to U-boot (loader/trust/uboot)
The start process is as follows:
In short, a signed firmware includes Firmware(OBM Code) + Digital Signature + Public key
Digital Signature + Public Key are added by signature tool.
About memory, the signed firmware is stored in eMMC or Flash, and the Public Key Hash is stored in OTP (eFuse) of a chip.
When starting, public key of the end of a firmware is verified by the Hash in OTP, and then the digital signature is verified by the public key to achieve the binding effect of a chip and signature code.
See Rockchip-Secure-Boot-Application-Note-V1.9.pdf for details.
2.1 Signature Tools
2.1.1 UI tool (Windows)
SDK/tools/windows/SecureBootTool_v1.94 or see the enterprise network disk (see Section 1.3 Reference Resources)
- Modify configurations
Open setting.ini in the tool：
If AVB is needed, modify exclude_boot_sign = True。
If the chip uses OTP to enable Secure Boot, set sign_flag=0x20. (bit 5: loader OTP write enabled, boards that have been written OTP, or eFuse chips, this flag should be set to null.)
- Generate public and private keys
Select Chip and Key formats (pem is common format), click “Generate Key Pairs” to generate PrivteKey.pem and PublicKey.pem. (Keys are generated randomly. Please save these two keys properly. After the security function is enabled, if the two keys are lost, the device will not be able to upgrade.)
- Load key
Select “Load Key” to load the public and private keys follow the prompts.
- Signature
There are two ways to sign: only sign update.img and independent sign.
If you have already packaged update.img, you can sign update.img directly by “Sign Firmware”.
Independent sign need to press “CTRL + R +K” to open “Advanced Function”:
“Sign Loader” is used to sign Miniloader.bin
“Sign File” is used to sign trust.img and uboot.img (Actually, sign update.img is unpack update.img, and then sign each firmware separately, and then packaged as a whole, at last sign the whole again)
2.1.2 Command Line Tool
rk_sign_tool_v1.3_win.zip or rk_sign_tool_v1.3_linux.zip are in the enterprise network disk(see Section 1.3 Reference Resources)
| 1 # step1：Generate rsa public private key (if you already have a key, skip this step) 2 ./rk sign tool kk --out . _ _ 3 # step2：Load the public and private keys (can be load only once) and automatically saved to setting.ini 4 ./rk sign tool lk --key privateKey.pem --pubkey publicKey.pem _ _ 5 # step3：Select the chip to determine signature solution 6 ./rk sign tool cc --chip 3326 _ _ 7 # stpe4：Open setting.ini 8 # Set sign flag = 0x20 _ 9 # If the platform uses OTP to store security information, set sign flag = _ 0x20, enable RKloader OTP writing function, empty boards must be enabled; otherwise, this item will be cleared. 10 # If AVB is needed, change exclude boot sign = True _ _ 11 # stpe5：Overall sign( independent sign skip this step). 12 ./rk sign tool sf --firmware update.img _ _ 13 # stpe6：Sign loader, overall sign, skip steps 6-8. 14 ./rk sign tool sl --loader rk3326loader.bin _ _ 15 # stpe7：Sign uboot, for versions before v1.3, RK3326/RK3308 need to add—pss; others do not need. 16 ./rk sign tool si --img uboot.img _ _ 17 # stpe8：Sign trust, for version before v1.3, RK3326/RK3308 need to add-- pss；others do not needed. 18 ./rk sign tool si --img trust.img _ _ | |
|---|---|
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | # step1：Generate rsa public private key (if you already have a key, skip this step) ./rk sign tool kk --out . _ _ # step2：Load the public and private keys (can be load only once) and automatically saved to setting.ini ./rk sign tool lk --key privateKey.pem --pubkey publicKey.pem _ _ # step3：Select the chip to determine signature solution ./rk sign tool cc --chip 3326 _ _ # stpe4：Open setting.ini # Set sign flag = 0x20 _ # If the platform uses OTP to store security information, set sign flag = _ 0x20, enable RKloader OTP writing function, empty boards must be enabled; otherwise, this item will be cleared. # If AVB is needed, change exclude boot sign = True _ _ # stpe5：Overall sign( independent sign skip this step). ./rk sign tool sf --firmware update.img _ _ # stpe6：Sign loader, overall sign, skip steps 6-8. ./rk sign tool sl --loader rk3326loader.bin _ _ # stpe7：Sign uboot, for versions before v1.3, RK3326/RK3308 need to add—pss; others do not need. ./rk sign tool si --img uboot.img _ _ # stpe8：Sign trust, for version before v1.3, RK3326/RK3308 need to add-- pss；others do not needed. ./rk sign tool si --img trust.img _ _ |
| 2.2 S |
2.2.1 OTP
If a chip uses OTP to enable Secure Boot function, ensure that OTP pin of the chip is powered during Loader process. Download firmware directly through AndroidTool (Windows) / upgrade_tool (Linux). The first time you restart, Loader will be responsible for writing Hash of the Key to OTP and activating Secure Boot. Restart again and then the firmware is protected.
2.2.2 eFuse
If a chip uses eFuse to enable Secure Boot function, please ensure that the hardware connection is correct, because kernel has not been started when downloading eFuse, so please ensure that VCC_IO was powered in MaskRom state.
The board enters MaskRom state by using tools/windows/eFusetool_vXX.zip,.
Click "Firmware", select the signed update.img, or Miniloader.bin, click "Start" to start download eFuse. After eFuse is successfully downloaded, power off and restart, enter MaskRom, use AndroidTool to download other sign firmware to the board.
2.3 Verify
After secure boot takes effect, there are logs similar to the following output during Loader process.
| 1 SecureMode = 1 2 Secure read PBA: 0x4 3 SecureInit ret = 0, SecureMode = 1 | |
|---|---|
| 1 2 3 | SecureMode = 1 Secure read PBA: 0x4 SecureInit ret = 0, SecureMode = 1 |
3. AVB
AVB requires U-boot to work together. AVB on Linux is used to guarantee the integrity of uboot.img (including boot.img and recovery.img).
The corresponding tool is in tools/linux/Linux_SecurityAVB.
For detailed usage, please refer to tools/linux/Linux_SecurityAVB/Readme.md
(If there is a conflict, the Linux_SecurityAVB/Readme.md shall prevail)
3.1 Notice
About device lock & unlock：
When a device is in unlock state, program will still verify the whole boot.img. If the firmware has an error, the program will report what the error is, but the device starts normally. If a device is in lock state, the program will verify the whole boot.img. If the firmware has an error, the next level of firmware will not be started. Therefore, setting the device to unlock state during debugging is more convenient.
3.2 Firmware Configuration
Trust：
Endter rkbin/RKTRUST, take RK3308 as an example, find RK3308TRUST.ini and change:
[BL32_OPTION]
SEC=0
to
[BL32_OPTION]
SEC=1
U-boot：
U-boot needs FASTBOOT and OPTEE support:
| 1 CONFIG OPTEE CLIENT=y _ _ 2 CONFIG OPTEE V1=y #RK312x/RK322x/RK3288/RK3228H/RK3368/RK3399 and V2 are _ _ mutually exclusive 3 CONFIG OPTEE V2=y #RK3308/RK3326 and V1 are mutually exclusive _ _ | |
|---|---|
| 1 2 3 | CONFIG OPTEE CLIENT=y _ _ CONFIG OPTEE V1=y #RK312x/RK322x/RK3288/RK3228H/RK3368/RK3399 and V2 are _ _ mutually exclusive CONFIG OPTEE V2=y #RK3308/RK3326 and V1 are mutually exclusive _ _ |
In config files, configure AVB to open:
| 1 CONFIG AVB LIBAVB=y _ _ 2 CONFIG AVB LIBAVB AB=y _ _ _ 3 CONFIG AVB LIBAVB ATX=y _ _ _ 4 CONFIG AVB LIBAVB USER=y _ _ _ 5 CONFIG RK AVB LIBAVB USER=y _ _ _ _ 6 CONFIG AVB VBMETA PUBLIC KEY VALIDATE=y _ _ _ _ _ 7 CONFIG CRYPTO ROCKCHIP=y _ _ 8 CONFIG ANDROID AVB=y _ _ 9 CONFIG ANDROID AB=y #open when needed _ _ 10 CONFIG OPTEE ALWAYS USE SECURITY PARTITION=y #open when pmb is not _ _ _ _ _ available, not open by default 11 CONFIG ROCKCHIP PRELOADER PUB KEY=y #should be open in eFuse security _ _ _ _ solution | |
|---|---|
| 1 2 3 4 5 6 7 8 9 10 11 | CONFIG AVB LIBAVB=y _ _ CONFIG AVB LIBAVB AB=y _ _ _ CONFIG AVB LIBAVB ATX=y _ _ _ CONFIG AVB LIBAVB USER=y _ _ _ CONFIG RK AVB LIBAVB USER=y _ _ _ _ CONFIG AVB VBMETA PUBLIC KEY VALIDATE=y _ _ _ _ _ CONFIG CRYPTO ROCKCHIP=y _ _ CONFIG ANDROID AVB=y _ _ CONFIG ANDROID AB=y #open when needed _ _ CONFIG OPTEE ALWAYS USE SECURITY PARTITION=y #open when pmb is not _ _ _ _ _ available, not open by default CONFIG ROCKCHIP PRELOADER PUB KEY=y #should be open in eFuse security _ _ _ _ solution |
| Firmw |
config file.
| 1 CONFIG FASTBOOT=y _ 2 CONFIG FASTBOOT BUF ADDR=0x800800 #it varies between platforms, refer to _ _ _ default configuration 3 CONFIG FASTBOOT BUF SIZE=0x04000000 #it varies between platforms, refer to _ _ _ default configuration 4 CONFIG FASTBOOT FLASH=y _ _ 5 CONFIG FASTBOOT FLASH MMC DEV=0 _ _ _ _ | |
|---|---|
| 1 2 3 4 5 | CONFIG FASTBOOT=y _ CONFIG FASTBOOT BUF ADDR=0x800800 #it varies between platforms, refer to _ _ _ default configuration CONFIG FASTBOOT BUF SIZE=0x04000000 #it varies between platforms, refer to _ _ _ default configuration CONFIG FASTBOOT FLASH=y _ _ CONFIG FASTBOOT FLASH MMC DEV=0 _ _ _ _ |
| Use |
Parameter：
AVB needs to add vbmeta partition to store firmware signature information, the size is 1M and the location is optional.
AVB needs system partition. On buildroot (that is rootfs partition), rootfs is renamed to system. If uuid is used, uuid partition name should be modified.
If storage medium is Flash, you have to add another security partition to store operation information. Contents also should be encrypted, the size is 4M and the location is optional. (eMMC does not need to add this partition, eMMC operation information is stored in physical RPMB partition)
The following is an example of AVB parameter:
0x00002000@0x00004000(uboot),0x00002000@0x00006000(trust),0x00002000@0x000080
00(misc),0x00010000@0x0000a000(boot),0x00010000@0x0001a000(recovery),0x000100
00@0x0002a000(backup),0x00020000@0x0003a000(oem),0x00300000@0x0005a000(system
),0x00000800@0x0035a000(vbmeta),0x00002000@0x0035a800(security),-
@0x0035c800(userdata:grow)
AVB ab parameter:
| 1 0x00002000@0x00004000(uboot),0x00002000@0x00006000(trust a),0x00002000@0x0000 _ 8000(trust b),0x00002000@0x0000a000(misc),0x00010000@0x0000c000(boot a),0x000 _ _ 10000@0x0001c000(boot b),0x00010000@0x0002c000(backup),0x00020000@0x0003c000( _ oem),0x00300000@0x0005c000(system a),0x00300000@0x0035c000(system b),0x000008 _ _ 00@0x0065c000(vbmeta a),0x00000800@0x0065c800(vbmeta b),0x00002000@0x0065d000 _ _ (security),-@0x0065f00(userdata:grow) | |
|---|---|
| 1 | 0x00002000@0x00004000(uboot),0x00002000@0x00006000(trust a),0x00002000@0x0000 _ 8000(trust b),0x00002000@0x0000a000(misc),0x00010000@0x0000c000(boot a),0x000 _ _ 10000@0x0001c000(boot b),0x00010000@0x0002c000(backup),0x00020000@0x0003c000( _ oem),0x00300000@0x0005c000(system a),0x00300000@0x0035c000(system b),0x000008 _ _ 00@0x0065c000(vbmeta a),0x00000800@0x0065c800(vbmeta b),0x00002000@0x0065d000 _ _ (security),-@0x0065f00(userdata:grow) |
When downloading, the name on the tool should be modified synchronously. After modification, reload parameter.
3.3 AVB Key
The main information of AVB contains the following four Keys:
Product RootKey (PRK): root Key of AVB, in eFuse devices, related information is verified by Base Secure Boot Key. In OTP devices, PRK-Hash information pre-stored in OTP is directly read and verified;
ProductIntermediate Key (PIK): intermediate Key;
ProductSigning Key (PSK): used to sign a firmware;
ProductUnlock Key (PUK): used to unlock a device. A series of files are generated based on these 4 Keys, as shown in the figure. Refer to the Google AVB open
source documents for details. https://android.googlesource.com/platform/external/avb/+/master/README.md
Compared with the original AVB, Linux grabs of main firmware verification function of AVB. In order to adapt to RK platform, additional permanent_attributes_cer.bin is generated in eFuse, in other words, it unnecessary to store permanent_attributes.bin in eFuse, permanent_attributes.bin information is verified directly by Base Secure Boot Key to save eFuse space.
There is already a set of test certificates and key in this directory. If you need a new Key and certificate, you can generate it yourself by the following steps:
Please keep the generated files properly, otherwise you will not be able to unlock after locking, and the device will not be able to flashed.
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -outform PEM -
out testkey_prk.pem
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -outform PEM -
out testkey_psk.pem
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -outform PEM -
out testkey_pik.pem
touch temp.bin
python avbtool make_atx_certificate --output=pik_certificate.bin --
subject=temp.bin --subject_key=testkey_pik.pem --
subject_is_intermediate_authority --subject_key_version 42 --
authority_key=testkey_prk.pem
echo "RKXXXX_nnnnnnnn" > product_id.bin
python avbtool make_atx_certificate --output=psk_certificate.bin --
subject=product_id.bin --subject_key=testkey_psk.pem --subject_key_version
42 --authority_key=testkey_pik.pem
python avbtool make_atx_metadata --output=metadata.bin --
intermediate_key_certificate=pik_certificate.bin --
product_key_certificate=psk_certificate.bin
# The temp.bin is a temporary file created by yourself, just new temp.bin
and don’t need to fill in data.
# Product_id.bin needs to be defined by yourself, the size is 16 bytes,
which can be defined as product ID.
# Generate permanent_attributes.bin：
python avbtool make_atx_permanent_attributes --
output=permanent_attributes.bin --product_id=product_id.bin --
root_authority_key=testkey_prk.pem
# Generate PUK：
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -outform PEM -
out testkey_puk.pem
# Puk_certificate.bin and permanent_attributes.bin are certificates for
unlocking a device. The generation process requires PrivateKey.pem which is
the key to be downloaded into efuse/otp (refer to [Chapter 2 Base Secure
Boot](# Base Secure Boot)). The process is as follows:
python avbtool make_atx_certificate --output=puk_certificate.bin --
subject=product_id.bin --subject_key=testkey_puk.pem --
usage=com.google.android.things.vboot.unlock --subject_key_version 42 --
authority_key=testkey_pik.pem
# For eFuse devices, you also need to generate additional
permanent_attributes_cer.bin (OTP devices can skip this step)
openssl dgst -sha256 -out permanent_attributes_cer.bin -sign PrivateKey.pem
permanent_attributes.bin
3.4 Generate vbmeta.sh
The signature script is make_vbmeta.sh
Below is firmware signature format:：
python avbtool add_hash_footer --image <IMG> --partition_size <SIZE> --
partition_name <PARTITION> --key testkey_psk.pem --algorithm SHA512_RSA4096
IMG is the signed firmware.
SIZE is firmware size after signature, it is at least 64K larger than the original file, and does not exceed the partition size defined in parameter and must be 4K aligned.
PARTITION is boot / recovery
After signature, generate vbmeta.img by the signed file.
Basic format:
| 1 python avbtool make vbmeta image --public key metadata metadata.bin -- _ _ _ _ include descriptors from image <IMG> --algorithm SHA256 RSA4096 -- _ _ _ _ rollback index 0 --key testkey psk.pem --output vbmeta.img _ _ | |
|---|---|
| 1 | python avbtool make vbmeta image --public key metadata metadata.bin -- _ _ _ _ include descriptors from image <IMG> --algorithm SHA256 RSA4096 -- _ _ _ _ rollback index 0 --key testkey psk.pem --output vbmeta.img _ _ |
"--include_descriptors_from_image <IMG> this field can be used multiple times, that is, how many encrypted files, how many --include_descriptors_from_image are added.
For example：
python avbtool make_vbmeta_image --public_key_metadata metadata.bin --
include_descriptors_from_image boot.img --include_descriptors_from_image
recovery.img --algorithm SHA256_RSA4096 --rollback_index 0 --key
testkey_psk.pem --output vbmeta.img
You can modify make_vbmeta.sh script and generate vbmeta.img according to the above rules.
3.5 Flashing Process
- Put boot.img/recovery.img in the directory 2. Run make_vbmeta.sh to generate vbmeta.bin and encrypt boot.img/recovery.img 3. Replace firmware:
Replace uboot.img, trust.img, MiniloaderAll.bin with newly configured firmware
Boot.img uses the encrypted firmware generated in this directory.
Extracted out vbmeta.bin
Modify parameter.txt according to the rules in chapter 2.3
- Flash by the tool.
If you are using a Windows tool, add a vbmeta partition to the tool (security partition depends on parameter), the address should not be full filled. Then reload parameter and the tool will update the address itself.
- After downloading, the device is in unlock state by default. At this time, the firmware will still verify, but it will not block system startup, and only report errors.
3.6 AVB Lock & Unlock
AVB will block unsigned firmware startup only in lock state.
AVB Lock state is active in Fastboot mode. There are three ways for a device entering Fastboot mode:
- Boot to system and run reboot fastboot 2. Go to U-boot command line and enter fastboot usb 0 3. If there is a fastboot button, enter fastboot mode by the button.
Then PC operates by fastboot command (may require administrator permission)
Download PUB Key
| 1 sudo ./fastboot stage permanent attributes.bin _ 2 sudo ./fastboot oem fuse at-perm-attr 3 #Permanent attributes.bin is stored in RPMB/security partition. On an OTP _ device, Hash of permanent attributes.bin is also calculated and download into _ OTP. 4 5 # eFuse only， skip this step if used OTP 6 sudo ./fastboot stage permanent attributes cer.bin _ _ 7 sudo ./fastboot oem fuse at-rsa-perm-attr 8 #Download permanent attributes cer.bin to RPMB/security, in this way, Base _ _ Secure Boot Root Key can be used to verify permanent attributes.bin in efuse _ devices. | |
|---|---|
| 1 2 3 4 5 6 7 8 | sudo ./fastboot stage permanent attributes.bin _ sudo ./fastboot oem fuse at-perm-attr #Permanent attributes.bin is stored in RPMB/security partition. On an OTP _ device, Hash of permanent attributes.bin is also calculated and download into _ OTP. # eFuse only， skip this step if used OTP sudo ./fastboot stage permanent attributes cer.bin _ _ sudo ./fastboot oem fuse at-rsa-perm-attr #Download permanent attributes cer.bin to RPMB/security, in this way, Base _ _ Secure Boot Root Key can be used to verify permanent attributes.bin in efuse _ devices. |
Lock process:
sudo ./fastboot oem at-lock-vboot
sudo ./fastboot reboot
Unlock process:
| 1 sudo ./fastboot oem at-get-vboot-unlock-challenge 2 sudo ./fastboot get staged raw unlock challenge.bin _ _ _ 3 ./make unlock.sh _ 4 sudo ./fastboot stage unlock credential.bin _ 5 sudo ./fastboot oem at-unlock-vboot | |
|---|---|
| 1 2 3 4 5 | sudo ./fastboot oem at-get-vboot-unlock-challenge sudo ./fastboot get staged raw unlock challenge.bin _ _ _ ./make unlock.sh _ sudo ./fastboot stage unlock credential.bin _ sudo ./fastboot oem at-unlock-vboot |
The last Lock Log:
| 1 ANDROID: reboot reason: "(none)" 2 Could not find security partition 3 read is device unlocked() ops returned that device is LOCKED _ _ _ | |
|---|---|
| 1 2 3 | ANDROID: reboot reason: "(none)" Could not find security partition read is device unlocked() ops returned that device is LOCKED _ _ _ |
4. DM-V
One precondition of using DM-V is that boot.img must be secure. This solution will package a ramdisk in boot.img. The security of ramdisk is guaranteed by AVB. The veritysetup tool is used to verify mounted firmware in ramdisk.
The advantage of DM-V is that verification speed is fast, the larger the firmware, the more obvious the effect.
The disadvantage is that DM-V can only work in read-only file systems, Boot and System firmware will become larger.
The basic theory is Device-Mapper-Verity technology, which will do 4K segmentation on a verification firmware and hash calculation for each 4K data slice, iterate multiple layers, and generate corresponding Hash-Map (within 30M) and Root- Hash. When creating a virtual partition based on DM-V, Hash-Map is verified to ensure that the Hash-Map is correct. After the partition is mounted, when there is data accessing, it is going to do hash verification of the 4K partition where the data is located. When verification errors occur, I/O errors are returned, and the corresponding location cannot be used, which is similar to file system corruption.
Please refer to Documentation/device-mapper/ under Kernel for details.
Or refer to https://source.android.google.cn/security/verifiedboot/dm-verit.
4.1 Sign Firmware
DM-V function can be used when kernel opens related resources.
Pay attention to open CONFIG_DM_VERITY when Compiling Kernel.
For related tools, refer to the network disk file (Section 1.3 Reference Resources) Linux_SecurityDM_v1_01.tar.gz
The above compressed files should be decompressed in a Linux environment. It contains soft links and will be expanded to original file size, causing the file to become larger under windows.
Decompress the file to get:
| 1 |── config 2 |── mkbootimg 3 |── mkdm.sh 4 └── ramdisk.tar.gz | |
|---|---|
| 1 2 3 4 | |── config |── mkbootimg |── mkdm.sh └── ramdisk.tar.gz |
First configure the config file, please fill in the corresponding information according to actual situation.
ROOT_DEV= #the partition location of actual root firmware in flash, such as
/dev/mmcblk2p8
INIT= #the first script that actual root runs, generally is /init or
/sbin/init
ROOTFS_PATH= #rootfs firmware that needs to be signed
KERNEL_PATH= #Kernel Image location, generally is
kernel/arch/arm(64)/boot/Image
RESOURCE_PATH= #kernel resource.img location, generally is
kernel/resource.img
Then run ./mkdm.sh -m dmv -c config (--debug) , the script will automatically package Root-Hash into Ramdisk, and package with kernel, resource to boot.img. Hash-Map is attached to rootfs.img. Obtain boot.img and rootfs_dmv.img from output directory.
Download the two firmware to the board instead of the original boot.img and rootfs.img.
5. Partition Encryption
Partition encryption is also based on device-mapper technology, except each partition block treatment. Refer to Chapter 4 DM-V
Advantages: high security, free file system, readable and writable.
Disadvantages: when encrypting partitions, they cannot be compressed; reading and writing data must be calculated by encryption and decryption, which affects the efficiency of reading and writing to some extent.
5.1 rootfs Encryption
Like DM-V, partition encryption also requires Kernel to open related resources:
| 1 CONFIG BLK DEV DM _ _ _ 2 CONFIG DM CRYPT _ _ 3 CONFIG BLK DEV CRYPTOLOOP _ _ _ | |
|---|---|
| 1 2 3 | CONFIG BLK DEV DM _ _ _ CONFIG DM CRYPT _ _ CONFIG BLK DEV CRYPTOLOOP _ _ _ |
Share a set of tools with DM-V (Linux_SecurityDM_v1_01.tar.gz)
Need to configure the following items in the config file:
ROOT_DEV= #the location of actual root firmware in flash, such as
/dev/mmcblk2p8
INIT= #the first script that the actual root runs, generally is /init or
/sbin/init
KERNEL_PATH= #Kernel Image location, generally is
kernel/arch/arm(64)/boot/Image
RESOURCE_PATH= #Kernel resource.img location, generally is
kernel/resource.img
inputimg= #firmware that needs to be encrypted
cipher= #aes-cbc-plain by default
key= #note the format size, the key should match with cipher
Use ./mkdm.sh -m fde-s -c config
to generate boot.img and encrypted.img in output directory.
Download these two firmware to the board instead of the original boot.img and rootfs.img.
5.2 Non System Firmware Encryption
There are many open source tools for firmware encryption and decryption. We are talking about dmsetup (consistent with tools in chapter 5.1) here. To use this tool, you need to open the following configurations:
| 1 # Kernel： 2 CONFIG BLK DEV DM _ _ _ 3 CONFIG DM CRYPT _ _ 4 CONFIG BLK DEV CRYPTOLOOP _ _ _ 5 6 # Buildroot： 7 BR2 PACKAGE LUKSMETA _ _ | |
|---|---|
| 1 2 3 4 5 6 7 | # Kernel： CONFIG BLK DEV DM _ _ _ CONFIG DM CRYPT _ _ CONFIG BLK DEV CRYPTOLOOP _ _ _ # Buildroot： BR2 PACKAGE LUKSMETA _ _ |
| Share |
Need to configure the following items in the config file
inputimg= #firmware that need to be encrypted, or use inputfile to encrypt
folders
cipher= # aes-cbc-plain by default
key= # note the format size, the key should match with cipher
Using ./mkdm.sh -m fde -c config to generate encrypted.img and encrypted_info in the output directory.
Encrypted.img is the encrypted file, which can be mounted and virtualized to a partition device by dmsetup. The encrypted_info here is encrypted information, such as:
| 1 #dmsetup create encfs-4284779680572201071 --table "0 550912 crypt aes-cbc- plain 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 0 TARGET PARTITION 0 1 allow discards" _ _ 2 sectors=550912 3 cipher=aes-cbc-plain 4 key=000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f | |
|---|---|
| 1 2 3 4 | #dmsetup create encfs-4284779680572201071 --table "0 550912 crypt aes-cbc- plain 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 0 TARGET PARTITION 0 1 allow discards" _ _ sectors=550912 cipher=aes-cbc-plain key=000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f |
| 1 source encrypted info _ 2 loopdevice=`losetup -f` 3 losetup ${loopdevice} encrypted.img 4 dmsetup create encrypt-file --table "0 $sectors crypt $cipher $key 0 $loopdevice 0 1 allow discards" _ 5 mount /dev/mapper/encrypt-file /mnt | |
|---|---|
| 1 2 3 4 5 | source encrypted info _ loopdevice=`losetup -f` losetup ${loopdevice} encrypted.img dmsetup create encrypt-file --table "0 $sectors crypt $cipher $key 0 $loopdevice 0 1 allow discards" _ mount /dev/mapper/encrypt-file /mnt |
| 1 umount /mnt 2 dmsetup remove encrypt-file 3 losetup -d ${loopdevice} | |
|---|---|
| 1 2 3 | umount /mnt dmsetup remove encrypt-file losetup -d ${loopdevice} |
5.3 About mkdm.sh
Mkdm.sh provides some basic debugging functions in addition to dm-verity and partition encryption.
For example：
- boot_only
When this option is packaged, only boot.img changed but rootfs didn’t. 2. debug
Provide real-time running commands for all mkdm.sh, which can be useful when script fails to run.
- ramdisk
This option is useful when customers have a customize ramdisk requirement.
- More functions, please read the script.