Los diagramas UML se pueden utilizar para explicar la criptografía de una solución de seguridad empresarial. Lo sé porque he contribuido a documentos técnicos de seguridad y documentos explicativos similares mientras trabajaba en el negocio del software empresarial.

Por qué uso UML

Hace algunos años recibí una explicación verbal de las relaciones entre los recursos criptográficos de una solución de un ingeniero de seguridad. Estaba haciendo preguntas y comencé a dibujar cuadros y líneas en una pizarra. El ingeniero de seguridad corrigió mi comprensión borrando y volviendo a dibujar algunos de los cuadros y líneas. Tomé una foto con mi teléfono y transcribí los diagramas con una herramienta de dibujo en mi computadora.

Más tarde, pero en el mismo puesto, estaba contribuyendo al libro blanco de seguridad del producto en el que trabajaba. Se me ocurrió una convención, ad hoc, para representar en diagramas las relaciones entre sus recursos criptográficos.

Aún más tarde, en un trabajo diferente, estaba nuevamente escribiendo un documento técnico de seguridad con diagramas. No podía utilizar la misma convención ad hoc porque esa era propiedad intelectual de mi empleador anterior. Fue entonces cuando recurrí a un estándar con el que ya estaba familiarizado, el Lenguaje de modelado unificado (UML).

UML como conjunto de herramientas

Un gran valor del estándar UML es que proporciona herramientas y no es prescriptivo. Mi UML no es riguroso. A veces hago uso de elementos estándar de una manera no estándar. Pero mis diagramas cumplen con lo que Martin Fowler describió como la “fracción de UML que es más útil”.

El estándar UML es una herramienta que me va a ayudar a explicar la criptografía de una solución.

lo que debe ser explicado

Explico todo lo siguiente con UML.

• Cuáles son los principales recursos criptográficos de la solución. Por ejemplo, qué claves de cifrado y valores de sal existen.
• Qué algoritmos se utilizan.
• Qué valores de parámetros se usan, como cuánto tiempo en bits son las claves y los valores de sal.
• Cómo se genera cada recurso criptográfico.
• Cuáles de los recursos criptográficos se almacenan de forma persistente y dónde, y cuáles no.
• Qué recursos están protegidos por qué claves, en otras palabras, la jerarquía de claves.

Una explicación que doy realmente no permitirá que un competidor copie el producto, porque no será lo suficientemente detallada. Puede pensar de manera diferente, en cuyo caso podría requerir un acuerdo de no divulgación (NDA) de cualquier parte externa que quiera ver su explicación.

Ejemplo de requisitos del producto

Para ilustrar cómo usar UML para explicar la criptografía, voy a imaginar un producto con algunos requisitos de seguridad. Luego propondré una implementación y explicaré la criptografía de la implementación con diagramas UML.

Imagine que el producto es Digital Encabulator for Enterprise (DEE) versión 1. DEE podría estar disponible para usuarios finales en dispositivos móviles y en computadoras portátiles y de escritorio. Los requisitos de seguridad son hacer todo lo siguiente.

• Proteja los datos en reposo con el cifrado basado en contraseña ( PBE ). El código de acceso será un valor secreto ingresado por el usuario final.
• Admite el cambio de contraseña , sin interrupciones en la disponibilidad de los datos protegidos.
• Admite la recuperación de datos en caso de que el usuario final olvide su contraseña.
• Admite la auditoría de datos por parte de la empresa sin el conocimiento del usuario final.
• Utilice prácticas bien conocidas y estándar para la criptografía.

• Cada usuario final establece un código de acceso cuando instala la aplicación.
• Se genera una clave de código de acceso (PK) a partir del código de acceso mediante un proceso PBKDF2 (función de derivación de clave basada en código de acceso versión 2) con estos parámetros.
  - Función pseudoaleatoria de código de autenticación de mensajes basado en hash (HMAC).
  - Función hash SHA256.
  - 20.000 iteraciones.
• Se incluye un valor de sal de código de acceso (PS) en las entradas de PBKDF2. PS será generado por un generador seguro de números aleatorios (RNG).
• El valor de PS se almacena de forma persistente en el dispositivo. No se almacena ni el valor PK ni el código de acceso.

• Proteja los datos de la aplicación con una clave de cifrado de datos intermedia (DEK). DEK será un valor aleatorio largo generado por un RNG seguro. DEK tendrá una longitud de 256 bits, para evitar que la fuerza bruta lo adivine en un tiempo práctico.
• Almacene DEK encriptado por PK en el almacenamiento persistente del dispositivo. Nunca almacene DEK en claro en ningún almacenamiento persistente. El cifrado utilizará el algoritmo AES Key Wrap.
• Cuando el usuario cambie su código de acceso, vuelva a cifrar DEK con el nuevo valor de PK. (Sin DEK, todos los datos de la aplicación tendrían que volver a cifrarse cuando se cambia el código de acceso).

