4. Considérations de sécurité
4. Considérations de sécurité
La mise en œuvre et l'utilisation appropriées d'un algorithme de signature cryptographique nécessitent de prendre en compte de nombreux paramètres. En particulier, la génération, le stockage, le contrôle d'accès et l'élimination des clés privées sont des opérations sensibles, que ce document n'aborde d'aucune manière. (EC)DSA déterministe montre comment atteindre les caractéristiques de sécurité d'un schéma de signature DSA ou ECDSA standard tout en supprimant le besoin d'une source de randomité forte, ou même de toute source de randomité, pendant la génération de signature.
La génération de clé privée, cependant, nécessite absolument une telle source fortement aléatoire. Dans les situations où (EC)DSA déterministe doit être utilisé en raison du manque d'une source appropriée de randomité, on doit supposer que la clé privée a été générée de manière externe et importée dans le système de génération de signature ou a été générée dans un contexte où la randomité était disponible. Par exemple, on peut imaginer une carte à puce qui génère sa clé privée alors qu'elle est encore en usine sous des conditions environnementales contrôlées, mais pour laquelle la génération de données aléatoires ne peut pas être garantie une fois déployée sur le terrain, lorsqu'elle est physiquement entre les mains d'attaquants potentiels.
La suppression de l'exigence de source aléatoire et la capacité de tester une implémentation par rapport à des vecteurs de test améliorent toutes deux la sécurité des implémentations de signataires DSA et ECDSA, en ce qu'elles aident à éviter des conditions d'échec difficiles à tester. Les schémas de signature déterministes peuvent également aider dans d'autres situations, par exemple pour éviter les duplicatas parasites, lorsque le même élément de données est signé plusieurs fois avec la même clé: avec un schéma de signature déterministe, la même signature est générée à chaque fois, rendant la détection de duplicatas beaucoup plus facile.
Inversement, le manque de randomisation peut avoir des effets néfastes dans certains protocoles avancés, par exemple liés à l'anonymat dans certains schémas de vote. En règle générale, DSA ou ECDSA déterministe peut être utilisé à la place du DSA ou ECDSA véritable, sans problèmes de sécurité supplémentaires, si le protocole global tolérerait un autre schéma de signature déterministe, en particulier RSA tel que spécifié dans PKCS #1 [RFC3447] (avec le rembourrage "type 1", pas PSS) ou ISO 9796-2 [ISO-9796-2]. La liste des protocoles dans lesquels DSA ou ECDSA déterministe est approprié inclut Transport Layer Security (TLS) [RFC5246], le Secure SHell (SSH) Protocol [RFC4251], Cryptographic Message Syntax (CMS) [RFC5652] et ses dérivés, les infrastructures de clés publiques X.509 [RFC5280], et bien d'autres.
La construction décrite dans ce document est connue sous le nom de "dérandomisation". Cela a été proposé pour divers schémas de signature. La sécurité repose sur le fait que la génération de k soit indiscernable de la sortie d'un oracle aléatoire. En gros, HMAC_DRBG est sécurisé dans ce rôle tant que HMAC se comporte comme une PRF (fonction pseudoaléatoire). Pour plus de détails sur la sécurité de HMAC et HMAC_DRBG, veuillez consulter [H2008] et [B2006]. Pour un traitement plus formel de la dérandomisation, voir [LN2009].
Un problème restant avec (EC)DSA déterministe, tel que présenté dans ce document, est la "double utilisation" de la clé privée x, à la fois comme clé privée dans l'algorithme de génération de signature lui-même et comme entrée à l'oracle pseudoaléatoire basé sur HMAC_DRBG pour produire la valeur k. Cela nécessite que HMAC_DRBG continue d'être un oracle aléatoire, même lorsque la clé publique (qui est calculée à partir de x) est également connue. Étant donné le manque de structure commune entre HMAC et les logarithmes discrets, cela semble être une hypothèse raisonnable.
Les attaques par canal auxiliaire sont une considération importante chaque fois qu'un attaquant peut mesurer avec précision des aspects d'une implémentation tels que la durée nécessaire pour effectuer une opération de signature ou la puissance consommée à chaque point d'une opération de signature. Le déterminisme des algorithmes décrits dans cette note peut être utile à un attaquant dans certaines formes d'attaques par canal auxiliaire, donc les implémentations DEVRAIENT utiliser des mesures défensives pour éviter de divulguer la clé privée par un canal auxiliaire.