Empreintes digitales : les capteurs Windows Hello loin d’être exemplaires

Une équipe de chercheurs de Blackwing Intelligence s’est penchée sur les trois principaux capteurs d’empreintes digitales compatibles Windows Hello utilisés sur les PC. Une recherche commanditée par Microsoft, qui souhaitait savoir si des failles de sécurité étaient présentes. Il y en a bel et bien.

À la demande de l’équipe MORSE (Microsoft’s Offensive Research and Security Engineering), les chercheurs se sont mis en chasse d’éventuelles vulnérabilités dans les lecteurs d’empreintes. Trois machines ont ainsi été visées : l’Inspiron 15 de Dell, le Thinkpad T14S de Lenovo et la Surface Pro X de Microsoft équipée du clavier détachable Pro Type Cover, lui-même contenant le fameux lecteur. Ces ordinateurs sont les plus vendus de ceux compatibles avec Windows Hello, technologie de Microsoft centralisant les méthodes de sécurité pour ouvrir la session système.

Pour comprendre ces failles, il faut d’abord rappeler le fonctionnement général de Windows Hello avec la lecture des empreintes digitales.

• Le doigt dans l’œil de la biométrie

Windows Hello et empreintes : principe de fonctionnement

Pour qu’une empreinte digitale puisse déverrouiller une session, il y a deux briques essentielles.

En premier lieu, le capteur lui-même, dit « MoC », pour Match on Chip. Par opposition aux générations précédentes qui étaient de type MoH (Match on Host), le stockage des empreintes a lieu de manière sécurisée dans la puce, de même que toutes les opérations qui leur sont liées, par l’intermédiaire de jetons. Le système d’exploitation ne peut pas y accéder et les empreintes ne partent pas se balader un peu partout. Windows Hello exige des capteurs MoC pour Enhanced Sign-in Security (ESS).

Comme le signalent les chercheurs, ces capteurs bloquent toute « redite » des empreintes. On ne peut donc pas les interroger à la chaine sur ce point. En revanche, cette technologie ne bloque pas en elle-même la présence de faux capteurs, ni la redite d’un trafic qui aurait été récupéré entre l’hôte et le capteur.

C’est là qu’intervient la deuxième brique essentielle : le Secure Device Connection Protocol (SDCP). Ce protocole de sécurité a trois missions : s’assurer que le capteur d’empreintes est de confiance, que le statut de ce capteur est sain, et protéger les entrées entre le capteur et l’hôte, via notamment l’établissement d’un canal chiffré de bout en bout.

Sans trop entrer dans les détails, l’ensemble de cette sécurité tient en bonne partie à l’EFI et aux clés de sécurité associées à ce dernier et stockées dans une zone ne pouvant pas être modifiée. Les trois machines examinées disposaient en outre toutes d’un firmware chiffré et signé cryptographiquement.

Première cible : Dell Inspiron 15

Les chercheurs ont adopté des approches différentes selon les machines, en établissant une liste de questions, auxquelles les réponses les dirigeaient vers une méthode ou une autre. Par exemple, savoir si le capteur est supporté par d’autres systèmes, Linux en tête, quel est le bus utilisé pour la communication, de quelle qualité semble être le code, etc.

Concernant l’Inspiron 15, les chercheurs ont trouvé un bon support de Linux (souvent le cas chez Dell, qui vend certaines configurations avec Ubuntu), des communications en clair entre le capteur et l’hôte via USB et, globalement, un code de qualité médiocre pour le pilote.

Au vu du contexte, les chercheurs ont adopté une approche très directe : passer par Linux et insérer dans le capteur une empreinte tierce, en lui donnant le même identifiant unique que celle de l’utilisateur authentique, stockée pendant son utilisation de Windows. Dans un premier temps, l’approche a échoué, car si le capteur a bien accepté l’empreinte en entrée, il l’a stockée dans une base de données spécifique à Linux.

Cependant, certaines commandes ne sont pas protégées, notamment celle permettant de basculer entre les bases. En récupérant le lecteur sur l’Inspiron 15 et en le branchant sur un Raspberry Pi. De là, ils ont pu intercepter les commandes qui les intéressaient.

En rebranchant le capteur sur sa machine d’origine et en relançant Windows, ils ont alors pu envoyer celle qui a permuté les deux bases. La puce a alors spontanément présenté l’empreinte correspondant à l’identifiant unique recherché et la session s’est ouverte.

Deuxième cible : Lenovo Thinkpad 14S

