x.509 based identity, OS level or dedicated application?

June 4th, 2017 Company News

Introduction

Using x.509 certificate as identity tag, makes identity verification independent of its owner personal features. All is put on cryptography, that proved to be the only unbroken barrier between secured data access and complete uncertainty when my dear virtual “self” will stop being really mine.

Lets consider that we agreed that x.509 based crypto identity is the future (see my other posts to understand why I insist on that). Now, how and where the secret part of such crypto ID is generated and stored? Why should one trust that? Well, there are options. In this post we’ll discuss two of them. As usual, some technical terms with simple explanation in the beginning, and may be we’ll be able to decide which way of crypto ID storage is the best.

 

Client-side certificate

Such credential is usually produced on some independent HSM, and provided to the target machine as Pkcs or Pfx  file (kind of a bundle of crypto data packed into archive, optionally encrypted and/or protected by password). Import of such credential requires root/admin access, and the process of adding it will be different for each OS, and/or Internet Browser.

On successful import, OS/Browser will save the provided credential in its secure storage, specific for each OS (certificate store for Windows ,  keychain for MacOS or iOS,  credential store for Android etc).

So happens, that Browsers treat Client side certs differently. For example Firefox stores it inside its own secure storage, whereas Chrome requires root access to push the cert into OS keychain. The way, how Browser/OS stores the certificate, is not exactly covered in this post. What should be clear, is that it is not a trivial task adding or replacing such credential.

Eventually this cred is a part of device’s Operation System or Browser PKI vault. And it does not matter where we are: mobile, home PC or laptop, and independent of the OS type. It will be accessible to the application that requires it,  to be presented whenever the application will try to access a server, that requires client-side certificate as identification.

Regular use-case, is when Internet Browser, during connection attempt, prompts to a User to choose a client-side certificate from the list of installed certificates. Not user friendly, due to the fact that usually prompt proposes CN certificate field as its identifier, so no real logical connection between the names in the list and service one tries to login.

Would be used to authenticate the device it is installed on. Best fit for enterprise laptop, when service and corresponding cert are configured by the IT group. Can be used on mobile devices, limited to access applications that are fit to run in mobile browser.

Dedicated Application certificate

Each installed application has rights to import a valid x.509 for its own needs.The certificate is validated by the OS prior to be stored in device’s application specific secure storage.

In this case the keys and request are made and certificate received on target device in some custom secure procedure, and are unavailable outside the parent application. Use of such certificate is limited to the parent application functionality.

More secure than the first one, due to double protection (protected by the OS and by Application) and the fact that it is used by the same device that created it.

Best fit to authenticate independent sessions (like using mobile based cred to open a session on some PC).

Simple to use.

Ideal for crypto ID functionality.

x.509 ID, where to store, summary

As it can be understood, those two types , though formally alike, are very different in their final form.

I’ll build the summary based on two Beame.io products: Beame Gatekeeper and Beame Authenticator.

To relate the Gatekeeper to the theme of this post, it can be considered as a framework, to create and export the Pfx, and verify the cred’s validity afterwords. So it would be installed on some secure machine, and controlled by the administrator. Client-side certs based credentials produced by it will be transferred to target devices by one of available methods: email, shared drive, or any other custom secure process.

Beame Authenticator would be the application that creates and imports application specific certificate onto target device. It will contact some Gatekeeper to register a new credential, and any use of that credential will be handled by both the Authenticator and the Gatekeeper.

Both ways of storage have advantages for specific use-cases:

Recent Posts

Private cloud is easy

PKI based identity on a blockchain

Insta-SSL as a simple way to use RDP / VNC / SSH into LANs

VMs, Docker and Beame.io vs NSA

SSO and custom Identity Providers