Android 9 admite la rotación de claves APK , lo que brinda a las aplicaciones la capacidad de cambiar su clave de firma como parte de una actualización de APK. Para que la rotación sea práctica, los APK deben indicar niveles de confianza entre la clave de firma nueva y la antigua. Para admitir la rotación de claves, actualizamos el esquema de firma de APK de v2 a v3 para permitir el uso de claves nuevas y antiguas. V3 agrega información sobre las versiones de SDK compatibles y una estructura de prueba de rotación al bloque de firma de APK.
Bloque de firma de APK
Para mantener la compatibilidad con versiones anteriores del formato APK v1, las firmas APK v2 y v3 se almacenan dentro de un bloque de firma APK, ubicado inmediatamente antes del directorio central ZIP.
El formato del bloque de firma de APK v3 es el mismo que el de v2 . La firma v3 del APK se almacena como un par ID-valor con ID 0xf05368c0.
APK Signature Scheme v3 Block
El esquema v3 está diseñado para ser muy similar al esquema v2 . Tiene el mismo formato general y admite los mismos ID de algoritmo de firma , tamaños de clave y curvas EC.
Sin embargo, el esquema v3 agrega información sobre las versiones de SDK compatibles y la estructura de prueba de rotación.
Formato
El bloque APK Signature Scheme v3 se almacena dentro del APK Signing Block con el ID 0xf05368c0
.
El formato del bloque APK Signature Scheme v3 sigue el de v2:
- secuencia con prefijo de longitud del
signer
prefijo de longitud:-
signed data
prefijo de longitud:- Secuencia con prefijo de longitud de
digests
prefijo de longitud:-
signature algorithm ID
(4 bytes) -
digest
(prefijo de longitud)
-
- secuencia con prefijo de longitud de
certificates
X.509:-
certificate
X.509 con prefijo de longitud (formulario ASN.1 DER)
-
-
minSDK
(uint32): este firmante debe ignorarse si la versión de la plataforma está por debajo de este número. -
maxSDK
(uint32): este firmante debe ignorarse si la versión de la plataforma está por encima de este número. - secuencia con prefijo de longitud de
additional attributes
prefijo de longitud:-
ID
(uint32) -
value
(longitud variable: longitud del atributo adicional - 4 bytes) -
ID - 0x3ba06f8c
-
value -
estructura de prueba de rotación
-
- Secuencia con prefijo de longitud de
-
minSDK
(uint32) - duplicado del valor minSDK en la sección de datos firmados - se usa para omitir la verificación de esta firma si la plataforma actual no está dentro del rango. Debe coincidir con el valor de los datos firmados. -
maxSDK
(uint32) - duplicado del valor maxSDK en la sección de datos firmados - usado para omitir la verificación de esta firma si la plataforma actual no está dentro del rango. Debe coincidir con el valor de los datos firmados. - secuencia con prefijo de longitud de
signatures
prefijo de longitud:-
signature algorithm ID
(uint32) -
signature
con prefijo de longitud sobresigned data
-
-
public key
prefijo de longitud (SubjectPublicKeyInfo, formulario ASN.1 DER)
-
Estructuras de prueba de rotación y certificados antiguos de autoconfianza
La estructura de prueba de rotación permite a las aplicaciones rotar su certificado de firma sin ser bloqueadas en otras aplicaciones con las que se comunican. Para lograr esto, las firmas de aplicaciones contienen dos nuevos datos:
- afirmación para terceros de que se puede confiar en el certificado de firma de la aplicación dondequiera que se confíe en sus predecesores
- Certificados de firma más antiguos de la aplicación en los que la propia aplicación todavía confía
El atributo de prueba de rotación en la sección de datos firmados consiste en una lista enlazada individualmente, con cada nodo que contiene un certificado de firma utilizado para firmar versiones anteriores de la aplicación. Este atributo está destinado a contener las estructuras de datos conceptuales de prueba de rotación y certificados antiguos de autoconfianza. La lista está ordenada por versión con el certificado de firma más antiguo correspondiente al nodo raíz. La estructura de datos de prueba de rotación se construye haciendo que el certificado en cada nodo firme el siguiente en la lista, y así imbuir cada nueva clave con evidencia de que debe ser tan confiable como las claves más antiguas.
La estructura de datos de certificados antiguos de autoconfianza se construye agregando indicadores a cada nodo que indican su pertenencia y propiedades en el conjunto. Por ejemplo, puede haber una bandera que indique que el certificado de firma en un nodo determinado es confiable para obtener permisos de firma de Android. Esta marca permite que a otras aplicaciones firmadas por el certificado anterior se les otorgue un permiso de firma definido por una aplicación firmada con el nuevo certificado de firma. Debido a que todo el atributo de prueba de rotación reside en la sección de datos firmados del campo del signer
v3, está protegido por la clave utilizada para firmar el apk que lo contiene.
Este formato excluye múltiples claves de firma y la convergencia de diferentes certificados de firma de antepasados en uno (múltiples nodos de inicio a un receptor común).
Formato
La prueba de rotación se almacena dentro del bloque APK Signature Scheme v3 con el ID 0x3ba06f8c
. Su formato es:
- secuencia con prefijo de longitud de
levels
prefijo de longitud:-
signed data
prefijo de longitud (por certificado anterior, si existe)-
certificate
X.509 con prefijo de longitud (formulario ASN.1 DER) -
signature algorithm ID
(uint32): algoritmo utilizado por cert en el nivel anterior
-
-
flags
(uint32): indicadores que indican si este certificado debe estar o no en la estructura autoconfianza-antiguos-certs y para qué operaciones. -
signature algorithm ID
(uint32): debe coincidir con el de la sección de datos firmados en el siguiente nivel. -
signature
con prefijo de longitud sobre lossigned data
arriba
-
Varios certificados
Actualmente, Android trata un APK firmado con varios certificados como si tuviera una identidad de firma única independiente de los certificados que lo componen. Por lo tanto, el atributo de prueba de rotación en la sección de datos con signo forma un gráfico acíclico dirigido, que podría verse mejor como una lista de enlaces individuales, con cada conjunto de firmantes para una versión dada que representa un nodo. Esto agrega complejidad adicional a la estructura de prueba de rotación (versión de múltiples firmantes a continuación). En particular, hacer pedidos se convierte en una preocupación. Además, ya no es posible firmar APK de forma independiente, porque la estructura de prueba de rotación debe tener los certificados de firma antiguos firmando el nuevo conjunto de certificados, en lugar de firmarlos uno por uno. Por ejemplo, un APK firmado por la clave A que desea ser firmado por dos nuevas claves B y C no podría tener el firmante B solo incluir una firma de A o B, porque esa es una identidad de firma diferente a B y C. Esto haría significa que los firmantes deben coordinarse antes de construir dicha estructura.
Atributo de prueba de rotación de varios firmantes
- secuencia con prefijo de longitud de
sets
prefijo de longitud:-
signed data
(por conjunto anterior, si existe)- secuencia de
certificates
prefijo de longitud-
certificate
X.509 con prefijo de longitud (formulario ASN.1 DER)
-
- Secuencia de
signature algorithm IDs
designature algorithm IDs
(uint32): uno para cada certificado del conjunto anterior, en el mismo orden.
- secuencia de
-
flags
(uint32): indicadores que indican si este conjunto de certificados debe estar o no en la estructura autoconfianza-antiguos-certs y para qué operaciones. - secuencia con prefijo de longitud de
signatures
prefijo de longitud:-
signature algorithm ID
(uint32): debe coincidir con el de la sección de datos firmados -
signature
con prefijo de longitud sobre lossigned data
arriba
-
-
Múltiples antepasados en la estructura de prueba de rotación
El esquema v3 tampoco maneja dos claves diferentes que rotan a la misma clave de firma para la misma aplicación. Esto difiere del caso de una adquisición, en la que la empresa adquirente desea mover la aplicación adquirida para usar su clave de firma para compartir permisos. La adquisición se considera un caso de uso admitido porque la nueva aplicación se distinguiría por su nombre de paquete y podría contener su propia estructura de prueba de rotación. El caso no admitido, de la misma aplicación que tiene dos rutas diferentes para llegar al mismo certificado, rompe muchas de las suposiciones hechas en el diseño de rotación de claves.
Verificación
En Android 9 y versiones posteriores, los APK se pueden verificar de acuerdo con el esquema de firma APK v3, el esquema v2 o el esquema v1. Las plataformas más antiguas ignoran las firmas v3 e intentan verificar las firmas v2, luego v1.
Figura 1. Proceso de verificación de la firma de APK
Verificación de APK Signature Scheme v3
- Busque el bloque de firma de APK y verifique que:
- Dos campos de tamaño de APK Signing Block contienen el mismo valor.
- ZIP Central Directory es seguido inmediatamente por el registro ZIP End of Central Directory.
- ZIP End of Central Directory no va seguido de más datos.
- Busque el primer bloque APK Signature Scheme v3 dentro del APK Signing Block. Si el bloque v3 está presente, continúe con el paso 3. De lo contrario, vuelva a verificar el APK mediante el esquema v2 .
- Para cada
signer
en el bloque APK Signature Scheme v3 con una versión mínima y máxima de SDK que esté dentro del rango de la plataforma actual:- Elija el
signature algorithm ID
compatible más fuerte de lassignatures
. El orden de fuerza depende de cada versión de implementación / plataforma. - Verifique la
signature
correspondiente de lassignatures
con lossigned data
utilizandopublic key
. (Ahora es seguro analizarsigned data
). - Verifique que las versiones mínimas y máximas del SDK en los datos firmados coincidan con las especificadas para el
signer
. - Verifique que la lista ordenada de ID de algoritmos de firma en
digests
ysignatures
sea idéntica. (Esto es para evitar la eliminación / adición de firmas). - Calcule el resumen del contenido de APK utilizando el mismo algoritmo de resumen que el algoritmo de resumen utilizado por el algoritmo de firma.
- Verifique que el resumen calculado sea idéntico al
digest
correspondiente de losdigests
. - Verifique que SubjectPublicKeyInfo del primer
certificate
decertificates
sea idéntico apublic key
. - Si el atributo de prueba de rotación existe para el
signer
verifique que la estructura sea válida y que estesigner
sea el último certificado de la lista.
- Elija el
- La verificación se realiza correctamente si se encuentra exactamente un
signer
dentro del alcance de la plataforma actual y el paso 3 se realizó correctamente para esesigner
.
Validación
Para probar que su dispositivo es compatible con v3 correctamente, ejecute las pruebas CTS de PkgInstallSignatureVerificationTest.java
en cts/hostsidetests/appsecurity/src/android/appsecurity/cts/
.