Thursday, October 19, 2017

Signing weak RSA Keys? Not on our watch!

I'm sure very few of you have missed the rather crippling flaw found in a widely used code library to generate RSA keys which has been named the Return of Coppersmith's Attack, or ROCA for short.

Fortunately none of PrimeKey's products uses these libraries, nor do any of our supported HSM vendors to the best of our knowledge, so no key pairs produced by EJBCA should be affected by this flaw.

Nonetheless, EJBCA does run the risk of signing such keys as part of a Certificate Signing Request. As fears of similar flaws have been lifted to us before, in EJBCA 6.9.0 released in late August of this year we introduced the concept of Validators, among them the RSA Key Validator.
For EJBCA 6.10, slated to be released on the 1st of November, we've added functionality to the RSA Key Validator to reject keys affected by the ROCA flaw.

All you need to do after upgrading to EJBCA 6.10.0 or later is to check this box in your validator, and you're set to go!

Mike Agrenius Kushner,
Product Owner EJBCA

Tuesday, September 19, 2017

Master's Thesis Paper on Post-Quantum Algorithms for Digital Signing in PKI Available Now

Mikael Sjöberg has been with us here at PrimeKey this spring exploring different algorithms suitable for use in PKI even after quantum computers becomes a reality.

As Mikael's mentor I am very pleased with his work and that he choose to do the study at PrimeKey.

The final version of the master's thesis has now been approved.  Read the abstract below or download the full version PDF.

Markus Kilås
Product Owner SignServer

Post-quantum algorithms for digital
signing in Public Key Infrastructures



One emerging threat to Public Key Infrastructures is the possible development of large-scale quantum computers, which would be able to break the public-key cryptosystems used today. Several possibly post-quantum secure cryptographic algorithms have been proposed but so far they have not been used in many practical settings. The purpose of this thesis was to find post-quantum digital signature algorithms that might be suitable for use in Public Key Infrastructures today.

To answer the research question, an extensive literature study was conducted where relevant algorithms were surveyed. Algorithms with high-grade implementations in different cryptographic libraries were benchmarked for performance. Hash-based XMSS and SPHINCS, multivariate-based Rainbow and lattice-based BLISS-B were benchmarked and the results showed that BLISS-B offered the best performance, on par with RSA and ECDSA. All the algorithms did however have relatively large signature sizes and/or key sizes.

Support for post-quantum digital signature algorithms in Public Key Infrastructure products could easily be achieved since many algorithms are implemented in cryptographic libraries. The algorithms that could be recommended for use today were SPHINCS for high-security applications and possibly BLISS-B for lower security applications requiring higher efficiency. The biggest obstacles to widespread deployment of post-quantum algorithms was deemed to be lack of standardisation and either inefficient operations compared to classical algorithms, uncertain security levels, or both.

Full report (PDF)

Tuesday, August 29, 2017

Presenting EJBCA 6.9.0: Delegated Keypair Generation, Validation and CAA

Greetings to all, and welcome back after a long summer. Just in time for CAA to go live on September 8th, we'd like to present to you all the release of EJBCA 6.9.0. All in all we've fixes about 90 issues during the summer, but we'd like to highlight the four major features of this release: 

Delegated Keypair Generation

As requested by some customers running EJBCA instances as RAs over Peers, this feature is similar to the key recovery feature long used in EJBCA in that it stores generated soft keys encrypted in the database, but with the purpose that the soft keys are generated on the RA (instead of on the CA). The purpose of this is security - where the owner of the RA doesn't wish for the keys to ever be transmitted to the CA but merely be signed. 

Since this feature requires an EJBCA instance running as RA, it only applies to Enterprise customers. 


In EJBCA 6.9.0 we've introduced the concept of Validators, an API that can perform content validation during certificate creation. To explore this new functionality, look under CA Functions -> Validators

Once there, the Validators management screen should be familiar to most EJBCA users:
All Validators have some common options, as seen at the bottom of each configuration screen:
This allows for setting a description, restricting application of the Validator to certain certificate profiles and to define behavior in cases where the Validator fails (to abort issuance or to merely log and warn), or if the Validator was applied to a value it couldn't validate (such as an RSA validator on an ECC key). 

RSA/ECC Key Validation

Foremost we've implemented Key Validators, which can be applied to a CA to reject incoming signing requests based on inadequate key length or poorly chosen exponents. Both of these validators are quite powerful. Looking at the RSA Validator:

We can see immediately that the Validator gives control over exponent size and modulus, as well as restricting key sizes to either a custom list, to those set by the Certificate Profile or to the CA/B-Forum recommendations. 
Exploring the ECC Validator, we find a similar level of control there:

Lastly, both Key Validators can be restricted to certain time periods, which allows for enforcement of standards from or up until a certain date:

BlackList Validators

We've also developed an API for blacklisting signing requests based on known information. In EJBCA 6.9.0 we've implemented a Key Blacklist Validator, which will check incoming certificate requests against a user defined blacklist of known bad keys. 

Keys can be added to the blacklist using the EJBCA CLI:

This command can also be used to upload a complete list of blacklisted keys. PrimeKey Solutions can provide list of known bad keys as compiled by the metasploit project, contact us for more info. 

Certificate Authority Authentication (CAA) Validation

Last and absolutely not least, EJBCA 6.9.0 can perform CAA checks during or after certificate issuance, as I wrote about last spring. We have implemented CAA support in two methods, the first being a manual CLI tool that can be used to manually verify CAA records:

The second is in the form of a Validator:

This Validator allows specification of issuer, DNS Resolver and whether to validate DNSSEC for results, as well as options for how to handle IODEF statements. Note that EJBCA doesn't support WebService IODEF calls (RFC 5070) yet.

CAA support is an Enterprise only feature. 

Mike Agrenius Kushner,
Product Owner EJBCA

Saturday, July 15, 2017

Introducing the EJBCA RA, Part 2.2: Migrating from the Public Web (continued)

Hey folks, and welcome back. The last post was dragging on a bit, so I decided at the last minute to split it up. This post will cover the rest of the RA (as implemented in EJBCA 6.8.0) before I get into a bit more technical and architectural stuff in the next post(s).

So, sit back and enjoy the continuation of the tour.

Request Management/Approvals

A big part of being an RA is naturally approving requests. To begin with, let's take a look at the Manage Requests screen. You'll notice four tabs:

  • To Approve - a list of all requests that you as a logged in administrator may approve or deny
  • Pending Approval - a list of all currently pending requests to which you have view access, including those that you may approve yourself. 
  • Processed - a list of past requests to which you have view access.
  • Custom Search - a standard search screen, allowing you to filter and search through all requests to which you have view access. 
So let's return to the scion of the Widget fortune and our example from the last blog post, Alan Widget and his quest for certificates. So you'll remember that his enrollment request was sent of for approval? Well, over on their end the ever friendly neighborly RA administrator was on the case. Receiving an e-mail notification about Alan's request, they log in to the RA and check the To Approve-tab.

As expected, here we see Alan's request waiting for review. Clicking on the Review-link, the administrator is shown all pertinent information having to due with Alan's request.

We could mention here that we've only set up a simple cumulative approval profile for this action for the sake of simplicity. We could have also used the more complex partitioned profiles which were introduced in EJBCA 6.6.0, but I'll probably write a bit more about those in a future blog post.

You'll notice that there is an edit button at the bottom of the screen, which allows the administrator to edit some information in Alan's request. Doing so would invalidate the administrator as an approver though, as they would be considered party to the request itself. Instead they choose to approve, which changes the request's status to Executed, will send a notification mail off to Alan and allow him to retrieve his certificate.

Heading over to the Processed-tab, the administrator can now see Alan's request listed, and likewise under the Custom Search-tab.

Search Functions

That ends the final epic saga of Alan Widget and his quest for certificates, so we'll move on to the remaining pages on the RA interface in EJBCA 6.8.0. Clicking on the Search option in the top menu reveals two choices: Certificates and End Entities

Certificate Search

Being able to search for certificates is a brand new feature in EJBCA, and is only implemented in the RA interface. It provides options for searching for partial matches against Subject DN, SAN, username or against the full serial number. Certificates can also be filtered by end entity profile, certificate profile, issuer and status. 

Extra search options include specifying more results to be shown per screen and mechanisms for searching for more precise issuance, expiry and revocation dates. Note that result size is restricted to avoid murdering the database. I would also like to point out that the listed certificates will be restricted to those CA to which the RA is authorized to. 

End Entity Search

The End Entity search is gives roughly the same options as the certificate search screen, and will likely feel familiar to those of you used to the End Entity search screen from the CA interface. 

CA/CRL Overview 

The CA Certificates and CRL screen remains largely unchanged from the public web.

Notice from the screenshot that the WidgetCorp SubCA is slightly indented to show that it's subservient to the WidgetCorp Root CA

Role Management

The last screen to review is the Role Management screen, which was first introduced in EJBCA 6.8.0. Clicking on the menu will show two options: Roles and Role Members. 

At this point you may be wondering why we've moved roles management out into the RA interface, when there is an excellent (well, more or less) equivalent already written in the CA interface? Well, for many use cases this won't make much sense, in particular when CA and RA are on the same machine. It starts getting interesting when the CA is located in a secure environment, using one or many RAs placed in the DMZ to communicate. As these would by bare minimum be physically separated and in different security zones, this allows senior RA administrators some freedom to administrate their own personell, without being forced to enter the CA security zone. This functionality becomes even more pertinent when CA and RA are physically separated, or not even being operated by the same business entities. 


The roles screen will display a table of all roles to which the current administrator and RA are authorized to see, sorted by name and namespace. The standard options for editing, deleting and cloning roles exist, as well as for creating roles and reviewing role members. 

If we click on Create New Role will bring us to the following screen, which will be similar for editing or cloning. 

Notice that what you see is a simplified rules management screen, restricted to only RA functions and access to Certificate Authorities and End Entity Profiles.

Role Members

Had we instead clicked on the Members link in the previous table, we would have ended up in the same screen as the Role Members menu option. Displayed is a table of all available role members which this RA and administrator is authorized to view, which can be further narrowed down by identifier (common name, certificate serial number, etc), role or CA. 

Choosing to add a role member will lead us on to a familiar screen where we can specify role for the member, what CA has issued the certificate for that member and by what means we identify that certificate. There is also a field for making remarks pertaining to that member.

That brings us to the end of our tour for the EJBCA RA as implemented in EJBCA 6.8.0. I hope that you've learnt something, and you'll join me in future blog posts as we add and modify functionality. We're not done yet though! Fact is that the EJBCA RA is not only a fancy new user interface, but part of a brand spanking new feature: for EJBCA Enterprise customers an instance of EJBCA can be set up to act as a synchronous external RA for another EJBCA instance acting as CA, communicating securely using EJBCA Peers, even through a one-way firewall. 

Will we introduced this functionality back in EJBCA 6.6.0, in the next blog post I'm going to explain how such a setup would look like on an architectural level, and provide an easy walkthrough for how to set it up!

Mike Agrenius Kushner
Product Owner EJBCA

Monday, July 3, 2017

Introducing the EJBCA RA, Part 2.1: Migrating from the Public Web

As mentioned in the previous blog entry on this subject, one of our end goals with the RA is that it will replace what is currently known as the Public Web. As a result, its final demise is in the works (expect it for EJBCA 7.0), and so I'd like to guide you on how to migrate from using the current Public Web to the RA, as well as give a detailed tour of the entire RA web.

Certificate and Key Store Creation, and Registration

The biggest change to the current process is in the context of certificate and key store creation, as well as end entity self registration, which we've chose to collect under a common workflow. As a reminder, here is the current menu in the Public Web (as of EJBCA 6.8.0):
Nearly this entire menu has been replaced by the top option in the Enroll-menu in the RA, as can be seen below:

So What's Missing?

To just get that out of the way, the only part of the Public Web which hasn't yet been implemented in the RA is the ability to request certificate renewal, i.e. the Renew Browser Certificate option in the first screenshot. 

Registering a new End Entity 

The main procedural change is that self registration (Register -> Request Registration in the Public Web) is now the default first step in either creating a certificate or requesting a key store. Using the old Public Web, the first step in either case is to go to the Administration Web and creating a new end entity, a process I'm sure that you're more than familiar with:

Going instead to the RA and clicking Enroll -> Make New Request brings up the following screen:

As you see, we're first asked to input a Certificate Type, which is analogue to the End Entity Profile concept in the EJBCA Administrative web. I'd like to point out that only WidgetCorp's profiles are visible on the RA, due to this being a dedicated RA for WidgetCorp, even though several other end customers share the same CA, but more on that later. 

