Vue générale technique

Concepts

Compte de Jami

  • Un compte Jami est défini par une identité cryptographique Jami basée sur un paire de clés asymétriques RSA et géré avec des certificats x.509 tels que définis par RFC 5280.

  • Jami utilise la bibliothèque de GNUTLS pour générer et gérer les clés et certificats RSA.

Certificat de Jami

  • Ceci représente l’identité d’un utilisateur Jami.

  • Généré lors de la création de compte

  • Il contient la clé publique du compte Jami.

  • L’empreinte digitale SHA-1 (160 bits) de ce certificat public est le JamiId.

  • Signataire d’un CA (d’une organisation ou autogénéré).

  • Le champ UID sujet doit être la forme hexadecimale du JamiId.

  • Le champ UID de l’émetteur doit être la forme hexadecimale de l’empreinte digitale de la clé publique de l’émetteur (CA).

  • Couple de clés RSA aléatoires d’au moins 4096 bits de long.

Certificat de l’appareil

  • C’est l’identité d’un appareil spécifique utilisé pour diriger Jami.

  • Un par appareil.

  • Random et de 4096 bits de long.

  • L’empreinte digitale SHA-1 de la clé publique devient le DeviceId.

  • Il doit être signé par la clé privée qui a créé le certificat Jami.

  • Le champ UID sujet doit être la forme hexadecimale du DispositifID.

  • Le champ UID de l’émetteur doit être la forme hexadecimale de l’empreinte digitale de la clé publique de l’émetteur (JamiId).

Utilisations

  • Le Jamilid:

    • C’est la clé DHT où la liste des appareils de compte est publiée et où tous les appareils écoutent pour synchroniser les changements de compte (c’est-à-dire ajouter ou révoquer un appareil).

  • Les clés RSA du certificat Jami sont utilisées comme clés à long terme pour signer/encrypter/déchiffrer les messages envoyés par le DHT:

    • clé privée pour signer et déchiffrer les messages entrants et les certificats de l’appareil.

    • clé publique pour crypter les messages (ce qui est fait par l’émetteur du message en utilisant la clé publique du destinataire).

  • Un dispositif peut être « enlevé » d’un compte Jami par révocation du certificat de dispositif:

    • Les certificats de dispositifs révoqués sont ajoutés à une ou plusieurs listes de révocation de certificats x509 standard (CRL).

    • Les LRC du dispositif révoqué doivent être valables et signées avec la clé CA correspondante, qui est la clé privée du compte Jami.

Conservation à long terme

  • Pourquoi stocker des données?

    • Jami doit charger des certificats et des paires de clés chaque fois que l’application est lancée.

    • Quand Jami crée un nouvel appareil, ces informations sont également nécessaires, partagées à partir d’un autre appareil fiable de manière sécurisée.

    • Toutes les plateformes ne fournissent pas un moyen sécurisé de stocker des données, Jami prend en charge ce fait en cryptant les données stockées en dehors de la mémoire (c’est-à-dire sur un système de fichiers) en utilisant un mot de passe défini par l’utilisateur lors de la création du compte.

  • Ces fichiers sont stockés sur l’appareil utilisateur (voir ci-dessous pour plus de détails):

    • une archive comprimée et cryptée contenant des données de compte privé.

    • la chaîne de certificats publics en tant que fichier CRT

    • la clé privée du dispositif.

L’archivage de Jami (export.gz)

  • Contient des données de compte privé.

  • Transmis actuellement sur le réseau DHT lorsque le dispositif est créé ou révoqué.

  • C’est un fichier JSON comprimé et crypté.

  • Le format actuel est (peut changer à tout moment):

