TinyELCA
Introduction
Software
Why all this anyway?
How everything works
First time use
The manual process
The automatic process
How to build
Download
 

Introduction

"To enable HTTPS on your website, you need to get a certificate (a type of file) from a Certificate Authority (CA). Let’s Encrypt is a CA. In order to get a certificate for your website’s domain from Let’s Encrypt, you have to demonstrate control over the domain. With Let’s Encrypt, you do this using software that uses the ACME protocol which typically runs on your web host."

(Source: Let’s Encrypt)

Let’s Encrypt is a great thing and has brought security to many websites through ease of use. The certificates from Let’s Encryped are also used for this website. Unfortunately can Let’s Encrypt only be used for domains which are accessible over the internet.

TinyELCA is an Embedded Local Certification Authority and tries to bring the HTTPS functionality to the local intranet.

Software

TinyELCA uses the same building blocks as TinyES3 used before. Again, Mbed TLS is used for the TLS support. And here, too, a BeagleBone Black is used for the hardware.

Why all this anyway?

If you want to transfer data securely in the intranet or another closed system, you also need TLS here for the web server. In order for this to work, a corresponding server certificate must be installed on the web server. These certificates are issued by a certificate authority (CA). Since an official CA does not issue certificates for the intranet, you have to trust your own CA for this. For example, you can create your own certification authority with OpenSSL, but the certificates must be issued manually for the respective server.

With TinyELCA this process can be automated and the servers can request their certificates independently.


How everything works

In order to trust a security solution, it must be available in source so that it can be verified. That is why TinyELCA is open source and the sources are available here. Furthermore, it will be described later on how to create the finished project from the sources if you want to do it yourself.

The functionality of the software is described transparently here, so you can decide for yourself if the functionality of the software meets your cybersecurity needs. Later, there are step-by-step instructions on how to set up TinyELCA.

Like TinyES3, TinyELCA is secured by user / password login of the Server System Administrator. A 2FA login with a FIDO2 stick is under development. There is no default password and you have to assign a password the first time you use it. The password requires at least one uppercase letter, one lowercase letter, one number and symbols. And the total length must be between 8-32. Only a salted hash is stored from this password. This is only the password for the administration not for the ELCA system.

The ELCA system has his own password. This password must be assign the first time the ELCA is used. Here the ELCA key is derived with the help of PBKDF2 and has a size of 256 bits. In contrast to the admin password, no hash is saved here, but a file with a specific content is encrypted with the ELCA key and stored on the SD card. If a password, for the ELCA, is entered later, an ELCA key is generated again and an attempt is made to decrypt the file with it. If the correct content can now be restored, the password is correct. AES is a cryptographic algorithm used to protect the ELCA. The ELCA can be locked and unlocked with the ELCA key.

So that a server certificate can be issued by the certificate authority (CA) at all, a Certificate Signing Request (CSR) is required.

"Before creating a CSR, the applicant first generates a key pair, keeping the private key secret. The CSR contains information identifying the applicant (such as a distinguished name in the case of an X.509 certificate) which must be signed using the applicant's private key. The CSR also contains the public key chosen by the applicant. The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority, and the certificate authority may contact the applicant for further information." (Source: Wikipedia)

With the system presented here, there are two ways in which the server certificate can be created. The first option is a manual process that can only be performed by the system administrator. The certificate signing request (CSR) is entered on the website of TinyELCA, and the server certificate will be created. The server certificate that has now been created must then be installed on the server. This is a viable option for test purposes, but it is more time-consuming and error-prone for installation on multiple systems.

That is why there is a second automated option available. Here the server itself connects to TinyELCA and transmits the CSR. The certificate is then generated by TinyELCA and sent back to the server. This process is of course protected with an authentication to TinyELCA.

