¿Cómo implementar el requisito 3.5.2 de PCI DSS?

Question

¿Cómo implementar el requisito 3.5.2 de PCI DSS?

#1 de John Deters (3 votos)
#2 de kiBytes (1 votos)

2

De acuerdo con PCI-DSS requisito 3.5.2 :

Las claves secretas y privadas utilizadas para cifrar / descifrar los datos del titular de la tarjeta deben almacenarse en uno de los siguientes formularios en todo momento:

Encriptada con una clave de cifrado de clave que es al menos tan fuerte como la clave de cifrado de datos, y que se almacena por separado de la clave de cifrado de datos .
Dentro de un dispositivo criptográfico seguro (como un módulo de seguridad del host ( HSM ) o PTS (punto de acceso aprobado) dispositivo de interacción).
Como al menos dos componentes clave completos o claves compartidas, de acuerdo con un método aceptado por la industria .

Mis preguntas:

Cómo almacenar la clave de cifrado de clave por separado de la clave de cifrado de datos y ¿es esa una buena práctica ?
Si decidimos almacenar KEK por separado de DEK , entonces deberíamos almacenar DEK en un servidor y KEK en un servidor separado ?
Si decidimos almacenar claves en un dispositivo criptográfico , ¿cuál será la mejor práctica entre HSM y PTS ?
¿Qué son dos componentes clave completos o partes clave compartidas ? ¿Alguien podría explicarlo?

¿Hay enlaces o documentos útiles disponibles?

pci-dss

pregunta RajeshKannan 25.02.2014 - 20:21

fuente

2 respuestas

Lea otras preguntas en las etiquetas pci-dss

¿Qué tan segura es la técnica de intercambio de claves anti-MITMA Diffie-Hellman de Samy Kamkar? .NET proporciona más de 8 formas de codificar datos para evitar ataques XSS. ¿Cuál debo usar cuando? [cerrado]

score 3 · Answer 1

Piense en la clave de cifrado de datos como una "clave de sesión" en SSL. Puede / debe ser un valor aleatorio que giraría para cifrar un número de cuenta. La clave de cifrado de clave sería la clave pública recuperada de un certificado. Usted utiliza la tecla KEK para cifrar el DEK, luego deseche el DEK de texto simple después de cifrar los datos. Mientras tanto, la clave privada (combinada con la clave pública en el certificado) permanece segura dentro de un entorno protegido, lejos del entorno de datos. Y sí, esta es una mejor práctica.
Nunca almacenaría el DEK de texto plano. En su lugar, encripte el DEK con la tecla KEK y almacene solo el DEK encriptado.
Un HSM proporciona un entorno resistente a la manipulación indebida para albergar operaciones criptográficas, y se prefiere para operaciones delicadas como el descifrado de claves.
Usa un algoritmo como Shamir's Secret Sharing. Le permite dividir la clave en varias partes y requiere un cierto número de partes para volver a ensamblarla.

score 1 · Answer 2

Bueno, déjame intentar ayudarte.

Imaginemos que tiene una caja fuerte dentro de un cajón lleno de diamantes, ¿almacenará la combinación o la llave de la caja fuerte en el mismo cajón? Esto es lo mismo, solo el sentido común. Así que para responder a sus preguntas:

Sí, es una buena práctica. Si realmente no usas mucho tu KEK, incluso puedes mantenerlo en un pendrive dentro de una caja fuerte. Pero como puede usarlo mucho, puede almacenarlo en un servidor diferente (o una PC diferente).
Bueno, eso depende de usted, si alguien tiene acceso a todo el disco encontrará: KEK y DEK, ¿este problema por sí solo vale la pena para un nuevo servidor? Tendrá que hacer un análisis sobre eso. Si no, considere al menos almacenarlos dentro de diferentes conjuntos de permisos (tal vez diferentes usuarios con diferentes capacidades ...).
PTS no tiene nada que hacer aquí para HSM si puede costearlo, ya que es una solución por sí misma y parece un poco inseguro sobre estos temas.
Esta es simplemente una manera de tener varias personas / procesos involucrados al descifrar una clave, esto se conoce como compartir en secreto y hay varios algoritmos disponibles.