Cifrado fuerte para clave pública codificada en base64 en Android

Primero, tenga en cuenta que lo que necesita no es cifrado. Este consejo es sobre claves públicas. Las claves públicas son, como su nombre lo indica, no son secretas (excepto a veces por privacidad, pero cuando la clave de su aplicación está en su aplicación, no hay privacidad involucrada). Lo que necesita es garantizar la integridad de la clave pública, es decir, asegurarse de que una entidad maliciosa no pueda reemplazarla por una clave diferente.

La aplicación utiliza la clave pública para autenticar un pedido de compra. La secuencia normal de eventos para una compra es:

1. El usuario se pone en contacto con un servidor de Google y paga algo de dinero para comprar una función en la aplicación.
2. El servidor de Google emite un recibo por esa compra. Firma este recibo con una clave privada que nunca abandona el servidor.
3. La aplicación que se ejecuta en el dispositivo móvil descarga el recibo.
4. Su aplicación verifica que el recibo sea genuino, confiando en la clave pública incluida con la aplicación.
5. Si la compra es repetible (por ejemplo, permite descargar X minutos de contenido protegido, en lugar de desbloquear una función), la aplicación debe asegurarse de que el mismo recibo no se pueda usar dos veces (ataque de reproducción). Lo hace "consumiendo" la compra.

El problema es que el usuario puede modificar el código o los datos de su aplicación para poner una clave pública de su elección en lugar de la verdadera. En particular, puede poner una clave pública para la cual conoce la clave privada. Si lo hace, puede generar recibos de compra sin pasar por ningún servidor, y su aplicación los aceptará como auténticos en el paso 4.

Lo que debe hacer para protegerse contra este ataque es detectar cualquier intento de modificar la clave pública. No importa si el atacante potencial puede leer la clave pública, siempre y cuando no pueda cambiarla. Esto significa que su aplicación debe contener código que verifique que la clave sea genuina. Pero hagas lo que hagas, el atacante podría cambiar el código de verificación (solo voltea un poco en algún lugar para cambiar de if is_genuine(public)key) a if not(is_genuine(key)) ) ...

Por lo tanto, debe hacer imposible que el atacante encuentre el código de verificación. No solo eso: debe hacer que le sea imposible saltar por encima del código de verificación y entrar en la parte interesante. Necesitas ofuscar toda tu aplicación. Pero ofuscación es difícil, si no imposible .

Solo hay dos formas de beneficiarte de la ofuscación:

• Si a nadie le importa tu aplicación, tal vez nadie intentará descifrarla. (Desventaja: usted tampoco está ganando dinero).
• Pones mucho esfuerzo en él, y solo esperas que se mantenga por un poco de tiempo. Tenga en cuenta que se debe hacer un esfuerzo importante en cada versión: si se lanza una gran cantidad de software con las mismas técnicas de ofuscación, alguien encontrará una manera de resolverlo y todo el software estará expuesto.

Para una historia exitosa de ofuscación, recomiendo leer La historia de Gavin Dodd sobre el juego Spyro: YOTD . Los puntos clave son que tomó mucho esfuerzo, que el objetivo era solo retrasar la grieta por un par de meses, y que se basó en parte en la psicología de los atacantes que solo pasan un tiempo limitado atacando cada juego y se detienen como Tan pronto como hayan pasado el primer obstáculo.

En la mayoría de los casos, la ofuscación te costará mucho más de lo que puede beneficiarte.

Entonces, ¿qué puedes hacer? Como se recomienda en el artículo: no verifique la compra en el dispositivo, verifíquelo en un servidor bajo su control. Esto solo es útil si el resultado de la compra proviene de un servidor. Por ejemplo, si la compra es para contenido o características adicionales, el recibo debería desbloquear el contenido de la cuenta del usuario en el servidor, y la aplicación descargaría cualquier contenido que el servidor le permita tener.

Independientemente del cifrado que utilices, todavía está en el dispositivo del cliente, por lo que pueden descifrarlo. Te encuentras con el mismo problema que tienen los sistemas DRM, por lo que cualquier cosa que entregues al usuario puede ser modificado.

Si la seguridad de su aplicación depende del secreto de su clave pública, entonces tiene una falla fundamental en su arquitectura y necesita atacar el problema desde un ángulo diferente.

Si solo está tratando de evitar que los usuarios cambien la clave pública para que puedan usar servidores privados personalizados, entonces lo más que puede hacer es ofuscarla y esperar lo mejor.

@Polynomial prácticamente lo ha definido como de costumbre, pero para cierta expansión en lo que quiere decir con obfuscate ;

Como sugiere la documentación de Android, debes hacer que la clave pública sea un poco difícil de extraer del binario. Básicamente tienes dos capas de protección;

1. Cree la clave en tiempo de ejecución utilizando un enfoque razonablemente complejo. XOR es bueno, algún tipo de iteración es bueno, la transposición y la sustitución también son buenas.
2. ofuscar su mecanismo de derivación clave. Con esto me refiero a emplear las técnicas de anti-debugging para su código. Pocos desarrolladores llegan hasta este punto, pero todo ayuda.