Connexion
Abonnez-vous

Passkeys : les plateformes d’Apple vont prendre en charge l’import/export sécurisé

Approuvé par Juliette Nichols

Passkeys : les plateformes d’Apple vont prendre en charge l’import/export sécurisé

Les clés d’accès, ou passkeys, sont souvent présentées comme la solution idéale pour remplacer les mots de passe. Elles ont notamment pour avantage de ne pas pouvoir être volées. Elles ont cependant un gros inconvénient : la complexité pour les transférer d’un compte à un autre. Apple a confirmé que toutes les versions 26 de ses plateformes prendront en charge cette opération.

Le 13 juin à 17h52

Les clés d’accès ont de nombreux avantages par rapport aux mots de passe traditionnels. Il n’y a pas d’information à retenir, elles sont uniques et reposent sur une architecture de clés publiques/privées. Ainsi, la première est publique et est stockée par le service sur lequel on souhaite s’identifier. L’autre est privée, n’appartient qu’à l’utilisateur et est stockée dans une zone sécurisée. Toute utilisation de la clé privée demande une authentification, biométrique par défaut.

Le gros avantage de cette infrastructure est que la clé privée ne sort jamais de son antre. Lorsque l’on veut se connecter, une autorisation d’accès est demandée. Après authentification, un jeton est émis, basé sur la clé privée. Ce jeton est alors mis en contact avec la clé publique. Si la négociation se passe bien, la connexion est autorisée. L’intégralité du mécanisme repose sur le protocole WebAuthn (Web Authentication de l’alliance FIDO, un consortium réunissant tous les principaux acteurs dans ce domaine, dont Apple, Google et Microsoft.

Le danger des silos

Comme nous l’avions indiqué en novembre 2024, les clés d’accès souffrent actuellement d’un défaut majeur. Si vous restez constamment connecté dans le même univers centré sur un fournisseur, ce n’est pas un problème. Mais si vous comptez changer, ou si vous avez un lot hétérogène d’appareils, comme c’est le cas chez beaucoup de personnes, la situation est un peu compliquée.

Les principaux éditeurs proposent tous depuis plusieurs années la compatibilité avec les clés d’accès. Ils tentent de motiver les internautes en proposant régulièrement de passer à ce mode de connexion. Cependant, pour des questions pratiques, ces clés sont synchronisées avec le compte maison. Comme nous l’avions montré, Google synchronise ainsi les clés via Chrome, qui a l’avantage d’être disponible partout. Le navigateur peut même être paramétré comme gestionnaire de mots de passes (et de clés d’accès) sur d’autres plateformes, y compris iOS.

Le problème se voit de loin : si l’on passe plusieurs années dans un environnement synchronisé par un certain compte, comment changer de crèmerie ? La question est valable autant pour les trois principaux éditeurs de systèmes d’exploitation que pour les gestionnaires tiers. Avec les mots de passe, il y a possibilité d’exportation, le plus souvent sous forme de fichier CSV ou JSON. Mais une solution équivalente pour les clés d'accès romprait leur promesse principale en sortant les clés privées de leur enclave et en les rendant vulnérables.

Cette limitation, inhérente à la première version du mécanisme, a engendré bon nombre de critiques. Certaines personnes ont ainsi estimé que les clés d’accès n’étaient qu’un moyen supplémentaire de verrouiller un peu plus les utilisateurs dans certains écosystèmes. Pourtant, rester maitre de ses clés et pouvoir les déplacer sont des conditions sine qua non de leur succès. L’alliance FIDO avait donc commencé à travailler sur une extension du standard, avec notamment un protocole et un format de données pour sécuriser les échanges.

Généralisation des échanges dans les versions 26 chez Apple

Avantage de l’alliance FIDO, elle réunit sous un même toit tous les principaux acteurs considérés comme fournisseurs d’authentification. On y trouve ainsi 1Password, BitWarden, Dashlane, Devolution ou encore Okta. Autant de noms que l’on retrouvait en mars dans le brouillon du Credential Exchange Format, la nouvelle structure de données pour les échanges de clés.

Apple, en marge de sa WWDC, a publié une vidéo pour faire le point sur les nouveautés des clés d’accès. L’entreprise rappelle que le mécanisme est en lui-même « un voyage », qui change progressivement les habitudes. « Les gens sont propriétaires de leurs informations d'identification et devraient avoir la possibilité de les gérer comme ils l'entendent. Cela permet aux gens de mieux contrôler leurs données et de choisir le gestionnaire d'informations d'identification qu'ils utilisent », explique l’entreprise.

Apple présente le nouveau mécanisme comme « fondamentalement différent et plus sûr que les méthodes traditionnelles d’exportation ». Celles-ci passent le plus souvent par l’enregistrement des informations dans un fichier non chiffré, puis son importation manuelle dans une autre application. Dans la nouvelle solution, le partage des clés est initié depuis l’application qui les gère habituellement (l’app Mots de passe, chez Apple). On sélectionne alors l’application de destination, qui aura exposé cette capacité. L’opération doit être validée par une authentification et le transfert se base sur le format de données défini par l’alliance FIDO.

« Le système fournit un mécanisme sécurisé pour déplacer les données entre les applications. Aucun fichier non sécurisé n'est créé sur le disque, ce qui élimine le risque de fuite de données d'identification à partir de fichiers exportés. Il s'agit d'un moyen moderne et sûr de transférer des informations d'identification », explique Apple dans sa vidéo.

Côté applications et sites web, aucune modification n’est nécessaire. Elles continueront à s’adresser au gestionnaire de mots de passe et clés d’accès déclaré par défaut. Du côté des développeurs qui veulent pouvoir intégrer ces capacités dans leurs gestionnaires, il faut regarder du côté de deux nouvelles classes créées pour les versions 26 des plateformes d’Apple, ASCredentialImportManager et ASCredentialExportManager.

Précisons enfin que ces annonces sont basées sur un standard en brouillon. L’extension de la norme devrait être finalisée dans les prochains mois. Au vu des participants, ces fonctions vont se retrouver prochainement dans l’ensemble des plateformes et gestionnaires.

Commentaires (10)

votre avatar
Plutôt une bonne idée, le principe d’avoir d’application d’origine qui initie le transfert. Ça évite les erreurs de ceux qui valident à vitesse maximale sans même prendre le temps de lire le message affiché (« Voulez-vous laisser l’application ChatGPT Password Lurker accéder à toute votre vie privée et la rendre publique pour la modique somme de 0,03 BTC ? »).

Bien sûr, ça demande aux applications qui veulent pouvoir importer d’implémenter une API standardisée mais je ne doute pas que la volonté sera présente (et ce n’est pas plus de boulot que de développer un plugin pour chacun des formats de sortie proposés par les 36 autres applications du même type).
votre avatar
À date d'aujourd'hui, 0,03 BTC ça fait 2732 € quand même 💰
votre avatar
L'inflation ça ne touche pas que l'alimentaire :D
votre avatar
Avec les mots de passe, il y a possibilité d’exportation, le plus souvent sous forme de fichier CSV ou JSON. Mais une solution équivalente pour les clés d'accès romprait leur promesse principale en sortant les clés privées de leur enclave et en les rendant vulnérables.
Excuse à deux balles.
Déjà, les utilisateur n'ont pas demandé que ca soit stocké dans une enclave auquel ils n'ont pas accès.
Ensuite, il suffit de toujours exporter le CSV/JSON dans un zip chiffré AES. Hop, problème résolu.

Pour moi, la raison c'est que les acteurs du web ne veulent plus s'embêter à gérer les intrusions/usurpations. Ils veulent une solution robuste "coté client", même si elle prive les utilisateurs de leurs libertés.
votre avatar
Pour les gens dubitatifs...

Pour moi, l'intérêt de la passkey c'est de ne pas (=JAMAIS) émettre votre précieux sésame sur le réseau.
- impossible d'intercepter MiM.
- impossible de leak en cas de piratage du site web.

Ensuite, qqn s'est dit "oui, mais, en cas de piratage du PC/Smartphone... faut absolument faire qqc !"
Certes, c'est un risque et faut faire qqc.

Mais sécuriser le stockage du passkey/password c'est de la responsabilité du client (OS, appli...).
Je ne vois pas pourquoi ca serait une exigence du mécanisme d'authentification.

Le seul cas où j'ai vu ce genre de décision unilatérale c'est pour les DRM.
Et, à bien y réfléchir, la spécification v1 du mécanisme prend son sens avec une vision DRM:
- la clé-privée est stockée sur votre terminal, mais elle ne vous appartient pas.
- c'est le résultat d'un accord secret entre votre terminal et le site web.
votre avatar
En fait ça a du sens dans le fonctionnement MFA, le Device est quelque chose que tu as, la clé privée quelque chose que tu "connais / es".

Ou alors j'ai mal compris ta remarque, ce qui est possible, mais dans ce cas, peux-tu préciser un peut en quoi on serait dans un système purement DRM ?
votre avatar
Ou alors j'ai mal compris ta remarque, ce qui est possible, mais dans ce cas, peux-tu préciser un peut en quoi on serait dans un système purement DRM ?
C'est analogue au DRM dans le sens où

DRM:
Le vendeur qui diffuse le média demande au client de prouver qu'il a la licence pour accéder au contenu du média.
Afin que le client ne puisse pas (1) bidouiller ou (2) partager/se-faire-voler la licence, celle ci est:
(1) inaccessible à l'utilisateur = dans une enclave protégée.
(2) spécifique à l'appareil.

PASSKEY:
Le vendeur qui diffuse le site web demande au client de prouver qu'il a la clé pour accéder au contenu du site web.
Afin que le client ne puisse pas (1) bidouiller ou (2) partager/se-faire-voler la clé, celle ci est:
(1) inaccessible à l'utilisateur = dans une enclave protégée.
(2) spécifique à l'appareil.
votre avatar
Je suis pas forcément d'accord sur les principes exposés.

DRM, la clé est stockée dans une enclave sécurisée, la clé (le certificat) est commun(e) à tout matériel pour un constructeur donné.
La clé (certificat) est commune pour toutes les galettes d'un média donné, voir pour des séries de médias donnés.
C'est un fonctionnement type navigateur Internet avec pour le petit cadenas des sites web.

Pour la Passkey,
Elle est spécifique à 1 terminal pour 1 usage donné (Gmail, AppStore, ...)
Elle la clé privée est stockée dans une enclave sécurisée, ce n'est pas un certificat.
La site échange un jeton (qui peut être un certificat du point de vue technique) après une phase d'authentification basée sur une clé publique signée par la clé privée.

Pour le coup, c'est quand même bien différent.

DRM : terminal générique / média générique / contrôle d'intégrité
PassKey : terminal spécifique / média générique / "partage" de secret et authentification

Y'a du secure element et du chiffrement dans les 2 cas, mais c'est pas du tout la même chose.
votre avatar
PassKey : terminal spécifique / média générique / "partage" de secret et authentification
Oui, le secret est partagé... Mais il n'est pas partagé avec moi.

Le secret est partagé entre le "site web" et le "terminal spécifique" que je possède.
Mais moi, l'être humain qui possède le terminal, je n'y ai pas accès.

C'est en cela que c'est, pour moi, analogue au DRM.
Ca sécurise les échanges entre deux systèmes, chacun s'assurant que l'autre est authentique.
Mais ca exclut l'être humain du processus car on ne lui fait pas confiance.
votre avatar
Ces passkeys sont franchement une aberration : on ne partage jamais une clé privée, celle-ci ne sort pas du périphérique client.
On peu très facilement enregistrer plusieurs périphériques : il suffit simplement d’enregistrer un simple certificat lié à une paire de clé par périphérique.
Vouloir partager ce trousseau : casse tout principe de sécurité ! Impossible de bloquer un device particulier qu'on aurait perdu, ou qui se serait fait pirater. Le fait de partager la clé privée est un risque énorme de duplication.

Passkeys : les plateformes d’Apple vont prendre en charge l’import/export sécurisé

  • Le danger des silos

  • Généralisation des échanges dans les versions 26 chez Apple

Fermer