For this example WidgetCorp's employee Alan Widget (sadly, well designed PKI is not a cure for nepotism) needs to enroll for a P12 for his personal use. As a trusted employee (and for the sake of example), he has access to an RA terminal where he's free to select any certificate type allotted to WidgetCorp. He'll select the WidgetCorp User type, which gives him a choice of Certificate Subtypes.

Selecting the End User Certificate subtype, he'll next be given a choice of where to generate the key pair:

 In this case Alan requires a soft signed key pair produced by the server, so he'll select the top option. We'll talk more about the second option in a moment.
 Next the RA will provide Alan with a choice of key algorithms as defined by the Certificate Profile/Certificate Subtype.
Lastly, he'll be asked to provide whatever values that must or could go into the distinguished name of his certificate. Notice that mandatory values are marked by an asterisk, while values defined in the End Entity Profile/Certificate Type are filled in and unchangeable. Lastly he'll be asked to provide a username and enrollment code, as well as his e-mail. The username/enrollment code can be used to retrieve the finished certificate at a later date (using the Use Username option in the menu above), and the enrollment code will also be used as a passphrase if a key store is desired as the end result. Lastly, a field for an e-mail address is provided so that Alan can be notified once his key store is ready for retrieval.

Finally Alan is given a chance to review the contents of his request before confirming and sending it off:

Alan's request is sent off for approval by a higher level admin, and Alan has been left with a request ID. 
We'll talk about the approvals process in the RA in a later blog post, so for now we'll stick with Alan. Once his request has been approved, he'll receive an e-mail telling him that he can return with either his username/password or his request ID, using the Use Request ID option in the Enroll menu.

Entering his request ID, he moves on to the final screen, where he's asked to input his passphrase to authenticate himself. Lastly he simply has to choose how his wants his key store delivered (as permitted in the Certificate Profile). 

Creating a New Certificate

So, how is the procedure different if all we need is a certificate? Well, Alan's first task at the job is to set up a new VA for WidgetCorp's SubCA. He's set up the machine and generated the signing keys, so he needs to get them signed. As it happens we've already defined the WidgetCorp M2M Certificate end entity profile for just this purpose, so we'll choose that from the dropdown, and then the OCSP Signer subtype. 

You'll notice he's never given a choice of where to generate the keys, as the OCSP Signer certificate subtype specifies that they be user generated only. Alan is instead encouraged to upload or paste his CSR.
Doing so will fill in any data already defined in the CSR such as key algorithm and DN values, and all he has to do now is submit the signing request for approval.

The astute of you will notice one feature missing in the current Public Web, which is letting the browser generate its own key pair. We have chosen to not implement this feature because it's already been dropped by Chrome, and it's on its way out in FireFox as well.

This blog post has gone on long enough for now, so we'll cut it here and continue with the rest of the RA interface in a few days time, so please check back then!

Mike Agrenius Kushner,
Product Owner EJBCA

Monday, June 26, 2017

Introducing the EJBCA RA, Part 1: Introduction

Where we are now

One the primary complaints we here at PrimeKey get about EJBCA is about the design of our interface, or rather the lack of thereof. We've come a long way from being a tiny open source project to being one of the primary PKI software vendors globally, so while we maintain our dedication to delivering a powerful and secure product, it's time for us to give our users a bit of a break.

The Public Web 

A major feature EJBCA has always been lacking is a dedicated RA. The Public Web, while basically functional, is merely a rudimental interface for performing RA functions, one which only works locally, needs to be used in conjunction with the CA web, and is not in a state that can be considered deployable to the end user.

Many of you reading this have in all likelihood designed your own personal RA using CMP, SCEP or our WebService interface, which brings us to our next topic. Most CA installations are understandably hesitant to expose their CAs to the wild in order to interact with an RA, but instead protect it using a firewall. Currently we provide the standalone ExternalRA, an asynchronous proxy meant to reside outside the firewall, restricted to only being polled by the RA.

What is in store

Those of you familiar with EJBCA Enterprise will hopefully be a bit familiar with the EJBCA's RA Web. We released it back in EJBCA 6.6.0, and with the refinements being done in EJBCA 6.8.0 and beyond.

The EJBCA RA in EJBCA 6.7.0
The RA is the herald of the end of the Public Web and of ExternalRA. By the end of this year we will be discontinuing these two modules and removing them. So what does this mean to you? Well, quite a bit, and all of it good. The RA is in fact designed to completely supersede the Public Web, while providing quite a bit more functionality and improved design, aside from being a whole lot prettier.

