Les diagrammes UML peuvent être utilisés pour expliquer la cryptographie d'une solution de sécurité d'entreprise. Je le sais parce que j'ai contribué à des livres blancs sur la sécurité et à des documents explicatifs similaires tout en travaillant dans le secteur des logiciels d'entreprise.

Pourquoi j'utilise UML

Il y a quelques années, je recevais une explication verbale des relations entre les ressources cryptographiques d'une solution d'un ingénieur en sécurité. Je posais des questions et j'ai commencé à dessiner des boîtes et des lignes sur un tableau de nettoyage. L'ingénieur en sécurité a corrigé ma compréhension en effaçant et en redessinant certaines cases et lignes. J'ai pris une photo avec mon téléphone et transcrit les schémas avec un outil de dessin sur mon ordinateur.

Plus tard, mais au même poste, je contribuais au livre blanc de sécurité du produit sur lequel je travaillais. J'ai imaginé une convention, ad hoc, pour représenter sous forme de diagrammes les relations entre ses ressources cryptographiques.

Plus tard encore, à un autre poste, j'écrivais à nouveau un livre blanc sur la sécurité avec des diagrammes. Je ne pouvais pas utiliser la même convention ad hoc car c'était la propriété intellectuelle de mon ancien employeur. C'est alors que je me suis tourné vers un standard que je connaissais déjà, le langage de modélisation unifié (UML).

UML comme boîte à outils

L'un des grands avantages de la norme UML est qu'elle fournit des outils et qu'elle n'est pas prescriptive. Mon UML n'est pas rigoureux. J'utilise parfois des éléments standards de manière non standard. Mais mes diagrammes sont conformes à ce que Martin Fowler a décrit comme la "fraction d'UML la plus utile".

Le standard UML est un outil qui va m'aider à expliquer la cryptographie d'une solution.

Que faut-il expliquer

J'explique tout ce qui suit avec UML.

• Quelles sont les principales ressources cryptographiques de la solution. Par exemple, quelles clés de chiffrement et valeurs de sel existent.
• Quels algorithmes sont utilisés.
• Quelles valeurs de paramètre sont utilisées, comme la longueur en bits des clés et des valeurs de sel.
• Comment chaque ressource cryptographique est-elle générée.
• Lesquelles des ressources cryptographiques sont stockées de manière persistante et où, et lesquelles ne le sont pas.
• Quelles ressources sont protégées par quelles clés, autrement dit la hiérarchie des clés.

Une explication que je donne ne permettra pas vraiment à un concurrent de copier le produit, car elle ne sera pas suffisamment détaillée. Vous pourriez penser différemment, auquel cas vous pourriez exiger un accord de non-divulgation (NDA) de toute partie externe qui souhaite voir votre explication.

Exemple d'exigences de produit

Pour illustrer comment utiliser UML pour expliquer la cryptographie, je vais imaginer un produit avec certaines exigences de sécurité. Ensuite, je vais proposer une implémentation, et expliquer la cryptographie de l'implémentation avec des diagrammes UML.

Imaginez que le produit est Digital Encabulator for Enterprise (DEE) version 1. DEE pourrait être disponible pour les utilisateurs finaux sur des appareils mobiles, ainsi que sur des ordinateurs portables et de bureau. Les exigences de sécurité sont de faire tout ce qui suit.

• Protégez les données au repos avec un chiffrement basé sur un mot de passe ( PBE ). Le mot de passe sera une valeur secrète entrée par l'utilisateur final.
• Prise en charge du changement de mot de passe , sans interruption de la disponibilité des données protégées.
• Prise en charge de la récupération des données au cas où l'utilisateur final oublie son mot de passe.
• Prend en charge l'audit des données par l'entreprise à l'insu de l'utilisateur final.
• Utilisez des pratiques bien connues et standard pour la cryptographie.

• Un mot de passe est défini par chaque utilisateur final lorsqu'il installe l'application.
• Une clé de code d'accès (PK) est générée à partir du code d'accès par un processus PBKDF2 (Passcode Based Key Derivation Function version 2) avec ces paramètres.
  - Fonction pseudo-aléatoire du code d'authentification de message basé sur le hachage (HMAC).
  - Fonction de hachage SHA256.
  - 20 000 itérations.
• Une valeur de sel de code d'accès (PS) est incluse dans les entrées PBKDF2. PS sera généré par un générateur de nombres aléatoires sécurisé (RNG).
• La valeur PS est stockée de manière persistante sur l'appareil. Ni la valeur PK ni le mot de passe ne sont stockés.