{
  ringCaKey: <base64 serialized PEM-encoded CA private key>,
  ringAccountKey: <base64 serialized PEM-encoded Jami private key>
  ringAccountCert: <base64 serialized PEM-encoded Jami certificate (public key)>,
  ethKey: <base64 serialized of the optional 160-bits Etherium key used to register the JamiId on a public blockchain>,
  ringAccountCRL: <base64 serialized of packet list of revoked device certificates PEM-encoded>,
  ringAccountContacts: <JSON dictionary to export trusted user contacts>
}

  • Le flux de octets JSON est comprimé à l’aide de l’algorithme *gzip*.

  • Ensuite, le gzip-stream est crypté en utilisant le chiffrement symétrique AES-GCM-256 avec une clé de 256 bits.

    • Cette clé est dérivée du mot de passe fourni par l’utilisateur, d’un code PIN et d’un timestamp, en utilisant Argon2 (un étirement de mot de passe et normalisateur) comme suit:

salt = PIN + timestamp
key = argon2(password, salt)
  argon2 is the argon2i algorithm using t_cost = 16, m_cost = 2^16 (64 MiB), mono-threaded, to generate a 512-bits key and then hashed with SHA-256 to generate a 256-bits key.
  PIN is a random 32bits number in hexadecimal form.
  + is string concatenation operator.
  timestamp is the current UNIX timestamp divided by 1200 (20 minutes).
  password is a user-chosen password (given at account creation).

  • Le code PIN doit être montré à l’utilisateur pour être copié manuellement sur le nouvel appareil physique ainsi que le mot de passe pour terminer le processus de création de l’appareil.

  • NOTE: lors de l’exportation d’un fichier sur le DHT ou ailleurs, le démon met d’abord à jour l’archivage, pour écrire les derniers contacts. C’est la raison pour laquelle le mot de passe est nécessaire lors de l’exportation (il ne s’agit pas seulement d’une copie de l’archivage ailleurs)

Chaîne de certificats de dispositifs Jami (ring_device.crt)

  • Format PEM

  • Inclut le certificat de dispositif et les certificats de parent (certificat de dispositif Jami et les certificats de parent)

clé privée de l’appareil (ring_device.key)

  • Format PEM

  • pas crypté, nous laissons le système de fichiers de l’appareil protéger ce fichier

Le réseau DHT

Page dédiée [réseau distribué Jami] ((réseau « wikilink »)

Demande de contact

  • Deprecated in favor of « Conversation requests »

Conversation request

  • Max 64k (a DHT value)

  • Contains a conversation Id

  • Contains the sender URI

  • Can contains optional metadatas (avatar/profile)

Un message instantané

  • Mostly used to initiate connections with ICE candidates

  • Can transmit some SIP messages, however SIP channel is preferred

  • SIP messages can be read status, location sharing, messages notifications.

Appels sortants et entrants

  • Les adresses de contact (c.-à-d. adresses IP) de l’utilisateur sont données uniquement à des pairs:

    • Quand nous appelons un compagnon,

    • Quand un collègue de confiance appelle (appel entrant).

  • Toutes les formes combinées de la façon dont un dispositif spécifique peut être contacté sont résumées par un message ICE:

    • RFC 5245 définit ICE (Interactive Connectivity Establishment), un protocole de traversée NAT.

    • ICE est utilisé à Jami pour établir une communication entre deux appareils.

En faisant une visite

  1. Le dispositif d’appel recueille les candidats et crée une Offre initiale selon les spécifications de la CEI.

  2. Le dispositif d’appel met l’offre ICE cryptée (l’offre initiale*) sur le DHT à: h("[callto: »+DeviceID`](callto:%22+DeviceID)`)` où h est SHA1, + est la concaténation de chaîne, DeviceID est en forme hexadecimale.

  3. L’appareil d’appel attend la réponse de ses pairs, avec sa propre liste de candidats ICE.

  4. À la réception de la réponse par les pairs, l’appareil d’appel commence la négociation ICE.

  5. Si la négociation réussit, le processus se poursuit sur un établissement de session DTLS du côté client sur la prise ICE créée (voir ci-dessous).

Écoute des appels entrants

  1. Un appareil écoute les appels entrants en effectuant une opération OpenDHT d’écoute sur h("callto:"+DeviceID) où h est SHA1, + est la concaténation de chaîne et DeviceID est en forme hexadecimale.

  2. À la réception ICE Offer initial, l’appareil appelé ** doit** effectuer une validation de sécurité de la paire (voir ci-dessous).

  3. Si la validation de sécurité réussit, l’appareil appelé démarre la négociation ICE.

  4. Si la négociation réussit, le processus se poursuit sur un établissement de session DTLS côté serveur sur la prise ICE créée (voir ci-dessous).

  • Note: OpenDHT supprime les valeurs qui ne sont pas correctement cryptées ou signées, comme spécifié par le protocole OpenDHT.

Format de sérialisation ICE

  • Les messages ICE échangés entre les pairs lors d’un appel configuré utilisent le format suivant.

  • Un message ICE est une pièce de données binaires, suivant le format de données [msgpack]

<8-bits unsigned integer> giving the version of ICE message format protocol used for the rest of the data,
<C++ std::pair of string> of the ICE local session ufrag and the ICE local session password,
<8-bits unsigned integer> giving the number of components in the ICE session,
<array of string> of the previous number entries, where each string describe the ICE candidate, formated as an "a=" line (without the "a=" header) described in [rfc5245, section 4.3](https://tools.ietf.org/html/rfc5245#page-26)

  • Le protocole défini en cours est 1:

Validation de la sécurité par les pairs

  • Lorsqu’un appareil appelé reçoit l’offre initiale ICE cryptée et signée (par l’intermédiaire de l’opération écouter), il doit effectuer des vérifications d’autorisation de l’appelant, identifiée comme le signataire de l’offre initiale.

  • Les règles d’autorisation sont définies en termes d’exécution, mais une mise en œuvre typique autorise les contacts connus ou de confiance.

  • 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 par le protocole ICE, l’appelé commence une session DTLS côté serveur sur la prise ICE, tandis que l’appelant commence une session DTLS côté client de l’autre côté de la prise ICE.

  • La communication DTLS est RFC6347 conforme à l’aide de la bibliothèque gnutls.

  • Pour éviter que les certificats de pairs ne soient affichés en texte clair pour l’anonymat de l’appel, la poignée de main de session est effectuée deux fois:

  1. Une première poignée de main en mode anonyme pour créer un transport sécurisé mais anonyme.

  2. Une deuxième poignée de main en mode certificat, par rapport à la première, pour prouver l’identité des pairs.

  • Seules les suites de chiffrement PFS sont prises en charge:

    • L’ensemble des suites de chiffrement prises en charge est une mise en œuvre définie mais doit inclure au moins ECDHE-AES-GCM.

    • Les suites de chiffrement réelles (en forme de gnucles) sont:

      • Pas anonyme: SECURE192:-KX-ALL:+ANON-ECDH:+ANON-DH:+SECURE192:-VERS-TLS-ALL:+VERS-DTLS-ALL:-RSA:%SERVER_PRÉCEDENCE:%SAFE_RENEGOTION

      • étape de certification: `SECURE192:-VERS-TLS-ALL: +VERS-DTLS-ALL:-RSA:%SERVER_PRÉCEDENCE:%SAFE_RENEGOTIATION

Signalisation SIP

  • Utilisé sur la session DTLS pour signaler l’appel (vcard, négociation médiatique, accrochage, messagerie instantanée,…)

  • Une fois qu’un canal de communication peer-to-peer crypté et authentifié est disponible, le prototype SIP 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.

Présence

  • Sent on the DHT

  • DeviceAnnouncement (contains device hash + public key)

Sécurité / confidentialité

Jami fournit un parfait secret pour les appels et dans les messages texte d’appel avec différentes négociations de clés Eliptic Curve Diffie-Hellman à chaque appel. Pour les messages hors appel, un seul RSA-4096 est utilisé.

Pour plus d’informations:

  • [Voir technique] [Voir technique/technique] des concepts et des protocoles au sein de Jami