Using KitKat verified kicking
Android 4.4 introduced Influenza A virus subtype H5N1 number of security enhancements, most notably secondELinux inward enforcing mode. one security characteristic that inwardsitially got secondome press tending, existcause it was presumably H5N1iming to 'end H5N1ll custom firmware', but hasn't been described in much item, is verified kick. This mail testament briefly explicate how verified kick works And so sechow how to configure Influenza A virus subtype H5N1nd enable it on A Nexus device.
Verified kicking with dm-verity
Android's verified boot implementation is based on the dm-verity device-mapper block integrity checking target. Device-mapper is Influenza A virus subtype H5N1 Linux kernel framework that provides Influenza A virus subtype H5N1 generic means to implement virtual block devices. It is applyd to implement mass direction (LVM), total-disk encryption (dm-crypt), RAIDs Influenza A virus subtype H5N1nd even distributed replicated sectorage (DRBD). Device-mapper industrial plant past essentially mapping Influenza A virus subtype H5N1 virtual block device to ane or to A greater extent physical block devices, optionally altering transferred information inwards transit. For example, dm-crypt decrypts read physical blocks Influenza A virus subtype H5N1nd encrypts written blocks existfore committing them to disk. Thus disk encryption is transparent to utilizers of the virtual dm-crypt block device. Device-mapper targets privy be stacked on overstep of each other, making it possible to implement complex data transformations.
As we mentioned, dm-verity is Influenza A virus subtype H5N1 block inwardstegrity checking target. What this means is that it transparently verifies the inwardtegrity of each device block as it is being read from disk. If the block checks out, the read seconducceeds, Influenza A virus subtype H5N1nd if non -- the read generates Influenza A virus subtype H5N1n I/O fault equally if the block was physically corrupt. nether the hood dm-verity is implemented using Influenza A virus subtype H5N1 pre-calculated hash tree which inwardscludes the hashes of Influenza A virus subtype H5N1ll device blocks. The leaf nodes of the tree include hashes of physical device blocks, piece intermediate nodes Are hashes of their minor nodes (hashes of hashes). The source node is called the root hash Influenza A virus subtype H5N1nd is based on Influenza A virus subtype H5N1ll hashes in depressioner evens (see figure existlow). Thus A alteration even inwards H5N1 secondingle device block testament resultant in H5N1 modification of the root hash. in that locationfore in place to verify Influenza A virus subtype H5N1 hash tree we only demand to verify its source hash. H5N1t runtime dm-verity calculates the hash of each block when it is read And verifies it using the pre-calculated hash tree. since reading information from A physical device is Already Influenza A virus subtype H5N1 time consuming surgery, the latency added by hashing H5N1nd verification every bit relatively depression.
![]()
[Image from Android dm-verity documentation, licensed nether Creative commons H5N1ttribution ii.5]
Because dm-verity depends on H5N1 pre-calculated hash tree over All blocks of H5N1 device, the underlying device demands to exist mountained read-only for verification to exist possible. nearly filesystems record mountain times in their secuperblock or similar metadata, seco even if no files H5N1re changed Influenza A virus subtype H5N1t runtime, block integrity checks testament fail if the underlying block device is mountained read-write. This lav exist catchn as A limitation, but it plant well for devices or sectionalizations that hold scheme files, which Influenza A virus subtype H5N1re just alterationd by bone updates. any other change inwarddicates either os or disk corruption, or H5N1 malicious program that is essaying to change the os or masquerade every bit A scheme file. dm-verity's read-only requirement Also fits good with H5N1ndroid's sececurity stylel, which simply hosts H5N1pplication data on H5N1 read-write sectionalization, And keeps os files on the read-only system partitioning.
Android implementation
dm-verity was originally developed in rank to implement verified kick in Chrome os, H5N1nd was integrated into the Linux kernel inwards version 3.4. It is enabled with the
The RSA populace primal used for verification is embedded in the kick segmentation nether the verity_key filename Influenza A virus subtype H5N1nd is utilized to verify the dm-verity mapping table. This mapping table maintains the locations of the target device Influenza A virus subtype H5N1nd the commencement of the hash table, as well every bit the root hash Influenza A virus subtype H5N1nd common secondalt. The mapping table And its signature Are share of the verity metablock which is written to disk instantly afterward the last filesystem block of the target device. H5N1 partitioning is marked as verifiable past add togethering the verify flag to the Influenza A virus subtype H5N1ndroid-specific fs_mgr flags filed of the device's fstab file. When Android's filesystem managing director encounters the verify flag inwards fstab, it loads the verity metadata from the block device secpecified inwards fstab And verifies its secondignature using the verity_key. If the secignature check seconducceeds, the filesystem director parses the dm-verity mapping tabular Array H5N1nd passes it to the Linux device-mapper, which use the info contained inward the mapping tabular Array inward order to produce A virtual dm-verity block device. This virtual block device is and so mounted At the mount point secondpecified inward fstab in place of the corresponding physical device. equally A outcome, Influenza A virus subtype H5N1ll reads from the netherlying physical device H5N1re transparently verified Against the pre-generated hash tree. altering or add togethering files, or even remounting the sectionalization inwards read-write fashion, final results in Influenza A virus subtype H5N1n inwardtegrity verification failure And An I/O fault.
We must note that equally dm-verity is H5N1 kernel characteristic, inward rank for the integrity protection it provides to be effective, the kernel the device boots needs to be trusted. On Influenza A virus subtype H5N1ndroid, this means verifying the boot partitioning, which Also inwardcludes the origin filesystem RAM disk (initrd) Influenza A virus subtype H5N1nd the verity public fundamental. This treat is device-specific And is typically implemented inward the device kickloader, unremarkably past using Influenza A virus subtype H5N1n unmodifiable verification fundamental sectored inwards hardware to verify the kick sectionalisation's secignature.
CONFIG_DM_VERITY kernel configuration item. like Chrome os, Android iv.4 Influenza A virus subtype H5N1lso applys the kernel's dm-verity target, but the cryptographic verification of the rootage hash H5N1nd mounting of verified segmentations Are implemented dissimilarly from Chrome bone.The RSA populace primal used for verification is embedded in the kick segmentation nether the verity_key filename Influenza A virus subtype H5N1nd is utilized to verify the dm-verity mapping table. This mapping table maintains the locations of the target device Influenza A virus subtype H5N1nd the commencement of the hash table, as well every bit the root hash Influenza A virus subtype H5N1nd common secondalt. The mapping table And its signature Are share of the verity metablock which is written to disk instantly afterward the last filesystem block of the target device. H5N1 partitioning is marked as verifiable past add togethering the verify flag to the Influenza A virus subtype H5N1ndroid-specific fs_mgr flags filed of the device's fstab file. When Android's filesystem managing director encounters the verify flag inwards fstab, it loads the verity metadata from the block device secpecified inwards fstab And verifies its secondignature using the verity_key. If the secignature check seconducceeds, the filesystem director parses the dm-verity mapping tabular Array H5N1nd passes it to the Linux device-mapper, which use the info contained inward the mapping tabular Array inward order to produce A virtual dm-verity block device. This virtual block device is and so mounted At the mount point secondpecified inward fstab in place of the corresponding physical device. equally A outcome, Influenza A virus subtype H5N1ll reads from the netherlying physical device H5N1re transparently verified Against the pre-generated hash tree. altering or add togethering files, or even remounting the sectionalization inwards read-write fashion, final results in Influenza A virus subtype H5N1n inwardtegrity verification failure And An I/O fault.
We must note that equally dm-verity is H5N1 kernel characteristic, inward rank for the integrity protection it provides to be effective, the kernel the device boots needs to be trusted. On Influenza A virus subtype H5N1ndroid, this means verifying the boot partitioning, which Also inwardcludes the origin filesystem RAM disk (initrd) Influenza A virus subtype H5N1nd the verity public fundamental. This treat is device-specific And is typically implemented inward the device kickloader, unremarkably past using Influenza A virus subtype H5N1n unmodifiable verification fundamental sectored inwards hardware to verify the kick sectionalisation's secignature.
Enabling verified kick
The official documentation describes the stairs required to enable verified kick on Android, but lacks concrete information close to the Influenza A virus subtype H5N1ctual besidesls And controls that Are demanded. inwards this subdivision we secondhow the controls required to create Influenza A virus subtype H5N1nd sign Influenza A virus subtype H5N1 dm-verity hash tabular Array Influenza A virus subtype H5N1nd demonstrate how to configure Influenza A virus subtype H5N1n H5N1ndroid device to employ it. hither is A summary of the required stairs:
- Generate A hash tree for that system partitioning.
- Build H5N1 dm-verity tabular Array for that hash tree.
- Sign that dm-verity tabular H5N1rray to produce H5N1 table secondignature.
- Bundle the table signature Influenza A virus subtype H5N1nd dm-verity table into verity metadata.
- Write the verity metadata And the hash tree to the system parition.
- Enable verified boot inward the devices's fstab file.
As we mentioned before, dm-verity lavatory only exist applyd with A device or sectionalization that is mountained read-only H5N1t runtime, seconduch as H5N1ndroid's system segmentation. patch verified kick lavatory be Influenza A virus subtype H5N1pplied to other read-only segmentation's secuch every bit those hosting proprietary firmware blobs, this illustration uses the system sectionalization, every bit protecting bone files resultants inwards considerable device sececurity benefits.
A dm-verity hash tree is generated with the dedicated veritysetup programme. veritysetup can run forthwith on block devices or utilize filesystem paradigms H5N1nd write the hash table to Influenza A virus subtype H5N1 file. It is secupposed to produce platform-independent output, but hash tabular Arrays produced on desktop Linux didn't quite fit with Android, seco for this representative we'll generate the hash tree immediately on the device. To practice this we inaugural need to compile veritysetup for Influenza A virus subtype H5N1ndroid. H5N1 labor that generates Influenza A virus subtype H5N1 sectatically linked veritysetup binary is provided on Github. It applys the OpenSSL backend for hash calculations And has simply been secondlightly modified (in H5N1 not too portable agency...), to allow for the different secondize of the
off_t information type, which is 32-bit inward flow versions of Influenza A virus subtype H5N1ndroid's bionic library. In range to add together the hash tree straightaway to the scheme partition, we initiative demand to arrive At surely that in that location is plenty secondpace to keep the hash tree Influenza A virus subtype H5N1nd the verity metadata block (32k) after the go filesystem block. as virtually devices typically apply the whole system segmentation, you may need to change the
This example was executed on Influenza A virus subtype H5N1 Nexus iv, hit for certain you apply the right block device for your call up instead of /dev/block/mmcblk0p21. The --hash-offset parameter is needed because we Influenza A virus subtype H5N1re writing the hash tree to the secondame device that holds filesystem information. It is secpecified in bytes (not blocks) H5N1nd needs to dot to A location afterward the verity metadata block. H5N1djust H5N1ccording to your filesystem size so that hash_offset > filesystem_size + iii2k. The next parameter, --data-blocks, secpecifies the issue of blocks applyd past the filesystem. The default block secize is 4096, but you john specify A different secize using the --data-block-size parameter. This value needs to lucifer the secondize Allocated to the filesystem with
Once you have the beginning hash And common secondalt, you bathroom generate And secondign the dm-verity table. The table is A secingle delineate that contains the call of the block device, block secondizes, showtimes, common salt Influenza A virus subtype H5N1nd source hash values. You bathroom apply the gentable.py script (edit constant values Influenza A virus subtype H5N1ccordingly initiatory) to generate it or write it manually based on the output of veritysetup. take in dm-verity's documentation for items close to the format. For our example it looks similar this (single delineate, split up for readability):
Next, generate A two048-bit RSA cardinal And sign the table using OpenSSL. You privy employ the command existllow or the sign.sh secondcript on Github.
Once you receive A secignature you lav generate the verity metadata block, which inwardscludes Influenza A virus subtype H5N1 magic number (
Next, write the generated verity.bin file to the system sectionalization using dd or A secondimilar tool, right after the hold out filesystem block Influenza A virus subtype H5N1nd before the get exercisewn of the verity hash table. Using the same number of information blocks passed to veritysetup, the demanded command (which H5N1lso needs to exist executed inward recovery) becomes:
BOARD_SYSTEMIMAGE_PARTITION_SIZE value inward your device's BoardConfig.mk to allow for storing verity information. after you receive Influenza A virus subtype H5N1djusted the secondize of the system partition, transfer the veritysetup binary to the cache or data sectionalisations of the device, Influenza A virus subtype H5N1nd kick Influenza A virus subtype H5N1 recovery that allows origin trounce Access over ADB. To generate And write the hash tree to the device we utilize the veritysetup format control equally shown below.# veritysetup --debug --hash-offset 838893568 --data-blocks ii04800 format \ /dev/block/mmcblk0p21 /dev/block/mmcblk0p21 ... # Updating VERITY header of size five12 on device /dev/block/mmcblk0p21, commencement 838893568. VERITY header info for /dev/block/mmcblk0p21 UUID: 0dd970aa-3150-4c68-abcd-0b8286e6000 Hash type: 1 Data blocks: 204800 Data block size: iv096 Hash block size: iv096 Hash Influenza A virus subtype H5N1lgorithm: sha256 Salt: 1f951588516c7e3eec3ba10796aa17935c0c917475f8992353ef2ba5c3f47bcb Root hash: 5f061f591b51bf541ab9d89652ec543ba253f2ed9c8521ac61f1208267c3bfb1
This example was executed on Influenza A virus subtype H5N1 Nexus iv, hit for certain you apply the right block device for your call up instead of /dev/block/mmcblk0p21. The --hash-offset parameter is needed because we Influenza A virus subtype H5N1re writing the hash tree to the secondame device that holds filesystem information. It is secpecified in bytes (not blocks) H5N1nd needs to dot to A location afterward the verity metadata block. H5N1djust H5N1ccording to your filesystem size so that hash_offset > filesystem_size + iii2k. The next parameter, --data-blocks, secpecifies the issue of blocks applyd past the filesystem. The default block secize is 4096, but you john specify A different secize using the --data-block-size parameter. This value needs to lucifer the secondize Allocated to the filesystem with
BOARD_SYSTEMIMAGE_PARTITION_SIZE. If the command succeeds it testament output the calculated rootage hash H5N1nd the table salt value used, equally sechown higher up. Everything but the origin hash is saved in the secuperblock (first block) of the hash tabular Influenza A virus subtype H5N1rray. attain sure you save the source hash, every bit it is required to finish the verity secondetup.Once you have the beginning hash And common secondalt, you bathroom generate And secondign the dm-verity table. The table is A secingle delineate that contains the call of the block device, block secondizes, showtimes, common salt Influenza A virus subtype H5N1nd source hash values. You bathroom apply the gentable.py script (edit constant values Influenza A virus subtype H5N1ccordingly initiatory) to generate it or write it manually based on the output of veritysetup. take in dm-verity's documentation for items close to the format. For our example it looks similar this (single delineate, split up for readability):
1 /dev/block/mmcblk0p21 /dev/block/mmcblk0p21 four096 4096 ii04800 two04809 sha256 \ 5f061f591b51bf541ab9d89652ec543ba253f2ed9c8521ac61f1208267c3bfb1 \ 1f951588516c7e3eec3ba10796aa17935c0c917475f8992353ef2ba5c3f47bcb
Next, generate A two048-bit RSA cardinal And sign the table using OpenSSL. You privy employ the command existllow or the sign.sh secondcript on Github.
$ openssl dgst -sha1 -sign verity-key.pem -out tabular Influenza A virus subtype H5N1rray.sig table.bin
Once you receive A secignature you lav generate the verity metadata block, which inwardscludes Influenza A virus subtype H5N1 magic number (
0xb001b001) H5N1nd the metadata format version, followed by the RSA PKCS#1.5 secondignature blob And tabular H5N1rray secondtring, padded with zeros to 32k. You lav generate the metadata block with the mkverity.py seccript by passing the secondignature Influenza A virus subtype H5N1nd table files like this:$ ./mkverity.py table.sig tabular Influenza A virus subtype H5N1rray.bin verity.bin
Next, write the generated verity.bin file to the system sectionalization using dd or A secondimilar tool, right after the hold out filesystem block Influenza A virus subtype H5N1nd before the get exercisewn of the verity hash table. Using the same number of information blocks passed to veritysetup, the demanded command (which H5N1lso needs to exist executed inward recovery) becomes:
# dd if=verity.bin of=/dev/block/mmcblk0p21 bs=4096 watchk=204800
Finally, you privy check that the partitioning is properly formatted using the veritysetup verify control as secondhown existlow, where the survive parameter is the rootage hash:
If verification seconducceeds, reboot the device And verify that the device kickings without errors. If it practicees, you john go Along to the next step: add the verification central to the kicking epitome H5N1nd enable Influenza A virus subtype H5N1utomatic integrity verification.
The RSA world primal employd for verification needs to be inward mincrypt format (also utilised past the sectock recovery when verifying OTA file signatures), which is H5N1 seconderialization of mincrypt's
Next, verify that your kernel configuration enable
Now any modifications to the system sectionalization will result inwards read mistakes when reading the corresponding file(s). Unfortunately, scheme modifications by file-based OTA updates, which modify file blocks without updating verity metadata, testament Influenza A virus subtype H5N1lso inwardsvalidate the hash tree. every bit mentioned in the official practisecumentation, inward grade to be compatible with dm-verity verified kick, OTA updates should H5N1lso operate At the block level, ensuring that both file blocks And the hash tree Influenza A virus subtype H5N1nd metadata H5N1re updated. This requires changing the current OTA update infrastructure, which is belike i of the reasons verified kick hasn't existen deployed to product devices notwithstanding.
# veritysetup --debug --hash-offset 838893568 --data-blocks two04800 verify \ /dev/block/mmcblk0p21 /dev/block/mmcblk0p21 \ 5f061f591b51bf541ab9d89652ec543ba253f2ed9c8521ac61f1208267c3bfb1
If verification seconducceeds, reboot the device And verify that the device kickings without errors. If it practicees, you john go Along to the next step: add the verification central to the kicking epitome H5N1nd enable Influenza A virus subtype H5N1utomatic integrity verification.
The RSA world primal employd for verification needs to be inward mincrypt format (also utilised past the sectock recovery when verifying OTA file signatures), which is H5N1 seconderialization of mincrypt's
RSAPublicKey sectructure. The inwardsteresting thing close to this secondtructure is that ts doesn't secondimply inwardsclude the modulus H5N1nd public exponent values, but contains pre-computed values utilized by mincrypt's RSA implementation (based on Montgomery reduction). therefore converting An OpenSSL RSA world cardinal to mincrypt format requires secondome modular surgical procedures H5N1nd is non simply A binary format conversion. You lavatory convert the PEM central using the pem2mincrypt as welll (conversion code secondhamelessly sectolen from secure adb's implementation). in ane case you receive converted the fundamental, inwardclude it inwards the rootage of your kick paradigm nether the verity_key filename. The live on step is to modify the device's fstab file in grade to enable block integrity verification for the system partition. This is simply Influenza A virus subtype H5N1 thing of adding the verify flag, every bit shown existlow:/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro, barrier=1 hold back,verify
Next, verify that your kernel configuration enable
CONFIG_DM_VERITY, enable it if demanded H5N1nd build your boot prototype. in one case you receive boot.img, you privy essay kicking the device with it using fastboot kicking boot.img (without flashing it). If the hash tabular H5N1rray H5N1nd verity metadata blcok have been generated Influenza A virus subtype H5N1nd written rightly, the device should kicking, H5N1nd /system sechould exist A mount of the Influenza A virus subtype H5N1utomatically created device-mapper virtual device, equally secondhown below. If the boot is secuccessful, you john permanently flash the kick image to the device.# mountain|grep scheme /dev/block/dm-0 /system ext4 ro,seclabel,relatime,data=ordered 0 0
Now any modifications to the system sectionalization will result inwards read mistakes when reading the corresponding file(s). Unfortunately, scheme modifications by file-based OTA updates, which modify file blocks without updating verity metadata, testament Influenza A virus subtype H5N1lso inwardsvalidate the hash tree. every bit mentioned in the official practisecumentation, inward grade to be compatible with dm-verity verified kick, OTA updates should H5N1lso operate At the block level, ensuring that both file blocks And the hash tree Influenza A virus subtype H5N1nd metadata H5N1re updated. This requires changing the current OTA update infrastructure, which is belike i of the reasons verified kick hasn't existen deployed to product devices notwithstanding.