Bootloader // AVB keys used in ROMs for Fairphone 3+4

,

ok, thanks
Is this really bad, or not? Don’t know…
What do you do in DivestOS?

test-keys basically means verified boot is doing absolutely nothing.

Here is how DivestOS handles it:

3 Likes

@SkewedZeppelin
Thanks for explaining

What’s about calyxOS and the brand new version for FP4
They are using a key, too.
Also only test key?

Can you test this, too, please.

Would be interesting…

And more then that
What is FP doing on their ROM?
In FPOS? Just test keys, too?

CalyxOS for FP4 is correct as it should be:

python verify_signature.py -f boot.img -v vbmeta.img 

Boot Signature Tool v1.6 (c) B.Kerler 2017-2019
----------------------------------------------
Kernel=0x00001000,	length=0x023D8000
Ramdisk=0x023D9000,	length=0x0018A000
Second=0x02563000,	length=0x00000000
QCDT=0x02563000,	length=0x00001000
Signature start=0x02564000

AVB >=2.0 vbmeta detected: avbtool 1.2.0
----------------------------------------
Image-Target: 				boot
Salt: 					12f8db8a983a54a16ee3adab96ad343d8945c6aeb263c0dc8a41e4a35f394482
Image-Size: 				0x25cc000

Calced Image-Hash: 			4ef843934ca727a6a486543641fbcf9d7696d144a918b6a161547b981951955e
Image-Hash: 				4ef843934ca727a6a486543641fbcf9d7696d144a918b6a161547b981951955e
VBMeta-Image-Hash: 			4ef843934ca727a6a486543641fbcf9d7696d144a918b6a161547b981951955e

Signature-RSA-Modulus (n):	b3dea877338dbc3b4cd9690d43c61c02b555154defe69095b5c5eb392b02c7c75391fd37597e1c7a01ad82c1943f94d2db264452004c052a1cd3edc7fecdae50abfbb7a98a921f8b2685f15745f127148c79cdbc651b224b88a8231352fdbcc5eeeda69f8e10b43c9a2d24e476ba3b46b3bda2eee4ea946e23fb50a90fc3e13de6a46f5617f6001caba20ef3eecaed0fab8edf06b39ff71df1c6a7155527b823b07f1108fd5b6c73d0fc4123ef99825fcbd97d219b6e2480a96a258fa943eddcbd47ab97f8075615c443e83f5b93a38ed309ef85c6e63bf1c4bbef53fcce42ed5e608f94ad5834b5b7d46f0e7265838d67b8e22584e9362ab4ce9ef4a3c8447cfa816f8b9a23471d37fd0831999cefa8101649315a85567854e1a21888c2d5d3c6aac2883af5749736b48df3b62f461a21e887d772583142283801ba6ee813b7d034a1589af3144a3f33b2543bb9e782b530ba96e17e31306ff2b70492cd67453207cbdade7ccc336f20e24edb2d3db3bdd5c0f17c1a2787e6a45c4bc98c5ae56b600a44b48abaff01eba8f95295e0c758a9d9d88af440d87f42a13aea4b8a4175f812682691652da1e4abb0797dddf5b2547106ac82b72fcf4b30824135170af271b467d58bce2aa853e02adc482693450757401da1287ac3366580ef7bfed5fd3197b3414a28fa6217095d4704e70e8990bfdcb0498b40ac8fc2ffc171f6874f2e6e065597e2187e73cd375aaf55fb09757f568296c0cba6fb6789bafa57801d8c65cab21ef2757a256365345b219077bd86f7f1d2c90c8fb34cfd9ec45f5030c6677c839721d10359094fa7f0de602b89cf75fa189d0797ceacfe1927397a71cce8b40831ccc0e52057f703e3c1991441cba0f74e962fb32ab54fc07dfabc2b2fcd5b7953cc78db787bce35dad5af9a843315386efa778a6abb28aeac26d1126ae0894ff2f74839c53c34c841ecca0aaf2f3297b1ae966f84b11f535f4160892ba4ef52a6e904739de08e5465f6e0f20b859737de9a967d17b3b7a70eeba4eedf838e0d436f9861a8e24b8cfffef442557214f0b2437369c63cfd158d0f31b8b04ec4bfac2f192cac7466769f8c15641d53d13ff751765e27810cba2f833efe0f8b0fd496a3b3812e8748e2b6ba78268e56e56117154705b85f440fad09c00df489b55f9cd343cb0bff9d0d09047b5f49492ca8b5f685ecbf08feb619543f23bd53507bbb3061c8381f48a164a93e700e7477c2213e15e8e12e50506c4a77c183cc887895a69f2f08b2bc08d541350a7d1484121d69dfac13f32f297d8446d62077fe10f845a644a51c3c163b2befb6bc92dd5a390f9fd5cf4b9ca65e8410d9033ca82ccfeed8edd37d740f673122b87b440af8be10e90b28401e904230158ec7254c79f634111ad23a91229bf2950f8459f32c8c7c22326e76b8e1addd36
Signature-n0inv: 			2872774857
AVB-Status: VERIFIED, 0
3 Likes

