A developer’s guide to key storage providers
As a developer, you specialize in code – not security.
However, as DevOps continues to blend roles and responsibilities, the typical software developer has become responsible for more and more operational aspects like security. A core component of application and IoT security is code signing.
Let’s start with a basic definition. Code signing is a cryptographic method used to digitally sign software and firmware to ensure that end users can verify that the code is authentic and hasn’t been tampered with since it was published. Developers digitally sign apps, software, and IoT-embedded firmware with a private key linked to a code signing certificate.
Safeguarding the private key is critical to prevent hackers from hijacking the process and signing malware that appears approved by your organization. This is where key storage providers (KSPs) come into play.
What is a key storage provider (KSP)?
While I was developing a KSP for our code signing solution, I found it difficult to figure out just what a KSP is. Documentation is slim to none, and the little bits you can find online through endless Google searches are relatively unhelpful to a developer or anyone that lacks any Microsoft cryptography experience. You can find a high-level explanation of what a KSP is capable of – encryption, hash signing, and key generation – but not much more.
So what is a KSP? Like the name suggests, it is a “provider” for actions that involve cryptographic keys. KSPs are the most recent iteration of the Microsoft Cryptographic API interface, which allows you to abstract cryptographic actions away from software and the operating system (OS).
What developer would want to write their own key generation, signing, or encryption solutions? If you said none, you’d be correct. Cryptographic functions are hard to get right in development, especially when trying to comply with industry standards like FIPS 140-2.
Simply put, why reinvent the wheel when somebody else has done the hard work for you?
Now, KSPs are not to be confused with the older generation of crypto interfaces known as Cryptographic Service Providers (CSP). CSPs were the first iteration of cryptographic APIs based on an architecture called CAPI 1.0.
Microsoft later recreated the architecture for their cryptographic libraries from the ground up as Cryptographic Next Generation (CNG). CNG is the future-proof alternative, supporting new types of keys like Elliptic Curve Cryptography (ECC) and newer algorithms such as SHA-512. It’s designed in a way that it can be easily expanded upon for backwards compatibility (more on that later).
The KSP interface exposes multiple functions from the dll it lives in (27 to 28 functions depending on the Windows version it is built for), each serving a unique cryptographic purpose.
Why is a KSP important?
The KSP you use will determine how your keys are stored. For instance, the Microsoft Software Key Storage Provider is the default KSP that ships with any new OS. It stores your keys in the file system in a secure format.
That may be enough for some use cases, but what about cases where protecting the key is critical to the business? A code signing certificate, for instance, is extremely valuable. The private key associated with that certificate must be protected as best as physically possible. If a malicious user gets hold of the private key, he or she can use that key to sign malicious software.
Private keys used for code signing should be stored securely by physical means – either a Hardware Security Module (HSM) or smartcard. However, your average run-of-the-mill KSP doesn’t understand how to use these physical devices to access keys.
This is where vendor-specific KSPs, including those built for HSMs and smartcards, come into play.
These vendor-specific KSPs function the same as a typical software KSP in that they expose an interface of cryptographic functions. But under the hood, they access keys much differently. For instance, some KSPs interface via USB with an HSM appliance directly, while others connect across the web to access keys, while keeping the keys off of local servers and devices entirely.
Protecting code signing certificate keys with a KSP
Let’s use a code signing certificate as an example of how to protect a key using a KSP.
You’ll first need a new private key. When you enroll the certificate through Microsoft Management Console (MMC), there is a private key tab in the enrollment details, where the user can select a KSP (as seen below).
The MMC allows you to choose any compatible KSP with your selected code signing certificate template for private key generation and storage. This can be used during certificate enrollment or a Certificate Signing Request (CSR). By choosing which KSP the private key is created with, you can dictate where the private key lives as well.
Of course, this is helpful in cases where you want to enroll for a certificate where the private key is generated and stored on an HSM.
But what if you already have a certificate and key that you want to store in an HSM? You can simply inject an existing key into an HSM using a PFX file and Certutil. Certutil enables the import of a PFX file and allows you to choose which KSP the private key goes into, instead of storing it in the default software KSP. Installing the PFX through the MMC certificate installation GUI does not allow you to do this, so it will need to be done with Certutil or other means.
And what if you already have a certificate installed, but have no idea where they key is being stored? Certutil also exposes a helpful way of looking at the key provider for any digital certificate installed in a certificate store on your machine. In the example below, I have a certificate installed in a user’s personal store, which has its private key stored in the Microsoft Software Key Storage Provider.
The “provider” field is what you’re looking for here – it specifies which KSP the certificate is associated with. The “key container” field is what the Windows certificate store uses to identify which key actually belongs to that certificate, since there will be more than one key stored in a provider at any given time.
Enable secure code signing with the right KSP
On the one hand, developers need quick access to sign any code, from anywhere, without disrupting the software development lifecycle (SDLC). On the other hand, IT security teams are pressured to protect the organization from emerging code signing and software supply chain attacks, such as the recent ASUS Live Update hack.
Most software developers recognize the need for code signing – the biggest challenge is how to implement code signing securely and effectively for today’s fast-paced and dispersed DevOps teams. Typically, keys are duplicated between developers (unsafe) or each developer gets their own keys (unsafe and expensive). These keys wind up in unsecured locations, from developer workstations to build servers, and who knows where else.
With the right KSP, developers can sign any code, from anywhere, without ever requiring physical access to the private keys. It can also be integrated into virtually any code signing process that uses a KSP, such as Visual Studio with MS Build and SignTool. The result? DevOps teams stay productive while the security team stays in control and ahead of emerging threats.
The post A developer’s guide to key storage providers appeared first on SD Times.
Tech Developers
No comments