Friday, December 19, 2014

Improved crypto token configuration and re-keying in SignServer 3.6

SignServer 3.6 brings great improvements in both crypto token configuration and management. There is now the advantage of single crypto token configuration and, related to this, re-keying has become far more convenient.

Single crypto token configuration

As crypto token configuration in SignServer 3.6 is now done in a single spot, management has become significantly simpler.

In previous versions, the necessity to configure keystores (soft or PKCS#11) in each worker resulted in duplicated configuration. The repetitive steps couldn't be avoided even when all workers shared the same keystore or HSM slot.

From version 3.6 there is separation between worker and crypto token configuration, which eliminates duplicate configuration entirely. You simply set up a single crypto worker (a special type of worker). Other workers, using key-pairs in the same keystore or HSM slot, will then point to the singly configured crypto worker.

One crypto token and multiple workers

Crypto token referenced from another worker

Rekeying without production stop

Achieving rekeying without production stop used to be a bit of a hassle. Special care had to be taken to ensure that at least one signer was available to handle emerging requests.

To everyone's satisfaction rekeying has improved as of version 3.6. Crypto workers now stay active as the keying process does not change the configuration of the crypto token. Entirely superfluous, special measures to avoid production halt are now history.

In practice, the process of rekeying (generating a new key-pair and getting a new certificate for it)  always has to be done before the signer's certificate expires. In the Admin GUI every operation is accessed in the tool bar, from the corresponding buttons (screen shot below) which basically follow these five steps:
  1. Activate the worker
  2. Renew the key-pair
  3. Test the key-pair
  4. Generate CSR
  5. Install certificates

AdminGUI toolbar


Step 2 previously put the worker in an off-line state but with the new crypto worker configuration this is not the case, and it can thus stay active at all times, greatly facilitating re-keying in production.

Trying it out

Let's configure a PDF signer which uses keys provided by a crypto worker.

Set up a new crypto worker configuration by copying the sample config file:
$ cp doc/sample-configs/keystore-crypto-configuration.properties \
  my-crypto-config.properties

Edit my-crypto-config.properties by changing the keystore path to point to the sample keystore provided:
GLOB.WORKERGENID1.CLASSPATH=\
     org.signserver.server.signers.CryptoWorker
GLOB.WORKERGENID1.SIGNERTOKEN.CLASSPATH=\
     org.signserver.server.cryptotokens.KeystoreCryptoToken
WORKERGENID1.NAME=CryptoTokenP12
WORKERGENID1.KEYSTORETYPE=PKCS12
WORKERGENID1.KEYSTOREPATH=\
     /opt/signserver/res/test/dss10/dss10_signer1.p12

Apply the configuration (replace WORKERID with ID printed):
$ bin/signserver setproperties my-crypto-config.properties
$ bin/signserver reload WORKERID

Activate the crypto token in the crypto worker (password is "foo123"):
$ bin/signserver activatecryptotoken CryptoTokenP12

Set up a new PDF signer using your newly activated crypto worker:
$ cp doc/sample-configs/qs_pdfsigner_configuration.properties\
  my-pdf-config.properties

Set my-pdf-config.properties to point to the crypto worker:
GLOB.WORKERGENID1.CLASSPATH=\
     org.signserver.module.pdfsigner.PDFSigner
WORKERGENID1.NAME=PDFSigner
WORKERGENID1.AUTHTYPE=NOAUTH
WORKERGENID1.CRYPTOTOKEN=CryptoTokenP12

Apply the configuration (replace WORKERID with ID printed):
$ bin/signserver setproperties my-pdf-config.properties
$ bin/signserver reload WORKERID

View the status of the workers:
$ bin/signserver getstatus brief all
Current version of server is : SignServer CE 3.6.2

Status of CryptoWorker with id 1 (CryptoTokenP12) is:
   Worker status : Active
   Token status  : Active

Status of Signer with id 2 (PDFSigner) is:
   Worker status : Active
   Token status  : Active
   Signings      : 0

You can also get more information by writing "complete" instead of "brief" or by using the Admin GUI:
$ bin/signserver-gui

More information

Basic information on SignServer Enterprise is available here. For entire documentation, see signserver.org.

Wednesday, September 17, 2014

Comparing EAC 2.10 to the previous 1.11

EAC 2.10 CV certificates are supported as of EJBCA Enterprise 6.1.0. This is an upgrade from the previously supported EAC 1.11. So, what's new in EAC 2.10 and why would you even need EAC certificates at all?

About Extended Access Control

Extended Access Control (EAC) is the technology used to protect fingerprints (or irises) in EU member states' e-passports, but in some eIDs other information is protected as well. As used in the EU, EAC is defined in the BSI technical specification TR-03110. Based on public key infrastructure (PKI), EAC works as an authentication mechanism between the terminal and the ePassport/eID chip. The specification includes several steps such as both chip- and terminal authentication, but only terminal authentication concerns PKI.

In an EAC process, each inspection system or terminal is given a CV Certificate (CVC) which gives the inspection system privileges to perform specific actions, or to read certain data from the e-passport or eID chip. If the inspection system cannot authenticate itself towards an e-passport or eID chip, the latter will deny access to the data or function.

The news in EAC 2.10

So what are the differences in EAC 2.10 compared to EAC 1.11? As mentioned, 1.11 was designed for ePassports only. With EAC 2.10 the use cases have been extended to other security documents, such as eIDs. In the context of EJBCA, we are primarily interested in terminal authentication (the part where the PKI implements something). Here, the main difference in EAC 2.10 is additional access control templates, used to specify new types of terminals relating to eIDs and digital signatures. There is also room for extensions, but since none have been specified at this stage and no sample certificates are using extensions, this is mostly a placeholder for future additions.

The CVC Terminal Type options illustrated
The news in EAC 2.10 may most easily be illustrated by a few screenshots of the Admin GUI in EJBCA Enterprise 6.2.0.
In EAC 1.11 the only CVC terminal type available  was Inspection System (allowing you to select DG3 and/or DG4). This option still provides an inspection system able to read fingerprints, and/or iris data, from e-passports. In the first image however, you can see the EAC 2.10 CVC terminal type (upper left corner) with two new options next to Inspection System: Authentication Terminal and Signature Terminal. Click the image to enlarge!

EAC 2.10 CVC terminal type options in EJBCA Enterprise 6.2.0.
CVC terminal type

So, what hides behind the new Authentication Terminal and the Signature Terminal options?

The Authentication Terminal can be given fine grained (read and write) control to any data group on an eID, as well as control to additional eID functions such as PIN Management and Age Verification.

Pic 1: CVC access rights of the Authentication Terminal in EAC 2.10, EJBCA Enterprise 6.2.0. Click to enlarge!
Authentication Terminal (pic 1)

Pic 2: CVC access rights of the Authentication Terminal in EAC 2.10, EJBCA Enterprise 6.2.0.
Authentication Terminal (pic 2)

The Signature Terminal on the other hand, can either be given the role of an Accreditation Body or a Certification Service Provider, where each can be allowed to generate signatures and/or qualified signatures.

Pic 1: Body or a Certification Service Provider options in the Signature Terminal in EAC 2.10, EJBCA Enterprise 6.2.0.
Signature Terminal (pic 1)

Pic 2: Body or a Certification Service Provider options in the Signature Terminal in EAC 2.10, EJBCA Enterprise 6.2.0.
Signature Terminal (pic 2)

Summary
To sum up the additional features in EAC 2.10:
  • New terminal types for using eIDs.
  • New access controls for mentioned terminals.
  • Possibility for extensions.

More information

Basic information on EJBCA Enterprise PKI is available here.
EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries.

About the author
Tomas Gustavsson, CEO/CTO of PrimeKey, founder of EJBCA
Contact me at tomas(at)primekey.se.
Follow me on Twitter.
Follow PrimeKey on Twitter.

Tuesday, June 3, 2014

Certificate Transparency with EJBCA Enterprise

As of the release of version 6.0.4, EJBCA Enterprise now supports Certificate Transparency RFC6962.

Google Initiative to Increase https Security

Certificate Transparency (CT) is an initiative by Google to increase security and auditability of the https ecosystem itself. These important aims are accomplished by having CAs (CA services using a software such as EJBCA) issue TLS certificates, which are transparently auditable and exactly reveals which certificates have been issued. The purpose of CT is to create public audit logs of all certificates issued by the public SSL/TLS CAs. For example, this means the owners of a certain web domain can monitor CT Log servers, to see if there are any unknown or suspicious TLS certificates issued for their domain. In addition, the presence of audit records is planned to be required for EV certificates in Google Chrome from February 2015. And perhaps later on for other web browsers and non-EV certificates as well.

Note that Certificate Transparency is only relevant for CAs issuing public SSL/TLS certificates; other types of CAs mustn't use CT at this time. More information can be found on the CT website.
The specification of Certificate Transparency is still being discussed, and a follow up to RFC6962 will likely be available in the not so distant future, including (among other things) a way to handle private subdomains.

How EJBCA Enterprise perceives Certificate Transparency

From the CA's angle, CT works by publishing pre-certificates from itself to the log servers; then in immediate response, Signed Certificate Timestamps (SCTs) are retrieved. Certificate and timestamp exchange is done within a single operation, so requesting an SCT for a certificate also publishes it. The resulting SCTs can then be sent to end-users in any of three different ways: 1) in a certificate extension (embedded when issuing the real certificate), 2) in a stapled OCSP response extension, 3) and/or in a TLS extension (yes, EJBCA does support all of those methods, including any combination of the three).

The EJBCA Admin Guide describes how to configure EJBCA Enterprise for one or more of the above methods.

For more information, contact:
Tomas Gustavsson, CEO of PrimeKey, founder of EJBCA
tomas(at)primekey.se.
Follow me on Twitter

Tuesday, April 8, 2014

Securing 4690 POS Terminals with PKI

Point of Sale (POS) terminals, communicate not only to all of the cash registers of a store, but also to central location. In order to secure this particular type of communication, and secure other items on the terminals as well, you need to add keys and certificates managed by a PKI.
To enable POS terminals to enroll for certificates specifically against an EJBCA® Enterprise PKI server, C2 Company and PrimeKey have successfully installed and used the EJBCA Enterprise clientToolBox on several Toshiba 4690 POS terminals.

About POS and Toshiba 4690

Commonly used in POS terminals, the Toshiba 4690 is an operating system which is basically IBM Java and DOS based, using specific 4690 DOS commands. So, if you are used to common computing with Linux or Windows, the Toshiba will appear a bit alien. However, taking the trouble to introduce PKI to the POS system, will enable any user of the 4690 terminals to trade on both strong authentication and encryption.

Steps to Enroll and Renew Certificates

Having IBM Java on board, helped us run EJBCA clientToolBox on Toshiba 4690, and made it possible to enroll and manage certificates. The Toshiba required some figuring out of which new commands to run, but once that was (elegantly) performed by C2, EJBCA clientToolBox was running ever so nicely.
The following steps are only a single example of how you can use the certificate management capability on POS terminals. In fact, there are limitless possibilities.
Use the Native DOS commands to generate keys and CSRs. Once those are generated you can enroll for a certificate against EJBCA, using clientToolBox.
To enroll new terminals for the first time when they are installed in a store, you can use a pre-installed certificate on the POS terminal image. To enroll for the real terminal certificate you use the pre-istalled certificate temporarily, to enable access from the POS terminal to EJBCA. The pre-installed certificate does not need any admin access in the EJBCA system. Do the following:
  • Install a new POS terminal with an image, including a pre-installed communication certificate on the image.
  • Register the POS terminal (with serial number or similar) in EJBCA, and you'll receive a one-time enrollment code.
  • Generate keys and a CSR (to the csr.pem file) on the POS terminal, by using DOS commands.
  • Submit the CSR to EJBCA, to get the signed certificate back, using this command:
./ejbcaClientToolBox.sh EjbcaWsRaCli pkcs10req terminalSerial enrollmentCode csr.pem PEM NONE certificate.pem
Now you are ready to remove the pre-installed communication certificate from the image, to finally make the image secure, only by its rightful individual certificate. However, to block the POS terminal from accessing store systems (in case the terminal gets stolen or hacked) the latter step can be revoked.
A single PKI administrator action is found in the above work-flow; registering the POS terminal in EJBCA. This is done in order to authenticate the initial enrollment and make sure that no unauthorized terminal receives real certificates, that is, illegitimate access to store systems. With the final certificate installed, the terminal can automatically renew it before expiry, requiring no PKI administrator action during daily operations.

More information

Fore more information, or to get in touch with C2 for help with securing your POS terminals, contact Chris or me. Cheers!
Chris Chu
chris at c2company.com
Tomas Gustavsson
tomas at primekey.se
Twitter

Wednesday, March 26, 2014

EJBCA Enterprise 6.1.0 released

The PrimeKey EJBCA® team is happy to announce the release of EJBCA Enterprise 6.1.0.
This release resolves several issues, with a few highlights: Increased performance through OCSP improvements; Key Recovery improvements; support for EAC 2.10 (ePassport) access control templates.
Running on the latest technology platforms, EJBCA Enterprise v.6 is so flexible it is suitable for any organization, cloud, social or mobile system. Faster, more resource efficient, more secure and more user friendly than ever.

EJBCA Enterprise *6.1.0* release notes

A maintenance release containing 32 new features and improvements, below a selection of the most noteworthy:
  • New features

    • New OCSP features related to RFC 6960, minimizing size of OCSP responses.
    • Implemented OCSP signing algorithm selection from client requested algorithms.
    • CVC certificate profiles (ePassport PKI) now supports EAC 2.10 access control templates.
  • Improvements

    • OCSP improvements with more cache control settings.
    • Improvements to Key Recovery, enabling encryption key rollover and providing more information about encryption keys.
    • Ability to build and install EJBCA on Windows platforms.
    • The ManagementCA created during default install, now uses SHA256WithRSA.
    • EJBCA compiles cleanly with Java 8, WildFly 8 and Glassfish 4 (running on those platforms however, is not yet supported).
    • EJBCA can now use certificate serial number longer than 64 bits.
    • Many reported minor issues have been fixed, as well as minor GUI improvements.

More information

Basic information on EJBCA Enterprise PKI is available here. For entire technical details view the changelog in the PrimeKey Issue Tracker.
EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries.

Wednesday, March 12, 2014

Using CMP with BouncyCastle Java API

Introduction

A convenient method to enroll for certificates and do automatic certificate renewal, is to use the BouncyCastle API to implement a client that uses the CMP (RFC4210) protocol. In this example the implementation is done using java code and you need a CA that supports the CMP protocol on the server side.

Using the CMP protocol is a good way to integrate clients and RAs in a PKI, and BouncyCastle API is a great tool for this task. By the way, BouncyCastle needs your support to fund a FIPS certification. Help spread the word.

A short background on CMP

The open source CA EJBCA, implements many standard PKI protocols, CMP being one of them.

In the early days of CMP there were mainly commercial SDK implementations, and only a single open source instance (written in C). As always, that slowed down adoption. Nowadays, there is full support for CMP in the governing de-facto standard java crypto API BouncyCastle. No more excuses not to use CMP! :-)

