El paso a paso o código que encontrarás en este post es la solución más sencilla y efectiva que hallamos a tu duda o problema.
Solución:
Utilice Android SafetyNet. Así es como se valida Android Pay.
El flujo básico es:
- Su servidor genera un nonce que envía a la aplicación cliente.
- La aplicación envía una solicitud de verificación con el nonce a través de Google Play Services.
- SafetyNet verifica que el dispositivo local no esté modificado y haya pasado el CTS.
- Se devuelve una respuesta firmada por Google (“atestación”) a su aplicación con un resultado de aprobado / reprobado e información sobre el APK de su aplicación (hash y certificado de firma).
- Su aplicación envía la certificación a su servidor.
- Su servidor valida la firma nonce y APK, y luego envía la certificación a un servidor de Google para su verificación. Google comprueba la firma de la atestación y le indica si es auténtica.
Si esto pasa, puede estar bastante seguro de que el usuario está ejecutando una versión genuina de su aplicación en un sistema no modificado. La aplicación debe obtener una certificación cuando se inicie y enviarla a su servidor con cada solicitud de transacción.
Sin embargo, tenga en cuenta que esto significa:
- Los usuarios que hayan rooteado su teléfono no pasarán estas comprobaciones
- Los usuarios que hayan instalado ROM / firmware / SO personalizados o de terceros (por ejemplo, Cyanogen) no pasarán estas comprobaciones
- Los usuarios que no tienen acceso a los servicios de Google Play (por ejemplo, dispositivos de Amazon, personas en China) no pasarán estos controles.
… y, por lo tanto, no podrá utilizar su aplicación. Su empresa debe tomar una decisión comercial sobre si estas restricciones (y los usuarios molestos que las acompañan) son aceptables o no.
Finalmente, date cuenta de que esta no es una solución completamente hermética. Con acceso de root y quizás Xposed, es posible modificar la biblioteca de SafetyNet para mentir a los servidores de Google, diciéndoles las respuestas “correctas” para obtener un resultado de aprobación de verificación que Google firma. En realidad, SafetyNet simplemente mueve los postes de la portería y lo hace más difícil para los actores malintencionados. Dado que, en última instancia, estas comprobaciones tienen que ejecutarse en un dispositivo fuera de su control, de hecho es imposible diseñar un sistema completamente seguro.
Lea un excelente análisis de cómo funcionan los componentes internos de SafetyNet aquí.
Lo único que el servidor puede determinar de manera confiable sobre un dispositivo es su comportamiento hacia el servidor (los datos recibidos y en qué patrones de tiempo). Suponiendo que un atacante tiene conocimiento y control de todos los elementos que influyen en el comportamiento, el atacante puede crear un clon malicioso y el servidor nunca lo sabrá.
Entonces, técnicamente, esto es imposible. A menos que emplee el soporte del hardware del dispositivo, el archivo APK entero es suficiente para crear un clon malicioso (la descompilación es bastante fácil, proguard no ayudará mucho contra un ingeniero inverso experimentado).
Como se ha mencionado en los comentarios de @CodesInChaos y @OrenMilman:
Puede incluir elementos en ese comportamiento que sean muy difíciles de conseguir para un atacante, por ejemplo, un TPM / TEE e implementar una atestación remota. Suponiendo que el TPM no tenga vulnerabilidades (lo cual es poco probable, pero supongamos), esta sería una solución. Además, la seguridad no tiene sentido sin un modelo de amenaza. Entonces, si su modelo de amenazas excluye a los atacantes con dedicación a tiempo completo, mucho dinero y posiblemente acceso a días 0, puede considerar que este mecanismo es seguro.
No sé qué dispositivos Android tienen un TPM y son compatibles con tales medidas; Dejaré esa investigación y enmendaré esta respuesta a otra persona.
Llego un poco tarde a la fiesta, pero creo que puedo agregar algunas ideas útiles.
¿Hay alguna manera de que pueda validar la integridad de la aplicación (usando una suma de verificación o una firma) en el lado del servidor para asegurarme de que no esté alterada? (por ejemplo, un troyano no se implanta en la aplicación y luego se redistribuye)
Para mayor seguridad entre su aplicación y el servidor API, debe utilizar un servicio de atestación de integridad de la aplicación móvil junto con la solución SafetyNet, el servicio OAUTH2. También es importante utilizar la fijación de certificados para proteger el canal de comunicación entre el servidor de API y la aplicación móvil, como se describe en esta serie de artículos sobre técnicas de API móviles.
La función de un servicio de atestación de integridad de aplicaciones móviles es garantizar en tiempo de ejecución que su aplicación no fue manipulada o no se está ejecutando en un dispositivo rooteado mediante el uso de un SDK integrado en su aplicación y un servicio que se ejecuta en la nube.
Tras la certificación exitosa de la integridad de la aplicación, se emite un token JWT y se firma con un secreto que solo el servidor API de su aplicación y el servicio de certificación de integridad de la aplicación móvil en la nube conocen.
En caso de falla en la atestación de integridad de la aplicación, el JWT se firma con un secreto que el servidor API no conoce.
Ahora la aplicación debe enviar con cada llamada a la API el token JWT en los encabezados de la solicitud. Esto permitirá que el servidor de API solo atienda solicitudes cuando pueda verificar la firma en el token JWT y rechazarlas cuando falle la verificación.
Una vez que la aplicación no conoce el secreto utilizado por el servicio de atestación de integridad de la aplicación móvil, no es posible realizar ingeniería inversa en el tiempo de ejecución, incluso cuando la aplicación está alterada, ejecutándose en un dispositivo rooteado o comunicándose a través de una conexión que está siendo la objetivo de un ataque de Hombre en el Medio. Aquí es donde brilla este tipo de servicio en relación con la solución SafetyNet.
Puede encontrar un servicio de este tipo en Approov que tenga SDK para varias plataformas, incluido Android. La integración también necesitará una pequeña verificación en el código del servidor API para verificar el token JWT con el fin de protegerse contra el uso fraudulento.
Tenga en cuenta que no todos mis clientes descargan la aplicación a través de Google Play, algunos de ellos utilizan mercados de terceros o descargan el apk desde otro lugar.
Con el uso de un servicio de atestación de integridad de API móvil como Approov, no importará desde dónde se instaló la aplicación.
Tengo aplicaciones de Android (banca móvil) que se conectan a mi servidor y realizan transacciones en línea (a través de Internet / USSD / SMS), quiero asegurarme de que esos clientes no sean manipulados y sean los originales distribuidos por mí.
y
Para soluciones sugeridas:
¿Se pueden implementar en los 3 canales de comunicación (SMS / USSD / Internet) o las soluciones son propiedad de uno / algunos canales?
Entonces, suponiendo que su aplicación hable directamente con los servicios de terceros, le sugiero que delegue esa responsabilidad al servidor de API, que evitará el uso no autorizado de sus servicios de terceros en su nombre, una vez que ahora solo atienda solicitudes auténticas del móvil. Aplicaciones que superaron los desafíos de integridad.
Red de seguridad
La API de SafetyNet Attestation le ayuda a evaluar la seguridad y compatibilidad de los entornos de Android en los que se ejecutan sus aplicaciones. Puede utilizar esta API para analizar los dispositivos que han instalado su aplicación.
OAUTH2
El marco de autorización de OAuth 2.0 permite que una aplicación de terceros obtenga acceso limitado a un servicio HTTP, ya sea en nombre del propietario de un recurso mediante la orquestación de una interacción de aprobación entre el propietario del recurso y el servicio HTTP, o al permitir que la aplicación de terceros obtener acceso en su propio nombre. Esta especificación reemplaza y hace obsoleto el protocolo OAuth 1.0 descrito en RFC 5849.
Fijación de certificados
La fijación es el proceso de asociar un host con su certificado X509 esperado o público key. Una vez que un certificado o público key es conocido o visto por un host, el certificado o público key está asociado o ‘anclado’ al host. Si hay más de un certificado o público key es aceptable, entonces el programa contiene un conjunto de pines (tomado de Jon Larimer y Kenny Root Google I / O talk). En este caso, la identidad anunciada debe coincidir con uno de los elementos del conjunto de pines.
Token JWT
Autenticación basada en token
Los tokens web JSON son un método RFC 7519 estándar de la industria abierto para representar reclamaciones de forma segura entre dos partes.
Descargo de responsabilidad: trabajo en Approov.
Comentarios y valoraciones
Nos puedes añadir valor a nuestro contenido tributando tu veteranía en las reseñas.