Vericert – validation de certificats
Les certificats électroniques permettent aux applications d’intégrer des services de sécurité tels que l’authentification des utilisateurs, la non répudiation des transactions et la confidentialité des échanges de données. La validité des certificats doit être vérifiée avant leur utilisation et après, pour la non répudiation et la confidentialité des données.
Atos, acteur européen de la sécurité des systèmes d’information propose Vericert, une solution complète de validation des certificats s’appuyant sur des politiques de validation personnalisées.
Nous suivre et nous contacter :
CRL et OCSP – Qu’est-ce qui les différencie ?
Une CRL (Certificate Revocation List) est la liste « noire» regroupant les identifiants des certificats qui ne sont plus dignes de confiance, soit parce qu’ils ont été révoqués ou parce qu’ils sont désormais invalides.
La révocation d’un certificat pour rappel consiste à annuler le certificat avant la date de son expiration effective ou à « faire opposition », la même procédure que pour une carte bancaire lorsque celle-ci a été volée par exemple. Cette action est par conséquent définitive. Après révocation le certificat n’est plus utilisable, son statut change et passe ainsi de certificat valide à révoqué.
Une CRL est datée et signée par une AC et périodiquement publiée. Pour vérifier la validité d’un certificat, le vérificateur doit envoyer une requête au serveur de publication hébergeant la CRL correspondante, avec l’identifiant de l’AC en charge du certificat ; il reçoit alors la dernière CRL générée par l’AC et doit ensuite vérifier la signature de la CRL et sa durée de validité, pour ensuite rechercher le certificat au sein de la CRL.
L’avantage de la CRL est sa simplicité, sa richesse en informations et son faible risque système. La taille de la CRL constitue toutefois son inconvénient majeur… La bande passante nécessaire à la mise à jour et à la vérification est très élevée, ce qui limite considérablement son extensibilité.
La « fraicheur » d’une CRL mérite également un point d’attention car il existe une période d’« incertitude » entre l’interrogation du statut du certificat et la date de publication effective de la CRL comme le montre l’exemple ci-dessous :
- Heure de publication de la CRL 01:00:00
- Date d’interrogation du statut d’un certificat valide dans la précédente CRL 06:00:00
- Incertitude sur le statut du certificat 5 heures.
C’est indéniable, la mise en place de mécanismes de révocation est critique pour conserver la confiance dans les certificats.
Le choix du mécanisme de révocation repose donc sur l’analyse des besoins en sécurité et en disponibilité, des contraintes de débit et de temps ainsi que sur l’architecture du système d’information.
L’OCSP « Online Certificat Status Protocol » est un Protocole de vérification de certificat en ligne. Il représente une alternative efficace puisqu’il peut permettre de vérifier en temps réel (s’il se base sur « liste blanche ») le statut d’un certificat.
L’OCSP, qui est un standard de l’IETF (RFC2560), introduit un serveur OCSP de confiance auprès duquel les vérificateurs vont s’adresser pour connaître l’état de validité d’un certificat (‘bon’, ‘révoqué’, ‘inconnu’). Le vérificateur qui a connaissance du certificat du serveur doit vérifier l’authenticité des messages signés et retournés par le serveur.
L’OCSP peut s’appuyer soit sur CRL soit sur « liste blanche » qui vérifie en temps réel le numéro du certificat transmis par l’émetteur. Via un mécanisme de requête-réponse demandant à l’Autorité de certification des informations très précises, le protocole OCSP réduit ainsi au maximum la période d’incertitude entre les dates et heures de mises à disposition des CRL. Un transpondeur OCSP fournit donc des informations de révocation plus récentes que les CRL téléchargées de façon asynchrone, mais il doit pour cela être joignable en permanence.
Facile à utiliser
Vericert permet de valider les certificats de manière simple, cohérente et puissante.
Flexibilité
Une ou plusieurs stratégies de validation peuvent être définies afin de répondre aux besoins des différentes applications.
Expertise
Atos a développé une expertise unique en matière de sécurité des systèmes d’information, alliant savoir-faire dans le conseil et l’intégration de systèmes et une connaissance approfondie des technologies de sécurité d’entreprise.
En pratique, une requête OCSP contient :
- la version du protocole
- le service demandé
- les informations du certificat pour connaître son statut
- les extensions supportées ou non par le serveur OCSP en tant que signature de la requête.
La réponse signée du transpondeur contient :
- la version utilisée du protocole afin de construire la réponse
- la réponse sur le statut du certificat demandé
- le bloc de signature
- le certificat du serveur OCSP interrogé
- l’heure de production de la réponse
- l’heure exacte à laquelle la réponse est fournie (cette information est tributaire de l’aspect ou non temps réel de l’information).
Si l’information transmise n’est pas instantanée, apparaît alors une information complémentaire de type « prochaine mise à jour » qui indique le moment où le statut du certificat peut être contrôlé. En fonction du besoin client, le service OCSP met en œuvre différents mécanismes pour garantir la « fraîcheur » des informations qui sont à disposition du transpondeur !
Vous l’aurez compris, afin de satisfaire au mieux vos exigences environnementales, le choix d’une méthode de révocation par rapport à une autre doit être fait en fonction des exigences de l’application (surtout en matière de fraîcheur d’informations de révocation et niveau de sécurité), du niveau de disponibilité des ressources dans le système (bande passante, puissance de calculs, etc.) et du délai de calcul toléré.
Dans cette dynamique d’optimiser davantage le service, nous recommandons de combiner l’OCSP avec un service d’horodatage électronique. Il s’agit d’un service de sécurité qui permet d’attester que des données sous forme électronique existaient bien à un instant donné. L’horodatage consiste donc à apposer à un fichier une date provenant d’une source de temps fiable sous la forme d’un jeton.
Dans la pratique, lors de l’horodatage d’un document électronique, le jeton d’horodatage scelle le document avec une datation « universelle » pour en garantir son intégrité et sa valeur probante. L’horodatage constitue donc une preuve juridique incontestable.
La vérification du statut des certificats est une phase cruciale dans un processus de contrôle d’authentification ou de validation de signature. IDnomic en a bien conscience et c’est pour cette raison qu’elle met à disposition de ses clients une plateforme intégrant les services OCSP et TSP « Time Stamping Protocol » !
Vericert est distribué en Appliance Virtuelle ou sous forme de modules installables par le client dans son environnement. Il est géré par le biais d’une interface web. Quand un certificat est validé conformément à une politique de validation, vericert est accessible via une interface web (RPC-SOAP) utilisant HTTP ou HTTPS (SSL). Les réponses peuvent être signées.
Vericert est aussi accessible via le protocole OCSP (RFC 2560).
Vericert comporte les fonctionnalités suivantes
► Le stockage sécurisé des certificats
► Optimisation des performances via le préchargement des CRLs obtenues à partir de points de distribution prédéfinis
► Le chargement des TSL (« Trusted Service List ») pour le support des AC reconnues
► Un serveur OCSP pour fournir les statuts de révocation des certificats
Personnalisation des politiques de validation
En utilisant une interface web, il est possible d’administrer :
► des certificats d’autorités de certifications
► les chemins de certification
► les politiques de certification reconnues
► des valeurs d’usage de clés
► des valeurs d’usage étendues des clés compatible avec le format RFC 5280
Vericert comportent les options suivantes
► un HSM (Hardware Security Module) qui protège les clés utilisées pour signer les réponses de validation ou les réponses OCSP
► Vericert supporte différents HSM qu’ils soient fournis par Atos (Trustway Proteccio ou Trustway crypt2pay) ou par d’autres sociétés
Normes et standards pour les interfaces et les protocoles
► Format de certificat compatible avec ITU-T X.509v3 et RFC 52800
► Information de révocation compatible avec ITU-T X.509v2 CRL et le protocole OCSP (RFC 2560)
► SOAP 1.1 et WSDL 1.1 pour la validation des certificats contre une politique de validation
► RFC 2560 pour les statuts de révocation des certificats
► Connexio : HTTP, LDAP et HTTPS
Les politiques de validation
Une politique de validation est un ensemble de règles définissant les conditions de validation des certificats. Elle peut couvrir des cas plus ou moins complexes. Une ou plusieurs politiques
de validation peuvent être définies puis personnalisées afin de répondre au mieux aux besoins des différentes applications.
La validation d’un certificat donné requiert au minimum :
► un chemin de certification jusqu’à une autorité de certification (AC) reconnue
► une politique de validation.
Le statut de validation de chaque certificat appartenant au chemin de certification doit être vérifié à l’aide de CRLs (Certificate revocation list) ou de réponses OCSP (On-line Certificate Status Protocol).
Des contraintes supplémentaires peuvent être définies dans la politique de validation, telles que des politiques de certification reconnues, la longueur du chemin de certification ou les conditions d’utilisation des clés.
Vericert, un service centralisé de validation des certificats
La centralisation proposée par vericert simplifie l’accès aux informations nécessaires pour la validation des certificats. Les certificats des AC, les CRLs correspondantes sont collectés par vericert qui les fournit en retour au demandeur.
Les informations collectées pour répondre à une requête peuvent être partiellement ou totalement réutilisées pour une autre demande, permettant ainsi d’améliorer le délai de réponse et de réduire la charge du réseau.
Quand la validation d’un certificat se réfère à une date antérieure à la requête, les certificats, les CRLs et les réponses OCSP, déjà fournis par vericert, doivent être retournés par le demandeur.
Le règlement eIDAS, permet à l’Union Européenne de donner un cadre juridique pour les transactions numériques transnationales visant à renforcer la confiance des échanges électroniques. Il instaure un cadre s’appliquant à l’identification électronique et aux services de confiance, couvrant notamment le sujet de la signature électronique. Ainsi, le règlement eIDAS renforce la transparence et la fiabilité des transactions.
Découvrez comment nous pouvons vous accompagner sur le chemin de la conformité avec nos solutions.
Découvrez-en plusDocuments et actualité
Factsheet
Vericert – Renforcer et centraliser la validation des certificats
Les certificats électroniques permettent aux applications d’intégrer des services de sécurité
tels que l’authentification des utilisateurs, la non répudiation des transactions et la confidentialité des échanges de données. La validité des certificats doit être vérifiée avant leur utilisation et après, pour la non répudiation et la confidentialité des données.
Webinaire
Dopez vos procédures de dématérialisation avec la signature électronique en regardant notre webinaire avec un retour d’expérience avec l’APHM.