Cas 04 — SKRED Messenger

Une clé pour
tous les appareils.

SKRED est une application de messagerie à code source ouvert dotée d’un chiffrement de bout en bout. En examinant son code de gestion des clés, j’ai trouvé une clé de secours identique sur tous les appareils. Je l’ai signalée par l’intermédiaire du BSI CERT-Bund. L’éditeur a réagi comme on peut l’espérer : avec transparence, des explications techniques précises et un correctif rapide.

Par Abbas Hoseiny· Coordination via BSI CERT-Bund & CERT/CC· Éditeur : SKRED SAS / Twinlife

Toute faille n’est pas un drame, et un cas intéressant ne repose pas nécessairement sur une découverte spectaculaire. Celui-ci raconte une erreur précise dans une application de messagerie à code source ouvert et, surtout, une réponse qui montre comment la divulgation coordonnée devrait se dérouler.

Une même clé pour plusieurs téléphones identiques la même clé sur tous les appareils
Fig. 1 — une clé pour tous

SKRED chiffre certains paramètres sensibles stockés sur l’appareil. En temps normal, l’application crée une clé propre à chaque téléphone dans son espace sécurisé (Android Keystore). Si cette opération échouait — un problème connu sur certains anciens appareils —, une clé de secours inscrite dans le code prenait le relais. Cette clé était la même sur toutes les installations.

Pourquoi elle existait. L’objectif était légitime : protéger quand même les données si le Keystore de l’appareil échouait. Mais la clé de secours n’était pas propre à chaque appareil. Elle était calculée de manière déterministe à partir de deux valeurs intégrées au code ; elle était donc identique partout et pouvait être reconstituée à partir des sources publiques.

Sa portée, sans exagération. Il s’agissait d’une voie de secours, non du mécanisme normal de chiffrement. Elle concernait des paramètres stockés localement, pas le contenu des messages de tous les utilisateurs. Son exploitation exigeait l’accès à l’appareil lui-même ; il ne s’agissait pas d’une attaque à distance. La gravité se limite à ce scénario local : une faille réelle, mais clairement circonscrite.

La clé de secours est conservée uniquement pour lire les anciennes données désormais : arrêt en cas d’échec la clé de secours ne lit que les anciennes données
Fig. 2 — le correctif de l’éditeur

Dans la version actuelle, la clé de secours ne sert plus à chiffrer. Si la création de la clé dans le Keystore échoue, l’application passe en état d’erreur au lieu de poursuivre avec une clé connue. L’ancienne clé ne sert plus qu’à déchiffrer les données existantes lors de leur migration.

La réponse

Une personne répond — et corrige.

Après la transmission du rapport par le BSI, le responsable technique de l’éditeur a répondu personnellement. Pas de réponse standardisée : il a repris les points un par un, avec des explications techniques concrètes. Il a partagé de la documentation sur l’architecture, indiqué où trouver le code source et lancé les corrections sans attendre. Outre la clé de secours, il a ajouté l’épinglage de certificats qui manquait ; ces modifications sont vérifiables dans le dépôt public.

Ce que je retiens

Voilà comment cela devrait se passer.

La divulgation coordonnée ne se mesure pas au caractère spectaculaire d’une faille, mais à ce qui suit le signalement. SKRED a montré une voie constructive : code source ouvert, interlocuteur disponible, dialogue technique plutôt que réflexe défensif, puis corrections rapides et vérifiables. Le caractère ouvert des applications s’inscrit dans cette même démarche.

Rapport technique

SKRED Messenger — analyse et correction

Sommaire
  1. Résumé
  2. Constat 1 — clé de secours AES intégrée
  3. Constat 2 — absence d’épinglage de certificats
  4. Sur la gravité
  5. Coordination et divulgation

Résumé

Le code source de SKRED Messenger (SKRED SAS / Twinlife, France) est ouvert sur Android et iOS (AGPL). J’ai analysé l’application publiée et son code source. Ce rapport porte sur deux points corrigés : une clé de secours AES inscrite dans le code de gestion des clés et l’absence d’une configuration d’épinglage de certificats. Tous deux ont été signalés dans le cadre d’une divulgation coordonnée par le BSI CERT-Bund (et CERT/CC, VU#629507), puis corrigés par l’éditeur. Les changements sont vérifiables dans les sources publiques.

Constat 1 · gestion des clés

Clé de secours AES déterministe, identique sur tous les appareils

Ce qui se passait

La couche de gestion des clés (KeyChain) protège des paramètres « sécurisés » stockés localement à l’aide d’une clé provenant d’Android Keystore. Si la création de cette clé échouait — problème connu sur certains anciens appareils ou ROM —, l’application se rabattait sur une clé inscrite dans le code. Celle-ci était calculée de façon déterministe par XOR à partir de deux tableaux d’octets intégrés au code ; elle était donc identique sur toutes les installations :

// simplified from the open-source KeyChain implementation
static Key getDefaultSecretKey() {
    int n = Math.min(UUID1.length, UUID2.length);
    byte[] key = new byte[n];
    for (int i = 0; i < n; i++)
        key[i] = (byte) (UUID1[i] ^ UUID2[n - 1 - i]);
    return new SecretKeySpec(key, "AES");   // 128-bit, same on every device
}

Impact

Sur un appareil où le Keystore avait échoué, les paramètres « sécurisés » stockés localement étaient protégés par une clé connue publiquement. Toute personne disposant d’un accès local à cet appareil pouvait déchiffrer ces données. Il s’agit d’une voie de secours, non du fonctionnement normal, et l’accès requis est local et limité à l’appareil : aucune attaque à distance ni exposition du contenu des messages de tous les utilisateurs.

Correctif de l’éditeur

La clé de secours n’est plus utilisée pour chiffrer. Si la création de la clé dans le Keystore échoue, l’application passe en état d’erreur au lieu de chiffrer avec la clé connue. L’ancienne clé ne sert plus qu’à déchiffrer les données existantes lors de la migration ; la prise en charge d’Android 5.0/5.1, principale source des problèmes du Keystore, a été abandonnée. Vérifié dans les sources publiques.

Constat 2 · sécurité réseau

Absence d’épinglage de certificats

Ce qui se passait

L’application était distribuée sans configuration de sécurité réseau. Un certificat installé sur l’appareil — par exemple dans un environnement administré — aurait pu permettre d’intercepter ses connexions TLS.

Correctif de l’éditeur

L’application intègre désormais une configuration de sécurité réseau qui ne fait confiance qu’aux certificats système, interdit le trafic en clair et épingle un véritable ensemble de clés pour son propre domaine. Mise en place tôt dans le processus, cette correction a été confirmée par mes soins dans l’application publiée.

Sur la gravité

Pourquoi éviter une gravité excessive La clé de secours n’entrait en jeu qu’en cas de défaillance du Keystore et nécessitait un accès local à l’appareil ; l’absence d’épinglage exigeait qu’un certificat tiers y soit installé. Ces deux problèmes sont réels, mais leur portée est limitée, et tous deux ont été corrigés. Une note artificiellement élevée n’aiderait pas à les comprendre : l’accès est local et limité à l’appareil, sans attaque à distance.

Coordination et divulgation

Divulgation coordonnée via le BSI CERT-Bund et CERT/CC. Les corrections de l’éditeur sont vérifiables dans les sources publiques. À des fins de défense et de recherche.