Certification FIPS 140 et Golang
FIPS 140 ( Federal Information Processing Standard Publication 140 )
Le FIPS 140 est une norme de certification de sécurité des modules cryptographiques établie par le NIST américain. Cette norme évalue si un module ou une bibliothèque cryptographique spécifique répond aux exigences de sécurité définies par le NIST. Par conséquent, l'obtention de la certification FIPS 140 signifie que le module en question possède une fiabilité de sécurité officiellement reconnue et peut être utilisé dans des domaines où la sécurité est primordiale, tels que la finance, la santé et la défense nationale.
Le FIPS 140, initialement établi en 1994, a été révisé en FIPS 140-2 en 2001, puis en FIPS 140-3 en 2019. À ce jour, de nombreux systèmes et applications exigent toujours la certification FIPS 140-2 ou FIPS 140-3.
FIPS 140 et les langages de programmation
Pour ces raisons, les modules cryptographiques certifiés FIPS 140 sont utilisés comme une norme de facto dans divers langages de programmation et environnements. Parmi les exemples notables figurent OpenSSL, BoringSSL, LibreSSL et NSS, qui sont les modules les plus largement utilisés dans les applications où la sécurité est critique.
La plupart des modules certifiés FIPS 140 sont écrits en C ou C++. C'est pourquoi des langages comme PHP, Python et Javascript configurent l'environnement FIPS en interfaçant ces modules via des modules Provider externes plutôt qu'en les utilisant directement. Cependant, cette approche présente plusieurs limites.
Problème d'incompatibilité de version
La certification FIPS 140 n'est accordée que pour une version spécifique. Par conséquent, l'utilisation de la dernière version du module nécessite de repasser par le processus de certification, ce qui peut entraîner une incompatibilité de version entre le module utilisé par l'application et le module certifié FIPS. Si une version non autorisée est utilisée, l'environnement en question n'est plus considéré comme un environnement certifié FIPS.
Chargement dynamique et dégradation des performances
La plupart des langages chargent les modules certifiés FIPS 140 sous forme de bibliothèques dynamiques. Cette méthode peut entraîner une dégradation des performances pendant l'initialisation et l'exécution, et en cas de problème en temps réel, elle risque d'affecter directement la stabilité globale de l'application.
Vulnérabilités de sécurité
Comme mentionné précédemment, dans une architecture où des modules externes comme OpenSSL Provider sont interfacés, il existe un risque que les vulnérabilités de sécurité de ces modules se propagent directement à l'application. De plus, la couche de communication entre l'application et les modules externes devient elle-même une surface d'attaque supplémentaire, nécessitant une couche de sécurité distincte pour la protéger. Cela augmente la complexité et peut entraîner des vulnérabilités imprévues.
FIPS 140 et Golang
Pour ces raisons, Golang a adopté une stratégie différente. Go a choisi de prendre en charge la certification FIPS 140 directement dans sa bibliothèque cryptographique officielle, sans dépendre d'outils externes. Ainsi, les développeurs peuvent simplement activer le mode certifié FIPS (GOFIPS=1) tout en utilisant le paquet crypto standard, sans avoir à installer ou configurer un Provider distinct. Ce processus élimine les limites de communication avec les modules externes, renforçant ainsi la sécurité, et simplifie les opérations, car seule une seule binaire compilée statiquement doit être déployée.
FIPS 140-2 et Golang
Pour ce faire, Golang a intégré le module BoringCrypto, dérivé de BoringSSL, dans le runtime Go, obtenant ainsi la certification FIPS 140-2. BoringCrypto peut être activé dans certaines distributions Go 1.19 et versions ultérieures, permettant aux applications Go de configurer un environnement certifié FIPS 140-2 sans modules externes supplémentaires.
Cependant, BoringCrypto étant basé sur OpenSSL, il existe toujours une dépendance au langage C. Par conséquent, les applications Go n'étaient pas entièrement compilées en binaires indépendants, et il y avait la contrainte de devoir distribuer les bibliothèques C nécessaires.
FIPS 140-3 et Golang
L'équipe Go a surmonté ces limitations en améliorant la bibliothèque crypto standard de Go pour la rendre conforme à la spécification FIPS 140-3. Ce module amélioré est disponible de manière expérimentale depuis la version Go 1.21, et son évaluation pour la certification FIPS 140-3 par le NIST est actuellement en cours.Liste des modules en cours d'évaluation NIST FIPS 140-3
Cela démontre la maturité de la bibliothèque cryptographique de Go, permettant à Go de fournir un environnement certifié FIPS 140-3 en tant que binaire unique et entièrement indépendant.
De plus, l'équipe Go ne s'est pas contentée de satisfaire à la norme FIPS 140-3, elle a également renforcé la sécurité de manière autonome.
Fail Fast
Le mode FIPS de Go applique un modèle de sécurité Fail Fast, interrompant immédiatement l'exécution avec un panic si un algorithme non certifié est appelé. Contrairement aux modèles basés sur Provider d'autres langages qui laissent une possibilité de fallback, cela offre une garantie plus stricte et plus claire en termes de sécurité et de conformité réglementaire.
Hedged Signature
La norme FIPS 140-3 recommande la méthode RFC6979 pour les signatures ECDSA. Cependant, Go y a ajouté la méthode Hedged pour mieux résister aux attaques par canal auxiliaire qui peuvent survenir pendant le processus de signature.
Générateur de nombres aléatoires renforcé
Le générateur de nombres aléatoires de Go utilise un DRBG (Deterministic Random Bit Generator) en espace utilisateur, tout en injectant de l'entropie supplémentaire dans le noyau du système d'exploitation, générant ainsi des nombres aléatoires de haute qualité non seulement dans l'espace utilisateur mais aussi dans l'espace du noyau. Cela renforce davantage la sécurité du générateur de nombres aléatoires.