• Proporcionar un servicio de recuperación de datos (DRS).
• DRS recibirá una solicitud de configuración (DRS-SU) cuando un usuario final genere DEK en su dispositivo. DRS-SU incluirá un identificador de usuario y requerirá la autenticación del usuario fuera de banda, por ejemplo, redirigiendo al usuario a un proveedor de identidad (IDP).
• Cuando DRS recibe DRS-SU, genera un par de claves para el cifrado asimétrico. El par de claves tiene una clave privada (RIK) que se genera y almacena en un módulo de seguridad de hardware (HSM) y una clave pública correspondiente (RUK). RIK tendrá una longitud de 2048 bits.
• DRS responde a DRS-SU devolviendo RUK.
• La aplicación de usuario almacena DEK encriptado por RUK en el almacenamiento persistente del dispositivo. El cifrado utilizará el algoritmo RSA con relleno PKCS1.
• La aplicación de usuario final puede enviar una solicitud de recuperación (DRS-RY) a DRS. DRS-RY incluirá un identificador de usuario y requerirá autenticación de usuario, al igual que DRS-SU, e incluirá DEK encriptado por RUK.
• Cuando DRS recibe DRS-RY, RIK descifra DEK en el HSM. DRS responde a DRS-RY con DEK.

• DRS puede recibir una solicitud de auditoría (DRS-AT). DRS-AT incluirá los mismos valores que DRS-RY y además un identificador de usuario de auditoría. El usuario de auditoría requerirá autorización.
• El procesamiento y la respuesta de DRS a DRS-AT son, por lo demás, los mismos que para DRS-RY.

Este diagrama representa las funciones criptográficas básicas en la implementación como un diagrama de clases UML.

El diagrama expresa lo siguiente.

El generador seguro de números aleatorios es una clase. Su nombre se abreviará a RNG.

• Las instancias RNG tienen un atributo, longitud, con un valor predeterminado de 256.
• Las instancias RNG tienen una operación, getNext, sin parámetros que devuelve bits de longitud.

• Las instancias de cifrado tienen un atributo, algoritmo, con un valor predeterminado de AES-GCM (Estándar de cifrado avanzado en modo Galois/Contador).
• Las instancias de cifrado tienen una operación, cifrar, que toma dos parámetros, Clave y Texto sin formato, y devuelve Texto cifrado. No se dan detalles sobre los tipos de datos.
• Las instancias de cifrado tienen una operación, descifrar, que toma dos parámetros, clave y texto cifrado, y devuelve texto sin formato. No se dan detalles sobre los tipos de datos.

Diagrama de implementación de ejemplo

Este diagrama representa el almacenamiento y la protección de los recursos criptográficos en la implementación como un diagrama de implementación UML.

Disculpa interpuesta: el diagrama se desvía del estándar UML de las siguientes maneras.

• Los artefactos, por ejemplo, los datos de la aplicación, se muestran como rectángulos sin un marcador de documento.
  El marcador de documento parece superfluo en el estándar. Ya está claro a partir del rectángulo plano que los datos de la aplicación, por ejemplo, no son un entorno de ejecución.
• Los objetos, por ejemplo, las instancias de RNG, se muestran en un diagrama de implementación.
  El estilo utilizado aquí, rectángulos con esquinas cuadradas y texto subrayado, se toma del estándar de diagrama de objetos UML.
  Dibujar un diagrama de objetos separado con las mismas instancias pero sin su contexto implementado requeriría que el lector mirara un diagrama adicional.
• Las etiquetas en las conexiones no muestran exactamente la comunicación. En su lugar, muestran los nombres de los parámetros y, por lo tanto, las relaciones.
• La instancia de cifrado asimétrico se muestra en el entorno de memoria de tiempo de ejecución de la aplicación. Eso es correcto para el cifrado, pero incorrecto para el descifrado.
  Tal vez eso podría abordarse expandiendo el diagrama para mostrar entornos separados, o documentos, para una solicitud de configuración de DRS y una solicitud de recuperación de DRS.

• Estos datos son almacenados persistentemente por la aplicación.
  - PD.
  - DEK encriptado por PK.
  - Datos de la aplicación encriptados.
  - DEK encriptado por RUK.
