Aller au contenu principal

8. CBC-DES Symmetric Encryption Protocol (Protocole de chiffrement symétrique CBC-DES)

8. CBC-DES Symmetric Encryption Protocol (Protocole de chiffrement symétrique CBC-DES)​

Cette section décrit le protocole de chiffrement symétrique CBC-DES. Ce protocole est le premier protocole de confidentialité défini pour le modèle de sécurité basé sur l'utilisateur.

Ce protocole est identifié par usmDESPrivProtocol.

Au fil du temps, d'autres protocoles de confidentialité peuvent être définis soit en remplacement de ce protocole, soit en complément de celui-ci.

8.1. Mechanisms (Mécanismes)​

Le protocole de chiffrement CBC-DES fournit les mécanismes suivants:

Data Confidentiality Support (Support de confidentialité des données)​

Pour prendre en charge la confidentialité des données, un algorithme de chiffrement est requis. Une portion appropriée du message est chiffrée avant d'être transmise. Le modèle de sécurité basé sur l'utilisateur spécifie que le scopedPDU est la portion du message qui doit être chiffrée.

Secret Value and Timeliness (Valeur secrète et actualité)​

Une valeur secrète en combinaison avec une valeur d'actualité est utilisée pour créer la clé de chiffrement/déchiffrement et le vecteur d'initialisation. La valeur secrète est partagée par tous les moteurs SNMP autorisés à générer des messages au nom de l'utilisateur approprié.

8.1.1. Symmetric Encryption Protocol (Protocole de chiffrement symétrique)​

Le protocole de chiffrement symétrique défini dans ce mémo fournit un support pour la confidentialité des données. La portion désignée d'un message SNMP est chiffrée et incluse dans le message envoyé au destinataire.

Deux organisations ont publié des spécifications définissant le DES:

  • Le National Institute of Standards and Technology (NIST) DES-NIST
  • L'American National Standards Institute (ANSI) DES-ANSI

Il existe une spécification de modes d'opération associée pour chaque définition (DESO-NIST et DESO-ANSI, respectivement).

