Seald: documentation

Français

English

Français

English

Mécanismes cryptographiques ​

Vous trouverez ici une brève définition des mécanismes cryptographiques utilisés par Seald.

Leur implémentation utilisée dans Seald est SSCrypto.

Génération d'aléa ​

Selon l'environnement cible, différents générateurs d'aléa sont utilisés :

Générateur de paires de clés asymétriques ​

Les clés utilisées sont de type RSA (voir RFC 8017).

Selon l'environnement cible, différents générateurs de paires de clés asymétriques sont utilisés&bsp;:

Chiffrement symétrique ​

Pour chiffrer symétriquement, deux algorithmes sont utilisés pour assurer à la fois la confidentialité et l'intégrité : un algorithme de chiffrement symétrique ne garantissant que la confidentialité, et un MAC pour assurer l'intégrité.

Dimensionnement ​

Deux clés symétriques sont utilisées :

  • une clé de chiffrement de 256 bits notée encryptionKey ;
  • une clé pour le MAC de 256 bits notée authenticationKey.

Leur concaténation dans cet ordre est notée messageKey.

Durée de vie ​

Les clés sont utilisées pour une durée indéterminée pour les données qu'elles protègent.

Chiffrement ​

Le chiffrement symétrique de clearText avec une messageKey (concaténation de encryptionKey et de authenticationKey) pour obtenir cipheredMessage se fait comme suit :

  • génération d'un vecteur d'initialisation aléatoire noté iv de 128 bits ;
  • chiffrement :
  • MAC :
    • algorithme : HMAC-SHA-256 (voir RFC 6234 §8.3) ;
    • argument (message_array dans la RFC 6234) : la concaténation de iv et de cipherText ;
    • clé (key dans la RFC 6234) : authenticationKey ;
    • résultat : hmac ;
  • retourner : cipheredMessage qui est la concaténation de iv, cipherText, et hmac.

Déchiffrement ​

Le déchiffrement symétrique de cipheredMessage (concaténation de iv, cipherText, et hmac) avec une messageKey (concaténation de encryptionKey et de authenticationKey) pour obtenir clearText se fait comme suit :

  • MAC :
    • algorithme : HMAC-SHA-256 (voir RFC 6234 §8.3) ;
    • argument (message_array dans la RFC 6234) : la concaténation de iv et de cipherText ;
    • clé (key dans la RFC 6234) : authenticationKey ;
    • résultat : hmac ;
  • comparaison de hmac avec hmac2, si égal poursuivre ;
  • déchiffrement :
  • retourner clearText.

Enveloppe ​

Lors de l'utilisation du SDK, cipheredMessage est mis dans un format d'enveloppe :

Implémentation ​

L'implémentation utilisée dépend de l'environnement cible ;

Cryptographie asymétrique ​

Les clés utilisées sont de type RSA (voir RFC 8017).

Une paire de clés est réservée aux opérations de chiffrement, une autre aux opérations de signature.

Dimensionnement ​

Les clés sont générées avec un module n de 4096 bits et un exposant public e de 65537.

Durée de vie ​

Ces clés sont générées pour une durée ne pouvant excéder 157680000 secondes (5 ans), avec une durée de vie par défaut à 94608000 secondes (3 ans).

Chiffrement asymétrique ​

Le chiffrement asymétrique d'un clearText avec une clé publique notée (n,e) donnée pour obtenir cipheredMessage est effectué comme suit :

  • calculer une somme de contrôle de type CRC32 (voir POSIX.1-2017 §chksum) sur clearText pour donner crc32 de longueur 32 bits ;
  • chiffrement :
    • algorithme : RSAES-OAEP (voir RFC 8017 §7.1.1) avec les paramètres suivants :
      • SHA1 comme fonction de hachage
      • MGF1-SHA1 (voir RFC 8017 §B.2.1) comme fonction de génération de masque
      • le label L laissé vide
    • argument (noté M dans RFC 8017 §7.1.1) : concaténation de crc32 et de cleartext
    • clé utilisée (notée (n,e) dans RFC 8017 §7.1.1) : clé publique du destinataire
    • résultat cipheredMessage
  • retourner : cipheredMessage

TIP

L'utilisation de SHA-1 comme fonction de hachage dans RSAES-OAEP est robuste et conforme au RGS v2.0 (voir §B1.2.2.2), même en considérant que des collisions sont possibles. Pour plus d'informations, voir What Hashes Make RSA-OAEP Secure?.

Déchiffrement asymétrique ​

Le déchiffrement asymétrique d'un cipheredMessage avec une clé privée notée K donnée pour obtenir clearText est effectué comme suit :

  • déchiffrement :
    • algorithme : RSAES-OAEP (voir RFC 8017 §7.1.2) avec les paramètres suivants :
      • SHA1 comme fonction de hachage ;
      • MGF1-SHA1 (voir RFC 8017 §B.2.1) comme fonction de génération de masque ;
      • le label L laissé vide ;
    • argument (noté C dans RFC 8017 §7.1.2) : concaténation de crc32 et de cleartext ;
    • clé utilisée (notée K dans RFC 8017 §7.1.2) : clé privée du destinataire ;
    • résultat decipheredMessage ;
  • décomposer decipheredMessage en crc32 et clearText ;
  • calculer une somme de contrôle de type CRC32 (voir POSIX.1-2017 §chksum) sur clearText pour donner crc32-2 de longueur 32 bits ;
  • comparer crc32 et crc32-2, si égaux poursuivre ;
  • retourner : clearText.

Signature ​

La production d'une signature signature d'un textToSign à l'aide d'une clé privée notée K est effectuée comme suit :

  • signature :
    • algorithme : RSASSA-PSS (voir RFC 8017 §8.1.1), utilisant à la première étape l’encodage EMSA-PSS (voir RFC 8017 §9.1.1) avec les paramètres suivants :
      • SHA256 comme fonction de hachage ;
      • MGF1 (voir RFC 8017 §B.2.1) avec SHA256 comme fonction de hachage ;
      • sLen : la longueur maximale valant 478 bytes vu la fonction de hachage choisie et la longueur du module de la clé choisie ;
    • argument (noté M dans RFC 8017 §8.1.1) : textToSign ;
    • clé utilisée (notée K dans RFC 8017 §8.1.1) : Clé privée du signataire ;
    • résultat : signature ;
  • retourner : signature.

Vérification de signature ​

La vérification d'une signature signature d'un textToSign à l'aide d'une clé publique notée (n,e) associée à la clé privée K utilisée pour signer est effectuée comme suit :

  • vérification de signature :
    • algorithme : RSASSA-PSS (voir RFC 8017 §8.1.1), utilisant à la première étape l’encodage EMSA-PSS (voir RFC 8017 §9.1.1) avec les paramètres suivants :
      • SHA256 comme fonction de hachage ;
      • MGF1 (voir RFC 8017 §B.2.1) avec SHA256 comme fonction de hachage ;
      • sLen : la longueur maximale valant 478 octets vu la fonction de hachage choisie et la longueur choisie pour le module de la clé ;
    • arguments :
    • clé utilisée (notée (n,e) dans RFC 8017 §8.1.2) : Clé publique du signataire ;
    • résultat : booléen signatureIsValid indiquant si la signature est valide pour le message ;
  • retourner : signatureIsValid.

Implémentation ​

L'implémentation utilisée dépend de l'environnement cible ;

Dérivation de clé ​

La dérivation de clé à partir d'un passphrase et d'un salt pour obtenir key est effectuée comme suit :

  • dérivation :
    • algorithme : SCrypt, avec les paramètres suivants :
      • N : 16384 ;
      • r : 8 ;
      • p : 1 ;
      • taille de sortie : 64 octets ;
    • arguments : passphrase et salt donnés ;
    • résultat : key ;
  • retourner : key.

Implémentation ​

L'implémentation utilisée dépend de l'environnement cible ;