Cette page décrit le format de transmission de Tink pour les clés et la sortie primitive. La documentation s'adresse aux cryptographes qui souhaitent ajouter des langues supplémentaires à Tink et aux responsables d'autres bibliothèques de cryptographie de haut niveau qui souhaitent un mode compatible avec les fils. Il n'est pas destiné à tous les publics.
Sérialisation des collections 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 de collection de clés 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 ensemble de clés sérialisé au format JSON est un proto d'ensemble de clés 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 ensemble de clés sérialisé binaire chiffré 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 composé 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 prendre en charge 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 validation.
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 un préfixe de sortie Tink de 5 octets.
AES-CTR-HMAC
Pour AES-CTR-HMAC, Tink calcule le code MAC avec les données associées (DA) comme suit:
AD || IV || ciphertext || bitlen(AD)
où bitlen(AD) est la longueur de l'AD en bits représentée sous la forme d'un entier non signé de 64 bits en big-endian. Ce schéma HMAC suit la version préliminaire d'AES-CBC-HMAC de Mcgrew.
Chiffrement 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 cinq octets.
Bien 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 d'un seul élément dans la RFC 5297. Les données associées vides sont une liste avec un élément vide, et non une liste vide.
Streaming AEAD
Consultez HMAC AES-CTR 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:
- Une nouvelle
DEKest générée à l'aide d'un modèle de clé (ou de paramètres de clé) donné. DEKest sérialisé en une chaîne d'octets. Format de sérialisation du protocole de sérialisation du type de clé proto. Par exemple, il s'agit d'un message de tampon de protocoleAesGcmKeysérialisé défini dans aes_gcm.proto pour la clé DEK de type AES GCM. Pour savoir comment sérialiser un tampon de protocole, consultez la section Sérialisation de tampon de protocole.- Le
DEKsérialisé est chiffré par un fournisseur externe (par exemple, GCP) dans unencrypted DEK. DEKpermet de chiffrer le texte brut avec les données associées enciphertext.ciphertexta donc exactement le même format que la primitive AEAD correspondant àDEK.
Le format de sortie du chiffrement encapsulé est le suivant:
encrypted DEK length || encrypted DEK || ciphertext
Le encrypted DEK length est de 4 octets et stocke la longueur du encrypted DEK en tant qu'entier 32 bits big-endian.
Mac
Tink respecte les RFC correspondantes. Les primitives peuvent ajouter un préfixe de sortie Tink de 5 octets à la balise.
Ensemble PRF
Tink respecte les RFC correspondantes. Notez que pour PRF Set, 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 de l'ensemble PRF n'ajoutent jamais de préfixe de sortie Tink. Cela garantit que la sortie est bien un PRF.
Chiffrement hybride
Le format de transmission général pour le chiffrement hybride Tink est le suivant:
prefix || encapsulated_key || encrypted_data
prefix est vide ou un préfixe de sortie Tink de cinq 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.
Chiffrement hybride à clé publique (HPKE)
Tink respecte 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 fil 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
encdans la section 4.1 de la RFC 9180 - Format déterminé par le KEM HPKE spécifique utilisé
encrypted_data- Texte chiffré et balise (c'est-à-dire,
ciphertext || tagsans l'IV) - Défini comme
ctdans la section 4 de la RFC 9180 - Format déterminé par l'AEAD HPKE spécifique utilisé
- Texte chiffré et balise (c'est-à-dire,
KEM X25519 basé sur 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 de la RFC 7748 est utilisée (coordonnées x sous forme d'entier à taille fixe).
DEM
Pour encrypted_data, Tink utilise le même format que l'AEAD. Cela inclut la spécification d'une IV.
Dérive de clé
La coordonnée X x_ss du point partagé est d'abord calculée. 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 complète du KEM sous forme d'octets.
Signatures numériques
Tink respecte les RFC correspondantes. Les primitives peuvent ajouter un préfixe de sortie Tink de cinq octets à la balise générée.
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 remplis de 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 remplis de 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 DER (les signatures BER alternatives ne sont pas valides).
Cela permet d'éviter les attaques de malléabilité de signature, qui affectent souvent les systèmes de cryptomonnaies.