FORUMS
Remove All Ads from XDA

Security: Test keys vs Release Keys

166 posts
Thanks Meter: 46
 
By mrjeff2, Senior Member on 15th October 2012, 01:27 AM
Post Reply Email Thread
Hey everyone,

Quick questions. I have noticed that many ROMs (not all) appear to be signed using test-keys rather than release keys. I've always had thought this was insecure and led to additional vulnerabilities. Am I wrong? Is using test-keys secure? For reference, I'm looking at the build.prop to come to my conclusion on how a rom is signed.

Thanks.

Edit: googled and found this: http://uncutandroid.com/2011/03/they...-for-a-reason/
15th October 2012, 02:09 AM |#2  
adrynalyne's Avatar
Inactive Recognized Developer
Thanks Meter: 6,568
 
More
Quote:
Originally Posted by mrjeff2

Hey everyone,

Quick questions. I have noticed that many ROMs (not all) appear to be signed using test-keys rather than release keys. I've always had thought this was insecure and led to additional vulnerabilities. Am I wrong? Is using test-keys secure? For reference, I'm looking at the build.prop to come to my conclusion on how a rom is signed.

Thanks.

Edit: googled and found this: http://uncutandroid.com/2011/03/they...-for-a-reason/

You can't find the key type by build.prop. test-keys is just a label. Most Roms are using public aosp keys though.

In fact, the only rom I can think of thats custom signed is BAMF Paradigm.
15th October 2012, 07:49 AM |#3  
OP Senior Member
Thanks Meter: 46
 
More
Quote:
Originally Posted by adrynalyne

You can't find the key type by build.prop. test-keys is just a label. Most Roms are using public aosp keys though.

In fact, the only rom I can think of thats custom signed is BAMF Paradigm.

Do you know how I can verify which key is being used? While I agree it is just a label, I also know that label changes automatically to release-key after i sign my own AOSP builds.
15th October 2012, 03:36 PM |#4  
mwalt2's Avatar
Senior Member
Thanks Meter: 1,539
 
More
Quote:
Originally Posted by adrynalyne


In fact, the only rom I can think of thats custom signed is BAMF Paradigm.

Do you have a guide posted somewhere on how to generate a custom key and incorporate it into the build process? I think I remember seeing it one time, but now I can't find it. Thanks
15th October 2012, 05:43 PM |#5  
adrynalyne's Avatar
Inactive Recognized Developer
Thanks Meter: 6,568
 
More
Quote:
Originally Posted by mwalt2

Do you have a guide posted somewhere on how to generate a custom key and incorporate it into the build process? I think I remember seeing it one time, but now I can't find it. Thanks

I don't offhand. I followed the Readme under build/target/product/security when I built the BAMF ones:




-----------------------------------------------------------------------------------------------------
The following commands were used to generate the test key pairs:

development/tools/make_key testkey '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'
development/tools/make_key platform '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'
development/tools/make_key shared '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'
development/tools/make_key media '/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/[email protected]'

The following standard test keys are currently included:

testkey -- a generic key for packages that do not otherwise specify a key.
platform -- a test key for packages that are part of the core platform.
shared -- a test key for things that are shared in the home/contacts process.
media -- a test key for packages that are part of the media/download system.

These test keys are used strictly in development, and should never be assumed
to convey any sort of validity. When $BUILD_SECURE=true, the code should not
honor these keys in any context.


signing using the openssl commandline (for boot/system images)
--------------------------------------------------------------

1. convert pk8 format key to pem format
% openssl pkcs8 -inform DER -nocrypt -in testkey.pk8 -out testkey.pem

2. create a signature using the pem format key
% openssl dgst -binary -sha1 -sign testkey.pem FILE > FILE.sig

extracting public keys for embedding
------------------------------------
it's a Java tool
but it generates C code
take a look at commands/recovery/Android.mk
you'll see it running $(HOST_OUT_JAVA_LIBRARIES)/dumpkey.jar
--------------------------------------------------------------------------------------------------


This is the part rom developers should pay attention to when they do not change keys.

These test keys are used strictly in development, and should never be assumed
to convey any sort of validity. When $BUILD_SECURE=true, the code should not
honor these keys in any context.
The Following User Says Thank You to adrynalyne For This Useful Post: [ View ] Gift adrynalyne Ad-Free
15th October 2012, 05:51 PM |#6  
adrynalyne's Avatar
Inactive Recognized Developer
Thanks Meter: 6,568
 
More
Quote:
Originally Posted by mrjeff2

Do you know how I can verify which key is being used? While I agree it is just a label, I also know that label changes automatically to release-key after i sign my own AOSP builds.

