Wickr

Suivre

Avril La sécurité Wickr repose sur le concept d’un serveur non fiable. En d’autres termes, nous visons à assurer la sécurité même en cas de violation du serveur « dans le pire des cas”, où un attaquant omnipotent a le contrôle total des ressources du serveur, pour inclure la possibilité de lire et de modifier le code et les données de l’application back-end et de passer inaperçu pendant un certain temps.

Des experts tiers ont continuellement vérifié notre chiffrement et notre sécurité de bout en bout depuis le début. Dans le cadre de nos promesses de sécurité des clients récemment publiées, une entreprise de sécurité indépendante de premier plan a validé que le contenu des messages n’est pas lisible sur nos composants de serveur principal. Cet article examine plus largement la question de la sécurité et du compromis entre serveurs. Il résume les éléments clés de l’architecture de sécurité de Wickr qui offrent une résilience aux compromis sur le serveur principal et discute de l’événement en termes de capacités réelles des attaquants ou d’impact réel.

Objectifs de l’attaquant

Pour comprendre ce qu’un attaquant peut faire avec un compromis sur un serveur Wickr, nous devons comprendre le rôle du serveur dans l’architecture Wickr et considérer la valeur des données contenues dans les composants et bases de données back-end. Le serveur Wickr joue un rôle clé dans la diffusion des messages en prenant en charge les communications synchrones et asynchrones. Il fournit également des services d’annuaire d’utilisateurs centralisés, des ensembles d’autorisations et une synchronisation des profils et des paramètres.

Les attaques qui tentent d’exploiter le serveur Wickr peuvent généralement être classées comme suit:

• Attaques visant la sécurité des messages, ou l’accès au contenu des messages en clair;
• Attaques visant des informations et des métadonnées, ou la collecte et l’armement d’informations sensibles sur le système ou ses utilisateurs;
• Attaques visant la disponibilité ou la destruction de données.

Nous discutons de chaque type d’attaque dans les sections qui suivent.

Sécurité des messages

En compromettant le serveur, l’attaquant accède à des messages chiffrés ainsi qu’à des pools de clés éphémères publics. Cependant, les messages sont chiffrés de bout en bout et les messages chiffrés et les clés des pools de clés sont authentifiés de bout en bout. Cela signifie que les attaquants n’ont pas la capacité de lire ou de modifier les messages cryptés lorsqu’ils traversent le serveur et qu’ils ne peuvent pas manipuler les pools de clés pour exécuter des attaques man in the middle.

Avec ces protections en place, les attaquants qui espèrent accéder au contenu des messages doivent chercher à prendre le contrôle d’une identité Wickr. Les identités Wickr sont enracinées dans des paires de clés asymétriques utilisées pour signer et vérifier numériquement les données. La confiance est établie en vérifiant la chaîne de signature d’un objet ou d’un composant cryptographique donné à l’identité racine ou à l’utilisateur (par exemple, message à l’application, application à l’utilisateur).

Pour produire une clé (ou un message) authentique, un attaquant doit effectuer l’une des opérations suivantes :

1. Obtenez le composant privé de la clé d’identité d’un utilisateur, qui pourrait être utilisé pour authentifier les applications Wickr connectées au compte.

2. Obtenez le composant privé de la clé d’identité d’une application, qui pourrait être utilisé pour produire des clés de messagerie éphémères authentiques et authentifier les messages envoyés depuis l’application.

3. Inciter un utilisateur à accepter une fausse clé d’identité pour un utilisateur cible, ce qui aurait le même effet que l’obtention de la clé d’identité existante de l’utilisateur.

Les composants privés des clés d’identité d’application sont sécurisés dans un magasin de données chiffré côté client et hors de portée d’un attaquant côté serveur. Les composants publics sont stockés sur le serveur, mais sont signés par la clé d’identité (privée) de l’utilisateur, ce qui les protège de toute altération. Inciter les utilisateurs à accepter de fausses clés d’identité relève plus d’une attaque d’ingénierie sociale que d’une attaque technique et a peu à voir avec un pied côté serveur. Par conséquent, la capacité de l’attaquant côté serveur à compromettre une source d’authenticité – et en réalité leur seule voie d’attaque technique pour affecter la sécurité des messages — se résume à leur capacité à compromettre la clé d’identité d’un utilisateur.

Pour diverses raisons liées principalement à la convivialité du système, les clés d’identité de l’utilisateur sont stockées sur le serveur Wickr et sécurisées avec un cryptage symétrique puissant. La protection de ces données est finalement une clé de 256 bits qui est un puissant dérivé cryptographique du mot de passe de l’utilisateur. Cette clé n’est jamais stockée ou envoyée au serveur, de sorte qu’un attaquant tentant de compromettre la clé d’identité d’un utilisateur devrait effectuer une attaque de devinettes de mot de passe contre la version stockée à l’aide d’un algorithme de génération de dérivées de mot de passe spécialement conçu pour rendre le processus aussi long que possible. Pour les mots de passe non triviaux, nous pourrions nous attendre à ce que ce processus prenne de nombreuses années, voire des milliers ou des millions d’années si l’utilisateur choisit simplement un mot de passe de qualité d’aussi peu que 8 caractères. Pour compromettre plusieurs comptes, l’attaquant devrait déployer le même effort encore et encore. Ce niveau de protection signifie que les attaques côté serveur contre les clés d’identité de l’utilisateur sont infaisables contre tous les comptes sauf les plus faibles. Voir le Livre Blanc de Wickr sur la Protection par mot de passe.

Informations et métadonnées

