Google se compromete a avanzar en la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

APK Firma Esquema 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 hacer la rotación práctica, APK deben indicar los niveles de confianza entre el nuevo y el viejo clave de firma. 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 añade información sobre las versiones del SDK compatibles y una estructura de prueba de giro al bloque APK firma.

APK firma de Bloque

Para mantener la compatibilidad hacia atrás con las firmas de formato APK v1, v2 y v3 APK guardan en su interior un APK firma de Bloque, situado inmediatamente antes de la postal Directorio Central.

El APK v3 Firmar formato de bloque es el mismo que v2 . La firma v3 de la APK se almacena como un par ID-valor con 0xf05368c0 ID.

APK Firma Esquema de bloques v3

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 añade información acerca de las versiones soportadas del SDK 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 de la firma APK Esquema v3 bloque 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 datos firmado.
    • 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 datos firmado.
    • 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)

La prueba de rotación y structs auto-confianza-old-CERT

La prueba de estructura rotación permite aplicaciones para girar su certificado de firma sin ser bloqueado en otras aplicaciones con las que se comunican. Para lograr esto, las firmas de aplicaciones contienen dos nuevas piezas de datos:

  • afirmación de terceros que cert firma de la aplicación se puede confiar siempre que sus predecesores son de confianza
  • certs de firma mayor de aplicaciones que la aplicación en sí todavía fideicomisos

El atributo de prueba de rotación en la sección de datos firmado consiste en una lista simplemente enlazada, con cada nodo que contiene un certificado de firma utilizado para firmar las versiones anteriores de la aplicación. Este atributo está destinado a contener los conceptuales estructuras de datos de prueba de rotación y auto-confianza-old-CERT. La lista se ordena por versión con el cert firma más antigua correspondiente al nodo raíz. La estructura de datos de prueba de rotación está construido por tener el certificado en cada nodo de firmar el siguiente en la lista, y por lo tanto impregnando cada nueva clave con la evidencia de que se hiciese lo que de confianza como la clave más antiguo (s).

La estructura de datos de auto-confianza-old-certs se construye mediante la adición de banderas para cada nodo que indica su composición y propiedades en el conjunto. Por ejemplo, una bandera puede estar presente lo que indica que el certificado de firma en un nodo dado es de confianza para la obtención de permisos Android firma. Este indicador permite a otras aplicaciones firmadas por el certificado más para conceder el permiso sigue siendo una firma definida 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

certificados múltiples

Android actualmente trata un APK firmado con varios certificados como tener una identidad única firma independiente de los certs que comprenden. Por lo tanto, el atributo de prueba de rotación en la sección de datos firmado forma un gráfico dirigido acíclico, que mejor podría ser visto como una lista simplemente enlazada, con cada conjunto de firmantes para una versión determinada que representa un nodo. Esto añade complejidad adicional a la estructura de prueba de rotación (versión multi-firmante abajo). En particular, el pedido se convierte en una preocupación. Lo que es más, ya no es posible firmar APK de forma independiente, ya que la estructura de prueba de rotación debe tener las viejas certs de firma de la firma de la nueva serie de los CERT, en lugar de los firmantes de una en una. Por ejemplo, un APK firmado por una clave que los deseos de ser firmado por dos nuevas teclas B y C no podía tener el firmante B acaba de incluir una firma de A o B, ya que es una identidad diferente a la firma B y C. Esto haría significan que los firmantes deben coordinar antes de la construcción de una estructura tal.

Múltiples firmantes de prueba de rotación atributo

  • 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 estructura de prueba de rotación

esquema v3 también no maneja dos claves diferentes que giran a la misma clave de firma para la misma aplicación. Esto difiere del caso de una adquisición, en donde la sociedad absorbente desea mover la aplicación adquirida a utilizar su clave de firma de permisos de recurso compartido. La adquisición es visto como un caso de uso soportado debido a que la nueva aplicación se distingue por su nombre de paquete y podría contener su propia estructura de prueba de rotación. El caso no compatible, de la misma aplicación que tiene dos caminos diferentes para llegar a la misma cert, rompe muchas de las suposiciones hechas en el diseño de rotación de clave.

Verificación

En Android 9 y superior, APK pueden ser verificadas de acuerdo con la APK Signature Scheme v3, esquema v2, o esquema v1. plataformas más antiguas ignoran v3 firmas y tratar de verificar las firmas v2, v1 continuación.

proceso de verificación de firmas APK

Figura proceso de verificación de firma 1. APK

APK firma de verificación Esquema v3

  1. Busque el archivo APK de firma Block y verificar que:
    1. Dos campos de tamaño de bloque de firma APK contienen el mismo valor.
    2. Directorio Central postal es seguida inmediatamente por postal Final de la comunicación Directorio Central.
    3. Fin postal del Directorio Central no es seguida por más datos.
  2. Busque el primer Firma APK Esquema v3 bloque dentro de la APK Firma del bloque. 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 la aplicació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 firma de extracción adición /.)
    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/ .