¿La gestión de claves híbridas está haciendo mal?

3

Actualmente estoy trabajando en un proyecto que necesita ser lo más seguro posible para la administración de claves. Mi experiencia con el cifrado, el descifrado y la administración de claves no son en absoluto, así que hice una investigación sobre el tema en cuestión, pero todavía no estoy seguro de lo que he pensado que es seguro, por lo tanto, mis preguntas:

Proyecto

El proyecto en breve: Una aplicación cliente que envía (a través de WIFI) datos confidenciales de tarjetas de crédito hacia un servidor local que envía los datos a un procesador de tarjetas de crédito. La comunicación entre el cliente y el servidor local debe ser segura en todo momento y no quiero confiar en la configuración del servidor o del enrutador, así que inicio mi comunicación segura.

aplicación de cliente < - > [servidor local - > Solicitud de pago de conformidad PA-DSS] < - > Procesador

(Sé que para los pagos con tarjeta de crédito hay requisitos dados por el PCI-SSC específicamente PA-DSS y ya los he leído detenidamente, pero no soy un experto).

Preguntas

  1. (mirando la "Configuración cliente-servidor" a continuación) ¿Es esta una implementación correcta de un enfoque híbrido de administración de claves?
  2. Para garantizar que el contenido de los mensajes sea válido, ¿debo agregar una suma de comprobación o un hash en los datos cifrados?
  3. La primera clave AES256 que tanto el cliente como el servidor tienen incrustado en el código, porque esto solo es necesario para el primer contacto, ¿perdería esta clave? ¿inseguridad media para todo el sistema? (Creo que no, pero no estoy seguro)
  4. ¿Debo garantizar más autenticación en caso afirmativo, entonces cómo puedo lograr esto?

Como administración de claves, elijo un sistema híbrido de administración de claves que utiliza tanto AES-256 como RSA-1024/2048.

Configuración cliente-servidor

  • El cliente y el servidor [BOTH] tienen la misma clave AES-256
  • [CLIENTE] genera un par de claves 1024 o 2048 privadas / públicas
  • [CLIENTE] envía la clave pública (formato PEM x509) cifrada (CBC - PKCS7 rellenada) bajo la clave AES256 compartida hacia el servidor
  • [SERVIDOR] descifra los datos recibidos y recupera la clave pública
  • [SERVIDOR] genera una nueva clave AES-256 aleatoria y se cifra con la clave pública (O-AEP rellenada)
  • [SERVIDOR] devuelve la clave AES-256 cifrada con la clave pública
  • [CLIENTE] descifra los datos recibidos y recupera la nueva clave AES-256
  • [BOTH] la comunicación adicional se cifra con la nueva clave AES-256

Gracias de antemano

    
pregunta JustinV 03.04.2012 - 12:43
fuente

1 respuesta

5

Esto se siente como reinventar la rueda. Gran tiempo SSL debe poder cumplir con los requisitos (de PCI y muchas otras necesidades de comunicaciones seguras), mantener la confidencialidad y la integridad. Además, es compatible con una buena autenticación sólida de manera simple y efectiva sin tener que inventar su propio protocolo.

    
respondido por el Yoav Aner 03.04.2012 - 15:43
fuente

Lea otras preguntas en las etiquetas