Contexte du produit

Le dispositif présenté par Lenovo se décrit comme un lecteur USB doté d’une authentification par empreinte digitale et d’un chiffrement intégré. La description fournie indique que le boîtier renferme une carte micro‑SD standard, insérée dans un boîtier en plastique avec un capteur d’empreinte. Aucun composant de chiffrement matériel ou de module de sécurité dédié n’est mentionné dans les spécifications publiques.

Analyse technique du dispositif

En ouvrant le boîtier, les testeurs ont constaté la présence d’une carte micro‑SD non protégée, accessible directement via le connecteur USB. Aucun circuit supplémentaire n’est visible, ce qui suggère l’absence de puce de chiffrement dédiée (par exemple, un ASIC ou un TPM). Le capteur d’empreinte, bien que présent, ne semble pas être couplé à un algorithme de chiffrement, car aucune clé n’est générée ni stockée sur le support. Le fonctionnement se limite donc à la lecture/écriture brute sur la carte, sans transformation cryptographique des données.

lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  16G  0 disk 
└─sda1   8:1    0  16G  0 part /media/usb

Cette sortie typique d’un système Linux montre la carte reconnue comme un disque de masse ordinaire, sans indication de partition chiffrée (ex. LUKS). L’absence de messages d’erreur liés à l’authentification biométrique lors de la connexion confirme que le capteur ne bloque pas l’accès aux données.

Implications et limites de l’information disponible

Le principal problème soulevé par cette configuration est l’écart entre la promesse marketing (« USB chiffré avec empreinte ») et la réalité technique. Sans chiffrement, les données stockées restent lisibles par tout appareil capable de lire une carte SD, ce qui expose les informations sensibles à des interceptions physiques. De plus, le capteur d’empreinte, même s’il fonctionne, ne constitue pas une barrière de sécurité si aucune clé n’est dérivée de l’authentification.

Le manque de documentation détaillée empêche d’évaluer d’éventuels mécanismes logiciels qui pourraient être activés après authentification (par exemple, un driver propriétaire appliquant un chiffrement à la volée). Aucun firmware n’a été extrait, aucune version de driver n’a été identifiée, et aucune référence à un standard de chiffrement (AES‑256, ChaCha20, etc.) n’est fournie. En l’absence de ces éléments, il n’est pas possible de conclure à l’existence d’une protection logicielle cachée.

En résumé, les faits observés – une carte micro‑SD non chiffrée enfermée dans un boîtier avec capteur biométrique – indiquent que le produit ne fournit pas le niveau de protection attendu. Les utilisateurs qui recherchent un stockage réellement chiffré doivent se tourner vers des solutions explicitement certifiées, telles que les clés USB équipées de puces de chiffrement matériel conformes aux normes FIPS 140‑2.