I've not had that feature actually work.

# The "test-keys" tag marks builds signed with the old test keys,
# which are available in the SDK. "dev-keys" marks builds signed with
# non-default dev keys (usually private keys from a vendor directory).
# Both of these tags will be removed and replaced with "release-keys"
# when the target-files is signed in a post-build step.


That could be because we didn't change the name of the keys, just the actual key contents themselves.

Otherwise, you can open Cert.rsa in a text editor and it becomes pretty obvious if its been signed with stuff other than public test keys.
16th October 2012, 08:43 PM |#7  
OP Senior Member
Thanks Meter: 46
 
More
I sign mine using the sign_target_files command or something like that using the d switch to specify where my keys are. I then regenerate the ota using the ota_from_target_files command.

Sent from my Galaxy Nexus using Tapatalk 2
The Following 2 Users Say Thank You to mrjeff2 For This Useful Post: [ View ] Gift mrjeff2 Ad-Free
16th October 2012, 08:49 PM |#8  
adrynalyne's Avatar
Inactive Recognized Developer
Thanks Meter: 6,568
 
More
Quote:
Originally Posted by mrjeff2

I sign mine using the sign_target_files command or something like that using the d switch to specify where my keys are. I then regenerate the ota using the ota_from_target_files command.

Sent from my Galaxy Nexus using Tapatalk 2

Gotcha.
18th November 2013, 01:45 PM |#9  
GoDzPlaY's Avatar
Member
Flag Pune
Thanks Meter: 2
 
More
Question
Quote:
Originally Posted by adrynalyne

Gotcha.

I am doing R&D on FOTA(Firmware Update Over the Air) using Nexus 7-Wifi(grouper). For which I followed the following steps.

1. Downloaded the android source from source.android.com for v 4.2.2_r1 and v 4.3_r1
2. Downloaded the binaries for grouper, extract it to my source folder.
3. Then I compiled the source code using following commands.
i. source build/envsetup.sh
ii. lunch full_grouper-userdebug
iii. make -j8 dist
4. After few tries, I had success in compiling the source for Nexus 7(grouper).
5. I got following files in $out/source_4.2.2/dist folder
-----------------------------------------------
adb*
android-common-carousel.jar
android-common.jar
android-info.txt
android-support-v13.jar
android-support-v4.jar
android-support-v7-gridlayout.jar
build.prop
com.android.nfc_extras.jar
fastboot*
full_grouper-apps-eng.root.zip
full_grouper-emulator-eng.root.zip
full_grouper-img-eng.root.zip
full_grouper-ota-eng.root.zip
full_grouper-symbols-eng.root.zip
full_grouper-target_files-eng.root.zip
gpl_source.tgz
guava.jar
installed-files.txt
jsr305.jar
mkbootfs*
mkbootimg*
mkyaffs2image*
mp4parser.jar
package-stats.txt
ramdisk.img
signapk.jar
vendor_owner_info.txt
-----------------------------------------------
6. Then I generated my own keys using /development/tools/make_key tool for media, testkey, releasekey, shared, platform.
Assume my keys are locate at /keys folder.
7. Then I created a signed target zip file using following command.
/source/build/tools/releasetools/sign_target_files_apks -v -p ../host/linux-x86 -d /keys full_grouper-target_files-eng.root.zip signed_target_files.zip
8. From signed target zip file I create
/source/build/tools/releasetools/img_from_target_files -v -p ../host/linux-x86 signed_target_files.zip signed_img_from_target_files.zip
9. Then I flashed the signed_img_from_target_files.zip using fastboot command using the following script:
----------------------------------------------------------------------
fastboot oem unlock
fastboot erase boot
fastboot erase cache
fastboot erase recovery
fastboot erase system
fastboot erase userdata
fastboot reboot-bootloader
sleep 10
fastboot -w update signed_img_from_target_files.zip
----------------------------------------------------------------------
10. The device gets flashed well and is working, but I am getting an log while flashing in which it is unable to find boot.sig, system.sig and recovery.sig
11. Now the otacerts.zip file contains a testkey which is not the one that I signed it with.
file located at "/system/etc/security/otacerts.zip" on device.
12. Now since the otacerts.zip is signed with the default key it gives a mismatch error which I tried to flash an OTA update which is signed by the my custom key.

Now my doubt is:
How can I add boot.sig, recovery.sig and system.sig to signed_img_from_target_files.zip?
Is there anything I am doing wrong?
Does the recovery checks the current ROM keys from "/system/etc/security/otacerts.zip"?
What is the correct procedure to sign the OTA update?
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes