Problèmes connus liés au moteur dynamique OpenSSL pour AWS CloudHSM

Impact : OpenSSL Dynamic Engine prend uniquement en charge OpenSSL 1.0.2 [f+]. Par défaut, RHEL 6 et CentOS 6 sont livrés avec OpenSSL 1.0.1.

Solution : mettez à niveau la bibliothèque OpenSSL sur RHEL 6 et CentOS 6 vers la version 1.0.2 [f+].

Conséquence : pour optimiser les performances, le SDK n'est pas configuré pour décharger des fonctions supplémentaires telles que la génération de nombres aléatoires ou EC-DH les opérations.

Solution : Veuillez nous contacter au moyen d'une demande de support si vous avez besoin de décharger des opérations supplémentaires.

Statut de résolution : Nous ajoutons actuellement la prise en charge de la configuration des options de déchargement pour le kit SDK au moyen d'un fichier de configuration. Une fois disponible, la mise à jour sera annoncée sur la page de l'historique des versions.

Impact : Tout appel au chiffrement et au déchiffrement RSA avec remplissage OAEP échoue avec une erreur de division par zéro. Cela se produit car le moteur dynamique OpenSSL appelle l'opération localement à l'aide du fichier PEM factice au lieu de décharger l'opération vers le HSM.

Solution : Vous pouvez effectuer cette procédure à l'aide de bibliothèque PKCS #11 pour AWS CloudHSM SDK client 5 ou de fournisseur JCE pour le SDK AWS CloudHSM client 5.

Résolution d'état : Nous sommes en train d'ajouter la prise en charge pour le kit SDK pour décharger correctement cette opération. Une fois disponible, la mise à jour sera annoncée sur la page de l'historique des versions.

Impact : comme le basculement est silencieux, rien n'indique que vous n'avez pas reçu une clé qui a été générée de façon sécurisée sur le HSM. Vous verrez une sortie de trace contenant la chaîne "...........++++++" si la clé est générée localement par OpenSSL dans le logiciel. Cette trace est absente lorsque l'opération est déchargée sur le HSM. Comme la clé n'est pas générée ou stockée sur le HSM, elle sera indisponible pour une utilisation future.

Solution de contournement : utilisez uniquement le moteur OpenSSL pour les Types de clé qu'il prend en charge. Pour tous les autres types de clés, utilisez PKCS #11 ou JCE dans les applications, ou utilisez-les dans l'interface de ligne de key_mgmt_util commande.

Conséquence : par défaut, RHEL 8, CentOS 8 et Ubuntu 18.04 LTS fournissent une version d'OpenSSL qui n'est pas compatible avec OpenSSL Dynamic Engine for Client SDK 3.

Solution : utilisez une plateforme Linux qui prend en charge le moteur dynamique OpenSSL. Pour plus d'informations sur les plateformes prises en charge, consultez Plateformes prises en charge.

État de la résolution : AWS CloudHSM prend en charge ces plates-formes avec OpenSSL Dynamic Engine for Client SDK 5. Pour plus d'informations, consultez Plateformes prises en charge et OpenSSL Dynamic Engine.

Conséquence : l'utilisation du condensé des SHA-1 messages à des fins cryptographiques est devenue obsolète dans RHEL 9 (9.2+). Par conséquent, les opérations de signature et de vérification effectuées à SHA-1 l'aide du moteur dynamique OpenSSL échoueront.

Solution : si votre scénario nécessite l'utilisation de SHA-1 pour des signatures cryptographiques signing/verifying existantes ou tierces, consultez les notes de version de Enhancing RHEL Security : Understanding SHA-1 Deprecation on RHEL 9 (9.2+) et RHEL 9 (9.2+) pour plus de détails.

Conséquence : vous recevrez un message d'erreur si vous tentez d'utiliser le moteur dynamique AWS CloudHSM OpenSSL alors que le fournisseur FIPS est activé pour les versions 3.x d'OpenSSL.

Solution : pour utiliser le moteur dynamique AWS CloudHSM OpenSSL avec les versions 3.x d'OpenSSL, assurez-vous que le fournisseur « par défaut » est configuré. Pour en savoir plus sur le fournisseur par défaut, consultez le site Web d'OpenSSL.

Conséquence : les tentatives de connexion utilisant TLS 1.0 ou TLS 1.1 échouent car ces versions sont utilisées SHA-1 pour la signature, ce qui ne répond pas aux exigences de la norme FIPS 186-5.

Solution : si vous ne pouvez pas mettre à niveau les versions TLS immédiatement, vous pouvez migrer vers des clusters non FIPS, qui n'appliquent pas l'exigence de puissance de hachage. Cependant, nous vous recommandons de passer à TLS 1.2 ou TLS 1.3 pour maintenir la conformité FIPS et les meilleures pratiques de sécurité.

Solution : mettez à niveau votre implémentation pour utiliser TLS 1.2 ou TLS 1.3. L'Internet Engineering Task Force (IETF) a rendu obsolètes les protocoles TLS 1.0 et TLS 1.1 pour des raisons de sécurité.