Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

APK Signature Scheme v3

Android 9 soportes APK rotación de claves , lo que da aplicaciones la capacidad de cambiar su clave de firma como parte de una actualización APK. Para que la rotación sea práctica, los APK deben indicar niveles de confianza entre la clave de firma nueva y la anterior. Para apoyar la rotación de claves, actualizamos el esquema de firma APK de V2 a V3 para permitir que las llaves nuevas y viejas para ser utilizado. 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 APK v3 Firmar formato de bloque es el mismo que 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 de v2 . Tiene el mismo formato general y es compatible con los mismos identificadores de algoritmo de firma , los tamaños de clave, y las curvas de la CE.

Sin embargo, el esquema v3 agrega información sobre las versiones de SDK compatibles y la estructura de prueba de rotación.

Formato

APK Signature Scheme v3 bloque se almacena dentro de la APK Firma Bloquear bajo ID 0xf05368c0 .

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

  • secuencia de longitud prefijada de longitud prefijada signer :
    • de longitud prefijada signed data :
      • secuencia de longitud prefijada de longitud prefijada digests :
        • signature algorithm ID (4 bytes)
        • digest (longitud-prefijado)
      • secuencia de longitud prefijada de X.509 certificates :
        • longitud prefijada X.509 certificate (forma DER ASN.1)
      • minSDK (uint32) - esto firmante debe ser ignorado si versión de la plataforma está por debajo de este número.
      • maxSDK (uint32) - esto firmante debe ser ignorado si es versión de la plataforma por encima de este número.
      • secuencia de longitud prefijada de longitud prefijada additional attributes :
        • ID (uint32)
        • value (variable de longitud: longitud del atributo adicional - 4 bytes)
        • ID - 0x3ba06f8c
        • value - La prueba de la rotación estructura
    • minSDK (uint32) - duplicado de valor minSDK en la sección de datos firmado - se utiliza 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 firmado - se utiliza 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 de longitud prefijada de longitud prefijada signatures :
      • signature algorithm ID (uint32)
      • longitud prefijada signature sobre signed data
    • longitud prefijada public key (SubjectPublicKeyInfo, ASN.1 forma 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 de un solo enlace, 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. Porque todo el reside el atributo de prueba de rotación en la sección de datos firmada de la v3 signer campo, que está protegida por la clave utilizada para firmar el apk que contiene.

Este formato se opone múltiples claves de firma y de convergencia de los diferentes certificados de firma ancestro a uno (varios nodos de partida a un sumidero común).

Formato

La rotación de prueba de se almacena dentro de la Firma APK Esquema v3 Bloquear bajo ID 0x3ba06f8c . Su formato es:

  • secuencia de longitud prefijada de longitud prefijada levels :
    • de longitud prefijada signed data (por cert anterior - si existe)
      • longitud prefijada X.509 certificate (forma DER ASN.1)
      • signature algorithm ID (uint32) - algoritmo utilizado por el CERT en el nivel anterior
    • flags (uint32) - banderas que indican si o no este certificado debe estar en la estructura auto-confianza-old-CERT, y para los cuales las operaciones.
    • signature algorithm ID (uint32) - debe coincidir con el de la sección de datos firmado en el siguiente nivel.
    • longitud prefijada signature durante los anteriormente signed data

Varios certificados

Actualmente, Android trata un APK firmado con varios certificados como si tuviese una identidad de firma única independiente de los certificados que la 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 enlazada individualmente, 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 de longitud prefijada de longitud prefijada sets :
    • signed data (por el grupo anterior - si existe)
      • secuencia de longitud prefijada de certificates
        • longitud prefijada X.509 certificate (forma DER ASN.1)
      • Secuencia de signature algorithm IDs (uint32) - una para cada certificado de la serie anterior, en el mismo orden.
    • flags (uint32) - banderas que indican si o no este conjunto de CERT debe estar en la auto-confianza de edad-certs estructura, y para el cual las operaciones.
    • secuencia de longitud prefijada de longitud prefijada signatures :
      • signature algorithm ID (uint32) - debe coincidir con el de la sección de datos firmado
      • longitud prefijada signature durante los anteriormente signed data

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, donde la empresa adquirente quisiera 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.

Proceso de verificación de la firma de APK

Figura proceso de verificación de firma 1. 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 v3 bloque está presente, continúe con el paso 3. En caso contrario, caer de nuevo a la verificación de la APK utilizando esquema v2 .
  3. Para cada signer en la firma APK Esquema v3 bloque con una min y la versión SDK max que está en el rango de la plataforma actual:
    1. Elegir el más fuerte con el apoyo signature algorithm ID de signatures . El orden de fuerza depende de cada versión de implementación / plataforma.
    2. Comprobar la correspondiente signature de signatures en contra de signed data utilizando public key . (Ahora es seguro para analizar signed data .)
    3. Verificar las versiones min y SDK max en los datos firmados coincidir con los especificados para el signer .
    4. Compruebe que la lista ordenada de identificadores de algoritmo de firma en digests y signatures es idéntico. (Esto es para evitar la eliminación / adición de firmas).
    5. Calcular la síntesis de contenidos APK utilizando el mismo algoritmo de resumen como el algoritmo de resumen usada por el algoritmo de firma.
    6. Compruebe que la digestión calculada es idéntica a la correspondiente digest de digests .
    7. Compruebe que SubjectPublicKeyInfo del primer certificate de certificates es idéntica a la public key .
    8. Si el atributo existe prueba de rotación para el signer verificar que la estructura es válida y esto signer es el último certificado en la lista.
  4. Verificación tiene éxito si exactamente un signer se encontró en el rango de la plataforma actual y el paso 3 conseguido para ese signer .

Validación

Para prueba que admite su dispositivo v3 correctamente, ejecute los PkgInstallSignatureVerificationTest.java pruebas CTS en cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .