# 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
(opens new window).
# Génération d'aléa
Selon l'environnement cible, différents générateurs d'aléa sont utilisés :
- Node.js : la fonction
crypto.randomBytes
(opens new window) fournie par le modulecrypto
; - Navigateur : si SubtleCrypto (opens new window) est disponible
window.crypto.getRandomValues
est utilisé. Pour les navigateurs très anciens (Chrome <37, Edge<12, IE<11, Firefox<34, Opera<24, Safari<7) une implémentation en pur JavaScript est fournie par node-forge (opens new window), il s'agit d'une version modifiée de Fortuna dont le seed est dérivé de la date et de paramètres d'utilisation du navigateur (mouvements de souris, etc.). - React-native : le module
react-native-get-random-values
(opens new window) fournit un seed sécurisé pour le PRNG basé sur Fortuna de node-forge (opens new window).
# Générateur de paires de clés asymétriques
Les clés utilisées sont de type RSA (voir RFC 8017 (opens new window)).
Selon l'environnement cible, différents générateurs de paires de clés asymétriques sont utilisés&bsp;:
- Node.js : la fonction
crypto.generateKeyPair
(opens new window) fournie par le modulecrypto
; - Navigateur : si SubtleCrypto (opens new window) est disponible
window.crypto.subtle.generateKey
est utilisé. Pour les navigateurs très anciens (Chrome <37, Edge<79, IE, Firefox<34, Opera<24, Safari<7) une implémentation en pur JavaScript est fournie par node-forge (opens new window), il s'agit d'une version dePRIMEINC
; - React-native : le module
react-native-rsa-native
(opens new window) qui utilise le générateur de SpongyCastle (opens new window) en version 1.56 sur Android et celui de la bibliothèque standard (opens new window) sur iOS.
# 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 :
- algorithme :
AES-256-CBC
(voir FIPS 197 (opens new window) et NIST Special Publication 800-38A §6.2 (opens new window))) ; - vecteur d'initialisation :
iv
; - clé :
encryptionKey
; - argument :
clearText
; - résultat :
cipherText
;
- algorithme :
- MAC :
- algorithme :
HMAC-SHA-256
(voir RFC 6234 §8.3 (opens new window)) ; - argument (
message_array
dans la RFC 6234) : la concaténation deiv
et decipherText
; - clé (
key
dans la RFC 6234) :authenticationKey
; - résultat :
hmac
;
- algorithme :
- retourner :
cipheredMessage
qui est la concaténation deiv
,cipherText
, ethmac
.
# 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 (opens new window)) ; - argument (
message_array
dans la RFC 6234) : la concaténation deiv
et decipherText
; - clé (
key
dans la RFC 6234) :authenticationKey
; - résultat :
hmac
;
- algorithme :
- comparaison de
hmac
avechmac2
, si égal poursuivre ; - déchiffrement :
- algorithme :
AES-256-CBC
(voir FIPS 197 (opens new window) et NIST Special Publication 800-38A §6.2 (opens new window))) ; - vecteur d'initialisation :
iv
; - argument :
cipherText
; - clé :
encryptionKey
; - résultat :
clearText
;
- algorithme :
- retourner
clearText
.
# Enveloppe
Lors de l'utilisation du SDK, cipheredMessage
est mis dans un format d'enveloppe :
- soit de fichier ;
- soit de message.
# Implémentation
L'implémentation utilisée dépend de l'environnement cible ;
- Node.js : la fonction
crypto.createCipheriv
(opens new window) pour l'AES etcrypto.createHmac
(opens new window) pour le HMAC fournies par le modulecrypto
; - Navigateur : si SubtleCrypto (opens new window) est disponible,
window.crypto.subtle.encrypt
est utilisé pour l'AES etwindow.crypto.subtle.sign
est utilisé pour le HMAC. Pour les navigateurs très anciens (Chrome <37, Edge<79, IE, Firefox<34, Opera<24, Safari<7) une implémentation en pur JavaScript est fournie par node-forge (opens new window). - React-native : une implémentation en pur JavaScript est fournie par node-forge (opens new window).
# Cryptographie asymétrique
Les clés utilisées sont de type RSA (voir RFC 8017 (opens new window)).
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 (opens new window)) surclearText
pour donnercrc32
de longueur 32 bits ; - chiffrement :
- algorithme :
RSAES-OAEP
(voir RFC 8017 §7.1.1 (opens new window)) avec les paramètres suivants :SHA1
comme fonction de hachageMGF1-SHA1
(voir RFC 8017 §B.2.1 (opens new window)) comme fonction de génération de masque- le label
L
laissé vide
- argument (noté
M
dans RFC 8017 §7.1.1 (opens new window)) : concaténation decrc32
et decleartext
- clé utilisée (notée
(n,e)
dans RFC 8017 §7.1.1 (opens new window)) : clé publique du destinataire - résultat
cipheredMessage
- algorithme :
- 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) (opens new window), même en considérant que des collisions sont possibles. Pour plus d'informations, voir What Hashes Make RSA-OAEP Secure? (opens new window).
# 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 (opens new window)) avec les paramètres suivants :SHA1
comme fonction de hachage ;MGF1-SHA1
(voir RFC 8017 §B.2.1 (opens new window)) comme fonction de génération de masque ;- le label
L
laissé vide ;
- argument (noté
C
dans RFC 8017 §7.1.2 (opens new window)) : concaténation decrc32
et decleartext
; - clé utilisée (notée
K
dans RFC 8017 §7.1.2 (opens new window)) : clé privée du destinataire ; - résultat
decipheredMessage
;
- algorithme :
- décomposer
decipheredMessage
encrc32
etclearText
; - calculer une somme de contrôle de type
CRC32
(voir POSIX.1-2017 §chksum (opens new window)) surclearText
pour donnercrc32-2
de longueur 32 bits ; - comparer
crc32
etcrc32-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 (opens new window)), utilisant à la première étape l’encodageEMSA-PSS
(voir RFC 8017 §9.1.1 (opens new window)) avec les paramètres suivants :SHA256
comme fonction de hachage ;MGF1
(voir RFC 8017 §B.2.1 (opens new window)) avecSHA256
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 (opens new window)) :textToSign
; - clé utilisée (notée
K
dans RFC 8017 §8.1.1 (opens new window)) : Clé privée du signataire ; - résultat :
signature
;
- algorithme :
- 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 (opens new window)), utilisant à la première étape l’encodageEMSA-PSS
(voir RFC 8017 §9.1.1 (opens new window)) avec les paramètres suivants :SHA256
comme fonction de hachage ;MGF1
(voir RFC 8017 §B.2.1 (opens new window)) avecSHA256
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 :
- message (noté
M
dans RFC 8017 §8.1.2 (opens new window)) :textToSign
; - signature (notée
S
dans RFC 8017 §8.1.2 (opens new window)) :signature
;
- message (noté
- clé utilisée (notée
(n,e)
dans RFC 8017 §8.1.2 (opens new window)) : Clé publique du signataire ; - résultat : booléen
signatureIsValid
indiquant si la signature est valide pour le message ;
- algorithme :
- retourner :
signatureIsValid
.
# Implémentation
L'implémentation utilisée dépend de l'environnement cible ;
- Node.js : les fonctions
crypto.privateDecrypt
(opens new window),crypto.publicEncrypt
(opens new window),crypto.sign
(opens new window) etcrypto.verify
(opens new window) fournies par le modulecrypto
; - Navigateur : si SubtleCrypto (opens new window) est disponible,
window.crypto.subtle.encrypt
,window.crypto.subtle.decrypt
,window.crypto.subtle.sign
etwindow.crypto.subtle.verify
sont utilisées. Pour les navigateurs très anciens (Chrome <37, Edge<79, IE, Firefox<34, Opera<24, Safari<7) une implémentation en pur JavaScript est fournie par node-forge (opens new window). - React-native : une implémentation en pur JavaScript est fournie par node-forge (opens new window).
# 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
(opens new window), avec les paramètres suivants :N
: 16384 ;r
: 8 ;p
: 1 ;- taille de sortie : 64 octets ;
- arguments :
passphrase
etsalt
donnés ; - résultat :
key
;
- algorithme :
- retourner :
key
.
# Implémentation
L'implémentation utilisée dépend de l'environnement cible ;
- Node.js : la fonction
crypto.scrypt
(opens new window) fournie par le modulecrypto
est utilisée ; - Navigateur : le module
scrypt-js
(opens new window) est utilisé. - React-native : le module
@seald-io/react-native-scrypt
(opens new window) est utilisé, qui lui-même utilise libscrypt (opens new window).