6. Méthodes de distribution de clé de contenu
- Méthodes de distribution de clé de contenu
La section 8.5 de [RFC9052] contient une description générique des méthodes de distribution de clés de contenu. Ce document définit les identifiants et l'utilisation d'un certain nombre de méthodes de distribution de clés de contenu.
6.1. Chiffrement direct
Un algorithme de chiffrement direct est défini dans la section 8.5.1 de [RFC9052]. Des informations sur la façon de remplir la structure COSE_Recipient y sont détaillées.
6.1.1. Clé directe (Direct Key)
Cet algorithme de destinataire est le plus simple ; la clé identifiée est directement utilisée comme clé pour la couche suivante dans le message. Il n'y a pas de paramètres d'algorithme définis pour cet algorithme. La valeur de l'identifiant d'algorithme est attribuée dans le tableau 11.
Lorsque cet algorithme est utilisé, le champ "protected" DOIT être de longueur nulle. Le type de clé DOIT être "Symmetric".
+========+=======+============================================+
| Nom | Valeur| Description |
+========+=======+============================================+
| direct | -6 | Utilisation directe de la clé de |
| | | chiffrement de contenu (CEK) |
+--------+-------+--------------------------------------------+
Tableau 11 : Clé directe
6.1.2. Clé directe avec KDF (Direct Key with KDF)
Ces algorithmes de destinataire prennent un secret partagé commun entre les deux parties et appliquent la fonction HKDF (Section 5.1), en utilisant la structure de contexte définie à la Section 5.2 pour transformer le secret partagé en CEK. Le champ "protected" peut être de longueur non nulle. Soit le paramètre "salt" pour HKDF (Tableau 9), soit le paramètre "PartyU nonce" pour la structure de contexte (Tableau 10) DOIT être présent (les deux peuvent être présents si désiré). La valeur dans le paramètre "salt"/"nonce" peut être générée de manière aléatoire ou déterministe. L'exigence est qu'elle soit une valeur unique pour le secret partagé en question.
Si la valeur sel/nonce est générée de manière aléatoire, il est suggéré que la longueur de la valeur aléatoire soit la même que la sortie de la fonction de hachage sous-jacente à HKDF. Bien qu'il n'y ait aucun moyen de garantir qu'elle sera unique, il y a une forte probabilité qu'elle le soit. Si la valeur sel/nonce est générée de manière déterministe, elle peut être garantie unique, et il n'y a donc aucune exigence de longueur.
6.2. Enveloppement de clé (Key Wrap)
L'enveloppement de clé est défini dans la section 8.5.2 de [RFC9052]. Des informations sur la façon de remplir la structure COSE_Recipient y sont détaillées.
6.2.1. Enveloppement de clé AES (AES Key Wrap)
L'algorithme AES Key Wrap est défini dans [RFC3394]. Cet algorithme utilise une clé AES pour envelopper une valeur qui est un multiple de 64 bits. En tant que tel, il peut être utilisé pour envelopper une clé pour l'un des algorithmes de chiffrement de contenu définis dans ce document. L'algorithme nécessite un seul paramètre fixe, la valeur initiale. Celle-ci est fixée à la valeur spécifiée dans la section 2.2.3.1 de [RFC3394]. Il n'y a pas de paramètres de clé publique qui varient à chaque invocation. Le compartiment d'en-tête protégé DOIT être vide.
+========+=======+==========+=============================+
| Nom | Valeur| Taille | Description |
+========+=======+==========+=============================+
| A128KW | -3 | 128 | AES Key Wrap (clé 128 bits) |
+--------+-------+----------+-----------------------------+
| A192KW | -4 | 192 | AES Key Wrap (clé 192 bits) |
+--------+-------+----------+-----------------------------+
| A256KW | -5 | 256 | AES Key Wrap (clé 256 bits) |
+--------+-------+----------+-----------------------------+
Tableau 13 : Valeurs de l'algorithme AES Key Wrap
6.3. Accord de clé direct (Direct Key Agreement)
L'accord de clé direct est défini dans la section 8.5.4 de [RFC9052]. Des informations sur la façon de remplir la structure COSE_Recipient y sont détaillées.
6.3.1. ECDH direct (Direct ECDH)
Les mathématiques pour ECDH se trouvent dans [RFC6090]. Dans ce document, l'algorithme est étendu pour être utilisé avec les deux courbes définies dans [RFC7748].
ECDH est paramétré par les éléments suivants :
Curve Type/Curve: La courbe sélectionnée contrôle non seulement la taille du secret partagé, mais aussi les mathématiques pour calculer le secret partagé.
Computed Secret to Shared Secret: Une fois que le secret calculé est connu, la valeur résultante doit être convertie en une chaîne d'octets pour exécuter la KDF.
Ephemeral-Static or Static-Static: Le processus d'accord de clé peut être effectué en utilisant soit une clé statique, soit une clé éphémère pour le côté de l'expéditeur.
Key Derivation Algorithm: Le résultat d'un processus d'accord de clé ECDH ne fournit pas un secret uniformément aléatoire. En tant que tel, il doit être exécuté via une KDF afin de produire une clé utilisable.
Key Wrap Algorithm: Aucun algorithme d'enveloppement de clé n'est utilisé.
L'ensemble des algorithmes ECDH directs définis dans ce document se trouve dans le tableau 14.