A PSK is used for authentication. After a request from the server to TinyELCA, the ELCA system sends a random value of 16 bytes back to the server. The server now encrypts this data with the PSK and sends it back to TinyELCA with its CSR. The 16 bytes are decrypted on the ELCA system and compared with the bytes which was sent. If the result is the same, the server certificate for the given CSR is created and sent back to the server. This procedure ensures that only servers that have the PSK can get a certificate from TinyELCA.


First time use

As already mentioned, a password must be set when using it for the first time:

(Click inside the picture to expand)

After the initial setup, the login is required, with admin for the user:

(Click inside the picture to expand)

After the login the windows looks like:

(Click inside the picture to expand)

After switching on the TinyELCA, the ELCA is still locked, and must be unlocked:

(Click inside the picture to expand)

And as mentioned before, the first time, the ELCA must be initialized too:

(Click inside the picture to expand)

And the result looks like:

(Click inside the picture to expand)

After the initialization, the ELCA looks like this:

(Click inside the picture to expand)

Oops, the following files are missing here on the SD card:

  • /elca/root.crt
  • /elca/inter.crt
  • /elca/inter.key

In order for TinyELCA to work, these 3 files have to be created.
With the help of the "Build your own CA" project these missing files can be generated. Please rename and copy the following files accordingly on the SD card:

  <root-ca>/ca/certs/ca.cert.pem   =>   /elca/root.crt
  <root-ca>/ca/intermediate/certs/intermediate.cert.pem   =>   /elca/inter.crt
  <root-ca>/ca/intermediate/private/intermediate.key.pem   =>   /elca/inter.pem

With the correct files, the ELCA looks like this:

(Click inside the picture to expand)

Should the following error still be present here, "Error, the PSK "/elca/psk.key" could not be found.",
it can be ignored for the moment. The PSK will be needed for the automatic process later.

Don't worry that the "inter.pem" key was unencrypted copied on the SD card. When TinyELCA is starting, the "inter.pem" key is encrypted with the ELCA key and stored on the SD card under "inter.key". The unencrypted PEM key will first be overwrite with zeros, and after this deleted.

In order for the certificates generated by TinyELCA to be accepted by the users' browsers, the users must import the TinyELCA root certificate into their browsers. The Server System Administrator can download the root certificate by clicking on the "Root Certificate" link and make it available to the user.


Oh, by the way, if you don't use the TinyELCA's website for a minute, you will be logged out automatically.


The manual process

The manual process will be started by using "ELCA / Create Certificate". The content of the CSR must be copied into the text field:

(Click inside the picture to expand)

The certificate is now generated by clicking on the "Create" button:

(Click inside the picture to expand)

The server certificate can be saved by clicking on the "server" link:

And with a click on the "Intermediate" link, the intermediate certificate can be saved:

With the following files, the server is now able to support HTTPS:

  • device.key   (private key from the server which was used to create the CSR)
  • device.crt
  • intermed.crt

The automatic process

As already mentioned, the automatic process requires a PSK for authentication. PSK stands for "Pre Shared Key", which means a shared secret that must be known on both sides. Therefore create the file "/elca/psk.txt" on the SD card which contains the "password" for the authentication.

When TinyELCA is starting, the unencrypted "psk.txt" is encrypted with the ELCA key and stored on the SD card under "psk.key". The unencrypted file will first be overwrite with zeros, and after this deleted.


How to build

Segger Embedded Studio v5.42a was used as the compiler to build the TinyELCA.

I provide here the sources without Mbed TLS so that you can take the latest version when you build it yourself. To complete the sources please copy the original Mbed TLS sources into a temporary directory. At the time I write this description, version 2.16.10 is the current version of Mbed TLS. That means that when unpacking the original sources a directory "mbedtls-2.16.10" was created in the temporary directory. Then copy the data from inside the "mbedtls-2.16.10" directory into the empty mbedtls directory of the project.

Next, the Mbed TLS configuration has to be taken from the project and not from Mbed TLS itself. To do this, copy the "config.h" file from the "config" directory which is located in the root of the project over the "mbedtls / include / mbedtls / config.h" file.

Download

The download files can be found on GitHub at tinyelca.