Enviando datos encriptados a través de la aplicación de Android

0

Tengo un SDK para mi aplicación web, que el usuario puede integrar en su aplicación para Android. Para la autenticación, tenemos una clave de autenticación. Y se envía como un parámetro POST o GET cuando se produce la comunicación de servidor a servidor. Pero en la aplicación, me temo que alguien puede obtener la clave de autenticación por cualquier método, mientras se transmite. Para eso pensé en cifrar la clave de autenticación, pero aún así, siempre será la misma clave de autenticación cifrada y alguien puede simplemente obtener una clave de autenticación que se haya descifrado y puede usar la misma para enviar datos.

Para evitar esto, vine con una lógica, que creo que es lo suficientemente segura como para enviar authkey con cifrado y enviar claves de encriptación diferentes cada vez. Aquí está el proceso.

  1. Tengo una clave de autenticación, digamos ABCD1234, que debo enviar
  2. Genero un número aleatorio seguro criptográficamente, llamémoslo rand_number
  3. Luego cifro mi clave de autenticación con este número de rand, usando 'aes-256-cbc', y lo llamo como auth_token
  4. Luego cifro el número de rand con mi clave pública, y lo llamo como time_token.
  5. Luego transmito este auth_token y time_token a mi servidor

Y del lado del servidor:

  1. descifraré time_token con mi clave privada y obtendré rand_number
  2. Descifrará auth_token con este número de rand y obtendrá la clave de autenticación.

¿Este método es lo suficientemente seguro? ¿Incluso si revelamos todo el proceso de cifrado y envío de datos?

No lo sé, pero tengo la sensación de que este sería un método ya existente.

    
pregunta kadamb 24.05.2017 - 11:18
fuente

2 respuestas

1

Hay un número de problemas con tu esquema. Empecemos por lo más básico, sin embargo:

Lo que intentas hacer no se puede hacer.

Según tengo entendido, está intentando ocultar un token simétrico (authkey), que está presente en cada copia de su aplicación, de modo que alguien no pueda escribir otro cliente para su aplicación web. Esto es imposible.

  1. Tu aplicación debe contener el token. Cualquiera que pueda obtener la aplicación, que, si está en la Play Store, es alguien en absoluto, puede aplicar ingeniería inversa a la aplicación para sacar el token. Encriptar el token no ayuda; el atacante solo necesita conocer el token de la misma forma que la aplicación lo sabe.
  2. Tu aplicación tiene que usar el token. Ese uso se implementa en código. No importa cómo lo implementes, ese mismo código estará disponible para que un atacante simplemente copie en su propia aplicación (incluso como un binario, si es necesario).

Bien, a las fallas específicas en tu esquema.

Repetir ataques

Su esquema no tiene nonce y, por lo tanto, el atacante simplemente puede enviar el mismo par de auth_token + time_token que se capturaron del tráfico de la aplicación. El time_token todavía se descifra al mismo número de rand utilizado para cifrar la clave de autenticación. Esta es la forma más trivial de romper el esquema; el atacante ni siquiera necesita saber qué significan los tokens.

Tamaño de clave

No menciona la longitud de la clave de autenticación, ni cómo se generó. Dado que mencionó explícitamente esto para el número de rand, pero en cambio dio un token de ejemplo muy corto para la clave de autenticación, me preocupa que pueda ser demasiado fácil para la fuerza bruta. El atacante no necesita saber cuál es la clave de descifrado si el rango completo de valores para buscar es lo suficientemente pequeño.

Rendimiento

Su esquema requiere dos operaciones criptográficas asimétricas por mensaje, una del lado del cliente y otra del servidor. La criptografía asimétrica es computacionalmente bastante costosa. Los esquemas que lo usan casi siempre realizan un intercambio de una sola tecla y luego reutilizan la clave intercambiada para toda la comunicación real, o son para operaciones asíncronas (como correo electrónico o verificación de integridad de descarga) donde el rendimiento no es importante.

Reimplementando la rueda

Si solo te preocupa la seguridad de comunicación (que generalmente no es suficiente cuando hay un token estático involucrado, pero es el único vector de amenaza que mencionaste explícitamente ...), entonces deberías simplemente use TLS (HTTPS, ya que el formato del mensaje es HTTP). Si desea ser más seguro, coloque el certificado del servidor (o al menos la información de clave pública del sujeto del certificado) en su aplicación, de modo que un atacante no pueda hacer cosas como instalar un nuevo certificado raíz de confianza y usar su clave privada para falsificar el certificado de su servidor.

    
respondido por el CBHacking 23.07.2017 - 22:54
fuente
0

Debería utilizar un MAC para firmar todos los datos de API transmitidos con la "clave de autenticación" como secreto MAC.

Nunca debes implementar tu propio protocolo criptográfico si no es absolutamente necesario.

    
respondido por el Josef 24.05.2017 - 11:50
fuente

Lea otras preguntas en las etiquetas