Format de fil Tink

Cette page décrit le format fil de Tink pour les clés et la sortie primitive. La documentation s'adresse aux cryptographes qui souhaitent ajouter des langues à Tink et aux responsables d'autres bibliothèques de chiffrement de haut niveau qui souhaitent un mode compatible avec le réseau. Il n'est pas destiné à un public général.

Sérialisation de la collection de clés

Tink utilise Google Protobuf pour sérialiser ses ensembles de clés.

  • Une collection de clés sérialisée au format binaire est un proto Keyset sérialisé défini dans tink.proto. La propriété de valeur KeyData d'une clé est un proto sérialisé du type de clé correspondant.
  • Un keyset sérialisé JSON est un proto Keyset sérialisé au format JSON. Notez que la valeur KeyData est toujours un proto sérialisé binaire.
  • Une collection de clés chiffrée est un proto EncryptedKeyset sérialisé défini dans tink.proto. Il contient un keyset sérialisé binaire chiffré et, éventuellement, des métadonnées KeysetInfo non chiffrées.

Préfixe de sortie Tink

La plupart des primitives Tink sont compatibles avec un préfixe de sortie de 5 octets, qui se compose des éléments suivants :

  • Version à 1 octet : 0x01
  • Indice de clé de 4 octets : il s'agit de l'ID de la clé utilisée.

Certaines anciennes clés peuvent également être compatibles avec l'octet de version 0x00.

La primitive Prehash utilise l'octet de version 0xff. Pour en savoir plus, consultez Valeurs de préhash ML-DSA Mu externes.

Notez que ces préfixes ne sont pas authentifiés et ne peuvent pas être utilisés à des fins de sécurité. Tink les utilise comme indice pour accélérer le déchiffrement ou la validation, ou pour choisir la clé de signature dans un scénario de préhachage de signature.

AEAD

En général, Tink met en forme les textes chiffrés AEAD comme suit :

prefix || IV || ciphertext || tag

sauf indication contraire dans la RFC correspondante. prefix est vide ou correspond à un préfixe de sortie Tink de 5 octets.

AES-CTR-HMAC

Pour AES-CTR-HMAC, Tink calcule le MAC avec les données associées (DA) comme suit :

AD || IV || ciphertext || bitlen(AD)

où bitlen(AD) correspond à la longueur de l'annonce en bits, représentée sous la forme d'un entier non signé de 64 bits en big-endian. Ce schéma HMAC suit le brouillon pour AES-CBC-HMAC de Mcgrew.

AEAD déterministe

Tink implémente la RFC 5297 pour AES-SIV, en plaçant le vecteur d'initialisation synthétique (SIV) au début du texte chiffré. La primitive peut ajouter un préfixe de sortie Tink de 5 octets.

Alors que la norme RFC 5297 accepte une liste de données associées, Tink n'en accepte qu'une seule, ce qui correspond à une liste avec un seul élément dans la norme RFC 5297. Des données associées vides correspondent à une liste comportant un élément vide, et non à une liste vide.

Streaming AEAD

Consultez AES-CTR HMAC et AES-GCM-HKDF.

Chiffrement encapsulé

Le chiffrement encapsulé chiffre les données avec une clé de chiffrement des données DEK à l'aide des primitives AEAD de Tink. Le chiffrement fonctionne comme suit :

  • Un DEK est généré à l'aide d'un modèle de clé (ou de paramètres de clé) donné.
  • DEK est sérialisé en chaîne d'octets. Format de sérialisation de la sérialisation du tampon de protocole du type de clé. Par exemple, il s'agit d'un message de tampon de protocole AesGcmKey sérialisé défini dans aes_gcm.proto pour la clé de chiffrement des données (DEK) de type AES GCM. Pour savoir comment sérialiser un tampon de protocole, consultez Sérialisation de tampon de protocole.
  • Le DEK sérialisé est chiffré par un fournisseur externe (par exemple, GCP) dans un encrypted DEK.
  • Le DEK est utilisé pour chiffrer le texte brut avec les données associées dans ciphertext. Par conséquent, ciphertext a exactement le même format que la primitive AEAD correspondant à DEK.

Le format de sortie du chiffrement d'enveloppe est le suivant :

encrypted DEK length || encrypted DEK || ciphertext

encrypted DEK length correspond à 4 octets et stocke la longueur de encrypted DEK sous la forme d'un entier big-endian de 32 bits.

Mac

Tink suit les RFC correspondantes. Les primitives peuvent ajouter un préfixe de sortie Tink de 5 octets au tag.

Ensemble de PRF

Tink suit les RFC correspondantes. Notez que pour le PRF, le type de clé diffère du type de clé MAC du même algorithme en n'incluant pas la longueur de sortie. Les clés d'ensemble PRF n'ajoutent jamais de préfixe de sortie Tink. Cela permet de s'assurer que le résultat est bien une fonction pseudo-aléatoire.

Chiffrement hybride

Le format filaire général pour le chiffrement hybride Tink est le suivant :

prefix || encapsulated_key || encrypted_data

