gestion des certificats et des autorités de certification dans dcmtls
Certificat système et clé privée
Selon le protocole TLS, un serveur (c'est-à-dire une application qui accepte les connexions réseau TLS entrantes) doit s'identifier de manière cryptographique au moyen d'un certificat et d'une clé privée, tandis qu'un client (une application qui initie des connexions réseau TLS sortantes) peut s'identifier au moyen d'un certificat et d'une clé privée, ou rester anonyme.
Tous les outils DCMTK qui prennent en charge les connexions réseau chiffrées par TLS proposent des options de ligne de commande permettant de choisir une communication réseau non chiffrée, TLS avec certificats, ou (dans le cas des applications clientes) TLS en mode anonyme :
-tls --disable-tls- utilise une connexion TCP/IP normale (par défaut)
+tls --enable-tls [p]rivate key file, [c]ertificate file: string- utilise une connexion TLS sécurisée authentifiée
+tla --anonymous-tls- utilise une connexion TLS sécurisée sans certificat
Deux formats de fichiers différents sont pris en charge pour les certificats, les clés privées et les autres données cryptographiques : le format texte PEM ("Privacy Enhanced Mail"), qui est le format par défaut, et les fichiers binaires ASN.1 au format d'encodage DER ("Distinguished Encoding Rules"). Le format de fichier peut être sélectionné à l'aide des options suivantes :
-pem --pem-keys- lit les clés et les certificats au format PEM (par défaut)
-der --der-keys- lit les clés et les certificats au format DER
Notez que le format PEM prend en charge plusieurs certificats dans un même fichier, ce qui est une fonctionnalité importante lorsque des certificats émis par une CA intermédiaire sont utilisés avec TLS. Le format DER ne prend en charge qu'un seul certificat par fichier.
Dans de nombreux cas, la clé privée est stockée sous forme chiffrée et un mot de passe est nécessaire pour déchiffrer le fichier de clé privée. Dans ce cas, les options suivantes sont proposées :
+ps --std-passwd- invite l'utilisateur à saisir le mot de passe sur l'entrée standard (par défaut)
+pw --use-passwd [p]assword: string- utilise le mot de passe indiqué sur la ligne de commande
-pw --null-passwd- utilise une chaîne vide comme mot de passe
Profils de sécurité
La norme DICOM définit un certain nombre de profils de sécurité pour l'utilisation du protocole réseau DICOM au-dessus de TLS. DCMTK prend en charge les profils suivants :
+pg --profile-8996- BCP 195 RFC 8996 TLS Profile (par défaut)
+pm --profile-8996-mod- Modified BCP 195 RFC 8996 TLS Profile # disponible uniquement si la bibliothèque TLS sous-jacente prend en charge toutes les fonctionnalités TLS requises pour ce profil
+py --profile-bcp195-nd- Non-downgrading BCP 195 TLS Profile (retiré)
+px --profile-bcp195- BCP 195 TLS Profile (retiré)
+pz --profile-bcp195-ex- Extended BCP 195 TLS Profile (retiré)
+pb --profile-basic- Basic TLS Secure Transport Connection Profile (retiré) # disponible uniquement si la bibliothèque TLS sous-jacente prend en charge 3DES
+pa --profile-aes- AES TLS Secure Transport Connection Profile (retiré)
+pn --profile-null- communication non chiffrée authentifiée (retiré, utilisé auparavant dans IHE ATNA)
Le BCP 195 RFC 8996 TLS Profile, sélectionné par défaut, constitue un choix sûr tout en assurant la rétrocompatibilité avec les profils BCP 195 antérieurs. Il ne prend pas en charge la rétrocompatibilité avec les profils plus anciens. Il utilise la version TLS 1.2 ou 1.3, et privilégie TLS 1.3 lorsque cela est possible.
Le Non-downgrading BCP 195 TLS Profile, qui était le profil par défaut dans DCMTK 3.6.7, désactive lui aussi les versions de protocole et les suites de chiffrement plus anciennes. Il prend toutefois en charge les suites de chiffrement DHE, alors que la RFC 9325 recommande de ne pas les utiliser. Il utilise la version TLS 1.2 ou 1.3, et privilégie TLS 1.3 lorsque cela est possible.
Le BCP 195 TLS Profile, qui était le profil par défaut jusqu'à DCMTK 3.6.6 inclus, tente de négocier des algorithmes cryptographiques actuellement considérés comme sûrs, mais assure la rétrocompatibilité avec les applications plus anciennes qui implémentent le profil retiré AES ou Basic TLS. Ce profil n'est plus conforme à BCP 195 tel qu'amendé par la RFC 8996 (2021).
L'Extended BCP 195 TLS Profile est similaire au Non-downgrading BCP 195 TLS Profile, mais utilise une sélection plus restreinte de suites de chiffrement et se limite à la version TLS 1.2.
L'AES TLS Secure Transport Connection Profile utilise le chiffrement AES et la version TLS 1.0 ou ultérieure, et a été retiré de la norme DICOM. Il ne doit être utilisé que lorsque la rétrocompatibilité avec des dispositifs implémentant ce profil est requise.
Le Basic TLS Secure Transport Connection Profile utilise le chiffrement Triple DES et la version TLS 1.0 ou ultérieure, et a lui aussi été retiré de la norme DICOM. Il ne doit être utilisé que lorsque la rétrocompatibilité avec des dispositifs implémentant ce profil est requise, en particulier parce qu'une longueur de clé effective de 112 bits n'offre plus une sécurité suffisante contre les attaques par force brute.
La communication non chiffrée authentifiée est enfin un profil retiré, défini dans d'anciennes versions du profil IHE Audit Trail and Node Authentication. Elle utilise une communication non chiffrée accompagnée de sommes de contrôle cryptographiques. Ce profil doit être évité.
Il convient de noter que la prise en charge du profil Basic TLS n'est disponible que si la bibliothèque OpenSSL a été compilée de manière à activer la prise en charge de Triple DES, ce qui n'est plus le cas par défaut.
La liste des suites de chiffrement TLS proposées lors de la négociation TLS peut être étendue à l'aide de l'option suivante :
+cs --cipher [c]iphersuite name: string
add ciphersuite to list of negotiated suites
La liste des suites de chiffrement TLS 1.0-1.2 prises en charge peut être affichée à l'aide de l'option suivante :
+cc --list-ciphers
list supported TLS ciphersuites and exit
L'option --cipher peut être spécifiée plusieurs fois pour ajouter plusieurs suites de chiffrement.
Authentification du pair
Par défaut, l'implémentation TLS de dcmtls exige que le client et le serveur fournissent tous deux un certificat comme preuve d'identité, et vérifie la validité et la fiabilité de ce certificat. Ce processus comporte plusieurs étapes :
- La négociation TLS exigera une preuve que l'application a accès à la clé privée correspondant à la clé publique encodée dans le certificat.
- La signature numérique du certificat sera vérifiée.
- La période de validité du certificat sera vérifiée.
- Il sera vérifié que le certificat a été délivré par une autorité de certification (CA) de confiance (voir autorité de certification).
- Selon les options de ligne de commande, les listes de révocation de certificats (CRL) de toutes les CA jusqu'à la CA racine peuvent être vérifiées afin de déterminer si un certificat de la chaîne de certification a été révoqué (voir listes de révocation de certificats).
Ce comportement peut être modifié à l'aide des options de ligne de commande suivantes :
-rc --require-peer-cert- vérifie le certificat du pair, échoue s'il est absent (par défaut)
-vc --verify-peer-cert- vérifie le certificat du pair s'il est présent
-ic --ignore-peer-cert- ne vérifie pas le certificat du pair
La première option provoque l'échec de la connexion si le pair ne présente pas de certificat (c'est-à-dire s'il fonctionne en mode anonyme) ou si le certificat ne peut pas être entièrement vérifié. La deuxième option effectue une vérification du certificat s'il en existe un, mais accepte également les connexions anonymes. La troisième option n'effectue aucune vérification de certificat et accepte elle aussi les connexions anonymes.
Il convient de noter que ces deux derniers modes sont vulnérables aux attaques de l'homme du milieu et doivent donc être évités.
L'option --verify-peer-cert n'est pas disponible dans les applications clientes, car les serveurs TLS présentent toujours un certificat.
Autorité de certification
Tous les outils de DCMTK qui prennent en charge les connexions réseau chiffrées par TLS doivent disposer d'une liste de certificats racine de confiance (c'est-à-dire des certificats auto-signés) utilisée pour vérifier le certificat du pair lors de l'établissement de la connexion TLS.
Il existe deux façons de gérer cette liste de certificats de confiance : par fichier et par répertoire. Les outils en ligne de commande de DCMTK proposent à cet effet les options de ligne de commande suivantes :
+cf --add-cert-file [f]ilename: string- ajoute un fichier de certificat à la liste des certificats
+cd --add-cert-dir [d]irectory: string- ajoute les certificats de d à la liste des certificats
Les deux options peuvent être spécifiées plusieurs fois, y compris en combinaison.
Gestion par fichier des certificats racine de confiance
L'option par fichier charge un fichier et ajoute tous les certificats ou CRL présents dans ce fichier au pool de certificats de confiance. Le format de fichier est un texte ASCII contenant des certificats et des CRL PEM concaténés, sauf si le format ASN.1 DER a été sélectionné.
Gestion par répertoire des certificats racine de confiance
L'option par répertoire indique un répertoire contenant des certificats et des CRL. Ces certificats et CRL sont chargés à la demande, puis mis en cache en mémoire une fois chargés.
Le répertoire doit contenir un certificat ou une CRL par fichier au format PEM, avec un nom de fichier de la forme hash.N pour un certificat, ou hash.rN pour une CRL. Le hash est calculé à partir du nom du sujet (pour les certificats) ou du nom de l'émetteur (pour les CRL). La valeur de hash peut être obtenue en appelant l'outil en ligne de commande openssl :
openssl x509 -hash -noout -in <infile.pem>
où
Le suffixe .N ou .rN est un numéro de séquence qui commence à zéro et s'incrémente consécutivement pour chaque certificat ou CRL ayant la même valeur de hash. Les discontinuités dans la numérotation ne sont pas prises en charge ; il est supposé qu'il n'existe plus d'objets avec le même hash au-delà du premier numéro manquant de la séquence.
Les numéros de séquence permettent au répertoire de contenir plusieurs certificats ayant la même valeur de hash de nom de sujet. Il est par exemple possible d'avoir dans le magasin plusieurs certificats avec le même sujet, ou plusieurs CRL avec le même émetteur (et, par exemple, une période de validité différente).
CA intermédiaires
Dans de nombreux cas, les certificats système ne sont pas directement signés par une CA racine (c'est-à-dire une CA utilisant un certificat auto-signé), mais par une CA intermédiaire. Le certificat de la CA intermédiaire est signé par la CA racine (ou par un autre niveau de CA intermédiaire).
Lors de la négociation TLS, une application peut fournir plusieurs certificats : elle peut fournir son propre certificat, suivi des certificats de toutes les CA intermédiaires jusqu'à la CA racine, en incluant éventuellement le certificat de cette dernière.
Les outils DCMTK fournissent ces certificats intermédiaires lors de la négociation TLS s'ils sont présents dans le même fichier que le certificat système, lequel est fourni comme second paramètre de l'option --enable-tls. Cela nécessite l'utilisation du format PEM, car le format DER ne prend pas en charge plusieurs certificats dans un même fichier.
Le format PEM permet de simplement concaténer les certificats dans un fichier texte, en commençant par le certificat système, suivi des certificats des CA intermédiaires, puis éventuellement du certificat de la CA racine. Sur les systèmes Linux/Posix, un tel fichier peut être créé comme suit :
cat system_cert.pem intermediate_ca.pem root_ca.pem > fullchain.pem
Les utilisateurs de certificats LetsEncrypt remarqueront que LetsEncrypt fournit automatiquement un fichier "fullchain.pem" contenant une telle chaîne de certification.
Les certificats définis comme dignes de confiance à l'aide de --add-cert-file ou --add-cert-dir ne peuvent être que des certificats de CA racine. Il n'est pas possible d'ajouter des certificats de CA intermédiaire au "magasin de confiance".
Listes de révocation de certificats
La dernière étape, facultative, de la vérification des certificats consiste à consulter les listes de révocation de certificats (CRL) afin de vérifier si un certificat de la chaîne de certification a été révoqué. Les CRL ne peuvent pas être transmises lors de la négociation TLS : elles doivent être préconfigurées, et il convient de noter que les CRL ont elles aussi une période de validité limitée, définie dans le fichier.
Les options de CRL suivantes sont disponibles à partir de DCMTK 3.6.7 :
+crl --add-crl-file [f]ilename: string- ajoute un fichier de liste de révocation de certificats (implique --enable-crl-vfy)
+crv --enable-crl-vfy- active la vérification de la CRL terminale
+cra --enable-crl-all- active la vérification de la CRL sur toute la chaîne
L'option --add-crl-file charge un fichier de CRL qui pourra être utilisé pour la consultation des CRL. Cette option peut être spécifiée plusieurs fois. Autrement, les fichiers de CRL peuvent être placés dans le répertoire de CA indiqué avec --add-cert-dir. Voir gestion par répertoire des certificats racine de confiance pour savoir comment les fichiers de CRL doivent être nommés dans ce cas.
L'option --enable-crl-vfy active la consultation de la CRL de la CA terminale, c'est-à-dire qu'une seule CRL sera vérifiée pour déterminer si le certificat système du pair est révoqué ou non. L'option --enable-crl-all active la consultation de toutes les CRL jusqu'à la CA racine, ce qui couvre également le cas où un certificat de CA intermédiaire a été révoqué.
Une fois la vérification des CRL activée, la vérification du certificat échoue si l'une des CRL requises est absente.