2012-06-07 19 views
7

quiero incondicional a esta pregunta con dos cosas para que pueda reducir en donde mi pregunta real es:¿Cómo funciona la verificación de la aplicación/firma de Android?

a) que he hecho dev software antes, aunque nunca para android

b) Estoy familiarizado con PKI y encriptaciones y hashing y firmas digitales y blah blah blah

Dicho esto, tengo problemas para encontrar más información sobre dónde y cómo Android verifica los creadores de aplicaciones. He escuchado mucha información diferente, así que intento sintetizar para tener una mejor idea del flujo de trabajo.

Sé que cada desarrollador de aplicaciones obtiene su propio par de claves privadas/públicas y firman sus aplicaciones mediante el hash del APK (con SHA-1 la mayor parte del tiempo si no me equivoco) y listo. Usted lo sube y (creo) la clave pública entra en META INF dentro de la APK. Esto mucho lo entiendo.

Mi pregunta es cómo se relaciona esto con cuando un usuario descarga la aplicación. Sé que el teléfono verifica para asegurarse de que la aplicación esté firmada válidamente, y que la firma también tenga información sobre el autor, etc. incluida. Pero también he leído que las aplicaciones están autofirmadas y que Google Play (o lo que sea que llamen ahora al Mercado) no implementa una CA, y que no hay autenticación de identidad. Pero mi pregunta es, ¿qué impide que las personas carguen una aplicación con el nombre de otro desarrollador (crowdsourcing aparte)?

Si el teléfono solo comprueba si hay firmas válidas, ¿eso implica que el único medio de autenticación se realiza cuando se carga la aplicación? Y si ese es el caso, ¿cómo lo comprueba el mercado de aplicaciones? ¿Es lo habitual: usar la clave privada en el archivo y verificar la firma? ¿O el desarrollador tiene que proporcionar al mercado su clave privada para autenticarse?

+0

Cuando firme el apk, debe proporcionar la contraseña privada. Por lo tanto, para que alguien publique una aplicación "como otra persona", necesitaría acceder a sus claves de acceso/archivos de claves y contraseñas. Y acceso a la cuenta de Google que está vinculada al mercado. – FoamyGuy

+0

@Tim: Creo que él pregunta: ¿Qué es para evitar que otra persona cree su propio par de llaves y un certificado autofirmado que también contenga "Fewmitz"? ¿Está de alguna manera vinculado a una cuenta en alguna parte? –

Respuesta

9

En resumen, Android y Google Play esencialmente no se preocupan por lo que hay en el certificado real. Google Play lo validará efectivamente y verificará si es válido por 30 años o más, pero realmente no usan (al menos actualmente, AFAIK) la información real en el certificado. Puede usar su propio nombre/nombre de compañía en el CN, pero nadie lo validará, y los usuarios no verán esta información en absoluto. Lo que hace es Android:

  • verificación de la firma para asegurarse de que el APK no ha sido manipulado
  • luego comparar el certificado de canto como un blob binario a la de la versión actualmente instalada de la aplicación para asegurarse de que las dos versiones hayan sido firmadas con la misma clave/certificado (por ejemplo, por la misma persona/compañía)
  • hace lo mismo para aplicar el permiso si está utilizando el uso compartido o permisos de firma con dos o más aplicaciones.

Por lo tanto, para responder a su pregunta, alguien puede crear fácilmente un certificado con su nombre, pero a Android y Google Play en realidad no les importa. Siempre que no tengan su clave privada, no podrán generar una firma de aplicación que sea la misma que la suya y, por lo tanto, no podrán sobrescribir/actualizar su aplicación con la suya u obtener ningún permiso especial. .

+0

Entonces, ¿eso significa que si utiliza dos certificados con el mismo par de claves público-privadas pero diferentes nombres de sujeto, ambos serían válidos? Básicamente, cuando firmo mi aplicación con mi clave privada, ¿se tienen en cuenta mis detalles como el nombre del sujeto, etc.? – Ashwin

+2

No le importan los "detalles" reales (DN del certificado, número de serie, etc.), pero solo compara los certificados como blobs binarios. Como son diferentes, no puede actualizar una aplicación firmada originalmente con cert1 con otra firmada con cert2. –

+0

Al decir "No le importan los 'detalles' reales (DN del certificado, número de serie, etc.)," ​​¿quiere decir que esos detalles nunca se utilizan? Porque en última instancia, como usted mismo dijo, "compara los certificados como blobs binarios", eso significa que tiene en cuenta los detalles del certificado. – Ashwin

Cuestiones relacionadas