Esquema de firma APK v3

Android 9 admite la rotación de claves APK , lo que brinda a las aplicaciones la posibilidad 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 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.

Nota : No se recomienda la rotación de claves APK antes del lanzamiento de Android 11. Los desarrolladores tienen la opción de utilizar la actualización de claves de Google Play para nuevas instalaciones. Los desarrolladores inscritos en Play App Signing pueden solicitar una actualización a través de Play Console.

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.

Bloque de esquema de firma APK v3

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 bloque de firma APK con el ID 0xf05368c0 .

El formato del bloque APK Signature Scheme v3 sigue el de v2:

• secuencia con prefijo de longitud signer con prefijo de longitud:
  • signed data con prefijo de longitud:
    • secuencia con prefijo de longitud de digests con 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 supera este número.
    • secuencia con prefijo de longitud de additional attributes con prefijo de longitud:
      • ID (uint32)
      • value (longitud variable: longitud del atributo adicional - 4 bytes)
      • ID - 0x3ba06f8c
      • value - Estructura de prueba de rotación
  • minSDK (uint32): duplicado del valor minSDK en la sección de datos firmados: se utiliza para omitir la verificación de esta firma si la plataforma actual no está dentro del alcance. Debe coincidir con el valor de los datos firmados.
  • maxSDK (uint32): duplicado del valor de maxSDK en la sección de datos firmados: se utiliza para omitir la verificación de esta firma si la plataforma actual no está dentro del alcance. Debe coincidir con el valor de los datos firmados.
  • secuencia con prefijo de longitud signatures con prefijo de longitud:
    • signature algorithm ID (uint32)
    • signature con prefijo de longitud sobre signed data
  • public key con prefijo de longitud (SubjectPublicKeyInfo, formulario DER ASN.1)

Estructuras de prueba de rotación y certificados antiguos de confianza propia

La estructura de prueba de rotación permite que las aplicaciones roten 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 aplicación todavía confía

El atributo de prueba de rotación en la sección de datos firmados consta de una lista enlazada individualmente, y cada nodo 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 confianza propia. La lista está ordenada por versión y el certificado de firma más antiguo corresponde al nodo raíz. La estructura de datos de prueba de rotación se construye haciendo que el certificado de cada nodo firme el siguiente en la lista y, por lo tanto, imbuyendo a 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 confianza propia se construye agregando indicadores a cada nodo que indican su membresía y propiedades en el conjunto. Por ejemplo, puede haber una bandera que indique que se confía en el certificado de firma en un nodo determinado para obtener permisos de firma de Android. Esta marca permite que otras aplicaciones firmadas con el certificado anterior aún reciban 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 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 antecesores en uno (múltiples nodos iniciales para un sumidero 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 de levels con prefijo de longitud:
  • signed data con 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 el certificado en el nivel anterior
  • flags (uint32): indicadores que indican si este certificado debe estar o no en la estructura de certificados antiguos de confianza propia 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 los signed data arriba

Múltiples certificados

Actualmente, Android trata un APK firmado con varios certificados como si tuviera una identidad de firma única separada de los certificados que lo componen. Por lo tanto, el atributo de prueba de rotación en la sección de datos firmados forma un gráfico acíclico dirigido, que podría verse mejor como una lista enlazada individualmente, en la que cada conjunto de firmantes para una versión determinada representa un nodo. Esto agrega complejidad adicional a la estructura de prueba de rotación (versión multifirmante a continuación). En particular, realizar pedidos se convierte en una preocupación. Es más, ya no es posible firmar APK de forma independiente, porque la estructura de prueba de rotación debe hacer que los antiguos certificados de firma firmen 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 hacer que el firmante B solo incluya una firma de A o B, porque esa es una identidad de firma diferente a la de B y C. Esto 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 con prefijo de longitud:
  • signed data (por conjunto anterior, si existe)
    • secuencia de certificates con prefijo de longitud
      • certificate X.509 con prefijo de longitud (formulario ASN.1 DER)
    • Secuencia de signature algorithm IDs (uint32): uno para cada certificado del conjunto anterior, en el mismo orden.
  • flags (uint32): indicadores que indican si este conjunto de certificados debe estar o no en la estructura de certificados antiguos de confianza propia y para qué operaciones.
  • secuencia con prefijo de longitud signatures con prefijo de longitud:
    • signature algorithm ID (uint32): debe coincidir con el de la sección de datos firmados
    • signature con prefijo de longitud sobre los signed data arriba

Múltiples ancestros en estructura de prueba de rotación

El esquema v3 tampoco maneja dos claves diferentes que rotan hacia la misma clave de firma para la misma aplicación. Esto difiere del caso de una adquisición, donde a la empresa adquirente le gustaría mover la aplicación adquirida para usar su clave de firma para compartir permisos. La adquisición se considera un caso de uso compatible porque la nueva aplicación se distinguiría por el nombre del paquete y podría contener su propia estructura de prueba de rotación. El caso no admitido, en el que la misma aplicación 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 según el esquema de firma de APK v3, el esquema v2 o el esquema v1. Las plataformas más antiguas ignoran las firmas v3 e intentan verificar las firmas v2 y luego las v1.

Figura 1. Proceso de verificación de firma APK

Verificación del esquema de firma APK v3

1. Localice el bloque de firma de APK y verifique que:
   1. Dos campos de tamaño del bloque de firma de APK contienen el mismo valor.
   2. El directorio central ZIP va seguido inmediatamente del registro de fin del directorio central ZIP.
   3. ZIP El final del directorio central no va seguido de más datos.
2. Localice el primer bloque APK Signature Scheme v3 dentro del bloque de firma APK. Si el bloque v3 está presente, continúe con el paso 3. De lo contrario, vuelva a verificar el APK usando el esquema v2 .
3. Para cada signer en el bloque APK Signature Scheme v3 con una versión mínima y máxima del SDK que esté dentro del alcance de la plataforma actual:
   1. Elija el signature algorithm ID compatible más potente entre signatures . El orden de potencia depende de cada versión de implementación/plataforma.
   2. Verifique la signature correspondiente de signatures con signed data utilizando public key . (Ahora es seguro analizar signed data ).
   3. Verifique que las versiones mínima y máxima del SDK en los datos firmados coincidan con las especificadas para el signer .
   4. Verifique que la lista ordenada de ID de algoritmos de firma en digests y signatures sea idéntica. (Esto es para evitar la eliminación o adición de firmas).
   5. Calcule el resumen del contenido del APK utilizando el mismo algoritmo de resumen que el algoritmo de resumen utilizado por el algoritmo de firma.
   6. Verifique que el resumen calculado sea idéntico al digest correspondiente de digests .
   7. Verifique que SubjectPublicKeyInfo del primer certificate de certificates sea idéntico a public key .
   8. Si el atributo de prueba de rotación existe para el signer , verifique que la estructura sea válida y que este signer sea el último certificado de la lista.
4. La verificación se realiza correctamente si se encontró exactamente un signer dentro del alcance de la plataforma actual y el paso 3 se realizó correctamente para ese signer .

Precaución : el APK no se debe verificar utilizando el esquema v1 o v2 si se produce una falla en el paso 3 o 4.

Validación

Para probar que su dispositivo es compatible con v3 correctamente, ejecute las pruebas CTS PkgInstallSignatureVerificationTest.java en cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .