Android system startup security

  Signed version for release  |  Android Open source project  |  Android Open Source Project

Yes OTA Sign the update package

You can use the following steps to transfer the signed target file zip Convert to signed OTA to update zip：

/data/recovery/ota.zip

ota_from_target_files \
-k  (--package_key) 
signed-target_files.zip \
signed-ota_update.zip

Signature and side loading

Side loading does not bypass Recovery Normal package signature verification mechanism in the process . Before installing a package ,Recovery It will verify whether the software package is provided by Recovery The public key stored in the partition matches the private key for signature , This is the same as the processing of software packages transmitted wirelessly .

The update package received from the main system is usually verified twice ： Once used by the main system Android API Medium RecoverySystem.verifyPackage() Method validation , The other is through Recovery To verify .RecoverySystem API Compare... Stored in the main system /system/etc/security/otacerts.zip file （ By default ） Check the signature in .Recovery The comparison is stored in Recovery Partition RAM On disk /res/keys Check the signature in the file .

By default , The target file generated by this version .zip Will OTA The certificate is set to match the test key . On the published image , Different certificates must be used , In this way, the device can verify the authenticity of the update package . As shown in the previous section , take -o The sign is passed on to sign_target_files_apks You can replace the test key certificate with the publishing key certificate in your certificate directory .

