TinyES3
Introduction
Software
Why all this anyway?
How everything works
First time use
Private, public key creation
Add user
Daily use
How to build
Download
 

Introduction

TinyES3 is an Embedded Secure Signing Server that uses an encryped key storage, EKS. The server uses the private elliptic curves keys stored in the EKS to generate the digital signatures. The signature is based on selectable signing keys which are securely stored on the server. The signing keys can be generated on the server itself. Thanks to the EKS, it is easy to clone the server and create a redundant, highly available signing system.

The server can be used to sign embedded files like firmware uploads. A corresponding signature header will be added in front of the original file. To verify the file on the recipient side, the coresponding public key must be available on the recipient.

The signature process requires not only the server, but also a command line application, the client. The file to be signed is first hashed by the client and this hash is then sent to the server. The hash signature is now created on the server and sent back to the client. Here the signature header is created and placed in front of the original file.

Software

TinyES3 based on the software from TinyONE with the additional functionality of the Session ID and with TLS support. For the TLS support, Mbed TLS was used. The Session ID is not a new invention but the attempt to implement such functionality on small systems, which has been available for a long time in Windows and Linux applications. Small systems here do not mean embedded Linux systems, but rather even smaller systems with a simple operating system and limited resources.

Due to the basis of the TinyONE server, the following components are used. The current system uses a user / password login. A 2FA login with a FIDO2 stick is under development.

Btw, for the hardware a BeagleBone Black with TinyCTS instead of Linux was used.

Why all this anyway?

The lecture from 35C3, Smart Home - Smart Hack, inspired me to create a simple and secure signing solution for the embedded area. The lecture is available in German and English here:

That was at the end of 2018, and since then I wanted to create a solution so that embedded software can be signed, and this with open source components. With embedded software I don't mean Linux or Android applications. There is already an infrastructure here.

Furthermore, the system should be easy to use. This means that the signing should be easy to implement in an existing build process. The solution should not only be usable by a single person, but also by a small team. The private keys should not be on the developer's computer and it should be possible to set up a redundant system. In addition, it must be easy to clone the system and only authorized users should be able to sign.

That was actually the specification. Signing may be only a small part, but it can help to improve the security of a system.

Then let's see if the requirements have been implemented.


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 TinyES3 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 TinyES3, add an user, and an example for daily use.

TinyES3 is secured by user / password login of the Signing 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 encrypted key storage (EKS).

The encrypted key storage (EKS) has his own password. This password must be assign the first time the EKS is used. Here the EKS 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 EKS key and stored on the SD card. If a password, for the EKS, is entered later, an EKS 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 EKS. The EKS can be locked and unlocked with the EKS key.

The EKS is divided into different slots. Whereby slot 0 is the "root of trust" and the other slots are freely available. Each slot has a unique name. Slot 0 is created automatically when you first set it up. The elliptic curve "NIST P-256" is used to generate the keys. Only the administrator can create, disable and enable keys. It is not possible to delete keys by the GUI. Only the public key can be displayed. Each slot is individually secured with the EKS key and saved on the SD card. Because the EKS is stored encrypted on the SD card, a redundant system can also be set up easily. For this, the EKS only needs to be copied to the other system.

Authorization is required for the user who wants to receive a signature from the TinyES3. The public key procedure is used for authorization. To do this, the user has to generate a private and public key. And the public key is then stored in the TinyES3 by the Signing Server System Administrator. Each user is individually secured with the EKS key and saved on the SD card. Only the administrator can add and delete users. The actual signing job is then signed with the user's private key and sent to the TinyES3. This checks with the user's public key whether the order is authorized. If this is the case, the signing order is carried out. The request and the response to the order are not transmitted in encrypted form, since no data is transmitted here that would have to be protected. A replay attack would also make no sense here.


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 TinyES3, the EKS is still locked, and must be unlocked:

(Click inside the picture to expand)

And as mentioned before, the first time, the EKS 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 EKS looks like this:

(Click inside the picture to expand)

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


Private, public key creation

A new private, public key is created via the "Create" link in the EKS "Overview". Next, the identifier for the slot is required:

In this example the slot name is "firefly". After pressing "Create" the new key was created:

A slot can be temporarily disabled, or the public key can be shown:

Authorization is required for the user who wants to receive a signature from the TinyES3. Therefore a user will be added next.


Add user

Do you also know Alice and Bob? They are always very busy, but here Alice wanted to test TinyES3 with her firefly project. In order for Alice to be able to use TinyES3, she must first authorize herself as a user on the server. For this purpose, a private and public key must be generated by Alice. This is done with the command line tool es3keygen. To do this, Alice now starts es3keygen, the output looks like this:

In the user's home folder, the ".es3" folder is created with a private and public key. Alice must now send the id_es3.pub file to the administrator of the TinyES3 so that he can store Alice's public key in the server.

The administrator use now the "User" page and can add a new user via the "Add" link:

(Click inside the picture to expand)

The next window now looks like this, where the data of the "id_es3.pub" file has already been copied in by the administrator:

After pressing "Create" the new key was created:

The user overview page now looks like this:

Alice has now been added to the server, so she can now use the signing service.


Daily use

The following tools are available to Alice for daily work with the TinyES3:

  • es3discover
  • es3sign
  • es3verify

With es3discover Alice can check whether a TinyES3 is available in the network:

es3sign is the program for signing. The program needs as parameter the slot and the file which should be signed:

When signing, the first signing server found by the es3sign program is automatically used. After signing, a file is created in which the existing extension has been replaced by ".es3".

With es3verify and the public key of the slot with which the file was signed, it can be checked whether the signing is valid:

Thank you Alice for using the signing service of TinyES3 for your project.


How to build

SEGGER Embedded Studio v8.10b was used as the compiler to build the TinyES3. The "es3" tools was build with Microsoft Visual C++ 6.0.


Download

The repository can be found on GitHub at tinyes3.