• La aplicación no almacena ningún otro dato de forma persistente.
• RIK se almacena en un HSM dentro de DRS.
• RUK es generado por el DRS pero no se almacena allí.
• DEK se almacena encriptado por dos claves diferentes, RUK y PK. Para el cifrado PK, se utiliza el algoritmo AES-KW (Advanced Encryption Standard Key Wrap) en lugar del AES-GCM predeterminado.
• PS es un valor aleatorio de la longitud predeterminada, 256. RIK y RUK se basan en un valor aleatorio de longitud especificada, 2048.

• Los datos de la aplicación se pueden obtener del almacenamiento persistente solo si se obtiene DEK.
• DEK se puede obtener del almacenamiento persistente si se conoce el código de acceso. PS está en almacenamiento persistente y PK se puede obtener ejecutando KDF en el código de acceso y PS.
• DEK también se puede obtener del almacenamiento persistente si se puede acceder a RIK. DEK cifrado por RUK se almacena de forma persistente y RIK puede descifrarlo. El diagrama no expresa que DEK cifrado por RUK deba enviarse al DRS para procesar el descifrado.

Diagrama de actividad de ejemplo

Este diagrama representa el procesamiento para configurar el código de acceso como un diagrama de actividad UML.

Se utilizan los siguientes elementos estándar.

• Las acciones, como una derivación clave, tienen esquinas redondeadas.
• Los nodos de objetos, con esquinas cuadradas, se utilizan para representar recursos criptográficos como claves y valores salt.
• Alfileres, pequeños cuadrados con etiquetas de texto, indican parámetros para acciones. Los pines solo se utilizan en el caso de que haya más de un parámetro.
  - Los parámetros de entrada a un proceso de cifrado () tienen pines porque hay dos, clave y texto sin formato.
  - La salida de un proceso de cifrado () tiene solo un parámetro, texto cifrado, por lo que no tiene un pin.
• Las barras gruesas indican el inicio y el final del procesamiento independiente. Por ejemplo, el RNG getNext() para generar PS es independiente de que Passcode sea un parámetro para el procesamiento de KDF. Esto podría no ser del todo estándar, pero evita tener dos flujos de un recurso, lo que definitivamente no es estándar.

1. El procesamiento comienza cuando se ingresa el código de acceso.
2. Se ejecuta un generador de números aleatorios (RNG) seguro con una longitud predeterminada, como se muestra en el diagrama de clases. La salida es el código de acceso salt (PS), que se almacena de forma persistente.
3. Se ejecuta una función de derivación de clave con el código de acceso como secreto, el valor de PS como sal y el algoritmo predeterminado y el recuento de iteraciones, como se muestra en el diagrama de clases. El resultado es la clave de código de acceso (PK), que no se almacena de forma persistente.
4. Se ejecuta otro RNG con una longitud predeterminada, como se muestra en el diagrama de clases. El resultado es la clave de cifrado de datos (DEK), que no se almacena de forma persistente.
5. Se ejecuta un proceso de cifrado de cifrado con PK como clave, DEK como texto sin formato y el algoritmo AES-KW. La salida se almacena de forma persistente.

• Configurar la recuperación de datos.
• Cambiar contraseña.
• Inicie la aplicación, que incluiría la recuperación de la clave de cifrado de datos. La recuperación podría realizarse desde un almacenamiento persistente, mediante la regeneración de la clave del código de acceso a partir de un código de acceso ingresado por el usuario, o desde el servicio de recuperación de datos.
• Almacenar datos de la aplicación.

Los ejemplos anteriores muestran que los diagramas UML se pueden usar para explicar la criptografía. Se pueden usar diferentes tipos de diagramas UML para explicar diferentes aspectos.

• Los diagramas de clase muestran qué estándares y parámetros criptográficos se utilizan.
• Los diagramas de implementación muestran dónde se almacenan los recursos, si se almacenan y qué recursos están protegidos por qué claves.
• Los diagramas de actividad muestran secuencias de procesamiento. Los nodos de objetos muestran qué recursos están involucrados en el procesamiento.

Para ver un ejemplo de una explicación de la criptografía de una solución real, consulte el documento técnico publicado aquí.
developer.vmware.com/…/MobileApplicationManagement.pdf
(Los diagramas UML se encuentran en la sección Cifrado de datos en reposo de Workspace ONE, bajo el título Diagramas de cifrado basados ​​en código de acceso).

Los diagramas de este artículo y del libro blanco se dibujaron con la herramienta diagrams.net , también conocida como la herramienta draw.io.

Para obtener información sobre el estándar del lenguaje de modelado unificado (UML), consulte elhttps://uml.orgsitio web y el libro UML Distilled Third Edition de Martin Fowler.

Para obtener una referencia sobre los estándares y términos de criptografía, consulte el libro Serious Cryptography de Jean-Philippe Aumasson.