Aller au contenu

EJBCA

Un article de Wikipédia, l'encyclopédie libre.
EJBCA
Description de l'image Logo EJBCA 2023.svg.
Description de cette image, également commentée ci-après
EJBCA 8.0.0 – Administration web
Informations
Développé par PrimeKey Solutions et contributeurs externes
Première version
Dernière version 8.3.2 ()
Dépôt github.com/Keyfactor/ejbca-ceVoir et modifier les données sur Wikidata
État du projet Développement actif
Écrit en Java (Java EE)
Système d'exploitation MultiplateformeVoir et modifier les données sur Wikidata
Environnement Multiplate-forme
Langues Multilingue (bs + cs + de + en + fr + ja + pt + sv + uk + vi + zh)
Type Infrastructure de gestion de clés (IGC)
Licence LGPL-2.1-or-later
Site web www.ejbca.org

modifier - modifier le code - voir Wikidata (aide)

EJBCA ou Enterprise JavaBeans Certificate Authority est une solution logicielle de PKI – ou IGC, Infrastructure de gestion de clés – libre[1] et gratuite, développée et distribuée par l’entreprise suédoise PrimeKey Solutions[2] AB, devenue une filiale de Keyfactor[3] Inc. Le projet EJBCA est développé selon les méthodes du logiciel libre et open source, et dont le code source est disponible selon les termes de la licence GNU Lesser General Public License (LGPL).

EJBCA permet la mise en œuvre d’une plate-forme d’IGC composée d’une autorité de certification (AC), d’une autorité d’enregistrement (AE) et d’une autorité de validation (en) (AV) privées ou publiques. Le logiciel EJBCA est basé sur la librairie CESeCore[4], qui s’appuie elle-même sur l’API (Interface de programmation) cryptographique Bouncy Castle (en).

EJBCA est utilisée par plusieurs gouvernements, notamment de l’Union européenne, pour leur sécurité interne, et l’émission de passeports électroniques et de cartes d’identité électroniques[5]. Les entreprises privées utilisent également EJBCA, et sont intéressées par les nouvelles fonctionnalités (2023) telles que les algorithmes post-quantiques et la sécurisation de l’Internet des objets[6].

Fonctionnalités

[modifier | modifier le code]

EJBCA fournit les principales fonctionnalités[7] d’une infrastructure de gestion de clés, telles qu’une autorité de certification (AC), une autorité d’enregistrement (AE) et une autorité de validation (en) (AV). Ces fonctionnalités peuvent être déployées ensemble ou séparément, sous la forme de modules désignés par leur sigle anglophone : CA (pour les autorités de certification), RA (pour les autorités d’enregistrement) et VA (pour les autorités de validation).

Fonctionnalités d’autorité de certification

[modifier | modifier le code]

La mise en œuvre d’un seul module CA (Certificate Authority) permet de gérer plusieurs autorités de certification qui peuvent être organisées de façon hiérarchique et sur plusieurs niveaux de subordination. Ainsi, il est possible de créer des AC racines (dont le certificat est auto-signé) et des AC subordonnées (dont le certificat est signé par une autre AC). EJBCA permet également de générer plusieurs types d’AC : X.509, CVC[8], SSH CA[9], ITS ECA[10] (Enrollment Certification Authority), AC hybride[11].

Fonctionnalités d’autorité d’enregistrement

[modifier | modifier le code]

Le module RA (Registration Authority) permet de mettre en œuvre les principales fonctionnalités d’une autorité d’enregistrement, c’est-à-dire la gestion des clés et la gestion des certificats. Ainsi, il est possible de créer des clés cryptographiques, de les renouveler, de les mettre en séquestre et de vérifier leur validité du point de vue cryptographique. Les certificats peuvent être émis en mode centralisé (dans ce cas, les clés sont générées par la PKI elle-même) ou en mode décentralisé (dans ce cas, les clés sont générées par le demandeur qui peut être une personne physique ou un client logiciel).

Rôles et opérations

[modifier | modifier le code]

Une PKI EJBCA est gérée par des personnes pouvant avoir un des principaux types de rôle suivants : administrateur PKI, officier d’enregistrement, officier de révocation et auditeur. Un administrateur PKI configure les autorités de certification, les profils de certificats (i.e. gabarit technique d’un certificat), les services et les protocoles. Un officier d’enregistrement vérifie l’identité du futur titulaire du certificat, puis procède à son enregistrement. Un officier de révocation peut révoquer un certificat sur demande soit de l’abonné soit de l’autorité de certification. Un auditeur peut consulter tout le paramétrage de la PKI, ainsi que les journaux d’audit, en lecture seule. Des rôles personnalisés peuvent être définis selon un type de rôle choisi, selon des autorités de certification données et selon des profils de certificats donnés.

Services et interfaces

[modifier | modifier le code]

Pour faciliter la gestion de la PKI et des certificats, EJBCA propose de nombreux services tels que : un service de génération de CRL (Certificate Revocation List), un service de validation de certificats selon le protocole OCSP (Online Certificate Status Protocol), un service de publication LDAP (pour publier les CRL et les certificats), un service de notification par courriel (afin par exemple d’avertir l’abonné de l’expiration proche d’un certificat dont il est titulaire ou responsable), un service de journalisation, etc. Le protocole OCSP est mis en œuvre dans le module VA (Validation Authority).

La PKI EJBCA peut être gérée et configurée selon plusieurs interfaces, dont voici les plus courantes : interface web, Web Service (SOAP, REST), protocole SCEP (Simple Certificate Enrollment Protocol), protocole ACME (Automated Certificate Management Environment) ou interface en ligne de commande (CLI).

Les interfaces web d’EJBCA existent en plusieurs langues : allemand, anglais, français, japonais, tchèque, vietnamien (pour l’interface d’administration)[12] ; et allemand, anglais, suédois, vietnamien (pour l’interface de l’autorité d’enregistrement).

Architectures et intégration

[modifier | modifier le code]

EJBCA supporte toutes les architectures PKI courantes[13], ainsi que la plupart des HSM (Hardware Security Module, module de sécurité matériel) du marché via l’API standard PKCS #11 (en).

Caractéristiques

[modifier | modifier le code]

Primitives cryptographiques

[modifier | modifier le code]

Algorithmes asymétriques

[modifier | modifier le code]
  • PQC : CRYSTALS-Dilithium, Falcon (en) (depuis EJBCA 8.0.0, expérimental, standardisation NIST pour 2024)
  • ECC : plus de 50 courbes, dont les courbes du NIST (P-224, P-256, P-384, P-521), les courbes Brainpool, la courbe française FRP256v1[14], les courbes Curve25519 et Curve448 (en) (depuis EJBCA 7.4.0)
  • RSA : 1024, 1536, 2048, 3072, 4096, 6144, 8192 bits
  • DSA : 1024 bits (supprimé depuis EJBCA 8.3.0)

Fonctions de hachage

[modifier | modifier le code]

Protocoles et standards

[modifier | modifier le code]

Support applicatif et matériel

[modifier | modifier le code]
  • Serveurs d’applications : WildFly (version communautaire), JBoss EAP (avec support Red Hat)
  • Systèmes d’exploitation : GNU/Linux, Unix, FreeBSD, Solaris, Windows
  • Bases de données : PostgreSQL, MariaDB, MySQL, Oracle DB, IBM DB2, MS-SQL, Hypersoniq, Derby, Sybase, Informix, Ingres
  • Annuaires LDAP : OpenLDAP, Active Directory, LDAPv3, Sun Directory Server
  • Modules HSM[28] : nCipher netHSM, nCipher nShield, SafeNet Luna Network HSM7, SafeNet Luna SA, SafeNet Luna PCI, SafeNet ProtectServer Gold, Thales Trusted Cyber Technologies (TCT) Luna SA, Atos Trustway Proteccio, Bull TrustWay CryptoBox, Bull TrustWay PCI Crypto Card, Utimaco R2, Utimaco R3, Utimaco SafeGuard CryptoServer, Utimaco CryptoServer CP5, Securosys Primus HSM, Crypto4A QxHSM, Futurex HSM, I4P Trident HSM, Cavium Nitrox III, BlackVault HSM, ARX CoSign, AEP Keyper
  • HSM dans le Cloud : AWS CloudHSM, AWS KMS (en), Azure Key Vault, Azure Managed HSM, Google Cloud Platform (GCP) KMS[29], IBM Hyper Protect Crypto Services (HPCS)[30], Thales Data Protection on Demand (DPoD)[31], Securosys CloudsHSM[32], Fortanix Data Security Manager HSM
  • Cartes/tokens HSM : SmartCard-HSM, Nitrokey HSM, YubiHSM 2, OpenSC (générique)
  • API et outils logiciels PKCS11 (en) : IronCAP Crypto (ICC), OpenSC (en), SoftHSM (en), PKCS11 Spy, Unbound Key Control (UKC)

Certifications et conformité

[modifier | modifier le code]

Critères communs

[modifier | modifier le code]

EJBCA v7.4 a été certifié[33] conforme aux Critères communs (réf. : CSEC2019005)[34] le selon le profil de protection collaboratif « Certification Authorities »[35] (PP4CA).

EJBCA v5.0 a été certifié[36] conforme aux Critères communs (réf. : ANSSI-CC-2012/47) le selon le profil de protection « Certificate Issuing and Management Components » (PP-CIMC : composants de gestion et d’émission de certificats), niveau EAL 4+.

La librairie CESeCore – cœur de sécurité d’EJBCA – a été certifiée[37] conforme aux Critères communs (réf. : ANSSI-CC-2012/33) le , niveau EAL 4+.

Référentiel général de sécurité

[modifier | modifier le code]

Les caractéristiques[7] d’EJBCA permettent – par paramétrage – d’avoir des instances conformes au Référentiel général de sécurité (RGS v2) de l’ANSSI (Agence nationale de la sécurité des systèmes d’information, administration française).

ETSI eIDAS

[modifier | modifier le code]

Les caractéristiques[7] de l’édition « Entreprise » d’EJBCA permettent – par paramétrage – d’avoir des instances pouvant être qualifiées selon la conformité européenne eIDAS (Electronic Identification and trust Services) de l’ETSI (European Telecommunications Standards Institute), c’est-à-dire selon le standard ETSI EN 319 411-2[38].

CA/Browser Forum

[modifier | modifier le code]

Par paramétrage, les profils de certificats EJBCA peuvent être conformes aux exigences du CA/Browser Forum (en)[39].

Ainsi, EJBCA peut émettre des certificats serveurs TLS conformes aux exigences de base[40] du CA/Browser Forum, ainsi que des certificats EV (Extended Validation, ou Certificat à validation étendue (en)) conformes aux recommandations EV[41] du CA/Browser Forum.

EJBCA peut également émettre des certificats de signature de code (Code Signing)[42], des certificats d’horodatage (Time-stamping) et des certificats de sécurisation de courriels (S/MIME)[43], conformémant aux exigences du CA/Browser Forum.

Ainsi, cela permet aux AC concernées d’être conformes aux Root Programs (en) des navigateurs web.

Notes et références

