Verificación de seguridad de seguridad

5

Una empresa cuyos servicios estoy intentando integrar usa este protocolo:

  1. Una clave AES está incrustada en una biblioteca de Android.
  2. Para autenticarse, la biblioteca envía un hash SHA1 de la clave a través de HTTP simple.
  3. La respuesta contiene una clave pública RSA encriptada con la misma clave AES.
  4. Se genera una clave AES temporal en el cliente.
  5. La clave AES temporal y los datos confidenciales se cifran con la clave RSA y se envían a través de HTTP simple.

Su excusa para no usar HTTPS es que creen que tendrían que pagar por un certificado firmado en cada dispositivo móvil que admiten, en lugar de solo en su servidor. También creen que HTTPS agrega demasiados gastos de red para su uso en dispositivos móviles. Ah, y su sistema es "más seguro que HTTPS" porque están usando claves AES más largas. ¿Mencioné que esto se está utilizando para procesar tarjetas de crédito?

Estoy tratando de convencerlos de que esto es completamente loco. ¿Puede alguien indicarme una explicación clara y concisa que sea inteligible para los PHB? (¿O qué podría llevar a la audiencia de desempleo si me despiden por mover el barco?)

    
pregunta Kevin Krumwiede 22.07.2014 - 04:11
fuente

2 respuestas

5

Sí, si lo estás describiendo con precisión, esto está completamente roto, hasta el punto de ser inútil.

La clave AES inicial se ve comprometida por estar en la aplicación, cualquiera que tenga la aplicación tiene acceso a la clave AES. Si esto es global, entonces está bien y realmente atornillado, si es único para cada aplicación, puede haber un pequeño rayo de esperanza.

El SHA-1 es completamente reproducible. No menciona sal, pero incluso si hay un salt, el atacante puede volver a jugar contra un cliente legítimo como un MitM y luego responder de manera válida para aparecer como el cliente al servidor.

El servidor le proporcionará al atacante la clave pública, en forma encriptada, que no es particularmente útil para el atacante, pero también es la clave pública ... se supone que es pública. Tenerlo en privado no ofrece nada. Si el cliente estuvo comprometido (o cualquier cliente si la clave AES es global), la aplicación filtra la clave AES y la clave pública también está disponible para el atacante.

Además, si la clave AES está comprometida, el atacante puede enviar una clave pública de su elección ya que el cliente no tiene forma de verificar la clave pública RSA.

Una clave AES que se genera en el cliente es una idea bastante decente, pero hasta ahora, no hay nada que impida que el atacante genere su propia clave AES. Además, es probable que puedan proporcionar al cliente su propia clave pública para que también puedan engañar al cliente.

¿Por qué los datos se cifran con la clave RSA? ¿Cuál es el punto de la clave AES temporal entonces? ¿Es realmente completamente sin uso? En general, el cifrado de datos largos con RSA se considera menos seguro que el uso de cifrado simétrico, ya que requiere más trabajo para procesar y puede tener otras implicaciones de seguridad. La norma es simplemente intercambiar una clave simétrica y usarla para el intercambio de datos.

En resumen, el sistema es completamente inútil.

En realidad, sería mucho más útil si simplemente incrustaran la clave pública del servidor en la aplicación y la usaran para que el cliente generara una clave AES y la intercambiara para la comunicación de la sesión. No validaría nada sobre el cliente en sí, pero eso podría hacerse a través de contraseñas u otros tokens después de que la sesión se haya inicializado. Sin embargo, en ese momento está bastante cerca de usar un HTTPS autofirmado, pero podría usarse como una implementación personalizada si el HTTPS no es una opción por algún motivo (como no poder agregar un certificado raíz de confianza en el cliente). dispositivos.)

    
respondido por el AJ Henderson 22.07.2014 - 16:11
fuente
4

Bueno, la clave AES incrustada en la biblioteca es completamente inútil, y parece que no hay validación del lado del servidor. Veo muchos problemas con este esquema.

  1. Cualquier persona con acceso a la biblioteca de Android puede extraer la clave AES.
  2. Enviar un hash de un valor estático a través de HTTP simple es lo mismo que enviar una contraseña a través de HTTP simple. Cualquiera puede tomarlo de la observación pasiva, por lo que no hay autenticación del cliente.
  3. No hay autenticación del servidor, por lo que si obtengo acceso a un cliente (y así puedo robar la clave AES estática), puedo MITM a cualquier cliente, enviar mi propia clave RSA y leer / modificar / manipular todo el tráfico. .

No menciona cómo se implementa el AES (qué modo, cómo se genera el IV, etc.) en qué modo / relleno se usa la tecla RSA (si se usa sin relleno, también conocido como "libro de texto RSA", es aún más roto).

Dijo que esto se usa para el procesamiento de tarjetas de crédito y, aunque no soy un experto en PCI, estoy bastante seguro de que no pasaría el cumplimiento de PCI.

    
respondido por el David 22.07.2014 - 04:36
fuente

Lea otras preguntas en las etiquetas