Security considerations when building an identity service
When integrating your web or mobile application with one of the - mostly European - government or bank-provided identity solutions, you face a set of security-related challenges in order to match the level of security inherent in these solutions.
These identity services were all built to be able to identify legal persons in an online environment, such as a web bank, an insurance portal, or your stock broker’s online trading platform. The identity services offered typically also include the ability to sign transactions and (some types of) documents.
This article outlines the elements to consider based on our experience when implementing Grean’s easyID service. What follows is a list of elements to keep in mind when building and integrating your safe and secure identity solution.
- Token signing - the keys to the kingdom
- Privacy and control
- SSL termination and firewall logs
- Secure and safe coding
- Sensitive key management processes
- Hosting environment
At Grean we built a service for federated authentication, often referred to as an identity provider. An identity provider authenticates your users - with, say, Swedish BankID - and then issues a token of sorts (e.g. SAML or JWT) which is sent back to your application.
A token signing key is in effect the master key, which, if lost, will completely open your applications to an attacker.
When deciding to integrate a highly secure national or bank ID service into a federation service, the signing of issued tokens becomes a prominent point of attack: If an attacker gets hold of the token signing keys, they will be able to impersonate each and every user with very simple means.
With access to the token’s signing key, a token can be composed in a simple editor and signed easily with a minimum of programming skills. After that, it’s game over until you realize that the key has been compromised!
A token signing key is in effect the master key, which, if lost, will completely open your applications to an attacker. Safeguarding these keys at runtime, at rest, and during the configuration process is thus of paramount importance.
HSMs: Keeping private keys private
A Hardware Security Module (HSM) is a piece of crypto hardware built specifically for making asymmetric cryptographic operations very safe.
When using HSMs, private keys such as token signing keys are created by, and stored in, the HSM. The keys are used for signing and decryption operations, but they never leave the HSM. All cryptographic operations take place inside the HSM hardware, and, in fact, the HSM construction guarantees that the private keys cannot be extracted since the hardware will self-destruct rather than let go of the contained keys. So, even if an attacker were able to actually steal the HSM hardware boxes, they wouldn’t be possible to gain access to the keys.
Great defense against side-channel attacks
With HSMs, your servers never have the private key in memory - period. This is a very strong defense against the ever-growing number of side-channel attacks (Rowhammer), untrustworthy hardware components (Intel Management Engine), and more down-to-earth issues such as programming errors (Heartbleed): In other words, you cannot lose what you do not have.
For Grean’s easyID, we use the Azure Key Vault service for HSM support for both data storage and the central token signing operations. See the section Sensitive key management processes to learn more about the broader benefits of using HSMs.
For identity data processed and stored by your application, or by a separate identity service like easyID, privacy is a key concern. Not only do you need to make sure data is kept confidential and unmodified, but ultimately the user must be able to assert full control over their data.
New regulations, like the coming EU General Data Protection Regulation (GDPR), only reinforce this requirement - formalizing the user’s right to be forgotten and to export their data.
As such, use encryption for data at rest - particularly for personal data. And we suggest decrypting only the moment the data is actually needed. Even your memory cache should keep only encrypted data to reduce your vulnerability to various attacks (out-of-bounds/side-channels, etc.).
Finally, consider doing as we do at Grean: using HSMs for decryption, thus ensuring that the data by itself cannot be used without the accompanying HSM infrastructure.
Every professional deployment naturally uses some sort of combination of network and application firewalls to fend off malicious traffic, DDOS attacks, and more.
In relation to identity services, there are two areas in particular that require special attention. You’ll want to consider these in order to reduce and manage the chance that an ill-intended network administrator may be able to pick up user credentials and thereby completely assume a stolen online identity.
- SSL termination. To allow for payload inspection and/or to remove the burden of decryption from servers, you may choose to terminate SSL/TLS in the firewall. This means the clear text traffic is potentially available to your network administration, which, as we’ve seen in the past, is often an outsourced responsibility.
- Firewall logging. You must be careful what’s put into your firewall logs, especially in connection with SSL termination. Again, these logs may be accessible to people who you don’t normally think of as having permission to access identity credentials and personal data. And the logs may very well be backed up to unencrypted storage, thus potentially making it available to a much broader audience.
We recommend installing your SSL private keys only on the ultimate node; that is, not on any firewall equipment. At Grean, we terminate SSL traffic on the actual web server only. And similarly, the keys are only made available to a small group of application administrators, and never to network administrators.
While securing your infrastructure is an absolute necessity, it is clearly not enough. No matter the quality of your infrastructure, it isn’t worth much if you haven’t managed to program your application in a secure way.
While this subject is too big to cover here in any great detail, we will briefly discuss a few general strategies that we employ in our development work. These are not specific to security-related applications, but because your identity service forms the entry point into your applications, resilience, safety, and security are doubly important:
- Choice of programming language. You must choose a language with a compiler that helps you cover your bases. We use F# with its prescriptive terseness (more focused on what you want to do, and less on how), its compiler support for writing correct code (e.g. pattern matching to ensure you cover all values of an expression), and its uniquely expressive type system. When choosing a language for building secure applications, we value correctness of written and compiled code over the flexibility and runtime extensibility of more dynamic languages.
- Test- and type-driven development. This is sort of an oldie, except maybe for the notion of type-driven development. Type-driven refers to the quality gained from our choice of programming language, allowing us to write far fewer boilerplate unit tests as the type system and pattern matching let the compiler do much of the work previously done by your hand-crafted unit tests.
- Small updates and peer reviews. We use Git and GitHub and do all of the work with branches and pull requests (PRs). A PR should never cover more than a human reviewer can quickly understand and review in detail. If in doubt, push more PRs instead of fewer. When reviewing, have senior developers spend more time reviewing code. This is how the less experienced developers learn to walk the talk of
Like with any other type of application, your processes for things such as deployment and patching must be followed. Similarly, your health monitoring systems must inform qualified personnel in a predictable manner should quality of the total system degrade.
But with an identity service, you have to watch the processes of certificate issuance and updates, or more specifically the private key updates, extra carefully. As mentioned above, the token signing keys are very sensitive: In the wrong hands, any users may be impersonated. Therefore, the processes - sometimes referred to as key ceremonies - for updating these keys must be very controlled and formalized to avoid unintentional disclosure.
If you work with file-based certificates, this type of formal process is a requirement.
Alternatively, consider an HSM-based approach like we use at Grean. The private keys for token signing are generated inside the HSM and never see the light of day. They will never be available to anyone and can never be disclosed. The process for generating these keys is run automatically as users sign up for our service or decide to roll over their keys, all without the participation of Grean personnel.
Safe key management with HSMs
Using HSMs has the very nice side effect of transforming the otherwise high-risk process of private key configuration management into a completely mundane task, as there are no keys to install on your production servers. Contrast this with more traditional key stores such as Java Key Stores or the Windows Certificate Store. With these, you need to employ safe, and at least partly manual, procedures both for creating and for distributing the private keys to all of your production servers.
Finally, as always, we need to consider the hosting environment. The servers, the disks, the backup media, the network, and more all must be protected against unauthorized access, physical as well as virtual.
How to do this effectively is well beyond this small overview, but just remember: The time it takes to locate your backup media is the same amount of time it takes to get access to your data, no matter how secure your production environment may be.
For identity services, again, be extra careful with backups of your sensitive keys as well as sensitive personal data.
And one more thing we’ve seen quite a few times in the past: Someone sends you an email with the newest password or the newly issued private key for you to put on the production servers. Keep in mind that this is a poor practice as the email with this sensitive information most likely will be sitting on your organization’s email servers until you effectively purge it. (And even then it still sits on a backup tape somewhere!)
Sending sensitive information via email is bad for identity services. Even if emails were sent over secure channels, with no chance of disclosure, chances are your email infrastructure is handled by a group of administrators who you normally don’t consider part of the operations team for your highly secure identity service. Just like the network administrators taking care of your firewall.
At Grean, we use Microsoft Azure to abstract away and secure our hosting. You can read more about Microsoft Azure security at their Trust Center.
Go to grean.com to sign up today to quickly enable your applications to accept real people’s real identities. We run a tight ship to ensure that you get the same level of security and safety that you get from the various proprietary bank and government solutions!
RECENT POSTSJune 15, 2017
OpenID Connect from ASP.NET Core with Visual Studio 2017March 24, 2017
Sign text with BankID, NemID, right in your front-endFebruary 25, 2017
OpenID Connect from ASP.NET Core - on Mac OSXFebruary 14, 2017
Use BankID and NemID from a Node.js applicationJanuary 10, 2017
Security considerations when building an identity serviceDecember 15, 2016
Real world identities online: Why and how?December 07, 2016
Criipto Verify connects Auth0 to Scandinavian national and bank identitiesDecember 04, 2015
Grean extends Auth0 with B2B onboarding and authorizationAugust 31, 2015
Are security concerns holding back your B2B integration?