Aller au contenu
T-kall

Sécurité : ce qu'elle protège et ce qu'elle ne protège pas

Dernière révision : 23 septembre 2026.

Une application qui dit « chiffrement de bout en bout » sans dire où s'arrête ce chiffrement vend une garantie qu'elle ne peut pas tenir. À commencer par ceci : la garantie complète, c'est l'application installée qui la donne ; dans le navigateur, le programme qui chiffre se télécharge de notre serveur à chaque chargement. Cette page existe pour que vous décidiez quoi raconter sur T-kall en sachant ce qu'il en est.

Ce qu'elle protège vraiment

Ce qu'elle ne protège pas (encore)

1. Le registre de clés, c'est nous qui le publions

Jusqu'en août 2026, on disait ici que le premier contact avec une nouvelle personne ne pouvait pas être vérifié, et que le régler était « un gros chantier ». Ce chantier est fait et ce qu'il apporte est raconté plus haut. Ce qui reste ouvert est plus petit, mais ce n'est pas zéro.

Ce registre n'empêche pas l'attaque : il la rend détectable. Un serveur malveillant peut publier une fausse clé ; ce qu'il ne peut plus faire, c'est le faire en secret, car cela l'oblige à publier deux versions incompatibles de la même histoire, et cela se voit. C'est le même marché qui soutient les certificats de tout le web depuis une décennie.

Et c'est notre propre serveur qui le publie. Tant que les racines du registre ne sont pas copiées dans un lieu indépendant, celui qui les vérifie et celui qui les émet sont la même maison. Détecter la contradiction continue de fonctionner entre deux personnes qui se parlent — cela ne dépend pas de nous —, mais la vérification par des tiers n'existe pas encore.

Ce qui le règle : publier les racines à l'extérieur, là où n'importe qui peut les auditer sans avoir de compte. En attendant, comparer le numéro de sécurité par un autre canal reste la vérification la plus solide qui existe, car c'est la seule qui ne repose pas sur notre infrastructure.

2. Les discussions changent de clé à chaque message ; se remettre d'un vol, pas encore

Chaque message de discussion circule avec sa propre clé, dérivée d'un nouvel accord par message (X3DH, le même premier pas qu'utilise Signal). Cela couvre une attaque précise, et il convient de dire exactement laquelle, et laquelle non :

Et ce qui reste non couvert, et qui compte tout autant :

La moitié de cette section — que chaque message porte sa clé — est faite et en usage. L'autre moitié — que la conversation se remette d'un vol — exige le cliquet allumé, et l'allumer exige d'abord la récupération de session : c'est le plus gros chantier en attente de cette page. Et aucune des deux ne touche au point 1 — le premier contact — : elles servent à protéger une conversation, non à vous prouver avec qui vous l'avez.

3. Le serveur voit tout ce qui n'est pas chiffré

Ce qui suit ne voyage pas chiffré, et le serveur le voit en entier :

Ce sont là les métadonnées, et pour beaucoup de gens elles sont plus révélatrices que le contenu : que deux personnes se parlent chaque jour à trois heures du matin en dit long sans lire un seul mot. Signal s'attaque à cela avec des techniques que nous n'avons pas encore.

4. Il n'y a pas de sauvegarde, à dessein

Les clés privées ne vivent que sur l'appareil et la sauvegarde d'Android est désactivée. Le prix, il faut le dire avant et non après : en changeant de téléphone ou en réinstallant, on perd l'historique et les clés. Il n'y a aucun moyen de le récupérer.

La bonne alternative, c'est une copie chiffrée avec une clé que vous seul détenez, comme la sauvegarde chiffrée de WhatsApp. Elle n'est pas faite.

5. L'application est un web dans un conteneur

T-kall s'exécute dans le WebView du système, ce n'est pas un client natif. La sécurité du chiffrement dépend donc de la sécurité de ce WebView, que met à jour Google et non nous. C'est atténué (pas de trafic en clair, pas de sauvegardes, avec une politique de contenus), mais c'est une surface d'attaque que Signal ou Threema n'ont pas, parce que leurs clients sont natifs.

6. Le verrouillage par empreinte protège moins qu'il n'y paraît

