Comprendre le chiffrement asymétrique pour les applications mobiles

Le cryptage asymétrique, aussi connu sous le nom de cryptographie à clé publique, est un mécanisme de sécurité fondamental qui utilise deux clés mathématiques mais distinctes : une clé publique, qui peut être partagée librement, et une clé privée, qui doit rester secrète. Dans les applications mobiles, cette approche permet une communication sécurisée sans avoir à pré-partager une clé secrète, ce qui la rend idéale pour l'échange de clés, les signatures numériques, et authentifier les utilisateurs ou les serveurs.

Le principe de base repose sur la difficulté de certains problèmes mathématiques. Par exemple, RSA utilise la complexité informatique de factoring de grands produits de base, tandis que Elliptic Curve Cryptographie (ECC) se fonde sur le problème logarithmique discret sur les courbes elliptiques. Les deux offrent une sécurité forte, mais ECC offre une sécurité équivalente avec des tailles clés nettement plus petites, ce qui est particulièrement bénéfique pour les environnements mobiles où la bande passante et le stockage sont limités.

Choisir l'algorithme approprié pour Mobile

RSA: Largement soutenu mais intensif en ressources

RSA reste l'algorithme asymétrique le plus largement supporté, disponible dans presque toutes les bibliothèques cryptographiques. Sa force est de taille avec la longueur de la clé; une clé de 2048 bits est le minimum recommandé par NIST[ depuis 2025. Cependant, le chiffrement et le décryptage RSA sont coûteux sur le plan informatique, surtout pour les textes longs. En pratique, RSA est rarement utilisé pour chiffrer directement les charges utiles importantes; il est souvent combiné à un chiffrement symétrique (cryptage hybride).

ECC: Clés plus petites, opérations plus rapides

Une clé ECC de 256 bits fournit une sécurité comparable à une clé RSA de 3072 bits, réduisant considérablement la taille des certificats et des données transmises. Les opérations ECC sont généralement plus rapides pour la génération et la signature des clés, ce qui est un avantage important sur les processeurs mobiles de faible puissance. Apple , iOS et Android fournissent tous deux des CCE accélérées par le matériel via l'Enclave sécurisée et l'environnement d'exécution fiable. Les courbes les plus utilisées sont P-256 (secp256r1) et X25519 pour l'échange de clés.

Protocoles d'échange de clés et de diffie-hellman

Dans les applications mobiles, ECDH est souvent employé dans le cadre de la poignée de main TLS pour générer des clés de session. Les implémentations devraient utiliser des clés éphémères (ECDHE) pour fournir un secret parfait avant. Les bibliothèques comme libsodium[ offrent des primitives de haut niveau, audités pour l'échange de clés qui abstractionnent de nombreuses écueils de complexité.

Conseils de mise en oeuvre spécifiques à la plate-forme

iOS: Tirer parti de l'enclave sécurisée et du CryptoKit

Apple fournit deux API primaires pour la cryptographie asymétrique : le cadre de sécurité et le cadre moderne CryptoKit introduit dans iOS 13. CryptoKit prend en charge les opérations de haut niveau pour la signature, la vérification et l'accord clé en utilisant les courbes NIST (P-256, P-384, P-512) et Curve25519. Pour stocker les clés privées, utilisez toujours l'Enclave sécurisée quand disponible (sur iPhone 5s et plus). Les clés stockées dans l'Enclave sécurisée ne sont jamais directement accessibles au processeur d'application; les opérations telles que la signature sont effectuées à l'intérieur de l'enclave, et seul le résultat est retourné. Pour stocker une clé dans l'Enclave sécurisée, utilisez la fonction avec la mise à . Évitez d'utiliser la chaîne-clés pour les clés privées sans protection matérielle, car elle peut être moins résistante aux attaques physiques.

Android: KeyStore et StrongBox

Android offre le fournisseur, qui permet de stocker les clés générées par l'application dans un environnement d'exécution fiable soutenu par le matériel (TEE) ou une puce de sécurité dédiée (StrongBox). À partir d'Android 9 (niveau 28 de l'API), vous pouvez demander les clés soutenues par StrongBox en utilisant . Pour la génération de clés asymétriques, utilisez avec le fournisseur et spécifiez des algorithmes comme ou . Les appareils Android modernes avec support StrongBox offrent également une prise en charge intégrée pour les opérations de signe/vérification d'ECDSA et RSA sans exposer la clé privée au système d'exploitation principal.

