Sécurité
Un audit dont la moitié du travail a consisté à nous contredire.
Auditer veut dire une chose simple : relire tout le code en cherchant à le casser, comme le ferait quelqu’un qui vous veut du mal. Nous l’avons fait sur l’ensemble du logiciel, en interne, avec une règle. Chaque faille supposée est confiée à une seconde analyse chargée de démontrer qu’elle n’existe pas. Ce qui résiste est corrigé, puis surveillé par un test automatique.
La méthode, étape par étape
-
Étape 1 : attaquer
Nous relisons tout le code en cherchant les failles. Chaque comportement douteux est noté, avec l’attaque qu’il rendrait possible.
-
Étape 2 : contredire
Chaque problème noté part ensuite à une seconde analyse, dont le travail est de démontrer qu’il est faux. 30 des 72 n’ont pas survécu à cette étape. C’est ce qui nous permet d’affirmer que les chiffres annoncés ici ne sont pas gonflés.
-
Étape 3 : corriger et rejouer
Sur les 118 failles confirmées, 34 sont corrigées. Chaque correctif vient avec un test qui rejoue l’attaque à chaque nouvelle version : si la faille revient un jour, la fabrication de la version s’arrête avant qu’elle n’atteigne votre appareil. Les autres ne le sont pas encore : parfois le correctif dépend de travaux plus larges, parfois il change le format des messages sur le réseau et casserait la compatibilité entre versions, ce qui se conçoit et ne s’improvise pas. Le détail faille par faille n’est pas publié à ce jour, et nous ne prétendons pas le contraire tant qu’il ne l’est pas. Écrivez-nous : nous répondons précisément sur celles qui touchent votre usage.
Ce que la dernière campagne a trouvé
Début août, deux campagnes supplémentaires ont porté sur le cœur cryptographique. Deux failles y ont été démontrées par un programme qui les exécute, et non seulement décrites.
La première est corrigée. Un défaut d’échange de clés permettait à quelqu’un ne possédant aucune clé de faire accepter une conversation. Le contrôle manquant existait déjà ailleurs dans notre code ; il manquait précisément là où passent toutes les conversations. Corrigé, avec un test qui rejoue l’attaque à chaque version.
La seconde ne l’est pas, et elle est classée critique. Deux relais complices peuvent marquer un message au départ et le reconnaître à l’arrivée, ce qui relie l’expéditeur au destinataire. Le corriger change le format des messages sur le réseau : cela se conçoit, cela ne s’improvise pas. Le réseau actuel n’ayant qu’un seul opérateur, personne ne peut l’exploiter aujourd’hui — mais elle doit être réglée avant l’arrivée de relais tenus par des tiers.
Nous l’écrivons ici parce qu’un produit de sécurité qui ne publie que ses succès n’apprend rien à personne.
Ces chiffres viennent d’un audit interne, mené par l’équipe qui écrit le logiciel et non par un cabinet extérieur indépendant. Ils ne valent donc pas certification. Ils restent vérifiables : les tests qui rejouent chaque attaque sont publiés dans le dépôt public, à côté du code qu’ils surveillent, et n’importe qui peut les lire ou les relancer. Nous ne revendiquons aucun label que nous ne détenons pas. Le jour où un organisme indépendant nous en délivre un, son nom et la date seront écrits ici.
Signaler une vulnérabilité
Si vous trouvez une faille, écrivez-nous en privé avant d’en parler publiquement. Nous corrigeons d’abord, puis la faille et son correctif sont publiés. C’est ce qu’on appelle la divulgation coordonnée. Vos messages sont lus par les ingénieurs qui écrivent le code, pas par un service client.
Contact sécurité
crypto.app.organisation@proton.meChiffrement du courriel (PGP) sur demande · une personne vous répond