Le verrouillage biométrique empêche que quelqu'un qui prend votre téléphone déverrouillé ouvre l'application et lise. C'est ce qu'il fait, et c'est bien. Ce qu'il ne fait pas, c'est chiffrer quoi que ce soit : qui a accès au stockage de l'appareil (avec le root, avec un vidage forensique ou avec une faille d'Android) en tire les clés — et, depuis le 28 août 2026, le texte des messages allant jusqu'à 400 jours — sans passer par l'empreinte. C'est une porte, pas un coffre-fort.

8. Les appels de groupe, chiffrés sur votre appareil (avec une nuance)

Un appel entre deux personnes passé avec les boutons d'appel ou d'appel vidéo d'une discussion va directement d'un appareil à l'autre. Un appel de groupe a besoin d'un serveur qui rassemble et redistribue l'audio et la vidéo de tous, et par ce même serveur de salles passent aussi les rendez-vous vidéo et les réunions lancées avec « Réunion instantanée », même si vous n'y êtes que deux. Depuis la version 0.4.0, cet audio et cette vidéo sont chiffrés sur votre appareil (SFrame, avec la distribution des clés par le canal déjà chiffré) et notre serveur de salles se contente de les relayer, sans pouvoir les voir ni les entendre. Cela vaut aussi pour une réunion par lien, même si celui qui rejoint est d'une autre organisation : la clé n'est distribuée qu'entre ceux qui sont dans cette réunion.

La nuance. Un appel n'est chiffré ainsi que lorsque tous les présents utilisent une version récente. Si quelqu'un entre avec une version ancienne, cet appel redescend tout seul à un chiffrement jusqu'au serveur tant que cette personne est là — et l'application vous le dit, avec l'indicateur de la salle — pour ne laisser personne sans voir ni entendre. Tant que le parc se met à jour, cela arrivera souvent ; à mesure que tous mettront à jour, cela cessera d'arriver. Si ce que vous allez raconter ne peut pas passer par notre serveur dans ce cas, utilisez l'appel entre deux avec les boutons d'appel ou d'appel vidéo d'une discussion (celui d'appel de groupe passe par le serveur de salles).

Ce que le serveur de salles voit bel et bien, que l'appel soit chiffré ou non : qui entre (l'identifiant de son compte et son nom affiché), depuis quelle adresse IP, dans quelle salle —par son identifiant technique, pas par le nom du canal—, quand chacun entre et sort, ce que chacun publie (micro, caméra ou partage d'écran) et s'il l'a coupé, des données techniques sur la connexion (la version du logiciel d'appel et le navigateur ou le système depuis lequel il se connecte), si la version de chaque appareil sait chiffrer la salle, et les avis techniques « je n'arrive pas à te déchiffrer » que les appareils s'envoient entre eux. Et le nom de la réunion, si l'hôte lui en donne un dans « Réunion instantanée » : il est distribué par le canal de données de la salle, qui n'est pas chiffré sur l'appareil —seuls l'audio et la vidéo le sont—, de sorte que ce serveur peut le lire. Si le nom est délicat, ne le mettez pas. Le titre d'un rendez-vous vidéo ne passe pas par là : il reste chiffré. Et aucun appel n'est enregistré.

Et où il se trouve. Le serveur de salles est une autre machine, distincte de celle qui conserve les messages, souscrite chez Hostinger dans un centre de données aux États-Unis. Ce qu'il voit de chaque appel sort donc de l'Espace économique européen (Confidentialité, points 6.2 et 7).

9. Personne de l'extérieur ne l'a audité

Toute l'analyse de sécurité de T-kall, c'est nous qui l'avons faite. Signal, WhatsApp, Threema et Wire ont des audits externes publiés et des protocoles revus par le monde universitaire pendant des années. Une faille cryptographique ne se remarque pas à l'usage : l'application marche parfaitement et les messages se lisent pareil. C'est pourquoi une revue interne, aussi soigneuse soit-elle, ne remplace pas une revue externe.

Résumé

Les mêmes limites que nous tenons notées en interne, sans rien retrancher.
Limite Gravité aujourd'hui Ce qui la refermerait
Le registre de clés est publié par notre serveur : personne de l'extérieur ne l'audite Moyenne Publier les racines dans un lieu indépendant
Sans récupération après une compromission : la clé volée d'un appareil sert encore Moyenne Allumer le double cliquet, qui exige d'abord la récupération de session
Les rendez-vous ne changent pas de clé à chaque envoi (les messages, si) Moyenne Refaire le chiffrement des rendez-vous, qui aujourd'hui s'anticipe de plusieurs semaines
Qui emporte l'appareil lit ce qui est récent, et depuis le 28-08-2026 c'est le texte déjà déchiffré, pas seulement les clés (400 jours / 20 000 messages) Moyenne Un mot de passe local qui chiffre le stockage au repos, ou réduire cette limite
Métadonnées en clair Moyenne Expéditeur scellé et contacts chiffrés
Sans sauvegarde Moyenne (utilisabilité) Sauvegarde chiffrée avec la clé de l'utilisateur
Le WebView comme frontière Moyenne Client natif
La biométrie n'est pas du chiffrement Faible Clés liées au stockage sécurisé du système
Un appel de groupe avec quelqu'un en version ancienne redescend à un chiffrement jusqu'au serveur (l'application prévient) Moyenne Mettre à jour tout le parc (OTA 0.4.0) pour qu'aucun appel n'ait à redescendre ; l'avertissement apparaît déjà
Le nom que l'hôte donne à une réunion est visible par le serveur de salles, qui se trouve aux États-Unis : le canal de données de la salle n'est pas chiffré sur l'appareil Faible Chiffrer ce nom avec la clé de la salle quand tout l'appel est chiffré sur l'appareil ; en attendant, ne pas lui donner de nom délicat
Sans audit externe — En commander un

Ce que vous pouvez faire, vous

Si votre vie en dépend

Si vous êtes journaliste, militant ou toute personne ayant un adversaire capable et doté de moyens, utilisez une application avec des audits externes publiés. Signal est la recommandation honnête pour ce cas. Que, depuis août 2026, les discussions changent de clé à chaque message ne change pas cette recommandation, et le registre de clés d'août ne la change pas non plus. Et il convient de comprendre pourquoi : ce registre fait qu'une fausse clé laisse une trace, mais c'est notre propre serveur qui le publie et personne de l'extérieur ne l'audite, de sorte que la garantie continue de reposer sur nous. À cela s'ajoute que personne de l'extérieur n'a audité ce code : que l'algorithme soit le bon ne prouve pas qu'il soit bien implémenté, et cette différence est justement celle que paie un audit. Aucune de ces limites n'empêche d'utiliser T-kall ; toutes changent ce pour quoi il convient de l'utiliser.

Signaler une faille

Si vous trouvez un problème de sécurité, prévenez-nous avant de le rendre public et cela nous laisse le temps de le corriger : angel@engravitysigns.com. Écrivez « Faille de sécurité » dans l'objet.

Nous n'avons ni programme de récompenses ni accord de divulgation à vous offrir, et nous préférons le dire plutôt que de laisser entendre le contraire. Ce que nous faisons, en revanche : répondre, corriger, et vous donner le crédit que vous voulez — ou aucun, si vous le préférez ainsi.