Chiffrement AES-256. Handshake Diffie-Hellman 2048 bits. Zéro octet en clair entre votre téléphone et nos serveurs. Voici comment.
Le protocole japap est conçu pour empêcher les tiers d'accéder aux messages en clair échangés entre le client et le serveur. Même si la sécurité d'un appareil est compromise, un intrus ne pourra pas exploiter cette ouverture pour déchiffrer les messages.
Un protocole de messagerie mobile doit tenir trois promesses en même temps : chiffrer chaque octet, tenir sur une connexion intermittente, et démarrer instantanément sur un téléphone qui vient de sortir du mode avion. Voici comment japap tient ces trois promesses.
Les algorithmes utilisés lors de l'établissement de la session sont RSA 2048 et AES-256. Une fois la session établie, tous les messages sont chiffrés en AES-256-CBC avec une clé dérivée, unique pour chaque message.
japap s'appuie exclusivement sur des algorithmes cryptographiques standards, publiés, éprouvés par vingt ans d'analyse publique. Aucune invention maison dans la crypto elle-même.
Permet à deux appareils qui ne se sont jamais parlé de dériver un secret commun sans jamais le transmettre. La clé reste dans vos appareils.
Protège la phase d'échange de clés contre toute interception. Les paramètres Diffie-Hellman transitent uniquement sous enveloppe RSA.
Chiffre chaque message avec une clé dérivée unique. Deux messages identiques produisent deux chiffrés totalement différents.
Authentifie chaque message envoyé. Une seule altération d'un octet suffit à faire rejeter la frame. Impossible à forger sans la clé.
Six termes reviennent tout au long de ce document. Voici leur définition précise.
Identifie de manière unique chaque message dans une session. Prévient les attaques par rejeu.
Les 128 derniers bits du SHA-1 du message à chiffrer (entête externe exclu). Sert à générer le jeu de clé AES.
Clé partagée entre client et serveur, créée lors de l'établissement de la session. N'est jamais transmise sur le réseau.
32 octets de clé et 16 octets de vecteur d'initialisation, utilisés pour AES-256-CBC. Dérivé à chaque message.
Ajouté avant le message chiffré. Contient l'identifiant de clé de session (8 octets) et la clé de message (16 octets).
Les 64 derniers bits du SHA-1 de la clé de session. Permet au serveur de retrouver la clé utilisée pour chiffrer un message.
Une session est créée lors de la première ouverture de l'application ou après une déconnexion. Les algorithmes utilisés sont RSA 2048 et AES-256. Avant l'établissement, certains messages transitent en clair — mais un intrus ne peut rien en faire.
Le client envoie au serveur un nonce de 128 bits généré aléatoirement. Ce nonce identifie le client durant tout l'échange. Après cette étape, il est connu des deux parties.
Le serveur renvoie : le nonce du client, son propre nonce (128 bits), un nombre pq (produit de deux premiers impairs) et une empreinte de sa clé publique RSA. La paire (nonce client, nonce serveur) identifie le couple pendant tout l'échange — un intrus ne peut pas créer de session parallèle avec les mêmes paramètres, car un nouveau nonce serveur est généré pour chaque tentative.
Le client décompose pq en facteurs premiers p et q. À ce stade, l'échange Diffie-Hellman peut commencer.
Le client génère un nouveau nonce aléatoire de 256 bits, construit un message m contenant pq, p, q, la paire de nonces et ce nouveau nonce, puis le chiffre avec la clé publique RSA du serveur selon la construction ci-dessous. Après cette étape, le nouveau nonce n'est connu que du client et du serveur.
rand complète $m_{1}$ à 255 octets.
Un intrus peut intercepter cette requête et la remplacer par la sienne, mais il devrait alors régénérer son propre nouveau nonce sans jamais pouvoir déchiffrer m₁. Comme tous les messages suivants contiennent le hash de ce nouveau nonce, les valeurs divergeront côté client et seront rejetées à la vérification. L'interception aboutit simplement à l'échec de la session côté client — rien d'exploitable.
Le serveur répond avec la paire de nonces et un message chiffré AES-256 contenant les 128 derniers bits du SHA-1 du nouveau nonce, la paire de nonces, un entier g, un nombre premier p de 2048 bits, et g_a. Le client est ainsi certain que la réponse vient bien du serveur, puisqu'elle est chiffrée avec une clé dérivée du nouveau nonce.
où $a$ est un entier de 2048 bits connu uniquement du serveur.
Le client tire b, un entier aléatoire de 2048 bits, et envoie au serveur la paire de nonces accompagnée d'un message AES-256-CBC contenant g_b.
La clé de session est calculée indépendamment des deux côtés. Les deux résultats sont mathématiquement identiques.
Cette clé de 2048 bits n'est jamais transmise sur le réseau.
Les 64 derniers bits du SHA-1 de la clé de session servent d'identifiant public, permettant au serveur de retrouver la bonne clé pour chaque message.
Fin du processus. Tous les messages peuvent désormais être échangés de manière sécurisée selon la structure décrite ci-dessous.
Chaque message échangé après l'établissement de la session est composé de trois blocs. Voici ce que voit un observateur sur le réseau — et ce qu'il ne peut pas voir.
La clé de session (2048 bits) et la clé de message (128 bits) servent à calculer le jeu de clé AES utilisé pour chiffrer un message. La clé AES et le vecteur d'initialisation ne transitent jamais sur le réseau ; chaque extrémité les recalcule à partir du même algorithme.
Les 48 octets du résultat se décomposent en 32 octets de clé AES et 16 octets de vecteur d'initialisation. Lorsque la taille des données n'est pas un multiple de 16 octets, un padding aléatoire est ajouté avant le chiffrement.
Au-delà des primitives et de leur composition, japap vous garantit trois propriétés fondamentales, vérifiables mathématiquement.
Seul le détenteur de la clé de session peut déchiffrer le contenu. Sans cette clé, AES-256 en mode CBC est considéré hors de portée de toute puissance de calcul raisonnablement accessible.
Toute modification du chiffré — même d'un seul octet — produit un message corrompu dont la clé de message ne correspond plus. La frame est rejetée avant d'atteindre la logique métier.
La clé de message ne peut être produite que par un appareil qui détient la clé de session. Le serveur sait ainsi que chaque message vient bien d'un client authentifié, sans ambiguïté possible.
Notre équipe sécurité répond à chaque question. Chercheur, intégrateur, utilisateur curieux : écrivez-nous, nous vous répondons.