8.1.1.1. DES key and Initialization Vector (Clé DES et vecteur d'initialisation)​

DES Key (Clé DES)​

Les 8 premiers octets du secret de 16 octets (clé de confidentialité privée) sont utilisés comme clé DES. Comme DES utilise seulement 56 bits, le bit de poids faible dans chaque octet est ignoré.

Initialization Vector (IV) (Vecteur d'initialisation)​

Le vecteur d'initialisation pour le chiffrement est obtenu en utilisant la procédure suivante:

Étape 1: Pre-IV (Pré-IV)

Les 8 derniers octets du secret de 16 octets (clé de confidentialité privée) sont utilisés comme pre-IV.

Étape 2: Salt Generation (Génération du sel)

Afin de garantir que l'IV pour deux paquets différents chiffrés par la même clé ne sont pas identiques (c'est-à-dire que l'IV ne se répète pas), nous devons "saler" le pre-IV avec quelque chose d'unique par paquet. Une chaîne de 8 octets est utilisée comme "sel".

La concaténation du snmpEngineBoots 32 bits du moteur SNMP générateur et d'un entier local 32 bits, que le moteur de chiffrement maintient, est entrée dans le "sel". L'entier 32 bits est initialisé à une valeur arbitraire au démarrage.

Étape 3: Salt Encoding (Encodage du sel)

Le snmpEngineBoots 32 bits est converti en les 4 premiers octets (octet de poids fort en premier) de notre "sel". L'entier 32 bits est ensuite converti en les 4 derniers octets (octet de poids fort en premier) de notre "sel".

Étape 4: IV Calculation (Calcul de l'IV)

Le "sel" résultant est ensuite XOR-é avec le pre-IV pour obtenir l'IV.

Étape 5: privParameters (Paramètres de confidentialité)

Le "sel" de 8 octets est ensuite placé dans le champ privParameters encodé comme un OCTET STRING. L'entier "sel" est ensuite modifié. Nous recommandons qu'il soit incrémenté de un et qu'il boucle lorsqu'il atteint la valeur maximale.

Note d'implémentation (Implementation Note):

La façon exacte dont la valeur du "sel" (et donc de l'IV) varie est une question d'implémentation, tant que des mesures sont prises pour éviter de produire un IV en double.

Le "sel" doit être placé dans le champ privParameters pour permettre à l'entité réceptrice de calculer l'IV correct et de déchiffrer le message.

8.1.1.2. Data Encryption (Chiffrement des données)​

Le processus de chiffrement des données suit ces étapes:

Étape 1: Padding (Remplissage)​

Les données à chiffrer sont traitées comme une séquence d'octets. Sa longueur doit être un multiple entier de 8 - et si ce n'est pas le cas, les données sont remplies à la fin si nécessaire. La valeur de remplissage réelle est sans importance.

Étape 2: Cipher Block Chaining Mode (Mode de chaînage de blocs de chiffrement)​

Les données sont chiffrées en mode de chaînage de blocs de chiffrement.

Étape 3: Block Processing (Traitement des blocs)​

Le texte en clair est divisé en blocs de 64 bits.

Le texte en clair de chaque bloc est XOR-é avec le texte chiffré du bloc précédent, le résultat est chiffré et la sortie du chiffrement est le texte chiffré du bloc. Cette procédure est répétée jusqu'à ce qu'il n'y ait plus de blocs de texte en clair.

Étape 4: First Block (Premier bloc)​

Pour le tout premier bloc, le vecteur d'initialisation est utilisé au lieu du texte chiffré du bloc précédent.

8.1.1.3. Data Decryption (Déchiffrement des données)​

Le processus de déchiffrement des données suit ces étapes:

Étape 1: Length Verification (Vérification de longueur)​

Avant le déchiffrement, la longueur des données chiffrées est vérifiée. Si la longueur de l'OCTET STRING à déchiffrer n'est pas un multiple entier de 8 octets, le processus de déchiffrement est arrêté et une exception appropriée est notée. Lors du déchiffrement, le remplissage est ignoré.

Étape 2: First Block Decryption (Déchiffrement du premier bloc)​

Le premier bloc de texte chiffré est déchiffré, la sortie de déchiffrement est XOR-ée avec le vecteur d'initialisation, et le résultat est le premier bloc de texte en clair.

Étape 3: Subsequent Blocks (Blocs suivants)​

Pour chaque bloc suivant, le bloc de texte chiffré est déchiffré, la sortie de déchiffrement est XOR-ée avec le bloc de texte chiffré précédent et le résultat est le bloc de texte en clair.

8.2. Elements of the DES Privacy Protocol (Éléments du protocole de confidentialité DES)​

Cette section contient les définitions requises pour réaliser le module de confidentialité défini dans cette section de ce mémo.

8.2.1. Users (Utilisateurs)​

La confidentialité utilisant ce protocole de confidentialité utilise un ensemble défini de userName. Pour tout utilisateur au nom duquel un message doit être chiffré/déchiffré sur un moteur SNMP particulier, ce moteur SNMP doit avoir connaissance de cet utilisateur. Un moteur SNMP qui souhaite communiquer avec un autre moteur SNMP doit également avoir connaissance d'un utilisateur connu de ce moteur, y compris la connaissance des attributs applicables de cet utilisateur.

Un utilisateur et ses attributs sont définis comme suit:

<userName> (Nom d'utilisateur)​

Une chaîne représentant le nom de l'utilisateur.

<privKey> (Clé de confidentialité)​

La clé secrète d'un utilisateur à utiliser lors du chiffrement/déchiffrement des messages. Elle DOIT avoir une longueur de 16 octets pour CBC-DES.

8.2.2. msgAuthoritativeEngineID (ID du moteur autoritaire)​

La valeur msgAuthoritativeEngineID contenue dans un message authentifié/chiffré spécifie le moteur SNMP autoritaire pour ce message particulier (voir la définition de SnmpEngineID dans le document d'architecture SNMP RFC 3411).

La clé de confidentialité (privée) de l'utilisateur est normalement différente sur chaque moteur SNMP autoritaire et donc le snmpEngineID est utilisé pour sélectionner la clé appropriée pour le processus de chiffrement/déchiffrement.

8.2.3. SNMP Messages Using this Privacy Protocol (Messages SNMP utilisant ce protocole de confidentialité)​

Les messages utilisant ce protocole de confidentialité transportent un champ msgPrivacyParameters dans le cadre de msgSecurityParameters.

Pour ce protocole, le champ msgPrivacyParameters est l'OCTET STRING sérialisé représentant le "sel" tel que décrit dans la section 8.1.1.1.

8.2.4. Services Provided by the DES Privacy Module (Services fournis par le module de confidentialité DES)​

Cette section décrit les entrées et sorties que le module de confidentialité DES attend et produit lorsque le module de sécurité basé sur l'utilisateur appelle le module de confidentialité DES pour des services.

8.2.4.1. Services for Encrypting an Outgoing SNMP Message (Services pour chiffrer un message SNMP sortant)​

Le protocole de confidentialité DES suppose que la sélection de privKey est effectuée par l'appelant et que l'appelant transmet la clé secrète à utiliser.

À la fin, le module de confidentialité retourne statusInformation et, si le processus de chiffrement a réussi, l'encryptedPDU.

La primitive de service abstraite est:

statusInformation =              -- succès ou échec
  encryptData(
  IN   privKey                   -- clé secrète pour le chiffrement
  IN   dataToEncrypt             -- scopedPDU à chiffrer
  OUT  encryptedData             -- scopedPDU chiffré
  OUT  privParameters            -- valeur "sel" sérialisée
       )

Paramètres (Parameters):

  • statusInformation: Une indication de la réussite du processus de chiffrement. Sinon, c'est une indication du problème.

  • privKey: La clé secrète à utiliser par l'algorithme de chiffrement. La longueur de cette clé DOIT être de 16 octets.

  • dataToEncrypt: Le scopedPDU à chiffrer.

  • encryptedData: Le scopedPDU chiffré en sortie.

  • privParameters: La valeur "sel" utilisée pour ce chiffrement, à envoyer dans msgPrivacyParameters.

8.2.4.2. Services for Decrypting an Incoming SNMP Message (Services pour déchiffrer un message SNMP entrant)​

Le protocole de confidentialité DES suppose que la sélection de privKey est effectuée par l'appelant et que l'appelant transmet la clé secrète à utiliser.

À la fin, le module de confidentialité retourne statusInformation et, si le processus de déchiffrement a réussi, le decryptedPDU.

La primitive de service abstraite est:

statusInformation =              -- succès ou échec
  decryptData(
  IN   privKey                   -- clé secrète pour le déchiffrement
  IN   privParameters            -- tel que reçu dans msgPrivacyParameters
  IN   encryptedData             -- scopedPDU chiffré
  OUT  decryptedData             -- scopedPDU déchiffré
       )

Paramètres (Parameters):

  • statusInformation: Une indication de la réussite du processus de déchiffrement. Sinon, c'est une indication du problème.

  • privKey: La clé secrète à utiliser par l'algorithme de déchiffrement. La longueur de cette clé DOIT être de 16 octets.

  • privParameters: La valeur "sel" reçue dans msgPrivacyParameters.

  • encryptedData: Le scopedPDU chiffré à déchiffrer.

  • decryptedData: Le scopedPDU déchiffré en sortie.

8.3. Elements of Procedure (Éléments de procédure)​

Cette section décrit les procédures pour le protocole de confidentialité CBC-DES.

8.3.1. Processing an Outgoing Message (Traitement d'un message sortant)​

Cette section décrit la procédure suivie par un moteur SNMP lorsqu'il génère un message avec confidentialité (chiffrement) au nom d'un utilisateur.

Étape 1: Obtenir la clé de confidentialité​

Obtenir la privKey de 16 octets pour l'utilisateur.

Étape 2: Extraire la clé DES​

Extraire les 8 premiers octets comme clé DES.

Étape 3: Obtenir le Pre-IV​

Extraire les 8 derniers octets comme pre-IV.

Étape 4: Générer le sel​

Générer une valeur de sel de 8 octets en utilisant snmpEngineBoots et un compteur local.

Étape 5: Calculer l'IV​

XOR-er le sel avec le pre-IV pour obtenir le vecteur d'initialisation.

Étape 6: Remplir les données​

Remplir le scopedPDU si nécessaire pour en faire un multiple de 8 octets.

Étape 7: Chiffrer​

Chiffrer le scopedPDU rempli en utilisant CBC-DES avec la clé DES et l'IV.

Étape 8: Définir privParameters​

Placer le sel dans le champ msgPrivacyParameters.

Étape 9: Retourner le résultat​

Retourner l'encryptedPDU et privParameters.

8.3.2. Processing an Incoming Message (Traitement d'un message entrant)​

Cette section décrit la procédure suivie par un moteur SNMP lorsqu'il traite un message avec confidentialité (chiffrement).

Étape 1: Obtenir la clé de confidentialité​

Obtenir la privKey de 16 octets pour l'utilisateur.

Étape 2: Extraire la clé DES​

Extraire les 8 premiers octets comme clé DES.

Étape 3: Obtenir le Pre-IV​

Extraire les 8 derniers octets comme pre-IV.

Étape 4: Extraire le sel​

Extraire le sel de msgPrivacyParameters.

Étape 5: Calculer l'IV​

XOR-er le sel avec le pre-IV pour obtenir le vecteur d'initialisation.

Étape 6: Vérifier la longueur​

Vérifier que la longueur des données chiffrées est un multiple de 8 octets. Sinon, retourner une erreur.

Étape 7: Déchiffrer​

Déchiffrer l'encryptedPDU en utilisant CBC-DES avec la clé DES et l'IV.

Étape 8: Supprimer le remplissage​

Supprimer tout remplissage des données déchiffrées.

Étape 9: Retourner le résultat​

Retourner le scopedPDU déchiffré.

Implementation Notes (Notes d'implémentation)​

  1. Longueur de clé (Key Length): La privKey DOIT être exactement de 16 octets pour CBC-DES

  2. Utilisation de la clé DES (DES Key Usage): Seuls les 8 premiers octets sont utilisés comme clé DES; les 8 derniers octets sont utilisés pour la génération de l'IV

  3. Unicité du sel (Salt Uniqueness): Le sel doit être unique pour chaque message afin de garantir l'unicité de l'IV

  4. Remplissage (Padding): Les implémentations doivent gérer correctement le remplissage, en garantissant que les données chiffrées sont toujours un multiple de 8 octets

  5. Gestion du compteur (Counter Management): Le compteur de sel doit être initialisé au démarrage et incrémenté pour chaque message

Security Considerations (Considérations de sécurité)​

  • Dépréciation de DES (DES Deprecation): DES est considéré comme cryptographiquement faible selon les normes modernes. La longueur de clé effective de 56 bits est vulnérable aux attaques par force brute

  • Recommandation de migration (Migration Recommendation): Les nouvelles implémentations devraient envisager d'utiliser des algorithmes de chiffrement plus forts tels que AES

  • Unicité de l'IV (IV Uniqueness): Il est essentiel que l'IV ne se répète jamais pour la même clé. Les implémentations doivent garantir une gestion appropriée du sel

  • Gestion des clés (Key Management): La privKey de 16 octets doit être gardée secrète et correctement gérée

  • Mode CBC (CBC Mode): Bien que le mode CBC fournisse la confidentialité, il ne fournit pas l'intégrité. Le protocole de confidentialité doit toujours être utilisé avec l'authentification

Dernière mise à jour le