Described more in detail in a previous blog post is CMP and its implementation in EJBCA.

Examples on how to use BouncyCastle CMP API

Here, I will show two different enrollment types (with source code) for the client implementation: 1) an RA using a shared secret authentication and 2) a client using certificate authentication.
These are by no means everything you can do. The RA can also use certificate authentication, or you can do nested messages with multiple layers of authentication. And many, many more! Only your imagination sets the limits :-).

All mentioned configurations can be active at the same time when using EJBCA 6. For complete documentation, see the Admin Guide at EJBCA.org.

Enrollment type 1) RA with shared secret authentication

Using an RA means the RA is configured to order certificates for its clients. The clients themselves will not be pre-registered by the CA, but will be added by the RA when it enrolls for the client.

To create a CMP enrollment message for an RA, using BouncyCastle:

CertificateRequestMessageBuilder msgbuilder = new CertificateRequestMessageBuilder(BigInteger.valueOf(certReqId));
X509NameEntryConverter dnconverter = new X509DefaultEntryConverter();
X500Name issuerDN = X500Name.getInstance(new X509Name("CN=AdminCA1").toASN1Object());
X500Name subjectDN = X500Name.getInstance(new X509Name("CN=user", dnconverter).toASN1Object());
msgbuilder.setIssuer(issuerDN);
msgbuilder.setSubject(subjectDN);
final byte[]                  bytes = keyPair.getPublic().getEncoded();
final ByteArrayInputStream    bIn = new ByteArrayInputStream(bytes);
final ASN1InputStream         dIn = new ASN1InputStream(bIn);
final SubjectPublicKeyInfo keyInfo = new SubjectPublicKeyInfo((ASN1Sequence)dIn.readObject());
msgbuilder.setPublicKey(keyInfo);
GeneralName sender = new GeneralName(subjectDN);
msgbuilder.setAuthInfoSender(sender);
// RAVerified POP
msgbuilder.setProofOfPossessionRaVerified();
CertificateRequestMessage msg = msgbuilder.build();
GeneralName recipient = new GeneralName(issuerDN);
ProtectedPKIMessageBuilder pbuilder = new ProtectedPKIMessageBuilder(sender, recipient);
pbuilder.setMessageTime(new Date());
// senderNonce
pbuilder.setSenderNonce(senderNonce);
// TransactionId
pbuilder.setTransactionID(transactionId);
// Key Id used (required) by the recipient to do a lot of stuff
pbuilder.setSenderKID("KeyId".getBytes());
org.bouncycastle.asn1.crmf.CertReqMessages msgs = new org.bouncycastle.asn1.crmf.CertReqMessages(msg.toASN1Structure());
org.bouncycastle.asn1.cmp.PKIBody pkibody = new org.bouncycastle.asn1.cmp.PKIBody(org.bouncycastle.asn1.cmp.PKIBody.TYPE_INIT_REQ, msgs);
pbuilder.setBody(pkibody);
JcePKMACValuesCalculator jcePkmacCalc = new JcePKMACValuesCalculator();
final AlgorithmIdentifier digAlg = new AlgorithmIdentifier("1.3.14.3.2.26"); // SHA1
final AlgorithmIdentifier macAlg = new AlgorithmIdentifier("1.2.840.113549.2.7"); // HMAC/SHA1
jcePkmacCalc.setup(digAlg, macAlg);
PKMACBuilder macbuilder = new PKMACBuilder(jcePkmacCalc);
MacCalculator macCalculator = macbuilder.build("password".toCharArray());
ProtectedPKIMessage message = pbuilder.build(macCalculator);
       