And for the finale we see Fairphone shipping test-keys in production somehow:

FP4.FP3R.A.099.20220112_factory.zip:
python verify_signature.py -f boot.img -v vbmeta.img 

Boot Signature Tool v1.6 (c) B.Kerler 2017-2019
----------------------------------------------
Kernel=0x00001000,	length=0x023DC000
Ramdisk=0x023DD000,	length=0x00119000
Second=0x024F6000,	length=0x00000000
QCDT=0x024F6000,	length=0x00001000
Signature start=0x024F7000

AVB >=2.0 vbmeta detected: avbtool 1.1.0
----------------------------------------
Image-Target: 				boot
Salt: 					c68377f8602056d7e5736c8fa7aa40b4ea4af0fac29c02354cbe1f50755e8708
Image-Size: 				0x26e3000

Calced Image-Hash: 			99f243a244a45de8f0e9ca4832cd0eaa71bad3d76b545c89134417b45a6115af
Image-Hash: 				99f243a244a45de8f0e9ca4832cd0eaa71bad3d76b545c89134417b45a6115af
VBMeta-Image-Hash: 			99f243a244a45de8f0e9ca4832cd0eaa71bad3d76b545c89134417b45a6115af

Signature-RSA-Modulus (n):	d804afe3d3846c7e0d893dc28cd31255e962c9f10f5ecc1672ab447c2c654a94b5162b00bb06ef1307534cf964b9287a1b849888d867a423f9a74bdc4a0ff73a18ae54a815feb0adac35da3bad27bcafe8d32f3734d6512b6c5a27d79606af6bb880cafa30b4b185b34daaaac316341ab8e7c7faf90977ab9793eb44aecf20bcf08011db230c4771b96dd67b604787165693b7c22a9ab04c010c30d89387f0ed6e8bbe305bf6a6afdd807c455e8f91935e44feb88207ee79cabf31736258e3cdc4bcc2111da14abffe277da1f635a35ecadc572f3ef0c95d866af8af66a7edcdb8eda15fba9b851ad509ae944e3bcfcb5cc97980f7cca64aa86ad8d33111f9f602632a1a2dd11a661b1641bdbdf74dc04ae527495f7f58e3272de5c9660e52381638fb16eb533fe6fde9a25e2559d87945ff034c26a2005a8ec251a115f97bf45c819b184735d82d05e9ad0f357415a38e8bcc27da7c5de4fa04d3050bba3ab249452f47c70d413f97804d3fc1b5bb705fa737af482212452ef50f8792e28401f9120f141524ce8999eeb9c417707015eabec66c1f62b3f42d1687fb561e45abae32e45e91ed53665ebdedade612390d83c9e86b6c2da5eec45a66ae8c97d70d6c49c7f5c492318b09ee33daa937b64918f80e6045c83391ef205710be782d8326d6ca61f92fe0bf0530525a121c00a75dcc7c2ec5958ba33bf0432e5edd00db0db33799a9cd9cb743f7354421c28271ab8daab44111ec1e8dfc1482924e836a0a6b355e5de95ccc8cde39d14a5b5f63a964e00acb0bb85a7cc30be6befe8b0f7d348e026674016cca76ac7c67082f3f1aa62c60b3ffda8db8120c007fcc50a15c64a1e25f3265c99cbed60a13873c2a45470cca4282fa8965e789b48ff71ee623a5d059377992d7ce3dfde3a10bcf6c85a065f35cc64a635f6e3a3a2a8b6ab62fbbf8b24b62bc1a912566e369ca60490bf68abe3e7653c27aa8041775f1f303621b85b2b0ef8015b6d44edf71acdb2a04d4b421ba655657e8fa84a27d130eafd79a582aa381848d09a06ac1bbd9f586acbd756109e68c3d77b2ed3020e4001d97e8bfc7001b21b116e741672eec38bce51bb4062331711c49cd764a76368da3898b4a7af487c8150f3739f66d8019ef5ca866ce1b167921dfd73130c421dd345bd21a2b3e5df7eaca058eb7cb492ea0e3f4a74819109c04a7f42874c86f63202b462426191dd12c316d5a29a206a6b241cc0a27960996ac476578685198d6d8a62da0cfece274f282e397d97ed4f80b70433db17b9780d6cbd719bc630bfd4d88fe67acb8cc50b768b35bd61e25fc5f3c8db1337cb349013f71550e51ba6126faeae5b5e8aacfcd969fd6c15f5391ad05de20e751da5b9567edf4ee426570130b70141cc9e019ca5ff51d704b6c0674ecb52e77e174a1a399a0859ef1acd87e
Signature-n0inv: 			1440285869