Cadres transplats

Pour Flutter, les modules spécifiques à la plate-forme (p. ex. ] combinés avec la génération de clés natives) sont recommandés. Les développeurs Natifs peuvent utiliser des bibliothèques comme pour la manipulation des clés, mais le stockage devrait toujours déléguer à plate-forme-native Keychain/KeyStore. Évitez d'implanter des opérations cryptographiques JavaScript pures pour les données sensibles, car l'environnement JavaScript n'est pas conçu pour la résistance des canaux latéraux.

Gestion sécurisée des clés : la fondation du chiffrement asymétrique

Ne jamais coder les clés privées

Tout attaquant ayant accès au paquet app peut inverser le binaire et extraire les clés codées en dur. Utilisez la plate-forme de stockage sécurisé (Keychain sur iOS, Android KeyStore) ou un service de gestion des clés à distance (KMS) pour la fourniture des clés. Pour les applications authentifiées par le serveur, envisagez de publier des clés spécifiques aux appareils éphémères au moment de l'enregistrement.

Stockage avec support matériel

Les appareils mobiles modernes comprennent du matériel sécurisé dédié comme Apple , l'Enclave sécurisée et Android , l'environnement d'exécution fiable (TEE) ou StrongBox . Ces composants effectuent le déchiffrement et la signature sans exposer la clé privée au processeur principal d'application . Lorsque disponible , toujours préfèrent les clés supportées par le matériel . Si la prise en charge matérielle est obligatoire (p. ex. pour les applications traitant le paiement ou les données de santé ), utilisez sur Android ou sur iOS . Lorsque le matériel n'est pas disponible , retombez dans le stockage logiciel protégé par le chiffrement de niveau de l'appareil (p. ex., Keychain sur iOS avec l'attribut d'accessibilité défini à .

Rotation et révocation des clés

Les clés asymétriques devraient avoir une durée de vie limitée. Implémenter les politiques de rotation des clés : par exemple, générer de nouvelles clés de signature tous les six mois et déprécier les anciennes. Du côté du serveur, tenir une liste noire ou utiliser le pinning de clé publique pour révoquer les clés compromises. Les applications mobiles devraient périodiquement demander au serveur des clés publiques mises à jour et vérifier qu'elles sont signées par une autorité de confiance.

Considérations relatives au soutien

Lors de la sauvegarde des données utilisateur, décidez si les clés privées doivent être exclues. Les clés liées à un périphérique spécifique (par exemple pour le cryptage local) ne doivent pas être sauvegardées sur iCloud ou Google Drive, car cela mine le modèle de sécurité. Sur iOS, définissez l'accessibilité à pour empêcher la sauvegarde des clés. Sur Android, utilisez et assurez-vous que les clés ne sont pas exportées via des agents de sauvegarde.

Meilleures pratiques pour une communication sûre

Utiliser le chiffrement hybride pour les grandes données

Au lieu de cela, utilisez un schéma hybride : générer une clé symétrique unique (par exemple AES-256-GCM), chiffrer les données avec cette clé, puis chiffrer la clé symétrique en utilisant la clé publique du destinataire. Cette approche combine l'efficacité du chiffrement symétrique avec la distribution sécurisée de la clé du chiffrement asymétrique. Les bibliothèques telles que libsodium ou NaCl fournissent des primitives de chiffrement hybride de haut niveau qui gèrent automatiquement la génération de clé.

Valider toujours la chaîne de confiance

Pour la communication entre les pairs, toujours appliquer TLS 1.3 avec le pinning du certificat. Le code dur le serveur est l'empreinte digitale de la clé publique ou utiliser une CA intermédiaire clouée pour empêcher les attaques de l'homme dans le milieu. iOS fournit avec des ancres de confiance personnalisées; Android utilise de OkHttp ou Jetpack Security.

Mettre en oeuvre le secret parfait pour l'avenir (PFS)

Dans les protocoles d'échange de clés, utilisez toujours des clés éphémères (ECDHE) afin que le compromis sur la clé privée à long terme n'expose pas les clés de session passées. Cette propriété, appelée secret parfait avant, garantit que même si un attaquant obtient plus tard la clé privée du serveur, ils ne peuvent pas décrypter le trafic enregistré précédemment.

Gérer les erreurs sans laisser de l'information

Les opérations cryptographiques peuvent échouer en raison de clés non valides, de données corrompues ou de temps d'attente. N'exposez jamais les messages d'erreur détaillés à l'utilisateur ou enregistrez le matériel de clé brute. Par exemple, si la vérification de la signature échoue, affichez une « erreur de communication » générique plutôt que « signature ECDSA invalide » qui pourrait aider un attaquant. Utilisez des comparaisons à temps constant pour vérifier les signatures ou les MAC pour éviter les attaques de temps.

Test et vérification de votre mise en œuvre

Essais unitaires avec vecteurs d'essai connus

Valider vos fonctions de chiffrement et de signature contre les vecteurs de test publiés de NIST ou RFC. Par exemple, tester le chiffrement RSA-OAEP en utilisant les vecteurs NIST CAVP. Écrire des tests unitaires qui couvrent les cas de bord: texte clair de longueur zéro, tailles de clés invalides, clés expirées et grandes entrées. Utilisez le stockage simulé sécurisé pour vérifier que les clés sont stockées et récupérées correctement sans toucher le matériel réel pendant CI.

Essais de pénétration et analyse statique

Effectuer des tests de pénétration réguliers en se concentrant sur l'implémentation cryptographique. Les vecteurs d'attaque courants comprennent les attaques de dégradation (forçage d'un chiffrement plus faible), les fuites latérales (par exemple, par analyse de puissance ou par synchronisation du cache CPU), et les attaques d'oracles de rembourrage (par exemple, sur RSA avec PKCS#1 v1.5).

Essai de régression après les mises à jour de la bibliothèque

Après avoir mis à jour une bibliothèque (p. ex. OpenSSL, Bouncy Castle, Conscrypt), exécutez des tests de régression complets pour s'assurer que les fonctions de génération, de signature et de chiffrement des clés produisent encore des sorties valides. Attention aux déprécations : Apple a déprécié la fonction pour RSA en faveur de CryptoKit ; Google a déprécié les anciens fournisseurs . Migrez pour les API supportées afin d'éviter de futurs bris.

Pièges courants et comment les éviter

Utilisation de générateurs aléatoires imprévisibles

Toutes les opérations cryptographiques dépendent de numéros aléatoires sécurisés. Les applications mobiles doivent utiliser sur iOS et sur Android. Ne jamais compter sur ou sur , car elles sont prévisibles et peuvent briser la génération de clés.

Encodage et transmission de clés incorrectes

Lors de l'envoi des clés publiques sur le réseau, utilisez l'encodage Base64 dans un champ JSON ou un conteneur standard comme JWK (JSON Web Key). Soyez prudent avec les coupures de ligne et l'évasion. À la fin de la réception, validez le format de la clé avant d'importer. iOS et Android peuvent analyser les encodages standard; documentez le format attendu pour l'interopérabilité.

Ne pas gérer l'expiration des clés

Les clés qui ne s'expirent jamais deviennent un risque à long terme. Implémentez des vérifications d'expiration dans votre application : si une date de création de clé est plus ancienne qu'un seuil (p. ex. 90 jours), invitez l'utilisateur à réenrôler. Du côté du serveur, rejetez les clés qui ont expiré. Utilisez un horodatage de confiance ou comptez sur le serveur pour fournir l'heure actuelle via une API sécurisée. Évitez d'utiliser l'heure locale du périphérique pour la validation d'expiration, car les utilisateurs peuvent la manipuler.

Résistance à la négation des canaux latéraux

La plupart des API de plate-forme (p. ex., CryptoKit, ) sont des API de temps constant par conception, mais si vous utilisez une bibliothèque tierce, vérifiez sa résistance aux canaux latéraux. Pour les implémentations personnalisées, évitez de brancher des données secrètes et utilisez des opérations bitwise lorsque possible.

Conclusion

La mise en œuvre du cryptage asymétrique dans les applications mobiles ne consiste pas seulement à appeler quelques fonctions de bibliothèque; elle nécessite une compréhension approfondie de la sélection des algorithmes, de la gestion des clés, des API spécifiques à la plate-forme et des tests de sécurité. En suivant les pratiques décrites ici, choisir ECC par rapport à RSA dans la mesure du possible, tirer parti du stockage sécurisé soutenu par le matériel, faire respecter le secret parfait avant et tester rigoureusement contre les vecteurs connus, les développeurs peuvent construire des applications qui protègent les données utilisateur contre une large gamme de menaces. L'écosystème mobile continue d'évoluer : restez informé des nouvelles normes cryptographiques et des avis de dépréciation d'Apple et de Google.