The above requires a CMP alias with approximately the following EJBCA configuration:
  • RA mode.
  • HMAC authentication module.
  • Specified secret 'password1'.
  • DN parts with CN as RA name generation scheme.

Enrollment type 2) Pre-registered client with certificate authentication

Using a client means that the client is already registered and present on the CA, able to authenticate itself with a certificate. The certificate can be generated by other means than the CA, or be imported into EJBCA.

To generate a signature protected CMP enrollment message using BouncyCastle:
       
CertificateRequestMessageBuilder msgbuilder = new CertificateRequestMessageBuilder(BigInteger.valueOf(certReqId));
X509NameEntryConverter dnconverter = new X509DefaultEntryConverter();
X500Name issuerDN = X500Name.getInstance(new X509Name("CN=AdminCA1").toASN1Object());
X500Name subjectDN = X500Name.getInstance(new X509Name("CN=user", dnconverter).toASN1Object());
msgbuilder.setIssuer(issuerDN);
msgbuilder.setSubject(subjectDN);
final byte[]                  bytes = keyPair.getPublic().getEncoded();
final ByteArrayInputStream    bIn = new ByteArrayInputStream(bytes);
final ASN1InputStream         dIn = new ASN1InputStream(bIn);
final SubjectPublicKeyInfo keyInfo = new SubjectPublicKeyInfo((ASN1Sequence)dIn.readObject());
msgbuilder.setPublicKey(keyInfo);
GeneralName sender = new GeneralName(subjectDN);
msgbuilder.setAuthInfoSender(sender);
Control control = new RegTokenControl("foo123");
msgbuilder.addControl(control);
Provider prov = Security.getProvider("BC");
ContentSigner popsigner = new JcaContentSignerBuilder("SHA1withRSA").setProvider(prov).build(keyPair.getPrivate());
msgbuilder.setProofOfPossessionSigningKeySigner(popsigner);
CertificateRequestMessage msg = msgbuilder.build();
GeneralName recipient = new GeneralName(issuerDN);
ProtectedPKIMessageBuilder pbuilder = new ProtectedPKIMessageBuilder(sender, recipient);
pbuilder.setMessageTime(new Date());
// senderNonce
pbuilder.setSenderNonce(senderNonce);
// TransactionId
pbuilder.setTransactionID(transactionId);
org.bouncycastle.asn1.crmf.CertReqMessages msgs = new org.bouncycastle.asn1.crmf.CertReqMessages(msg.toASN1Structure());
org.bouncycastle.asn1.cmp.PKIBody pkibody = new org.bouncycastle.asn1.cmp.PKIBody(org.bouncycastle.asn1.cmp.PKIBody.TYPE_INIT_REQ, msgs);
pbuilder.setBody(pkibody);
ContentSigner msgsigner = new JcaContentSignerBuilder("SHA1withRSA").setProvider(prov).build(keyPair.getPrivate());
ProtectedPKIMessage message = pbuilder.build(msgsigner);
       

