Beyond Identity: Secure Enclaves and Authenticating Clients Rather Than Servers

Our current lock-down is showing cracks in our digital infrastructure, and there’s no greater crack than the usage of passwords. The…

Beyond Identity: Secure Enclaves and Authenticating Clients Rather Than Servers

Our current lock-down is showing cracks in our digital infrastructure, and there’s no greater crack than the usage of passwords. The simple user name and password is really just a legacy of the old main frame world, and possibly has no place in this world of knowing your user. Recently Microsoft defined at over 99% of identity theft could be overcome by simply enabling multifactor authentication (MFA).

Now a startup — Beyond Identity — aims to provide an identity solution which integrates an on-device personal certificate authority. In this way there is no need for the complexities of cerificate authorities, and where devices need to store the public keys of trust authorities. The signing process is then done within a secure enclave on the device. A device could then be registered as it’s own “server” domain, and be trusted to prove the user and the actions of the device.

If you have ever used Let’s Encrypt, you will know that they use a smart method of authenticating the Web server, and where they use the ACME protocol to securely install a digital certificate. The Beyond Identity aims to create a similar approach, but by authenticating clients rather than a servers.

One of the key features is the Beyond Identity aims to integrate with many of the existing standards for identity provision, including OpenID Connect (OIDC), OAuth 2.0, and SAML.

If you use a Macbook, you will find a friend in its secure enclave, and which is a place that securely stores passwords, encryption keys, and so on, and provides a place that not even Apple can get into. It is also a place that secure code can run, and that avoids any snooping. And so while this works on your Macbook, there will be questions as to whether Beyond Identity can setup a secure enclave within a wide range of Android and iOS related versions.

The ACME protocol

With Let’s Encrypt we use the ACME protocol, and which makes it easy to provide a certificate on a domain, and is at the core of Let’s Encrypt’s business model [here]:

While it started with Let’s Encrypt, it has now expanded to be used by either CAs (Certificate Authorities). In fact, it has been such a success that it is now being scaled to sign other things such as code signing and email. It basically works by creating an agent which will request, renew and revoke digital certificates. On a request, the agent initially creates a key pair (typically an RSA 2K key pair), and then shares this with a CA, and which then validates the site. Next, it signs a CSR (Code Signing Request) and sends it to the CA. The CA then takes the public key on the key pair, and issues a digital certificate and sends it back to the requestor. This can then be automated where the agent will make another request when the certificate needs to be updated or revoked. The great thing is that there is no human intervention required, and that will make many people happy, as certificate updates can cause so many problems.

The protocol is available on many different languages and with a range of target Web server environments. Here is the .NET version:

In the initial step, we need to generate a CSR. In the following we use OpenSSL to illustrate this:

The start of the process is the creation of a key pair. This can be achieved using Openssl [here]:

$ openssl genrsa -out ca.key 2048
Loading 'screen' into random state - done
Generating RSA private key, 2048 bit long modulus
..............................................+++
.......................................................+++
e is 65537 (0x10001)

In this case we have created 2,048-bit key pairs, and which are contained in the ca.key file:

Next create a self-signed root CA certificate ca.crt for MegaCorp:

$ openssl req -new -x509 -days 1826 -key ca.key -out ca.crt
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:UK
State or Province Name (full name) [Some-State]:None
Locality Name (eg, city) []:Edinburgh
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MegaCorp
Organizational Unit Name (eg, section) []:None
Common Name (e.g. server FQDN or YOUR name) []:None
Email Address []:none

Next we will create a subordinate CA (My Little Corp), and which will be used for the signing of the certificate. First, generate the key:

$ openssl genrsa -out ia.key 2048
Generating RSA private key, 2048 bit long modulus
............................................................+++
...............................................................................................................+++
e is 65537 (0x10001)

Next we will request a certificate for our newly created subordinate CA and create a code signing request (CSR):

$ openssl req -new -key ia.key -out ia.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:UK
State or Province Name (full name) [Some-State]:None
Locality Name (eg, city) []:Edinburgh
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Little Corp
Organizational Unit Name (eg, section) []:MLC
Common Name (e.g. server FQDN or YOUR name) []:MLC.none
Email Address []:Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:Qwerty123
An optional company name []:

The code signing request has the form of:

We can then create a certificate from the subordinate CA certificate and signed by the root CA.

$ openssl x509 -req -days 730 -in ia.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out ia.crt
Signature ok
subject=/C=UK/ST=None/L=Edinburgh/O=My Little Corp/OU=MLC/CN=MLC.none
Getting CA Private Key

If we want to use this certificate to digitally sign files and verify the signatures, we need to convert it to a PKCS12 file:

$ openssl pkcs12 -export -out ia.p12 -inkey ia.key -in ia.crt -chain -CAfile ca.crt
Enter Export Password: Qwerty123
Verifying - Enter Export Password: Qwerty123

The crt format is in encoded in binary. If we want to export to a Base64 format, we can use DER:

$ openssl x509 -inform pem -outform pem -in ca.crt -out ca.cer

and for My Little Corp:

$ openssl x509 -inform pem -outform pem -in ia.crt -out ia.cer

view of the cer file shows that it is in Base64 format:

Note what has happened here:

The client requestor setups an authorization key pair with the CA. This will be used to sign for CSR.
The client requestor creates a key pair for the domain.
The client requestor creates a CSR and sends it to the CA. It signs this with the private key of the authorization key pair that it setup security with the CA.
The CA check the CSR, and then signs a new certificate with its private key and puts the client’s public key on it. The public key of the CA is stored on a trusted root or intermediate level certificate.

Let’s Encrypt is an intermediate signer, and uses a root CA of DST Root CA X3:

For revocation, the client requestor signs a revocation request with its private key. The CA then posts the details of this on the Certificate Revocations Lists (CRLs) and Online Certificate Status Protocol responders (OCSPs).

The latest version of ACME is V2, and it has added the support for wild card certificates. As wild cards are not good practice, there is a strong challenge on the DNS record challenge, and whether the client has control over the domain.

And here it is my site with a 3K RSA public key [here]:

Conclusions

And so, we need move into an era — perhaps — where each device becomes its own little server, and runs in a secure enclave. It would thus move away from the complexities of PKI. Let’s Encrypt have shown a strong direction within trusting services, and Beyond Identity aims to move this type of approach to clients. It will be interesting to see if this approach works.