Hello everyone!
This a good time for a new blog post! Today I want to share some thoughts on Key Recovery Agent (KRA) certificate management.

What is KRA and Key Archival

Let's refresh what private key archival is in AD CS context. Key Archival is the process of securily storing subscribers' (clients) private key in CA database for backup purposes should client loose access to private key. Key archival is primarily used to implement a centralized long-term backup process for encryption keys (email, EFS, document encryption).

The whole idea may not be apparent from the first look, but here is a strong reason: encryption keys are used to decrypt documents/files/emails even after their expiration, so you may need encryption key after its expiration. Expired certificates are not normally backed up as part of regular backup process or stored in long-term backup set. If certificate is expired, we normally renew it and delete old one. And you will be stuck if such encryption certificates and their keys are lost. This is why Microsoft implemented a separate encryption certificate backup process and store them in CA database. CAs are long-living entities, can live for decades and survive multiple migrations. And it can be easily backed up with regular backup process, because it will store a complete history of CA DB content, including historical one.

While it may look insecure, storing private keys in database is never a good idea, right? And this is where Key Recovery Agent (KRA) comes to a play. All private keys stored in CA database are encrypted with one or more KRA certificates. And even if you steal CA database and dump it, client private keys will be stored in encrypted blobs and CA/attacker has no access to KRA keys to decrypt client keys. Here is a timeline diagram that shows key archival process:

As you can see, private key material is protected at every stage: between client and CA (on a wire) it is protected with CA Exchange certificate. In CA DB, it is protected with one or more KRA certificates. And this process perfectly scales to any enterprise size, whether it is SMB, or large holding because of built-in automation using certificate templates.

Key recovery process is a bit different as it involves different entities:

CA itself doesn't play any specific role, it acts as a secure storage. Instead, we involve two different entities: CA Manager, who has access to CA, CA database and retrieve encrypted blobs. CA Manager cannot decrypt these blobs, so we involve another entity, Key Recovery Agent. These MUST be different and highly trusted persons to avoid key archival misuse by a single person. So, CA Manager has access to CA DB, can retrieve encrypted blobs and that's pretty much all. KRA, on the other hand, can decrypt these blobs, but cannot retrieve them from CA DB. This is a clear responsibility separation. You cannot use single entity to compromise client keys.

What's wrong with KRA certificates?

While the whole process is pretty clear and understandable, there is a catch: KRA certs and keys MUST be available to decrypt the oldest encrypted client private key. And required KRA certificate MUST be easily identifiable over the time. Default recommendation is to use a pre-installed Key Recovery Agent certificate template to enroll for KRA certificates. Default validity is 2 years. Once it is expired, KRA has to enroll a new certificate and ask CA Administrator to replace expired KRA certs with new ones.

And here is the problem: KRA has to maintain the history of all its certificates and keys, including expired ones. When KRA certificate is replaced on a CA, previously encrypted client keys ARE NOT re-encrypted. So, in order to decrypt such key, KRA need its private key associated with certificate used to encrypt client's private key long ago. Assuming, CA lifetime of 20 years and default KRA cert validity of 2 years, you will end up with 10(!) different KRA certificates. And KRA is required to maintain them all. And this is where the process often fails. Comupters are changed/replaced/migrated much more often and it is enough to miss one KRA key backup process during PC replacement to make this KRA helpless. Of course, you can increase template validity to 5 years. It will reduce the number of keys from 10 to 4 per KRA. Still error-prone number.

I'm not familiar with latest official Microsoft recommendations as of today: the latest official whitepaper on Key Archival was released during Longhorn Beta 3, so I took an opportunity to think about my own solution.

Suggested Recommendation

Disclaimer: Suggested approach is provided by me. It may not comply with Microsoft recommendations or best practices or accepted by Microsoft Support. Provided recommendations are my own and gathered through my personal experience.

In order to make KRA certificate handling easier, less error-prone and keeping adequate security level, I propose to completely avoid CA-issued KRA certificates and instead use self-signed(!) ones with large validity. Yes, you read it right -- self-signed. Ultimately, KRA certificate will be valid throughout entire CA certificate validity.

KRA certificate validity scope is quite limited, it MUST be trusted only by CA and only at client private key encryption step (step 4.3 in first diagram). No other entity needs to trust KRA. And here we go: create a pair (at least) of long-living self-signed KRA certificates, configure them as trusted only CA server (install to Trusted Root CAs on CA itself only) and configure them as KRA certificates.

The only requirement here is to securely store KRA keys. Ideally, you would store them on smart cards, network¹ HSMs, protected USB dongles. It is important to store them on a portable secure storage, so you can lock them in safe, or secure offline location. And never use only one smart card/storage. I would recommend to have at least a pair of KRA certs and physical storages to avoid single point of failure.

¹ - I recommend to use network HSMs over PCIe ones, as netHSM provide high-availability (HA) configurations. PCIe HSMs may not provide redundancy.