Sur la machine de Lenovo, le contexte était différent. Le support Linux était cette fois limité, le code de meilleure qualité, la communication entre l’hôte et le capteur était chiffrée et se faisait par USB. L’approche semblait donc plus complexe.

Après une longue rétro-ingénierie, les chercheurs se sont rendu compte de plusieurs points. D’abord, et en dépit des recommandations de Microsoft pour Windows Hello, Lenovo ne se servait pas du SDCP pour la communication sécurisée entre l’hôte et le capteur, mais d’une pile TLS personnalisée. Ensuite, et surtout, que le chiffrement est basé sur des clés, dérivées de deux informations : le nom et le numéro de la machine. Ces clés sont récupérées depuis le BIOS/EFI via ACPI. Les chercheurs pensent que cette façon de faire permet le SSO (Single Sign-On) dans Windows, donc sans nouvelle authentification.

L’équipe avait ainsi sa marche à suivre : négocier avec TLS. Pour ce faire, ils ont – dans les grandes lignes – reconstitué la clé de chiffrement à partir des informations très simples à trouver (nom et numéro de série de la machine). Après quoi, ils ont réussi à pointer à Windows l’empreinte digitale de l’un d’entre eux et la confirmer comme valide après lui avoir donné la même référence unique que celle de l’utilisateur authentique.

Troisième cible : Surface Pro X avec Pro Type Cover

Autre contexte pour ce troisième cas, puisque la tablette de Microsoft ne dispose d’aucun support Linux (ce qui n’est pas étonnant, surtout avec un modèle Arm), une qualité de code décrite comme ambiguë, et un type de communication inconnu entre l’hôte et le capteur.

On ne s’y attendait pas forcément de l’entreprise ayant commandité l’étude des chercheurs, mais c’est bien ce troisième cas qui s’est avéré le plus simple. En effet, non seulement la communication entre l’hôte et le capteur se fait en clair, mais Microsoft n’utilise même pas sa propre recommandation pour cette communication, c’’est-à-dire le protocole SDCP. Ils se sont ainsi rendu compte qu’il était relativement simple de faire passer n’importe quel capteur comme provenant du fournisseur de celui intégré dans la Surface Pro X, à savoir ELAN. La seule « sécurité » est une vérification du nombre d’empreintes stockées dans la puce du capteur, peut-être pour vérifier rapidement si la bonne Type Cover a été branchée.

La méthode a consisté à enlever la Type Cover, brancher un faux périphérique servant pour l’attaque, repérer le SID (identifiant unique) émis par le driver Windows associé, passer la vérification du nombre d’empreintes digitales, initialiser la connexion par empreinte sur le système, envoyer une réponse valide de connexion depuis le faux périphérique. Et « c’est tout ».

Quelles conclusions en tirer ?

Les chercheurs disent avoir eu besoin de trois mois pour mettre en place ces attaques. Il ne s’agissait donc pas de procédures triviales, mais elles ont abouti à 100 % de machines piratées.

Qu’en conclure ? Précisons d’abord – au risque d’enfoncer une porte ouverte – que ces attaques ne peuvent pas être pratiquées à distance, ni qu’elles peuvent être réalisées en quelques minutes, sans équipement adaptées.

Ensuite, et surtout, que le SDCP est décrit comme un bon protocole, mais qui ne couvre pas l’ensemble de la surface d’attaque permise par les capteurs d’empreintes digitales. En outre, deux des trois machines n’utilisaient même pas le SDCP, y compris la propre entreprise qui en est à l’origine et recommande sa mise en œuvre.

Les chercheurs ont deux recommandations principales pour les constructeurs : s’assurer que le SDCP est utilisé dans l’implémentation du capteur, et demander l’intervention d’une tierce partie pour réaliser un audit de sécurité sur l’ensemble. Blackwing Intelligence se tient bien sûr à disposition pour aider (moyennant finances) les constructeurs qui seraient intéressés.

Si l’occasion leur en est donnée, les chercheurs aimeraient creuser certains points, notamment la qualité du code dans les firmwares, qui leur a paru globalement faible. Les fonctions cachées sont également un problème, augmentant d’autant la surface d’attaque. Ils aimeraient aussi tester des attaques plus directes sur le matériel : si l’on peut écrire directement dans les bases de données (comme ce fut le cas avec l’Inspiron 15), alors il n’y a aucune protection.

Enfin, bien que la demande initiale émane de Microsoft, les chercheurs souhaitent se pencher sur le cas des capteurs pour d’autres plateformes : Linux, Android et Apple.