Avec le contrôle du serveur Wickr, l’attaquant a accès à toutes les informations que le service possède sur ses utilisateurs. En concevant pour cette menace, Wickr limite la quantité d’informations utilisateur que nous stockons à celles qui sont minimalement nécessaires pour fournir un service de qualité. Ce qui suit est une liste des informations de compte d’utilisateur disponibles pour les services Wickr au moment de la rédaction de cet article :

Wickr Me :

• Date de création d’un compte
• Type d’appareil (s) sur lequel ce compte a été utilisé (par exemple, iOS, Android)
• Date de la dernière utilisation
• Nombre total de messages envoyés/reçus
• Nombre d’identifiants externes (numéros de téléphone) connectés au compte (pas le numéro
• Enregistrements limités des modifications récentes apportées aux paramètres du compte (par exemple, ajout ou suppression d’un périphérique; n’inclut pas le contenu du message ni les informations de routage et de livraison)
• numéro de version de Wickr

Wickr Pro:

• Wickr Pro ID (adresse e-mail)
• Affiliation au réseau
• Numéro de téléphone, s’il est fourni par l’administrateur réseau comme deuxième forme d’authentification
• Date de création d’un compte
• Type d’appareil(s) sur lequel un compte a été utilisé
• Date de la dernière utilisation
• Nombre total de messages envoyés/reçus
• Nombre d’identifiants externes (numéros de téléphone) connectés au compte (pas les identifiants externes en clair eux-mêmes)
• Enregistrements limités des modifications récentes apportées aux paramètres du compte (par exemple, ajout ou suppression d’un périphérique; n’inclut pas le contenu des messages ni les informations de routage et de livraison)
• numéro de version de Wickr
• Informations relatives au paiement
• Paramètres réseau, y compris les enregistrements limités des modifications récentes apportées aux paramètres réseau (par exemple, activation ou désactivation de la fédération)

Wickr Enterprise (déploiement contrôlé par le client):

• Wickr Enterprise ID (handle)
• Affiliation au réseau
• Date de création d’un compte
• Type d’appareil sur lequel un compte a été utilisé
• Date de la dernière utilisation
• Nombre total de messages envoyés/reçus
• Enregistrements limités des modifications récentes apportées aux paramètres du compte (par exemple, ajout ou suppression d’un appareil ; n’inclut pas le contenu des messages ni les informations de routage et de livraison)
• Numéro de version de Wickr
• Paramètres réseau, y compris les enregistrements limités des modifications récentes apportées aux paramètres réseau (par ex., activation ou désactivation de la fédération)

Les éléments ci-dessus risqueraient donc d’être divulgués en cas de compromission du serveur. Nos directives de procédure juridique et notre politique de confidentialité contiennent des discussions plus détaillées sur la manière dont nous limitons la collecte et l’utilisation des informations des utilisateurs sur notre plateforme.

Le contrôle du serveur permet également à un attaquant de collecter des informations et des métadonnées que le service ignore. Les deux meilleurs exemples de cela dans Wickr sont les adresses IP des clients et le suivi des messages.

Wickr en tant que service se désintéresse totalement de l’adresse IP des clients Wickr. Nous ne les enregistrons pas dans les journaux d’application de configuration standard ni ne les stockons dans les enregistrements utilisateur. Ils sont cependant disponibles pour certains composants de l’infrastructure principale, et en supposant que l’attaquant contrôle le bon composant et effectue la bonne analyse du trafic et de la corrélation, ces informations seraient à risque.

Wickr se désintéresse également de qui communique avec qui sur le réseau. Nous n’enregistrons pas ces informations dans les journaux d’applications de configuration standard. Cependant, en supposant que l’attaquant investit suffisamment de temps et d’efforts dans le processus, le nombre, les heures, les types de messages envoyés et reçus, ainsi que les identifiants Wickr source et destinataire seraient menacés. Les ID Wickr en texte brut ne sont pas disponibles dans les magasins de données Wickr Me, ce type d’analyse serait donc beaucoup plus difficile (mais pas impossible) à faire dans Wickr Me.

Disponibilité

Bien que ce ne soit peut-être pas la forme d’attaque la plus intéressante que l’on puisse imaginer contre un service de messagerie sécurisé, les attaques ciblant la disponibilité des services ont des probabilités très réelles et des impacts assez évidents. Il n’y a pas beaucoup de choses à discuter sur ce sujet dans ce document, si ce n’est pour reconnaître le risque, mais un attaquant contrôlant les serveurs Wickr aurait le pouvoir de désactiver les services et de supprimer des données, que ce soit simplement pour semer le chaos ou refuser le service aux utilisateurs légitimes.

Résumé

Nous espérons que ce document a été informatif pour les clients qui souhaitent comprendre l’impact réel d’une violation du serveur Wickr. En somme, un tel événement, s’il était exploité par un adversaire capable, mettrait potentiellement en danger les éléments suivants :

1. La sécurité des futurs messages des comptes avec des mots de passe faibles.

2. La confidentialité des informations et métadonnées de compte limitées.

3. La disponibilité des services.

Choisissez des mots de passe de qualité.

Si des mots de passe de qualité sont utilisés, un compromis du serveur Wickr (connu ou inconnu) peut être considéré comme un événement à faible ou sans impact.

Envisagez un réacheminement périodique.

La création périodique d’une nouvelle paire de clés et la re-vérification avec d’autres (par exemple, annuellement, semestriellement) peuvent réduire davantage le risque qu’une attaque réussie de devinettes de mot de passe compromette la clé d’identité d’un utilisateur. Il s’agit également d’une méthode efficace pour réhabiliter un compte d’utilisateur qui, selon vous, a déjà été compromis via une devinette de mot de passe ou une compromission côté client. Les utilisateurs peuvent réactiver leur compte en complétant le flux  » Mot de passe oublié  » dans Wickr Pro et Wickr Enterprise ou en créant un nouvel identifiant dans Wickr Me.