Article · brouillon de révision

Mise en contexte

Ezkey est une plateforme MFA cryptographique open source, pensée pour les équipes qui veulent une authentification forte sans la réduire à une histoire de navigateur ni à l’empilement de protocoles généralistes complexes. La proposition est volontairement backend-first : la confiance repose sur des APIs claires, un état serveur explicite et une continuité cryptographique entre les acteurs — avec un mobile qui participe à la chaîne de manière concrète et vérifiable.

La chaîne de confiance : deux socles

Au niveau le plus global, la confiance dans Ezkey repose sur deux références complémentaires :

1. L’organisation comme référence de confiance
   C’est l’installation Ezkey déployée dans l’environnement de l’organisation (on-prem ou équivalent). Elle définit où s’exerce la politique, qui administre le service, et quel back-end porte la vérité opérationnelle et cryptographique pour les intégrations. Conceptuellement, c’est le socle institutionnel : l’équipe sait qu’elle s’appuie sur son instance, sous son contrôle, et non sur une médiation opaque ou extérieure.
2. La confiance liée au participant et à son appareil
   Chaque utilisateur s’appuie sur une clé cryptographique associée à son appareil, protégée par les mécanismes de sécurisation que la plateforme mobile offre (stockage matériel ou fortement isolé selon les capacités du terminal). Ce n’est pas un détail cosmétique : c’est le socle utilisateur de la chaîne — la garantie que l’identité et les preuves présentées depuis le mobile restent liées à un matériel et à un contexte que l’utilisateur peut raisonnablement considérer comme dignes de confiance.

Ces deux socles ne se substituent pas l’un à l’autre : ils s’articulent. Le back-end Ezkey vérifie et orchestre ; le mobile détient et utilise des clés dans un environnement conçu pour les protéger — ce qui fait du mobile un acteur à part entière de la zone de confiance, pas un simple « écran » à côté du serveur.

Côté organisation : une installation, une zone de confiance

Une installation Ezkey = la zone de confiance de l’organisation : socle serveur pour l’état, les vérifications et les politiques — sous contrôle de l’organisation.

Côté mobile : sécurisation native et participation à la vérité

L’application mobile Ezkey s’appuie sur les API et abstractions de sécurisation inhérentes aux plateformes mobiles — en particulier le stockage protégé des clés. Dans l’application de référence Android actuelle, cela signifie une clé de signature protégée par la plateforme pour chaque enrollment, plus une clé de scellement dédiée au niveau application pour protéger au repos les secrets locaux de longue durée. Sans entrer dans le jargon fournisseur, l’idée est simple : le participant peut avoir confiance que l’usage du mobile, dans ce modèle, ajoute une couche de protection réelle — celle que le système d’exploitation et le matériel associent à la garde des secrets et à leur utilisation contrôlée.

Ce choix fait partie de l’ADN d’Ezkey : le produit réutilise ce que les plateformes font déjà bien pour l’identité locale sur l’appareil, au lieu de prétendre que l’interface seule suffit. Le mobile n’est donc pas un intermédiaire faible : il est le lieu où la preuve utilisateur prend sens dans un environnement durci, en cohérence avec le back-end qui valide cette preuve dans le flux global.

Beaucoup d’« authenticateurs » se contentent d’un code à recopier ou d’une confirmation par tap : la sécurité repose alors sur le canal humain (lecture, copie, dictée), pas sur une preuve liée cryptographiquement à la tentative en cours. L’app Ezkey ne joue pas ce rôle : les réponses s’inscrivent dans le protocole et les clés protégées sur l’appareil — ce n’est pas un code à six chiffres renouvelé qu’on peut recopier hors du flux comme avec les générateurs habituels, ni un « oui » découplé du contexte serveur.

Les flux essentiels

Inscription / rattachement d’un appareil

• bind puis verify : établissement d’une relation cryptographiquement liée entre le contexte d’intégration, le back-end et l’appareil.

Authentification

• pending puis respond : création d’une tentative côté serveur, notification côté mobile, réponse avec preuve adaptée ; le back-end vérifie et tranche l’état final.

Schéma logique (vue synthétique) :

Pourquoi cette approche

• APIs REST simples et bien documentées pour les équipes qui les intègrent.
• Deux niveaux de confiance clairs : référence organisationnelle (l’instance Ezkey) et référence utilisateur/appareil (clés protégées par les mécanismes natifs du mobile).
• Continuité cryptographique : bind/verify et pending/respond établissent des liens de preuve signés et validés formellement par le processus cryptographique — ce ne sont pas de simples libellés.
• Maîtrise et transparence : déploiement dans la zone de l’organisation, produit inspectable (open source).

Conclusion — positionnement

English : Same article in English