Format de fil Tink

Cette page décrit le format de communication de Tink pour les clés et la sortie primitive. Cette documentation s'adresse aux cryptographes qui souhaitent ajouter des langages à Tink et aux responsables d'autres bibliothèques cryptographiques de haut niveau qui souhaitent disposer d'un mode compatible filaire. Il n'est pas destiné à tous les publics.

Sérialisation d'une collection de clés

Tink sérialise ses ensembles de clés à l'aide du protobuf Google.

  • Une collection de clés sérialisée binaire est un fichier proto Keyset sérialisé défini dans tink.proto. La propriété de valeur KeyData d'une clé est un fichier proto sérialisé du type de clé correspondant.
  • Une collection de clés sérialisée JSON est un fichier Keyset proto 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 fichier proto EncryptedKeyst sérialisé défini dans tink.proto. Il contient une collection de clés sérialisée binaire chiffrée et éventuellement des métadonnées KeysetInfo non chiffrées.

Préfixe de sortie Tink

La plupart des primitives Tink acceptent un préfixe de sortie de 5 octets constitué des éléments suivants:

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

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

Notez que ce préfixe n'est pas authentifié et ne peut pas être utilisé à des fins de sécurité. Tink l'utilise comme indice pour accélérer le déchiffrement ou la vérification.

AEAD

En général, Tink formate les textes chiffrés AEAD de la manière suivante:

prefix || IV || ciphertext || tag

sauf indication contraire dans le document RFC correspondant. 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 (AD) comme suit:

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

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

AEAD déterministe

Tink met en œuvre la norme 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 RFC 5297 accepte une liste de données associées, Tink n'accepte qu'une seule donnée associée, ce qui correspond à une liste avec un seul élément dans la RFC 5297. Une donnée associée vide est une liste contenant un élément vide et non une liste vide.

AEAD en streaming

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

Chiffrement encapsulé

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

  • Un nouveau 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é proto. Par exemple, il s'agit d'un message de tampon de protocole AesGcmKey sérialisé défini dans aes_gcm.proto pour la clé DEK de type AES GCM. Consultez la section Sérialisation du tampon de protocole pour découvrir comment sérialiser un tampon de protocole.
  • Le DEK sérialisé est chiffré par un fournisseur externe (par exemple, GCP) dans un encrypted DEK.
  • DEK permet de chiffrer le texte brut avec les données associées dans ciphertext. Ainsi, ciphertext a exactement le même format que la primitive AEAD, qui correspond à DEK.

Le format de sortie du chiffrement encapsulé est le suivant:

encrypted DEK length || encrypted DEK || ciphertext

La valeur encrypted DEK length correspond à 4 octets. Elle 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.

PRF défini

Tink suit les RFC correspondantes. Notez que pour la définition de 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éfinies par PRF n'ajoutent jamais de préfixe de sortie Tink. Cela garantit que le résultat est réellement un PRF.

Chiffrement hybride

Le format de communication 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 manière de les analyser à partir de encapsulated_key.

HPKE (Hybrid Public Key Encryption)

Tink respecte le standard HPKE défini dans le document 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 les données associées (AEAD)

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

  • encapsulated_key
  • encrypted_data
    • Texte chiffré et tag (par exemple, ciphertext || tag sans le vecteur d'initialisation)
    • Définie comme ct dans la section 4 de la norme RFC 9180
    • Format déterminé par le HPKE AEAD spécifique utilisé
KEM basé sur Diffie-Hellman X25519

Pour les DHKEM X25519, la valeur enc est 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, Key Encapsulation Mechanism) et encrypted_data, la sortie du mécanisme d'encapsulation des données (DEM).

KEM

Selon le type de clé, Tink utilise des points à 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 de x et de la coordonnée y sous la forme d'entiers de taille fixe. Pour les coordonnées compressées, l'octet 0x02 ou 0x03 et la coordonnée x (en tant que nombre entier fixe) sont utilisés. Pour X25519, la définition RFC 7748 est utilisée (coordonnée x sous la forme d'un entier de taille fixe).

DEM

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

Dérivation des clés

Tout d'abord, la coordonnée X x_ss du point partagé est calculée. La clé du chiffrement AEAD est alors définie sur:

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

où encapsulated_key est 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 5 octets au tag généré.

ECDSA

En fonction du 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 à zéro 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 jusqu'à 32 octets.

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

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

En particulier, le codage 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 DER (les autres signatures encodées BER ne sont pas valides).

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