Mission chez Engy Partners · juillet 2025
TerangaID
Portefeuille d'identité numérique mobile : authentification par certificat, génération de CSR, et clés privées gardées par le matériel avec repli logiciel explicite.
- Problème
- Une identité numérique souveraine ne peut pas stocker ses clés privées dans le système de fichiers de l'application — il faut l'isolation matérielle.
- Résultat
- Portefeuille livré sur Android et iOS : authentification biométrique, gestion du cycle de vie des certificats, clés privées inextractibles du TEE.
- Rôle
- Développeur Mobile & Sécurité
Quel problème TerangaID résout-il ?
Un portefeuille d'identité numérique ne vaut que par la garantie qu'il donne sur une seule chose : la clé privée de l'utilisateur n'a jamais quitté son téléphone et ne peut pas en sortir.
Tout le reste — l'interface, la synchronisation, les écrans de consentement — est du logiciel ordinaire. Cette garantie-là, non : elle ne s'obtient pas en logiciel.
Quelle est la contrainte structurante ?
Stocker une clé dans le AsyncStorage de React Native, même chiffrée, revient à stocker la clé et son chiffrement au même endroit. Sur un appareil rooté, c'est perdu.
La réponse est le TEE (Trusted Execution Environment) — Android Keystore côté Android, Secure Enclave côté iOS. La clé y est générée et ne peut pas en être extraite : on ne peut que lui demander de signer.
Cela impose une inversion : l'application ne manipule jamais la clé, elle manipule une référence vers une clé qu'elle ne verra jamais. Toute la logique de signature devient asynchrone et faillible — l'utilisateur peut refuser la biométrie, l'OS peut invalider la clé si l'empreinte change.
Comment TerangaID est-il architecturé ?
Authentification par certificat, pas par mot de passe. L'appareil génère sa paire de clés, produit une demande de signature de certificat (CSR) et se fait délivrer un certificat. L'identité n'est plus un secret partagé qu'on peut se faire voler : c'est une clé que l'appareil détient et dont il prouve la possession.
Un pont natif Kotlin pour le matériel. Un module de gestion de clés côté Android expose une surface minimale à React Native : générer une paire, signer, attester. Le code TypeScript ne voit que ces opérations, jamais la clé.
Une fabrique qui choisit son gardien. C'est la décision dont je suis le plus satisfait : un KeyManagerFactory sélectionne à l'exécution entre gestionnaire matériel et gestionnaire logiciel. Tous les appareils n'ont pas d'enclave sécurisée — et un portefeuille qui refuse de démarrer sur un appareil d'entrée de gamme ne sert personne. Le repli est explicite, tracé, et le niveau de garantie est connu de l'application plutôt que supposé.
Récupération par phrase mnémonique. Une clé gardée par le matériel est une clé qu'on perd avec l'appareil. La sauvegarde chiffrée et la phrase de récupération répondent au seul scénario qui compte vraiment pour un utilisateur : le téléphone cassé.
La biométrie déverrouille, elle n'authentifie pas. L'empreinte débloque l'usage de la clé ; c'est la signature de la clé qui prouve l'identité. Confondre les deux, c'est faire reposer une identité sur un capteur.
Qu'est-ce que TerangaID m'a appris ?
Le travail de sécurité utile n'a pas été d'ajouter des couches de chiffrement, mais de réduire la surface : identifier la seule opération qui doit être inviolable, la pousser dans le matériel, et accepter que tout le reste soit du code ordinaire et audité comme tel.
Un projet du même calibre ?
Basé à Thiès, disponible à dakar & télétravail. Je réponds sous 48 h.
En discuter