prefix est vide ou correspond à un préfixe de sortie Tink de 5 octets. Chaque type de clé contient des informations sur le nombre d'octets à analyser et sur la façon de les analyser à partir de encapsulated_key.

HPKE (Hybrid Public Key Encryption)

Tink suit la norme HPKE définie dans la RFC 9180. Une suite de chiffrement HPKE inclut les trois primitives suivantes.

  • Mécanisme d'encapsulation de clé (KEM)
  • Fonction de dérivation de clé (KDF)
  • Chiffrement authentifié avec données associées (AEAD)

La norme HPKE ne définit pas de format de transmission général dans la section 10 de la RFC 9180. L'implémentation HPKE de Tink utilise les valeurs encapsulated_key et encrypted_data suivantes.

  • encapsulated_key
    • Clé publique sérialisée de l'expéditeur
    • Défini comme enc dans la section 4.1 de la RFC 9180
    • Format déterminé par le KEM HPKE spécifique utilisé
  • encrypted_data
    • Texte chiffré et tag (c'est-à-dire ciphertext || tag sans IV)
    • Défini comme ct dans la section 4 de la RFC 9180
    • Format déterminé par l'AEAD HPKE spécifique utilisé
KEM basé sur X25519 Diffie-Hellman

Pour les DHKEM X25519, la valeur enc correspond à la clé publique Diffie-Hellman de 32 octets de l'expéditeur.

ECIES-AEAD-HKDF

Pour l'implémentation ECIES-AEAD-HKDF de Tink, encapsulated_key est la sortie du mécanisme d'encapsulation de clé (KEM) et encrypted_data est la sortie du mécanisme d'encapsulation de données (DEM).

KEM

Selon le type de clé, Tink utilise des points de courbe elliptique compressés et non compressés, conformément aux normes d'encodage RFC 8422/ANSI.X9-62.2005. Pour les points non compressés, l'octet 0x04 est suivi des coordonnées x et y sous forme d'entiers de taille fixe. Pour les coordonnées compressées, l'octet 0x02 ou 0x03 et la coordonnée x en tant qu'entier de taille fixe sont utilisés. Pour X25519, la définition RFC 7748 est utilisée (coordonnée x en tant qu'entier de taille fixe).

DEM

Pour encrypted_data, Tink utilise le même format que l'AEAD. Cela inclut la spécification d'un vecteur d'initialisation.

Dérivation de clés

La coordonnée X x_ss du point partagé est calculée en premier. La clé de l'AEAD est ensuite définie sur :

HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)

où encapsulated_key correspond à la sortie KEM complète en octets.

Signatures numériques

Tink suit les RFC correspondantes. Les primitives peuvent ajouter un préfixe de sortie Tink de cinq octets au tag généré.

ECDSA

Selon le champ EcdsaSignatureEncoding de la clé, le format d'une signature ECDSA est IEEE P1363 ou ASN.1 DER.

Le format de la signature IEEE P1363 est r || s, où r et s sont complétés par des zéros et ont la même taille en octets que l'ordre de la courbe. Par exemple, pour la courbe NIST P-256, r et s sont complétés par des zéros pour atteindre 32 octets.

La signature DER est encodée à l'aide de ASN.1 :

ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }

En particulier, l'encodage est le suivant :

0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s

Tink suit les bonnes pratiques de validation des signatures en n'acceptant que les signatures ECDSA encodées au format DER (les signatures encodées au format BER ne sont pas valides).

Cela permet d'éviter les attaques de malléabilité de signature, qui affectent souvent les systèmes de crypto-monnaie.

Valeurs de préhachage ML-DSA Mu externe

La primitive Prehash transforme un message en valeur prehash, que la primitive SignPrehash signe ensuite. Pour ML-DSA en mode External Mu, comme décrit dans la RFC 9881, la valeur de préhash est de 69 octets avec la mise en page suivante :

0xff || key_id (4 bytes, big-endian) || mu (64 bytes)
  • mu est le représentant du message ML-DSA, calculé comme SHAKE256(tr || 0x00 || 0x00 || message, 64), où tr est le hachage de 64 octets de la clé publique, le premier 0x00 est le séparateur de domaine FIPS 204 pour le ML-DSA pur et le second 0x00 est la longueur de la chaîne de contexte (vide). Étant donné que tr est dérivé de la clé publique, mu est lié de manière cryptographique à cette clé. Toutefois, la vérification de la liaison nécessite le message d'origine.
  • Le préfixe de cinq octets est un encadrement Tink, et ne fait pas partie de mu. Il associe la valeur préhachée à une clé spécifique, afin que SignPrehash sache avec quelle clé signer et puisse rejeter une valeur préhachée pour laquelle il n'a pas de clé. Le préfixe est une simple métadonnée et ne lie rien de manière cryptographique : n'importe qui peut le réécrire.

La signature rejette toute entrée qui ne fait pas exactement 69 octets, qui ne commence pas par 0xff ou dont l'ID de clé ne correspond pas à une clé activée dans son ensemble de clés.