• Protégez les données d'application avec une clé de chiffrement de données intermédiaire (DEK). DEK sera une longue valeur aléatoire générée par un RNG sécurisé. DEK aura une longueur de 256 bits, pour éviter d'être deviné par la force brute dans un laps de temps pratique.
• Stockez DEK chiffré par PK dans le stockage persistant de l'appareil. Ne stockez jamais DEK en clair dans un stockage persistant. Le chiffrement utilisera l'algorithme AES Key Wrap.
• Lorsque l'utilisateur modifie son mot de passe, rechiffrez DEK avec la nouvelle valeur PK. (Sans DEK, toutes les données d'application devraient être rechiffrées lorsque le mot de passe est modifié.)

• Fournir un service de récupération de données (DRS).
• DRS recevra une demande de configuration (DRS-SU) lorsqu'un utilisateur final génère une DEK sur son appareil. DRS-SU inclura un identifiant d'utilisateur et exigera une authentification hors bande de l'utilisateur, par exemple en redirigeant l'utilisateur vers un fournisseur d'identité (IDP).
• Lorsque DRS reçoit DRS-SU, il génère une paire de clés pour le chiffrement asymétrique. La paire de clés a une clé privée (RIK) qui est générée et stockée dans un module de sécurité matériel (HSM) et une clé publique correspondante (RUK). RIK aura une longueur de 2048 bits.
• Le DRS répond au DRS-SU en renvoyant RUK.
• L'application utilisateur stocke DEK crypté par RUK dans le stockage persistant de l'appareil. Le chiffrement utilisera l'algorithme RSA avec le rembourrage PKCS1.
• L'application de l'utilisateur final peut envoyer une demande de récupération (DRS-RY) au DRS. DRS-RY inclura un identifiant d'utilisateur et exigera une authentification de l'utilisateur, comme DRS-SU, et inclura DEK crypté par RUK.
• Lorsque DRS reçoit DRS-RY, DEK est déchiffré par RIK dans le HSM. DRS répond à DRS-RY avec DEK.

• DRS peut recevoir une demande d'audit (DRS-AT). DRS-AT comprendra les mêmes valeurs que DRS-RY et en plus un identifiant d'utilisateur d'audit. L'utilisateur de l'audit aura besoin d'une autorisation.
• Le traitement DRS et la réponse à DRS-AT sont par ailleurs les mêmes que pour DRS-RY.

Ce diagramme représente les fonctions cryptographiques de base dans l'implémentation sous la forme d'un diagramme de classes UML.

Le schéma exprime ce qui suit.

Secure Random Number Generator est une classe. Son nom sera abrégé en RNG.

• Les instances RNG ont un attribut, longueur, avec une valeur par défaut de 256.
• Les instances RNG ont une opération, getNext, sans paramètre qui renvoie des bits de longueur.

• Les instances de chiffrement ont un attribut, l'algorithme, avec une valeur par défaut AES-GCM (Advanced Encryption Standard in Galois/Counter Mode).
• Les instances de chiffrement ont une opération, encrypt, qui prend deux paramètres, Key et Plaintext, et renvoie Ciphertext. Aucun détail n'est donné sur les types de données.
• Les instances de chiffrement ont une opération, decrypt, qui prend deux paramètres, Key et Ciphertext, et renvoie Plaintext. Aucun détail n'est donné sur les types de données.

Exemple de diagramme de déploiement

Ce diagramme représente le stockage et la protection des ressources cryptographiques dans l'implémentation sous la forme d'un diagramme de déploiement UML.

Excuses interposées : le diagramme s'écarte de la norme UML, de la manière suivante.

• Les artefacts, par exemple les données d'application, sont affichés sous forme de rectangles sans marqueur de document.
  Le marqueur de document semble superflu dans la norme. Il ressort déjà clairement du rectangle plat que Application Data, par exemple, n'est pas un environnement d'exécution.
• Les objets, par exemple les instances RNG, sont affichés dans un diagramme de déploiement.
  Le style utilisé ici, rectangles avec coins carrés et texte souligné, est issu de la norme de diagramme d'objets UML.
  Dessiner un diagramme d'objets séparé avec les mêmes instances mais sans leur contexte déployé obligerait le lecteur à regarder un diagramme supplémentaire.
• Les étiquettes sur les connexions ne montrent pas exactement la communication. Au lieu de cela, ils affichent les noms des paramètres et donc les relations.
• L'instance de chiffrement asymétrique s'affiche dans l'environnement de mémoire d'exécution de l'application. C'est correct pour le chiffrement, mais incorrect pour le déchiffrement.
  Cela pourrait peut-être être résolu en développant le diagramme pour afficher des environnements ou des documents distincts pour une demande de configuration DRS et une demande de récupération DRS.

• Ces données sont stockées de manière persistante par l'application.
  -PS.
  - DEK crypté par PK.
  - Données d'application cryptées.
  - DEK crypté par RUK.