[modifier | modifier le code]
  1. ↑ (en) https://www.ejbca.org/license/
  2. ↑ (en) https://www.primekey.com/
  3. ↑ (fr) https://www.keyfactor.com/fr/
  4. ↑ (fr) https://www.ssi.gouv.fr/administration/certification_cc/cesecore-version-1-1-2/ Librairie CESeCore sur le site de l’ANSSI
  5. ↑ (en) https://joinup.ec.europa.eu/collection/eidentity-and-esignature/solution/ejbca/about EJBCA on the Joinup platform of the European Commission
  6. ↑ (en) https://www.iot-now.com/2023/06/29/132157-keyfactor-launches-ejbca-8-0-and-signserver-6-0-enhanced-iot-security/ Article about EJBCA, the post-quantum readiness, and Internet of Things (IoT) security, on IoT Now
  7. ↑ a b et c (en) https://docs.keyfactor.com/ejbca/latest/ejbca-concepts
  8. ↑ (en) https://docs.keyfactor.com/ejbca/latest/cvc-ca Card Verifiable Certificates (CVC) CA
  9. ↑ (en) https://docs.keyfactor.com/ejbca/latest/ssh-ca SSH (Secure Shell) CA
  10. ↑ (en) https://docs.keyfactor.com/ejbca/latest/c-its-eca-overview C-ITS (Cooperative Intelligent Transport Systems) PKI architecture and concepts, and Enrollment Certification Authority (ECA)
  11. ↑ (en) https://docs.keyfactor.com/ejbca/latest/hybrid-ca Hybrid CA
  12. ↑ L’interface d’administration web supporte de façon très incomplète les langues suivantes : bosniaque, chinois, portugais, suédois, ukrainien.
  13. ↑ (en) https://docs.keyfactor.com/ejbca/latest/ejbca-architecture
  14. ↑ (fr) https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000024668816 Legifrance, JORF n° 0241 du 16 octobre 2011 page 17533, texte n° 30, “FRP256v1”
  15. ↑ (en) Request for comments no 5280
  16. ↑ (en) Request for comments no 6187
  17. ↑ (en) Request for comments no 3739
  18. ↑ (en) Request for comments no 6960
  19. ↑ (en) Request for comments no 4210
  20. ↑ (en) Request for comments no 7030
  21. ↑ (en) Request for comments no 8555
  22. ↑ (en) https://www.certificate-transparency.org/
  23. ↑ (en) Request for comments no 6962
  24. ↑ (en) Request for comments no 6844
  25. ↑ (en) Request for comments no 5652
  26. ↑ (en) Request for comments no 4211
  27. ↑ (en) Request for comments no 4511
  28. ↑ (en) https://docs.keyfactor.com/ejbca/latest/hardware-security-modules-hsm Vendor Specific Information (liste des modules HSM supportés par EJBCA)
  29. ↑ (fr) https://cloud.google.com/security-key-management Google Cloud Platform (GCP) KMS (Key Management Service)
  30. ↑ (fr) https://www.ibm.com/fr-fr/cloud/hyper-protect-crypto IBM Hyper Protect Crypto Services (HPCS)
  31. ↑ (en) https://cpl.thalesgroup.com/encryption/data-protection-on-demand Thales Data Protection on Demand (DPoD) HSM
  32. ↑ (en) https://www.securosys.com/primekey-ejbca Securosys Primus HSM or CloudsHSM
  33. ↑ (en) https://www.commoncriteriaportal.org/files/epfiles/Certification%20Report%20-%20PrimeKey%20EJBCA.pdf Rapport de certification Critères communs
  34. ↑ (en) https://www.commoncriteriaportal.org/files/epfiles/Certificate%20CCRA%20-%20PrimeKey.pdf Certificat CCRA (Common Criteria Recognition Arrangement)
  35. ↑ (en) https://www.commoncriteriaportal.org/files/ppfiles/pp_ca_v2.1.pdf Profil de protection PP4CA
  36. ↑ (en) https://www.commoncriteriaportal.org/files/epfiles/ANSSI-CC-2012_47.pdf Rapport de certification Critères communs
  37. ↑ (en) https://www.commoncriteriaportal.org/files/epfiles/ANSSI-CC-2012_33.pdf Rapport de certification Critères communs
  38. ↑ (en) https://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.02.02_60/en_31941102v020202p.pdf ETSI EN 319 411-2
  39. ↑ (en) https://cabforum.org/
  40. ↑ (en) https://cabforum.org/working-groups/server/baseline-requirements/documents/ Exigences de base pour les certificats serveurs TLS, CA/Browser Forum
  41. ↑ (en) https://cabforum.org/working-groups/server/extended-validation/documents/ Recommandations EV pour les certificats serveurs TLS, CA/Browser Forum
  42. ↑ (en) https://cabforum.org/working-groups/code-signing/documents/ Exigences pour les certificats de signature de code et les certificats d’horodatage, CA/Browser Forum
  43. ↑ (en) https://cabforum.org/working-groups/smime/documents/ Exigences pour les certificats S/MIME, CA/Browser Forum

Annexes

[modifier | modifier le code]

Bibliographie

[modifier | modifier le code]
  • Christophe CACHAT et David CARELLA, PKI Open Source : Déploiement et administration, Paris, Éditions O’Reilly, , 600 p. (ISBN 2-84177-235-7)

Articles connexes

[modifier | modifier le code]

Liens externes

[modifier | modifier le code]
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=EJBCA&oldid=220609527 ».