¿Cuándo debo generar nuevas claves públicas y privadas usando RSA?

4

Estoy creando un enorme juego móvil en línea. Tengo algunas preguntas para ustedes, porque mi conocimiento sobre criptografía y envío de datos a través de la red de manera segura es un poco escaso.

Algunos detalles:

  • Cada usuario tiene una cuenta
  • Para iniciar sesión, debe proporcionar su nombre de usuario y contraseña (a través de la aplicación, no del navegador web)
  • Los datos se transfieren del cliente (dispositivo móvil) al servidor en algún lugar.

Simple! Ok, como sé, la autenticación web normal está protegida por SSL, que es simplemente "enviar sin problemas, estás a salvo".

En el dispositivo móvil no puedo usar SSL (incluso si Android proporciona algunos métodos, simplemente no puedo porque estoy transfiriendo mi juego a iOS, usando diferentes motores de juegos / redes, etc.).

Tengo que hacer que el proceso de "envío y recepción" sea seguro para que una tercera persona no capture las credenciales del usuario.

Mientras leo, la mejor forma de realizar esto es el método RSA , que utiliza claves públicas y privadas para cifrar / descifrar paquetes.

Por lo que sé, funciona como:

  • hay dos claves, privada, pública y un mensaje: "mensaje".
  • cualquiera puede obtener una clave pública (porque es pública)
  • solo el servidor tiene acceso a la clave privada
  • cualquiera puede cifrar el "mensaje" con la clave pública y siempre se verá igual (el mismo mensaje cifrado con la misma clave pública)
  • el mensaje cifrado se puede descifrar de una sola manera: utilizando una clave privada y se verá como el primer mensaje: "mensaje".
  • las claves públicas y privadas no son iguales, pero utilizan diferentes algoritmos de cifrado / descifrado, por lo que funciona de forma mágica para que al final el mensaje sea el mismo

¡Por favor, corrígeme si me equivoco!

Y aquí están mis preguntas:

  • ¿Tengo razón en el ejemplo anterior, que los paquetes enviados de esta manera (y que la clave pública es realmente pública) están asegurados (por supuesto, cualquier cosa se puede descifrar) pero, sabes, está "seguro"?
  • ¿Debería cada usuario tener su propio par de claves?
  • ¿Cuándo debo generar un nuevo par de claves? ¿Con cada login?
  • ¿Cuándo debo enviar una clave pública al usuario? ¿Cuando hace clic en 'registrar' o 'iniciar sesión' (con campos de texto ya llenos con los datos)? ¿O cuando abre la aplicación?

Si hubiera alguien que pudiera explicar estas cosas un poco, ¡se lo agradecería! :)

Dos preguntas adicionales para @Luke Park

La clave pública es pública y usted dijo que no debería enviarse a través de la red. ¿Significa que con una clave pública el usuario puede descifrar los datos de alguna manera?

Y el segundo: Usted dijo que debería empaquetar la clave pública con la aplicación. Si la clave pública también es una herramienta peligrosa en manos de un pirata informático, ¿es aconsejable almacenarla en un código? Como sé, hay formas de recuperar los datos del programa compilado.

Y un extra! Si la clave está empaquetada (probablemente codificada), ¿debería permanecer siempre igual o debería cambiar el par (generar nuevo)? Mientras leo en alguna parte, al tener una clave pública 'pública' es posible descifrar los datos (toma algún tiempo, pero es posible).

    
pregunta Spectre 05.09.2016 - 20:28
fuente

1 respuesta

4

En general y con algunos malentendidos, lo que dijiste es correcto. La principal diferencia es que el texto cifrado (por ejemplo, después de cifrar el mensaje con la clave pública) no siempre tiene el mismo aspecto, RSA introduce algunos datos aleatorios y rellenos que hacen que el texto cifrado sea diferente, incluso si el texto simple es el mismo. Sin embargo, esto probablemente no le causará ningún problema, contribuye a la seguridad.

Personalmente, creo que el esfuerzo involucrado para que TLS funcione valdría la pena implementar su propia solución. Sin embargo, si quieres hacerlo tú mismo ...

No generaría un nuevo par de llaves para cada usuario. Un solo par de llaves del servidor sería suficiente. Distribuya la clave pública con su aplicación y mantenga la clave privada en su servidor. Utilice RSA no para cifrar sus datos de inicio de sesión, sino para negociar una clave AES, y luego usarla para cifrar sus datos. Este es un concepto básico utilizado por TLS. Una de las razones por las que se hace esto es porque el tamaño del texto sin formato que puede cifrar RSA está limitado por el tamaño de bit de la clave. Generalmente, más de ~ 240 bytes no se pueden cifrar sin aplicar RSA varias veces, lo que es una mala idea en términos de velocidad y seguridad.

Recuerde autenticar sus datos correctamente, utilizando HMAC o un modo autenticado como GCM. De lo contrario, su carga podría modificarse (no leerse) en tránsito.

No envíe la clave pública a la aplicación, debe estar incluida con la aplicación. Si envía la clave pública a través de su canal inseguro a la aplicación, entonces nada impide que se modifique en tránsito. Un atacante podría reemplazarlo con su clave pública y luego descifrar el tráfico (y los detalles de inicio de sesión) con su clave privada.

Vuelvo a decir, TLS sería mejor y más seguro que implementar el tuyo, pero parece que piensas que esto no es posible.

EDITAR: Digo que no envíe la clave pública a través de la red, no porque sea "peligrosa" o un activo cuando está en las manos equivocadas, sino porque está enviando la clave pública en texto plano (por ejemplo, a través de HTTP o TCP). Ya que cualquiera puede modificar este tráfico (no es un problema poder verlo), podrían reemplazar la clave pública con su clave pública PROPIA antes de que llegue a su aplicación. Si la clave ya está integrada con la aplicación, ambas partes ya tienen sus claves (por ejemplo, la aplicación con el público y el servidor con el privado).

La clave pública no es útil para nadie más que para cifrar y verificar. No es algo que necesites ocultar. Solo necesita poder verificar que es la clave pública correcta. Si integras esto con tu aplicación, la seguridad empleada por App Store y Play Store será suficiente para que llegue al dispositivo del usuario con tu aplicación.

    
respondido por el Luke Park 05.09.2016 - 22:43
fuente

Lea otras preguntas en las etiquetas