Protocole
Jami account creation
A Jami account is defined by an RSA key pair with a key length of at least 4096 bits.
L’empreinte digitale standard x509 160 bits de la clé publique du compte est appelée RingID.
La clé publique du compte est utilisée comme objet d’un certificat x509 qui doit être valide, avoir le drapeau de l’autorité de certification défini et être autosuffisant. Ce certificat est appelé certificat de compte Jami.
Le champ UID sujet du certificat de compte doit être la forme hexadecimale de l’empreinte digitale de la clé publique.
Persistant compte
Persisting a Jami account private key and certificate is implementation defined.
Access to a saved Jami account private key must be authenticated and authorized. Authentication and authorization method to access the account private key is implementation defined.
Adding a device to a Jami account
*Voir [RFC 5280]https://tools.ietf.org/html/rfc5280)
Un appareil est défini par une paire de clés RSA d’une longueur de clé d’au moins 4096 bits.
Un certificat d’appareil** est défini comme un certificat x509 dont le sujet est une clé publique de l’appareil, signée avec une clé privée du compte. Le certificat DOIT être valide. Le champ UID de l’émetteur DOIT être la forme hexadecimale de l’empreinte digitale de la clé publique du compte.
La définition de la mise en œuvre est définie pour maintenir une clé privée et un certificat de périphérique. L’accès à une clé privée de périphérique enregistrée doit être authentifié.
Removing a device from a Jami account
Un appareil peut être « retiré » d’un compte Jami par la révocation du certificat de l’appareil. Les certificats révoqués sont ajoutés à une ou plusieurs listes de révocation de certificats (CRL) x509 standard. Les LCR pour les dispositifs révoqués doivent être valides et signées avec la clé de l’autorité de certification correspondante, qui est la clé privée du compte de Jami.
Format de transmission du compte
Le format d’archives de compte définit comment sérialiser une clé privée de compte pour transmission, par exemple pour signer un certificat de nouvel appareil.
L’archivage du compte est un objet JSON crypté avec la structure suivante:
{
"ringAccountKey": (PEM-encoded account private key string),
"ringAccountCert": (PEM-encoded account certificate string),
"ringAccountCRL": (PEM-encoded account CRL string)
}
L’objet JSON peut contenir des paires de valeurs de clés définis par l’implémentation.
L” objet JSON de chaîne est crypté à l’aide d” une clé définie comme:
salt = PIN + timestamp
key = argon2(password, salt)
Lorsque le PIN est un numéro aléatoire de 32 bits sous forme hexadecimale, « + » est la concatenation de chaîne, le timestamp est le timestamp actuel UNIX divisé par 1200 (20 minutes) et le mot de passe est un mot de passe choisi par l’utilisateur.
Le code PIN doit être montré à l’utilisateur pour être copié manuellement sur le nouveau dispositif physique avec le mot de passe.
Contacter un autre compte
Échange de descripteurs ICE contre OpenDHT
Écoute des appels entrants
Un appareil écoute pour l’appel entrant en effectuant une opération OpenDHT écoute sur
h("appel"+appareil ID)
où h est SHA1, « + » est la concatenation de chaîne et deviceID est la forme hexadecimale de l’ID du dispositif.
Les valeurs OpenDHT reçues qui ne sont pas cryptées ou qui ne sont pas correctement signées doivent être abandonnées. La valeur doit être cryptée avec la clé publique du dispositif appelé et signée avec la clé privée du dispositif d’appel conformément aux spécifications OpenDHT.
Envoi de l’offre initiale
Voir [RFC 5245]
RFC 5245 définit ICE (Establishment Interactive Connectivity), un protocole de traversée NAT.
ICE est utilisé à Jami pour établir une communication entre deux appareils.
L’appareil d’appel rassemble les candidats et crée une offre initiale conformément aux spécifications de l’ICE et commence le processus de négociation de l’ICE.
L’appelant met l’offre ICE cryptée (l’offre initiale) sur le DHT à h(« callto »+deviceID) où l’ID du dispositif est la forme hexadecimale de l’ID du dispositif appelé.
** Format de sérialisation de l’ICE**
Les messages ICE échangés entre les pairs lors d’une configuration d’appel utilisent le format suivant.
Ce protocole est un composé de valeurs msgpack, successivement emballées dans cet ordre:
un nombre entier donnant la version du protocole de format de message ICE utilisé pour le reste des données.
un ensemble de chaînes de 2 éléments de la session locale ICE ufrag et le mot de passe de la session locale ICE
un nombre entier indiquant le nombre de composants de la session ICE
une série de chaînes, des entrées numériques précédentes, où chaque chaîne décrit le candidat ICE, formatée en ligne « a= » (sans l’en-tête « a= ») décrit dans rfc5245, section 4.3
Envoyer la réponse
Lors de la réception de l’offre initiale ICE cryptée et signée (par l’intermédiaire de l’opération écouter), un appareil appelé doit effectuer des vérifications d’autorisation du appareil d’appel, identifiée comme le signataire de l’offre initiale.
Si le dispositif d’appel n’est pas autorisé ou si, pour une raison définie de mise en œuvre, le dispositif appelé refuse la demande de connexion entrante, le dispositif appelé doit ignorer l’offre initiale et peut enregistrer l’événement.
Si le dispositif appelé autorise l’appelant et souhaite accepter la connexion, il doit construire une réponse ICE, démarrer le processus de négociation ICE et envoyer la réponse ICE cryptée et signée à la même clé DHT.
Les négociations sur le DTLS
Une fois qu’un canal de communication peer-to-peer a été établi, l’appelant écoute sur lui pour les connexions DTLS entrant (agissant comme un serveur DTLS) tandis que l’appelant initie une connexion DTLS sortante (agissant comme un client DTLS).
La communication DTLS doit être conforme à la RFC6347 (1).
Les pairs ne doivent prendre en charge que les suites de cyphère PFS. L’ensemble des suites de cyphère prises en charge est défini en application mais doit inclure au moins ECDHE-AES-GCM (TODO: spécifier les suites recommandées pour prendre en charge).
Lors de la poignée de main DTLS, les deux pairs doivent fournir leur chaîne de certificats de périphérique respectif et doivent authentifier l’autre paire, en vérifiant que sa clé publique est la même utilisée lors de l’échange DHT ICE.
Appel SIP
*Voir [Important_RFC]
Une fois qu’un canal de communication peer-to-peer crypté et authentifié est disponible, le protocole SIP 2 doit être utilisé pour passer un appel et envoyer des messages. L’appelant peut envoyer une SIP INVITE dès que le canal DTLS est établi.
La mise en œuvre du PIS doit soutenir le CEI et le SRTP.
Les codecs pris en charge sont définis par la mise en œuvre, mais les clients Jami doivent prendre en charge le codec audio Opus et le codec vidéo H264.
Le SRTP doit être utilisé lors de la négociation des médias avec le SIP, en utilisant une nouvelle clé aléatoire pour chaque média et chaque négociation.
Primitives cryptographiques
Détails de mot de passe
*Voir [spécifications de l’argon2]https://github.com/P-H-C/phc-winner-argon2/blob/master/argon2-specs.pdf) *
Les mots de passe sont étendus à l’aide d’argon2i en utilisant t_cost = 16, m_cost = 2^16 (64 MiB), mono-threaded, pour générer un hash de 512 bits.
Le résultat est ensuite haché à nouveau en utilisant SHA{1, 256, 512} selon la taille de clé demandée.
Le chiffrement
Utilisation d’une clé fournie (128, 192 ou 256 bits)
Le chiffrement utilise la norme AES-GCM mise en œuvre par Nettle en utilisant un IV aléatoire pour chaque chiffrement.
Utilisation d” un mot de passe texte
Le mot de passe est étendu pour générer une clé de 256 bits et un sel aléatoire de 128 bits.
Les données d’entrée sont cryptées à l’aide de l’AES-GCM (voir ci-dessus) et le sel est ajouté au début du texte chiffré qui en résulte.
Lors d’une visite
Les données audio/vidéo sont échangées par des canaux RTP cryptés entre pairs.
Le protocole est un SRTP classique, avec les suites cryptographiques suivantes prises en charge:
Jami account force AES_CM_128_HMAC_SHA1_80
SIP peut utiliser AES_CM_128_HMAC_SHA1_80 ou AES_CM_128_HMAC_SHA1_32
La clé principale et le sel sont un numéro aléatoire, différent pour chaque appel.
Les clés sont échangées à l’aide de la méthode SDES : les clés sont écrites dans les messages SIP SDP pendant la négociation SIP INVITE. Lorsque SDES est utilisé, Ring oblige le transport sous-jacent à être sécurisé (crypté) pour ne pas divulguer ces clés. Jami prend en charge DTLS de manière native pour SIP et Ring en tient compte. L’appel ne peut être effectué si cette condition n’est pas remplie.