almacenamiento de clave de cifrado

Question

almacenamiento de clave de cifrado

#1 de Akber Choudhry (3 votos)
#2 de Anthony Palmer (1 votos)

5

Recientemente heredé un sistema de almacenamiento de claves integrado en la empresa. La empresa almacena los datos de la tarjeta de crédito en dos servidores de bases de datos que están encriptados AES. Las claves residen en un sistema separado que se encuentra en su propia DMZ. Cuando un servidor web necesita cifrar algunos datos, se llama al servidor de claves a través de https y solicita una clave. Devuelve una clave y un número de serie codificado. El servidor de aplicaciones almacena la información cifrada y el número de serie y luego descarta la clave. Cuando es necesario descifrar los datos, el número de serie se envía al servidor de claves que devuelve la clave que se utilizó para ese registro.

El sujeto que desarrolló esto no usó grupos de claves. Cada clave es un valor aleatorio único. La base de datos de claves se cifra mediante una clave generada por 2 contraseñas proporcionadas por 2 custodios. Por lo que estoy viendo, incluso si obtuviera las llaves, tendría que poder decodificar los números de serie para poder usarlas, y luego cada tecla solo sería válida para un registro. Incluso escribió una extensión php en c que tiene las funciones de codificación / decodificación.

Este parece ser un diseño bastante bueno. Cualquier persona tiene experiencia con este tipo de cosas que puedan opinar sobre este método y cualquier posible agujero o mejora.

encryption architecture

pregunta Pete Robbins 17.11.2012 - 06:21

fuente

2 respuestas

Lea otras preguntas en las etiquetas encryption architecture

¿Es realmente factible o útil utilizar una gran cantidad de servidores proxy? ¿Cómo autentica un cliente el controlador de dominio?

score 3 · Answer 1

A primera vista, parece ser ingenioso y una doble capa de seguridad. Pensándolo bien, es bastante similar a la tokenización de las tarjetas de crédito, con 1 pro y 1 con en lugar de tokenización:

pro: hay dos capas de cifrado en dos sistemas separados
los números de tarjeta de crédito con - completos, aunque están encriptados, aún se almacenan en el sistema empresarial y el cifrado es reversible.

Aunque la configuración de dos custodios es un buen mecanismo, las claves del reino siguen siendo la clave de cifrado de la 'base de datos de claves'. Si están comprometidos, el resto es solo búsqueda y algoritmos y TODOS los números de tarjetas de crédito pueden escapar.

Basado en un análisis preliminar, me atrevería a decir que, en general, tal vez sea menos seguro para un sistema de tokenización. Un token no se puede revertir, solo se puede buscar y, por lo tanto, controlar, controlar desde IP, etc. Un buen sistema de tokenización tiene otras ventajas, como puede ser subcontratado, o el número CC solo puede ser entregado a un tercero como un pago El procesador, etc. y los números CC, encriptados o sin cifrar, nunca se almacenan en un sistema empresarial y ni siquiera pueden ingresar al patrimonio de la empresa después de haber sido intercambiados por un token la primera vez.

score 1 · Answer 2

Suena demasiado complicado y quebradizo: mantener esto va a ser un dolor. ¿Qué tal esto para un agujero potencial:

"el servidor de claves se llama a través de https y solicita una clave"

Si la solicitud https al servidor de claves está protegida mediante un certificado débil (por ejemplo, autofirmado), la conexión de intercambio de claves podría ser falsificada (por ejemplo, por un ataque MITM que devuelve una clave conocida; descifre fácilmente las cosas más adelante cuando sepa el Clave. Es bastante posible, ya que el servidor de claves no es público y tal vez el creador no pensó en utilizar una CA comercial. Me pregunto si el certificado del servidor SSL se verificó correctamente ... o si el solicitante clave verifica si se recibe una clave diferente cada vez, puede que sea fácil volver a reproducir el mensaje inicial una y otra vez ... ¡ahora solo necesito descifrar una tecla! Oh bien.