With suggested approach we make key recovery process pretty transparent and much more reliable, because you don't have to maintain a potentially large history of KRA certificates, you maintain only one KRA key per agent. And you can align KRA certificate renewals with CA certificate renewals, which will allow KRA key rolling at reasonable periods, which will exceed 5yr period offered by CA-issued certs.

Suggested Recommendation Implementation

This section will provide steps to implement new approach, including self-signed certificate creation and CA configuration.

First step is to prepare a pair of smart cards, ensure that required driver/CSP/KSP is installed on your system. Consult with supported asymmetric key algorithms. Pick the strongest one. Often it will be RSA 4096, or ECDH_P384/ECDH_P521, though actual algorithm support will vary. In our use-case, I will use ECDH_P521.

Second step is to prepare a self-signed certificate creation script. I will use New-SelfSignedCertificate cmdlet:

$name = "Example Org KRA-1"
$ValidForYears = 20
New-SelfSignedCertificate -Subject "CN=$name, OU=Division of IT (DoIT), O=Example Org, C=LV" `
    -NotBefore ([datetime]::UtcNow) `
    -NotAfter ([datetime]::UtcNow.AddYears($ValidForYears)) `
    -Provider "Microsoft Software Key Storage Provider" `
    -HashAlgorithm "SHA512" `
    -KeyAlgorithm "ECDH_P251" `
    -KeyExportPolicy Exportable `
    -KeyUsageProperty All `
    -KeyUsage DataEncipherment `
    -CertStoreLocation Cert:\CurrentUser\My `
    -TextExtension @('2.5.29.37={text}1.3.6.1.4.1.311.21.6',"2.5.29.19={critical}{text}false") `
    -FriendlyName $name

This command uses Software KSP with exportable (in case if no smart card is used) ECDH_P521 key, SHA512 signature, 20 years validity, EKU is set to Key Recovery Agent and Basic Constraints extension is set explicitly as end-entity certificate and critical.

For smart card-based enrollment, the command would look like this:

$name = "Example Org KRA-1"
$ValidForYears = 20
New-SelfSignedCertificate -Subject "CN=$name, OU=Division of IT (DoIT), O=Example Org, C=LV" `
    -NotBefore ([datetime]::UtcNow) `
    -NotAfter ([datetime]::UtcNow.AddYears($ValidForYears)) `
    -Provider "Microsoft Smart Card Key Storage Provider" `
    -HashAlgorithm "SHA512" `
    -KeyAlgorithm "ECDH_P251" `
    -KeyUsage DataEncipherment `
    -CertStoreLocation Cert:\CurrentUser\My `
    -TextExtension @('2.5.29.37={text}1.3.6.1.4.1.311.21.6',"2.5.29.19={critical}{text}false") `
    -FriendlyName $name

The difference is: smart card KSP, no export flags.

Do not use TPM to store KRA keys.

Repeat these commands for "Example Org KRA-2" certificate. It should be identical to previous, only different subject name.

Third step: If you use software KSP, export all KRA certificates and delete private key from system after export. Copy PFX and passwords to removable media and put them to secure location (safe). Store PFX and password separately. After securing KRA private keys, export KRA certificates into .cer file (only public part, no private key) and copy them to CA server or transfer to CA administrator.

Fourth step: we need to establish a trust to KRA certs on CA server. Use certmgr.msc or certutil commands:

Certutil -addstore Root path\kra1.cer
Certutil -addstore Root path\kra2.cer
# next two commands will publish KRA certs to AD, configuration naming context. This is where CAs will look for available KRA certs
Certutil -dspublish -f path\kra1.cer KRA
Certutil -dspublish -f path\kra2.cer KRA

First two commands (certutil -addstore) must be invoked again after migrating CA to another server.

Fifth step: Use AD CS MMC (certmgr.msc) to add and configure KRA certificates. You may need until KRA certificates published in AD are replicated to all domain controllers.

1. Open Certification Authority MMC snapin (certmgr.msc);
2. Right-click CA node and select Properties in context menu;
3. Switch to Recovery Agents tab;
4. Press Add button and select new certificates;
5. Add all required KRA certificates;
6. Save changes and restart certificate services

Additional Reading

Here are two official Microsoft whitepaper related to key archival:
1. Key Archival and Management in Windows Server 2003
2. Key Archival and Management in Longhorn Beta 3

Happy Key Archival and Key Recovery!

Six years ago I joined PKI Solutions company and as part of this process I wasn't allowed to blog about PKI/DEV stuff here. Today was my last official working day at PKI Solutions and I'm back here! I spent very interesting six years there, we did really incredible work "like no one ever seen before" ©Trump. We went just from some rough idea to a quite mature product: PKI Spotlight. I was responsible for architecture design, concepts and core/critical component development and for random really cool stuff. It was a very challenging journey, nothing came just as a straight line. Throughout the process, I learned quite a lot of new stuff, such as Azure, DevOps, containers, etc., it was a non-stop learning process. At PKI Solutions, I met some really good men, Ján Sokoly, Nick Sirikulbut, Mike Bruno, Jake Grandlienard and many others. But things are changing, the company is growing, people come and go, and it's a time for new opportunities and challenges.

