APK Signature Scheme v3

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
  • 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 sobre signed 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 los signed 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 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 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 los signed 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

1. Busque el bloque de firma de APK y verifique que:
   1. Dos campos de tamaño de APK Signing Block contienen el mismo valor.
   2. ZIP Central Directory es seguido inmediatamente por el registro ZIP End of Central Directory.
   3. ZIP End of Central Directory no va seguido de más datos.
2. 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 .
3. 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:
   1. Elija el signature algorithm ID compatible más fuerte de las signatures . El orden de fuerza depende de cada versión de implementación / plataforma.
   2. Verifique la signature correspondiente de las signatures con los signed data utilizando public key . (Ahora es seguro analizar signed data ).
   3. Verifique que las versiones mínimas y máximas 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 / adición de firmas).
   5. Calcule el resumen del contenido de 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 los 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 encuentra exactamente un signer dentro del alcance de la plataforma actual y el paso 3 se realizó correctamente para ese signer .

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/ .