!!!! Image seems to be signed by google test keys, yay !!!!
AVB-Status: VERIFIED, 0

If someone can edit the title of this thread to be something like:
AVB keys used in ROMs for Fairphone
That’d be appreciated.

5 Likes

@SkewedZeppelin

How can i interpret this:

Snipped from google doc: Device State, User-settable root of trust:

If an user-settable root of trust is set, the device should allow a version of Android signed with either the built-in root of trust or the user-settable root of trust to boot.

what difference regarding Trust does it makes?
As I understand it, it is still possible to boot any kernel as long as it is signed with the built-in key, because both will be accepted. Right? Or do I understand it wrong?

https://source.android.google.cn/security/verifiedboot/device-state?hl=en

@SkewedZeppelin
maybe I may have a stement?

@AlphaElwedritsch

In the case you install a properly signed ROM on such a broken bootloader, the
verified boot should be functional.

I am more concerned about the ROMs signing verified boot metadata with test-
keys.
If you could get EDL access you can very likely swap out the system without
triggering a wipe of usredata.

2 Likes

@SkewedZeppelin

Can you test newest iodé build?
https://github.com/vincentvidal/iode_ota/releases/download/v1/iode-2.4-20220405-FP4.zip

signed with own key instead of test-keys

got yellow bootscreen now: that a different OS will be booted…

thanks

@AlphaElwedritsch

iode-2.4-20220405-FP4 appears correct like DivestOS and CalyxOS now.

1 Like

A post was merged into an existing topic: Divest OS: Everything about Divest OS on the Fairphones

Sorry, I haven’t had my morning coffee yet and I just found this thread.

Is this “fixed” now? Do I have anything to worry about when it comes to ROMs?

Hi @SkewedZeppelin

Can you link your verify_signature.py script version ?

I’m testing with repos GitHub - bkerler/android_universal: Universal android boot to root or GitHub - bkerler/dump_avb_signature: Dump Android Verified Boot Signature

But the only result I have is :

python3 /opt/dump_avb_signature/verify_signature.py --file boot.img --vbmeta vbmeta.img

Boot Signature Tool v1.6 (c) B.Kerler 2017-2019
----------------------------------------------
Kernel=0x00000800,	length=0x00F1F800
Ramdisk=0x00F20000,	length=0x00B1C000
Second=0x01A3C000,	length=0x00000000
QCDT=0x01A3C000,	length=0x00000800
Signature start=0x01A3C800

AVB >=2.0 vbmeta detected: avbtool 1.2.0
----------------------------------------
Sorry, only avb version <=1.1 is currently implemented

@thasos

I think I just commented out the version check.

2 Likes

I had a look at vbmeta.img and can confirm that test keys are used for Android Verified Boot for the Stock ROM (checked via avbtool).

What does that mean? Probably the Google AVB test key is configured as OEM root of trust for the bootloader … that in theory opens the possibilty to modify the system without triggering the intergrity checks (though it’s not that trivial).

Or is there another mechanism for secure boot that I’m not aware of?

I personally am a bit more concerned that test key are used apparently accidientially then I am about the actual security implifications oft this.

Hi,

Is this issue about test key in production still revelant ? Does Fairphone support ever replied something on this problem ?

Regards

I just checked, builds are still signed with test keys and that’s unlikely to change.

Just imagine the support nightmare it would create if Fairphone suddenly started to sign their releases with a different key. I’m not even sure it’s possible to update the built-in root of trust, no idea :thinking:
If that’s the case, they’d have to switch to a user-settable root of trust, like some of the custom ROMs are using, which presents the user with a nice :warning: yellow warning screen :warning: on every boot.

FP support probably won’t be all that helpful here, you’d have to be lucky to get redirected to one of the developers. Either way, this issue is unlikely to get resolved :man_shrugging:

If I understand this correctly, using publicly available test keys undermines the whole verified boot process. Sounds like a serious security issue which really needs to be addressed by Fairphone…

If you are using stock FPOS, it absolutely does.

There’s still no leaked EDL loader available…

…so at the moment the door is held shut by security through obscurity, always the best kind… :man_facepalming::smirk:

I aggree, they need to address this, but I don’t think it’s going to get resolved.

4 Likes

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.