/**
 * Verify the cryptographic signature of a system update package before installing it.  Note that
@param packageFile  the package to be verified  
                    Package to validate
@param listener     an object to receive periodic progress
 updates as verification proceeds.  May be null.
                    As an object of the verification process , Can receive regular progress updates . May be null.
@param deviceCertsZipFile  the zip file of certificates whose
 public keys we will accept.  Verification succeeds if the
 package is signed by the private key corresponding to any
default file (currently "/system/etc/security/otacerts.zip").

@throws IOException if there were any errors reading the
  package or certs files.
@throws GeneralSecurityException if verification failed

Use winHex Check the upgrade package zip Whether the file contains a signature , Reciprocal 3 4 All for ff

 

 

public static void verifyPackage(File packageFile,ProgressListener listener,File deviceCertsZipFile) throws IOException, GeneralSecurityException {  
        long fileLen = packageFile.length();  
        RandomAccessFile raf = new RandomAccessFile(packageFile, "r");  
        try {  
        int lastPercent = 0;  
        long lastPublishTime = System.currentTimeMillis();  
        if (listener != null) {  
        listener.onProgress(lastPercent);  
        }  
        raf.seek(fileLen - 6);  
        byte[] footer = new byte[6];  
        raf.readFully(footer);  
// Whether the upgrade package contains system signature information -sunst2019-6-8 notes   
  if (footer[2] != (byte) 0xff || footer[3] != (byte) 0xff) {  
        throw new SignatureException("no signature in file (no footer)");  
        }  

        int commentSize = (footer[4] & 0xff) | ((footer[5] & 0xff) << 8);  
// The starting position of the signature -sunst2019-6-8 notes   
  int signatureStart = (footer[0] & 0xff) | ((footer[1] & 0xff) << 8);  
        Log.v(TAG, String.format("comment size %d; signature start %d", commentSize, signatureStart));  

        byte[] eocd = new byte[commentSize + 22];  
        raf.seek(fileLen - (commentSize + 22));  
        raf.readFully(eocd);  

        if (eocd[0] != (byte) 0x50 || eocd[1] != (byte) 0x4b ||  
        eocd[2] != (byte) 0x05 || eocd[3] != (byte) 0x06) {  
        throw new SignatureException("no signature in file (bad footer)");  
        }  

        for (int i = 4; i < eocd.length - 3; ++i) {  
        if (eocd[i] == (byte) 0x50 && eocd[i + 1] == (byte) 0x4b &&  
        eocd[i + 2] == (byte) 0x05 && eocd[i + 3] == (byte) 0x06) {  
        throw new SignatureException("EOCD marker found after start of EOCD");  
        }  
        } 

Usually , System images and Recovery Images store the same OTA Public key set . By adding keys only to Recovery key set , Can only be installed by side loading apk package （ Suppose that the update download mechanism of the main system is correctly compared with otacerts.zip To verify ） Signature . You can set... In the product definition PRODUCT_EXTRA_RECOVERY_KEYS Variable to specify that others can only be included Recovery Key in ：

vendor/yoyodyne/tardis/products/tardis.mk

 [...]

PRODUCT_EXTRA_RECOVERY_KEYS := vendor/yoyodyne/security/tardis/sideload

This includes restoring the public key in the key file vendor/yoyodyne/security/tardis/sideload.x509.pem, So it can install packages signed with this key . but otacerts.zip Does not contain additional keys , Therefore, the system that correctly verifies the downloaded package will not be targeted at the apk Package call Recovery.

Certificate and private key

Each key contains two files ： One is with an extension of .x509.pem Certificate , The other is with an extension of .pk8 The private key . The private key needs to be kept secret , And used for apk Sign the package . The key itself may also be password protected . by comparison , The certificate contains only half the public key , Therefore, it can be widely distributed . Certificates are used to validate a apk Whether the package is signed by the corresponding private key .

standard Android build Use four keys , All of these keys are located in build/target/product/security in ：

testkey

Applicable to... With no other key specified apk The general default key for the package .

platform

It is applicable to the... Included in the core platform apk Test key for the package .

share

For families / Test key for shared content in the contact process .

media

For media / Download the apk Test key for the package .

networkstack

It is applicable to apk Test key for the package .networkstack The key is designed for Modular system components   Binary file signature . If your module updates are built separately , And integrated into the device image in a pre built form , You may not need to be in Android Generate... In the source code tree networkstack secret key .

Single apk The bag will be in its Android.mk Set in file LOCAL_CERTIFICATE To specify one of the keys .（ If this variable is not set , Then use testkey.） You can also specify a completely different key by pathname , for example ：

device/yoyodyne/apps/SpecialApp/Android.mk

 [...]

LOCAL_CERTIFICATE := device/yoyodyne/security/special

Now? , Build using device/yoyodyne/security/special.{x509.pem,pk8} Key pair SpecialApp.apk To sign . This version can only use private keys that are not password protected .

Bootloader

avb The verification is carried out twice in total during one startup ,

For the first time bootloader To verify , Verify the root of each partition through the above interface hash And signature .

The second time was on the upper floor init In the , This verification also calls the same interface , Individual parameters may be different .

AVB2.0 Used to start boot , This usage adds a “vbmeta.img” Mirror image .public key Compiled to bootloader Used for verification in vbmeta data ,vbmeta.img The contents shall be as follows public key Verified signature .

vbmeta.img Contains... For validation public key, But only bootloader Verified vbmeta.img Will be credible , Just like certification , Contains credibility public key And signature .

Android Verified Boot 2.0 Briefly - Programmer base

AVB2.0 Used to start boot , This usage adds a “vbmeta.img” Mirror image .public key Compiled to bootloader Used for verification in vbmeta data ,vbmeta.img The contents shall be as follows public key Verified signature .

vbmeta.img Contains... For validation public key, But only bootloader Verified vbmeta.img Will be credible , Just like certification , Contains credibility public key And signature .

 ROM Signed documents

CERT.RSA

CERT.SF

MANIFEST.MF

 CERT.RSA Rename it to P7B It can be used windows Direct view

（1）MANIFEST.MF： This is a summary document . Program traversal Apk/ROM All the files in the package (entry), For files that are not folders, not signed files , Use one by one SHA1 Generate summary information , Reuse Base64 Encoding . If you change apk Files in package , So in apk When installing and verifying , The summary information of the changed document is consistent with MANIFEST.MF The test information is different , So the program cannot be successfully installed .

explain ： If the attacker modifies the contents of the program , A new summary has been regenerated , Then it can be verified , So this is a very simple verification .

WIN see file SHA1 Method

certutil -hashfile D:\test.txt SHA1

---

BTFM.bin SHA1>base64 practice Reference resources android APK Part of the signing process MANIFEST.MF analysis _ Big star column -CSDN Blog _android apk manifest

C:\Users\Administrator\Desktop\miui_DAVINCI_V12.5.1.0.RFJCNXM_d03c1be4ec_11.0\firmware-update>certutil -hashfile BTFM.bin SHA1
SHA1 Of BTFM.bin Hash :
f89045e946ee225f26bacd600c36d985d76ec10d
CertUtil: -hashfile Command completed successfully .

16 Hexadecimal encoding uses winhex convert to 2 Base number

WinHex: Hex Editor & Disk Editor, Computer Forensics & Data Recovery Software

  Binary files are saved as files and then used online base64 The website encodes the document

Base64 File online codec tool

（2）CERT.SF： This is a signed document for the abstract . For what was generated in the previous step MANIFEST.MF, Use SHA1-RSA Algorithm , Sign with the developer's private key . It can only be decrypted using the public key during installation . After decryption , Combine it with unencrypted summary information （ namely ,MANIFEST.MF file ） Contrast , If yes , It indicates that the content has not been abnormally modified .

explain ： In this step , Even if the developer changes the content of the program , And generated a new summary file , But the attacker doesn't have the developer's private key , So we can't generate the correct signature file （CERT.SF）. When the system verifies the program , Decrypt incorrect signature file with developer's public key , The results obtained and the summary file （MANIFEST.MF） It doesn't correspond to , So it can't pass the test , Unable to install file successfully .

（3）CERT.RSA file The public key is saved in 、 The encryption algorithm used .

explain ： The system decrypts the signature file , The required public key is taken from this file .

Conclusion ： As can be seen from the above summary ,META-INFO It says that the documents are linked , To ensure that Android The security of the program .（ It just prevents the developer's program from being modified by an attacker , If the public-private key pair of the developer is obtained from the attacker or the developer develops an attack program ,Android The system cannot detect .）

 

Android P Medium AVB2.0 check _BingKing88 The column -CSDN Blog _avb2.0