- Alors que les secure elements servent de base de confiance pour l’authentification forte, EUCLEAK est une attaque par canal auxiliaire qui extrait la clé secrète de l’implémentation ECDSA d’Infineon, démontrée sur une YubiKey 5Ci
- La vulnérabilité principale réside dans l’opération d’inverse modulaire non en temps constant de la bibliothèque cryptographique d’Infineon, qui a pourtant passé pendant 14 ans environ 80 évaluations de certification Common Criteria au plus haut niveau
- L’attaquant doit avoir un accès physique au secure element, et il faut quelques mesures électromagnétiques locales ainsi qu’un équipement coûteux, un logiciel sur mesure et des compétences techniques, mais les mesures elles-mêmes ne prennent que quelques minutes
- Le périmètre affecté comprend les YubiKey 5 Series avec un firmware antérieur à 5.7 ainsi que les microcontrôleurs de sécurité exécutant la bibliothèque cryptographique d’Infineon, y compris les TPM
- Dans FIDO, l’extraction de la clé secrète ECDSA permet la duplication de l’appareil, mais pour la défense contre le phishing, utiliser un produit affecté reste plus sûr que de ne pas en utiliser
Ce que vise l’attaque EUCLEAK
- Un secure element est un petit microcontrôleur qui génère et stocke des secrets et exécute des opérations cryptographiques, et il reçoit souvent des évaluations de sécurité Common Criteria au plus haut niveau
- Les jetons matériels FIDO sont un moyen d’authentification forte utilisé pour se connecter à des services web, et le protocole FIDO utilise ECDSA comme primitive cryptographique centrale
- La YubiKey 5 Series est un jeton matériel FIDO largement utilisé et emploie le Infineon SLE78 comme secure element
- NinjaLab a analysé l’implémentation ECDSA d’Infineon sur le Feitian A22, une plateforme ouverte JavaCard similaire basée sur l’Infineon SLE78, et a conçu une attaque réelle exploitant cette vulnérabilité par canal auxiliaire
- L’attaque a été démontrée sur une YubiKey 5Ci
- La vulnérabilité s’étend aussi à des produits plus récents, les microcontrôleurs de sécurité Infineon Optiga Trust M et Infineon Optiga TPM
- La cause de la vulnérabilité est l’inverse modulaire non en temps constant de la bibliothèque cryptographique d’Infineon Technologies, qui n’a pas été détecté pendant 14 ans et environ 80 évaluations de certification Common Criteria au plus haut niveau
- Une documentation technique détaillée est disponible ici : Download the Writeup
Produits affectés et conditions de l’attaque
- L’attaquant doit avoir un accès physique au secure element et peut extraire la clé secrète ECDSA avec quelques mesures locales par canal auxiliaire électromagnétique
- Dans le protocole FIDO, cela permet la duplication d’un appareil FIDO
- L’attaque nécessite un équipement coûteux, un logiciel sur mesure et des compétences techniques
- Les produits affectés sont les suivants
- Toutes les versions existantes des microcontrôleurs de sécurité Infineon intégrant la bibliothèque cryptographique d’Infineon
- Les versions existantes des TPM Infineon
- Toutes les YubiKey 5 Series avec un firmware antérieur à 5.7
- Ces microcontrôleurs de sécurité sont intégrés dans divers systèmes de sécurité reposant sur ECDSA, comme les passeports électroniques, les portefeuilles matériels de cryptomonnaies, les smart cards et la maison connectée, mais l’application réelle d’EUCLEAK à ces produits n’a pas encore été confirmée
- La JavaCard Feitian A22 est un ancien produit utilisé pour la recherche et n’est plus commercialisée
- Les produits actuellement vendus sur la boutique en ligne de Feitian et basés sur des microcontrôleurs de sécurité Infineon utilisent la propre bibliothèque cryptographique de Feitian et, à la connaissance de NinjaLab, ne sont pas affectés par cette recherche
Atténuation et informations officielles
- Le firmware YubiKey 5.7 est passé, lors de la mise à jour du 6 mai 2024, de la bibliothèque cryptographique d’Infineon à une nouvelle bibliothèque cryptographique de Yubico
- À la connaissance de NinjaLab, cette nouvelle bibliothèque n’est pas affectée par EUCLEAK
- Infineon dispose déjà d’un correctif pour sa bibliothèque cryptographique, mais, à la connaissance de NinjaLab, il n’a pas encore passé l’évaluation de certification Common Criteria
- La demande de CVE a été refusée, et MITRE utilise à la place CVE-2024-45678
- La demande de mise à jour de la description est en attente
- La position officielle peut être consultée dans les documents suivants
- 3 septembre 2024 : Yubico Security Advisory
- 9 septembre 2024 : communiqué de presse du BSI (German) / (Google Translated Version)
1 commentaires
Commentaires sur Hacker News
D’après l’article d’Ars Technica, l’attaquant a besoin non seulement du nom d’utilisateur et du mot de passe, mais aussi d’un accès physique à la clé ; il faut même démonter l’appareil puis le remonter pour le rendre, donc ce n’est en rien une attaque anodine
Mettre un peu de vernis à ongles sur la jointure en plastique pourrait servir de canari pour détecter une manipulation
Cela met toutefois aussi en lumière une faiblesse des jetons FIDO : il faut gérer soi-même la liste des services où ils sont enregistrés, et si le jeton est perdu ou volé, il faut le révoquer manuellement partout où il est enregistré
Selon NinjaLab, tous les microcontrôleurs sécurisés Infineon exécutant la bibliothèque cryptographique Infineon sont vulnérables à cette attaque dans toutes les versions connues à ce jour
Cela inclut les puces de passeport électronique de nombreux pays d’Europe et d’Asie ainsi que des États-Unis, de la Chine, de l’Inde et du Brésil, les enclaves sécurisées des téléphones Samsung et OnePlus, les portefeuilles matériels de cryptomonnaies comme Ledger et Trezor, les cartes SIM, les TPM des ordinateurs portables Lenovo, Dell et HP, ainsi que les puces EMV des cartes de crédit et de débit
Ainsi, si la clé est perdue, volée ou en panne, je peux rapidement extraire la liste des sites où elle doit être retirée
J’enregistre toujours 2 clés et je les conserve physiquement séparées, afin de pouvoir encore me connecter si j’en perds une
Cela ne concerne pas seulement l’accès à des actifs crypto, mais aussi des situations plus graves, comme chez des sous-traitants de la défense
Dans ces cas-là, les attaquants ont beaucoup de ressources et une forte motivation, et c’est précisément pour contrer ce type d’attaque qu’on utilise des YubiKey
Les clés continuent donc d’offrir une authentification résistante au phishing, mais il faut considérer que certaines attentes en matière de sécurité ont été déçues
Le plus agaçant, c’est qu’on ne peut pas simplement remplacer une YubiKey
Qu’on utilise des passkeys ou des clés non résidentes, il faut passer sur chaque compte pour remplacer cette clé par une nouvelle non vulnérable avant de mettre l’ancienne au rebut
Le fait qu’elle soit non résidente pose aussi problème, car je ne me souviens plus où j’ai utilisé ma YubiKey auparavant
L’article d’Ars [0] parle aussi du PIN, mais ce n’est pas une fonction propre à YubiKey : c’est une fonction FIDO
[0]: https://arstechnica.com/security/2024/09/yubikeys-are-vulner...
[1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...
Je l’ai réellement vécu lorsque la douane américaine a retenu des appareils électroniques, YubiKey comprise
J’ai ensuite pu récupérer de nombreux comptes qui acceptaient l’e-mail comme deuxième facteur ou moyen d’authentification final, mais certains, dont AWS, ne le permettaient pas
Beaucoup de sites web encouragent l’activation du 2FA sans expliquer clairement les moyens alternatifs d’authentification ni les conséquences d’une perte d’accès
J’ajoute le tag "YubiKey (FIDO)" aux comptes où une YubiKey est enregistrée
Mais l’expérience utilisateur globale de ce processus n’est toujours pas au niveau attendu
Dans mon cas, je garde aussi des TOTP stockés dans une application
Si « toutes les YubiKey 5 Series avec un firmware antérieur à 5.7 sont affectées », je pensais qu’il suffisait de mettre à jour le firmware de ce jeton matériel
Mais il est indiqué que le firmware des YubiKey n’est pas évolutif
https://support.yubico.com/hc/en-us/articles/360013708760-Yu...
Donc Yubico va sûrement proposer un remplacement gratuit ? J’en ai plusieurs comme ça…
Autrement dit, si vous avez suffisamment de valeur pour être visé physiquement dans le monde réel, vous ne devriez sans doute pas utiliser de YubiKey dès le départ
Quelqu’un pourrait remplacer votre clé de secours par une autre compromise, et vous pourriez ne pas vous en rendre compte avant qu’il ne soit trop tard
https://support.yubico.com/hc/en-us/articles/15705749884444-...
En revanche, ma YubiKey 4, sortie depuis moins de deux mois, a cessé de fonctionner comme carte à puce PIV avec attestation matérielle
Dire que c’est « à cause d’un calcul d’inverse modulaire qui n’est pas en temps constant » ne renvoie pas à un canal auxiliaire subtil comme de minuscules émissions électromagnétiques
Le fait que le temps varie selon les données secrètes est presque la première chose à vérifier lors d’un audit de canaux auxiliaires
Il suffit de vérifier que toutes les opérations utilisent toujours le même nombre de cycles d’horloge, indépendamment des données, et que les erreurs surviennent elles aussi après un nombre fixe de cycles, sans dépendre des données
Je me demande comment les auditeurs ont pu passer à côté de ça
Si j’ai bien compris l’article, ce qui n’est pas en temps constant n’est pas l’exécution de l’algorithme elle-même, mais le cycle d’activité du canal auxiliaire RF observable de l’extérieur
Si le temps d’exécution avait vraiment été non constant, l’attaque aurait au pire été possible via l’USB seul, mais l’implémentation d’Infineon ne semble pas vulnérable à une attaque purement temporelle
Le nonce blinding est bien implémenté, mais le problème est qu’il utilise un masque multiplicatif bien plus petit que la taille de la courbe elliptique, ce qui le rend attaquable par force brute
Cela dit, la sonde en elle-même est impressionnante
Si quelqu’un est prêt à obtenir un accès physique à une YubiKey, il peut tout aussi bien la remplacer par une clé d’apparence et d’usure similaires
La victime croira alors que sa YubiKey est en panne, ou bien cela donnera à l’attaquant largement le temps d’utiliser la YubiKey
Par exemple, j’ai deux YubiKey ; si quelqu’un entre discrètement chez moi et remplace la clé de secours, je ne m’en apercevrai pas avant de devoir utiliser cette clé de secours
Au final, cette attaque n’a de sens que si la cible vaut la peine d’être visée directement, et dans ce cas j’imagine qu’elle utiliserait quelque chose d’un peu plus sûr qu’une YubiKey
ykman listpermet de vérifier les informations d’identification de la YubiKey, donc on peut facilement mettre en place une procédure pour vérifier si la clé est vraiment en panne ou si elle a été remplacéeSi les exigences de sécurité sont élevées, on peut vérifier cela périodiquement ou protéger séparément l’emplacement physique de la clé de secours
Je me demande aussi quel matériel d’authentification serait plus sûr qu’une YubiKey
Un attaquant peut viser l’appareil, intercepter les communications, ou faire exécuter un mandat contre le service qui héberge les données, voire s’y infiltrer discrètement
PDF explicatif sur EUCLEAK : https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl...
Article de blog de Yubico : https://www.yubico.com/support/security-advisories/ysa-2024-...
La recherche de NinjaLab est excellente
Le point particulièrement intéressant dans l’avis de Yubico est que cette copie locale permet aussi de neutraliser l’attestation de WebAuthn [1]
Aurait-on pu concevoir le protocole pour mieux résister à ce type d’attaque par clonage local ?
« Un attaquant peut utiliser la clé d’attestation récupérée pour fabriquer une fausse YubiKey. Dans ce cas, un document d’attestation FIDO valide peut être généré pendant la création d’identifiants, ce qui permet de contourner les contrôles de préférence de modèle d’authentificateur d’une organisation pour les versions affectées de YubiKey. »
Tout le modèle de sécurité d’un élément sécurisé repose sur l’empêchement de l’extraction de la clé ; si cela devient possible, ce n’est guère mieux que de stocker la clé dans un fichier sur un ordinateur
Bien sûr, comme il faut un accès physique à l’appareil pour obtenir la clé, cela reste plus sûr qu’un stockage sur ordinateur tant que personne ne met physiquement la main sur l’appareil
Si ce secret d’attestation peut être extrait d’une manière ou d’une autre, il devient impossible d’empêcher un attaquant de fabriquer un faux authentificateur capable de produire de fausses attestations sans se comporter comme le vrai
En théorie, on pourrait réduire l’impact de la fuite d’un secret d’attestation unique via une attestation indirecte ou des clés d’attestation uniques par authentificateur
C’est l’approche utilisée à la place d’une clé d’attestation partagée par des centaines de milliers d’authentificateurs comme les YubiKey, mais cela risque malgré tout de n’être qu’une atténuation probabiliste
Le site de Yubico indique que les versions 5.7 et supérieures ne sont pas affectées
D’après un autre article de Yubico [1], l’une des nouveautés de la version 5.7 est la migration vers une bibliothèque cryptographique développée par Yubico pour les opérations cryptographiques de base RSA et ECC
J’espère que beaucoup de monde l’a examinée. À une époque où il existe autant d’implémentations publiques que privées, je ne vois pas bien pourquoi on voudrait utiliser sa propre bibliothèque cryptographique
[1] https://www.yubico.com/blog/now-available-for-purchase-yubik...
Si toute l’entreprise repose sur la cryptographie, il est en fait logique d’embaucher suffisamment de cryptographes appliqués pour garder soi-même le contrôle de son destin
Il peut aussi y avoir d’autres raisons, et dans le monde du code source fermé, les considérations économiques pèsent lourd
C’est particulièrement vrai si l’on passe d’une implémentation fournisseur précédente, propriétaire et probablement fournie avec le code source, à une implémentation interne
Infineon a encore frappé. Il y a 7 ans, il y avait déjà eu ça : https://en.wikipedia.org/wiki/ROCA_vulnerability
Il est indiqué qu’« Infineon dispose déjà d’un correctif pour la bibliothèque cryptographique, mais à ma connaissance, celui-ci n’a pas encore passé l’évaluation de certification Common Criteria », mais honnêtement, cela n’a aucune importance