The above requires a CMP alias with approximately the following EJBCA configuration (use a new CMP alias so you can run this and the previous config in parallell):
  • Client mode.
  • EndEntityCertificate authentication module.
  • CN as extract username component.

About the author

Tomas Gustavsson, CTO of PrimeKey, founder of EJBCA
Contact me at tomas(at)primekey.se.
Follow me on Twitter.

Monday, January 20, 2014

Using CMP with the CMP for OpenSSL tool, to integrate client and RAs in a PKI

Introduction

Implementing CMP to enroll for certificates and do automatic certificate renewal against a CA that supports the CMP protocol, the open source tool CMP for OpenSSL should be considered. Using the CMP protocol is a great way to integrate client and RAs in a PKI, and CMP for OpenSSL is a very promising tool.

Some background on CMP

The open source CA EJBCA implements many standard PKI protocols. One of them is CMP, which has been around since September 2005 when the RFC4210 first was published. In the early days adoption of CMP was progressing slowly due to the great complexity. The huge amount of options still make CMP somewhat cumbersome both to implement and use.

In the beginning CMP was mostly used from RAs, such as card/token management systems and in-house RAs. In the last couple of years adoption of CMP has increased and is now used in several systems, for example in LTE mobile networks where CMP is profiled by 3GPP (supported in PrimeKey's EJBCA Enterprise).

However, being a complex protocol with many options, CMP can be used for many different use cases. From clients that enrolls for certificates with optional automatic renewal, to RAs that registers end entities and issues certificates for those. All combined with several different ways of authentication, such as shared secrets and client certificates. One important distinction to make, is that messages specified by the protocol are one thing, another is the expected behavior in the back end (for example if a client needs to be pre-registered or not, or if any fields are accepted from an RA, or if there are any profile limitations). The messages themselves are specified in the CMP standard, but the behavior is defined by the specific use cases and sometimes standardization groups such as 3GPP.

CMP has been implemented within EJBCA since ECA-99 in 2006. PrimeKey's implementation has matured a lot during this time, and the latest evolution is CMP Aliases. In the current state CMP can be used for an uncountable number of different use cases with different back-end behavior, depending on the configuration.

CMP for OpenSSL

The main obstacle slowing the adoption of any protocol, is lack of free and open source implementations. So it is both pleasing and welcome to see CMP for OpenSSL appear. Being an excellent tool, we hope to see it integrated into OpenSSL at some point.

Note: Before using CMP for OpenSSL you must download and build it. It is not included in any standard distribution of OpenSSL.

Using CMP for OpenSSL as CMP client

Here I will show three different enrollment types; A client with a pre-registered shared secret, a client using certificate authentication, and an RA using shared secret authentication.
There is of course much else you can do. The RA can for example use certificate authentication, you can do nested messages with multiple layers of authentication etc. Only your imagination sets the limits on how to use CMP :-). Along with EJBCA 6 all these different configurations can be active at the same time.