As I mentioned in previous post, I brought my open-source projects (PSPKI and others) to company's GitHub account. In return, I've got a permission to work on them during my work hours (with some conditions, but anyways), which was very appealing. Throughout the work at PKI Solutions, I continued the support of these tools and we created some new open-source projects as part of company's commitment to community. As part of my resignation, I was given these tools back. I want to thank Mark B. "the PKI guy" Cooper (PKI Solutions president) who is a great man and released them without conditions. So, basically almost the same stuff is back:

• PowerShell PKI module
• pkix.net library
• ASN.1 Editor and ASN parser library

I didn't bring SSL Certificate Verifier, because it looks good enough in its current state and I have no particular plans on it. I will continue to support existing tools, though I need to do some work, such as updating documentation on my website, update internal tooling, Azure DevOps pipelines and so on. And, of course, will occassionally blog about some PKI/PowerShell/CryptoAPI stuff. So stay tuned!

Disclaimer: by no means I’m an IPv6 expert and I’m not going to teach on different IPv6 configuration options and basics. In this post, I will focus solely on a specific subject.

---

As a part of my IPv6 learning path I played with stateful DHCPv6 and spent all weekends to sort one interesting. Here is my simple network setup:

basically, two private networks connected to a router.

1. UDM Pro router
2. L2 switch
3. DHCPv6 stateful server
4. DHCPv6 client
5. IPv6 network: fd00:0:0:4::/64

The problem: clients receive IPv6 address from DHCPv6 and cannot communicate in same network using LUA (fd00) addresses.

Read more →

Hello everyone!

Today I’m excited to announce that I’m changing my position and moving to a great team at PKI Solutions starting with July 1!

As you may know, I recently was graduated as bachelor in computer science and it is a great time to make another step forward. I wanted to progress in PKI area as even stronger specialist. Unfortunately, there is no PKI market here in Latvia (where I’m living) and had two options: become another regular software developer here in Latvia or find opportunities outside of my country. I was looking for a not very big team where I could develop myself and (it is very important) where the team can benefit from my knowledge and experience. While looking for job opportunities I realised that I’m not fitting good many positions, because either, overqualified or underqualified for particular position.

I heard about Mark “The PKI Guy” Cooper from his years at Microsoft and knew him as a world-class PKI specialist. Mark is a president of PKI Solutions, they offer PKI consulting services and run PKI training. I didn’t see myself there, because PKI Solutions is US-based and relocation to US isn’t an option for me, but pinged him anyway, maybe he could have options in EU. Otherwise, PKI Solutions is a perfect place where both parties can benefit: I can continue my self-development in the area and the company gets a strong knowledge and experience in programming with PKI. Surprisingly, Mark showed a high interest in my work and heritage and made an offer which doesn’t require relocation.

During the negotiation of the deal, Mark showed himself as an awesome man with a clear vision of his business’ needs and how I can fill certain gaps to make the PKI Solutions a solid all-around team where each piece consists of strong specialists in particular areas. In addition, Mark expressed a wish to continue the support of all my public work: blogging, technical forums and open-source projects. These days community is vital for IT market, you have to support the community and you will get paid back eventually. And I will play an integral role in making the PKI Solutions a more community-oriented company though knowledge sharing.

Along the personal move I’m moving my public projects to PKI Solutions as well, because we will build new tools on top of existing frameworks. These tools are moved:

• PowerShell PKI module
• pkix.net library
• ASN.1 Editor and ASN parser library
• SSL Certificate Verifier

I will continue these tools development as open-source projects. Nothing will change to existing users, it is only brand change.

As a PKI Solutions employee I will continue blogging about PKI and CryptoAPI at https://www.pkisolutions.com/author/crypt32/. I will continue to maintain this blog in future so no existing link will break, but all new PKI-related posts will go to new blog.

Hello readers!

Blogs are dying

Last week I was surprised when got the following message on Microsoft Blogs (eaxmple: https://blogs.technet.microsoft.com/crypto):

After some investigation, more disabled blogs were found. I tried to find any information about what is going on, but not much luck. All I was able to find is the fact that Microsoft is retiring their TechNet and MSDN platforms and move to..yes, another blogging engine. Though, not all blogs are moved. There are various rumors (not yet official) and they suggest that only most popular and trending (Azure!) blogs will be migrated. The rest blogs will be wiped. Silently. Other rumors suggest that it is blogs owner’s responsibility to move their blog to a new platform. Keep in mind, these are just rumors, the fact is that blogs silently disappear: https://blogs.technet.microsoft.com/brandonlinton/2018/11/05/retirement/. There was no official announcement from Microsoft about the trend or blog decommission schedule. Further investigation revealed that MSDN blogs are mosing to DevBlogs and TechNet blogs are moving to TechCommunity.

Read more →