• Aucune autre donnée n'est stockée de manière persistante par l'application.
• RIK est stocké dans un HSM au sein de DRS.
• RUK est généré par le DRS mais n'y est pas stocké.
• DEK est stocké crypté par deux clés différentes, RUK et PK. Pour le chiffrement PK, l'algorithme AES-KW (Advanced Encryption Standard Key Wrap) est utilisé à la place de l'AES-GCM par défaut.
• PS est une valeur aléatoire de la longueur par défaut, 256. RIK et RUK sont basés sur une valeur aléatoire de longueur spécifiée, 2048.

• Les données d'application peuvent être obtenues à partir d'un stockage persistant uniquement si DEK est obtenu.
• La DEK peut être obtenue à partir d'un stockage persistant si le code d'accès est connu. PS est dans un stockage persistant et PK peut être obtenu en exécutant KDF sur le code d'accès et PS.
• DEK peut également être obtenu à partir d'un stockage persistant si RIK est accessible. La DEK chiffrée par RUK est stockée de manière persistante et peut être déchiffrée par RIK. Le schéma n'indique pas que la DEK chiffrée par RUK doit être envoyée au DRS afin de traiter le déchiffrement.

Exemple de diagramme d'activité

Ce diagramme représente le traitement de définition du mot de passe en tant que diagramme d'activité UML.

Les éléments standard suivants sont utilisés.

• Les actions, telles qu'une dérivation de clé, ont des coins arrondis.
• Les nœuds d'objet, avec des coins carrés, sont utilisés pour représenter des ressources cryptographiques telles que des clés et des valeurs de sel.
• Les épingles, petits carrés avec des étiquettes de texte, indiquent les paramètres des actions. Les broches ne sont utilisées que dans le cas où il y a plus d'un paramètre.
  - Les paramètres d'entrée d'un processus encrypt() ont des broches car il y en a deux, clé et texte en clair.
  - La sortie d'un processus encrypt() n'a qu'un seul paramètre, le texte chiffré, donc il n'a pas de code pin.
• Les barres épaisses indiquent le début et la fin du traitement indépendant. Par exemple, le RNG getNext () pour générer PS est indépendant du fait que le code d'accès soit un paramètre du traitement KDF. Ce n'est peut-être pas tout à fait standard, mais cela évite d'avoir deux flux à partir d'une ressource, ce qui n'est certainement pas standard.

1. Le traitement commence lorsque le mot de passe a été saisi.
2. Un générateur de nombres aléatoires sécurisé (RNG) est exécuté avec une longueur par défaut, comme indiqué dans le diagramme de classes. La sortie est le sel de code d'accès (PS), qui est stocké de manière persistante.
3. Une fonction de dérivation de clé est exécutée avec le mot de passe comme secret, la valeur PS comme sel, et l'algorithme par défaut et le nombre d'itérations, comme indiqué dans le diagramme de classes. La sortie est la clé de code d'accès (PK), qui n'est pas stockée de manière persistante.
4. Un autre RNG est exécuté avec une longueur par défaut, comme indiqué dans le diagramme de classes. La sortie est la clé de chiffrement des données (DEK), qui n'est pas stockée de manière persistante.
5. Un processus de chiffrement chiffré est exécuté avec PK comme clé, DEK comme texte en clair et l'algorithme AES-KW. La sortie est stockée de manière persistante.

• Configurez la récupération des données.
• Changer le mot de passe.
• Lancer l'application, ce qui inclurait la récupération de la clé de cryptage des données. La récupération peut se faire à partir d'un stockage persistant, en régénérant la clé de code d'accès à partir d'un code d'accès saisi par l'utilisateur ou à partir du service de récupération de données.
• Stockez les données d'application.

Les exemples ci-dessus montrent que les diagrammes UML peuvent être utilisés pour expliquer la cryptographie. Différents types de diagramme UML peuvent être utilisés pour expliquer différents aspects.

• Les diagrammes de classes montrent quels standards et paramètres cryptographiques sont utilisés.
• Les diagrammes de déploiement montrent où les ressources sont stockées, si elles sont stockées et quelles ressources sont protégées par quelles clés.
• Les diagrammes d'activité montrent les séquences de traitement. Les nœuds d'objet indiquent quelles ressources sont impliquées dans le traitement.

Pour un exemple d'explication de la cryptographie d'une solution réelle, jetez un œil au livre blanc publié ici.
developer.vmware.com/…/MobileApplicationManagement.pdf
(Les diagrammes UML se trouvent dans la section Workspace ONE Chiffrement des données au repos, sous l'en-tête Diagrammes de chiffrement basés sur un code.)

Les diagrammes de cet article et du livre blanc ont été dessinés avec l' outil diagrams.net , également connu sous le nom d'outil draw.io.

Pour plus d'informations sur la norme UML (Unified Modeling Language), consultez lehttps://uml.orgsite Web et le livre UML Distilled Third Edition de Martin Fowler.

Pour une référence sur les normes et termes de cryptographie, voir le livre Serious Cryptography de Jean-Philippe Aumasson.