Not only that, but by using the Peers protocol introduced in EJBCA 6.3.0, one instance of EJBCA can be set up in the DMZ as a proxy to another acting as CA within the confines of the firewall, responding to synchronous polling from the CA and communicating over TLS instead through database polling.

That's it for now, but follow us for an additional couple of blog posts. Part 2 will take a close look at the EJBCA RA and how to transition to it from using the Public Web, while Part 3 will talk about setting up an RA Proxy, as well as discuss some future ideas for the RA.

Mike Agrenius Kushner,
Product Owner EJBCA

Friday, June 9, 2017

A Sneak Peak into EJBCA 6.8.0: Roles, Rule and RA

So we're finally coming into the last sprints of the current release, testing and fixing bugs as we go. We're expecting the final drop of EJBCA 6.8.0 in the end of June, but in the meanwhile I'd like to talk about and demonstrate some of the new features we've implemented.

Improvements to Roles and Rules

So I know firsthand that one of the more complex and confusing aspects of administrating EJBCA are the roles and rules system. While we're not quite so brave as to redesign the rules system entirely, we've taken several steps to simplify rules administration, and make the capabilities of each role clearer. 

Simplified Rule Administration

You're probably all familiar with the current look and feel of the rules page:

In 6.8.0 we've made some simple improvements which we very much hope will improve usability. From now on, the same page will look like this:

I would like to draw your attention to several features:

  • We've removed the Unused-state and the Recursive-cbeckbox and replaced them both with the Inherit-state. It simply means to inherit whatever rights were set further up the tree (in the above example, setting Allow to /ca_functionality will give access to /ca_functionality/activate_ca and all other subsequent rules, unless they've been specifically set to Deny
  • In order to simplify overview, we made a conscious choice to go from drop-downs to radio buttons, as well as differentiating between leaf rules and branches by color. 
  • Rules are automatically normalized, which means that when saved the rule-set will automatically be minimized to its smallest possible size. Rules which are invalid or redundant are automatically culled. 

Rule Summary

If you check out the top right, a new meny option has been added to the navigation menu:
Clicking on it will bring up a summary of the active rule set for the role (after normalization, see above).

Role Namespaces

We've recognized that there may be many disjunct groups of users administrating EJBCA, all of which may not need to know of each other. In order to minimize confusion in naming Roles, we've added the concept of namespaces.
Belonging to a role in blank namespace (to which the Super Administrator Role belongs) gives access to all namespaces, while all other roles will only see the namespaces to which they themselves belong. In other words, an administrator belonging to WidgetCorp's namespace will only see the WidgetCorp roles. In addition to that, if the administrator only belongs to a single namespace, then the whole column will be hidden and they will never be aware of any other roles at all. 

Roles in the RA

We hope that you've all been following the exciting new development that came in version 6.6 last year, our very own proxyable RA! In EJBCA 6.8.0 we've also extended roles and rules administration to the RA, allowing end users on a proxied RA to manage their own users and rights without needing to access the CA.

CMP Proxy and Windows AutoEnroll Proxy

We're slowly migrating away from the legacy ExternalRA, as well as the CMP and SCEP Proxies. The reasoning behind and advantages to this will be explained in future blog posts, but for now I'd like to let you know about two new features we've introduced in 6.8.0. If an installation of EJBCA has been set up as an RA for a CA installation, it can now proxy both CMP messages and the Windows AutoEnroll feature we introduced in EJBCA 6.7. No special configuration is needed: simply send the messages to the RA as usual, and if it has contact with a CA it will automatically pass the messages on. 

Approval Profiles

Lastly, we decided to build a bit upon the concept of Approval Profiles that was introduced in EJBCA 6.6. In previous versions, only a single approval profile could be to cover for all actions for a CA or Certificate Profile.
CA settings

Certificate Profile settings
In EJBCA 6.8 we've somewhat more intuitively made it possible to set a profile per action, meaning that you don't need to have the same approval workflow for adding end entities as for revocations. 
CA settings

Certificate Profile Settings

Now, that's all for now. We're expecting EJBCA 6.8.0 to pass QA and be released by the end of next week, which will be announced through all the usual channels. On behalf of all of us at PrimeKey Solutions I'd like to wish you all an excellent summer, and check back here during the coming weeks for a series of blog posts about our new RA!

Mike Agrenius Kushner
Product Owner EJBCA