For complete documentation, see the Admin Guide at EJBCA.org.

Pre-registered client with password authentication

  • Download the CA certificate to the client
  • Add a new end entity in EJBCA
  • Run the command
./openssl cmp -cmd ir -server ejbca-test.primekey.se:8080 -path ejbca/publicweb/cmp -srvcert MyCA.cacert.pem -user username -pass password -certout clcert1.pem -newkey key1.pem -keyfmt PEM -certfmt PEM -subject "/CN=username/O=My Organization/C=SE"

Where username is the username you added (you have to type it twice it's in the CN as well) and password is the password you entered when adding the end entity.

The above requires a CMP alias in EJBCA with the following configuration:
  • Client mode
  • HMAC authentication module
  • CN as extract username component

Pre-registered client with certificate authentication

Since this requires an existing certificate for the client, you can use the above enrollment method to generate it, but other possibilities exist of course.

./openssl cmp -cmd ir -server ejbca-test.primekey.se:8080 -path ejbca/publicweb/cmp/alias1 -srvcert MyCA.cacert.pem -cert clcert1.pem -key key1.pem -certout clcert2.pem -newkey key1.pem -keyfmt PEM -certfmt PEM

Where clcert1.pem and key1.pem is the cert and key generated previously (used for authentication to the same user). clcert2.pem will be the new certificate, and for simplicity we re-use key1.pem as -newkey, but you can generate a new one as well.

The above requires a CMP alias in EJBCA with the following configuration:
  • Client mode
  • EndEntityCertificate authentication module
  • CN as extract username component

RA with shared secret authentication

Using an RA means that the RA should be able to order certificates for clients of the RA. The clients themselves will not be pre-registered by the CA, but will be added by the RA when the RA enrolls for the client.

./openssl cmp -cmd ir -server ejbca-test.primekey.se:8080 -path ejbca/publicweb/cmp/alias2 -srvcert MyCA.cacert.pem -user user4711 -pass password -certout clcert1.pem -newkey key1.pem -keyfmt PEM -certfmt PEM -subject "/CN=user4711/O=My Organization/C=SE"

Where User and CN should be the same, and afterwards the client will be available as "username" in EJBCA.

The above requires a CMP alias in EJBCA with the following configuration:
  • RA mode
  • HMAC authentication module
  • Specified secret 'password1'
  • DN parts with CN as RA name generation scheme

About the author

Tomas Gustavsson, CTO of PrimeKey, founder of EJBCA
Contact me at: tomas(at)primekey.se
Follow me on Twitter: primetomas


Sunday, January 5, 2014

ETSI CAdES PlugTest event with SignServer

Introduction

SignServer participated in the ETSI CAdES Plugtest Interop event with SignServer developers Markus Kilås and Marcus Lundblad. Here is a summary of Markus's report from the event.

The Plugtest Event

The ETSI Centre for Testing and Interoperability (CTI) organized a Remote Plugtest Interop event for CAdES Signatures scheduled from 2nd to 13th December 2013, and later extended to the 20th December.

The event was conducted remotely using the Electronic Signature Plugtest Portal, e-mail and three conference calls.

About 60 companies joined the event.

The Plugtest Portal

The event was conducted mostly through the portal where the participants could download an “inital package”, a zip file with test case specifications for which signatures to create, as well as folders for the different participants.

After creating the signatures (according to the specifications) those could be placed in the participant's folder, the relevant parts of the folder structure zipped together, then uploaded to the portal. The Portal took care of merging the uploaded files and created a new package for download by all participants. In the same way signature verification reports could be uploaded and a matrix with the results could be viewed in the portal.

There were 84 different test cases in the cross-verification part of the event.

SignServer implementation

SignServer did not support any form of CAdES prior to the event. We decided to base our implementation on the library SD DSS.

Because of limited time and SD DSS using an older version of BouncyCastle, we simply developed a standalone proof of concept not yet integrated in SignServer. We based our implementation on SD DSS version 2.0.2, but during the event version 3.0.2 was released. Yet, we decided to continue on 2.0.2 through the event, as we already had done a lot of changes, both bug fixes and added features, since it otherwise would have taken too long to merge it to the new version. We also took contact with the authors of the library and got informed about version SD DSS version 4, planned for January-February 2014, with major changes in the verification parts.

Our implementation consisted of a standalone Java CLI application, which could either sign or verify a document. The application used a configuration file (similar to the signer configuration file in SignServer) configuring the CryptoTokens to use.

Test Cases

To easily create all necessary signatures and also perform validation of the other participants's signatures, we used JUnit test cases that could be run from within the IDE. A Java base class contained a single test method for each type of signature to create/verify. The method took care of calling the PoC application with the right properties for each type of signature, and then performed the necessary verifications to check that the signature complied with the test specification. This was implemented using JUnit asserts, and some magic in a base class took care of producing a verification report, according to the plug test specification.

To be able to perform all the tests implemented for all participants, the base class was extended and parameterized with a list of all participants, so that each test method was executed for each participant.

A complete run produced about 600 verification reports.

JUnit test results (NetBeans IDE)

Results summary

  • The support for CAdES-BES, CAdES-BpB and CAdES-T was quite good, except for the missing support for counter signatures (BES-6).
  • For CAdES-EPES some participants were reporting problems.
  • For CAdES-C and CadES-X* we had some issues related to the ordering of revocation information references.
  • We did not perform any CAdES-A and signature upgrades (CAdES-UpdArb).
Support for correctly verifying signatures was mostly lacking and we did not put any big effort into resolving that during the event, as the verification support will be largely changed in the next version of SD DSS.

Conclusions

We participated in the event and had good interoperability results for the basic forms of CAdES, during the limited time-frame.

We now have a lot more knowledge about CAdES and the SD DSS library. We also developed a set of test cases that will be helpful when developing and integrating CAdES support in SignServer.

More work is needed to make our CAdES implementation stable and to integrate it in SignServer, as well as adding support for the more evolved forms of CAdES (which we did not have time for during this event).

We look forward to attending the next CAdES PlugTest Event!