IoT end-to-end encryption with E4 (3/n): automation component

Our previous post, introduced the architecture and components of E4, Teserakt’s encryption and key management for IoT systems. This post is about one of these components, the automation engine, which we’ll describe more in depth today.

Keys are not forever

Devices managed by E4 rely on symmetric or public-key cryptography to protect their communications. In both mode, each device has its own identity key, plus one one key for each topics (you can see a topic as a "conversation", as a data type, as a classification level, and so on). Since devices may be deployed for years, there must be processes to renew these keys remotely and securely. Motivations for rotating keys include:

  • Revocation of a key that has possibly been compromised, or is not to be trusted for various reasons

  • Provide forward secrecy, that is, guarantee that if a key is compromised at some point, then earlier communications (with a different key) cannot be decrypted

  • Provide backward secrecy, or post-compromise security, for example in order to guarantee that, would some topic key be compromised, future topic keys remain secret, and therefore content protected with these keys remain protected.

Such key rotation may be done manually, or partially manually by creating some scripts, creating a custom network service, and so on, and updating the script manually when needed. This is a cumbersome and error-prone procedure that is unlikely to scale and to prove reliable in critical environments. We therefore propose an automation system that is simple to use (both through a graphical UI and scripts), and that easily scales to many topics and many messages.

The E4 automation engine address exactly this problem. It automates the rotation of any E4 keys by defining rules following a simple grammar, depicted below:

In the context of our key rotation automation, we then use following terms:

  • Rule: a rule is the main component of the engine. It holds a list of triggers and targets controlling when the key rotation will happen, and which device or topic will be updated.
  • Trigger: a trigger is a condition that must be fulfilled in order to execute a key rotation for all the parent rule’s target. A trigger can be a predefined period of time, or a number of system events, such as a threshold of clients joining or leaving a certain topic.
  • Target: a target designates either a client device or a topic, for which the key will be updated when one of the rule’s triggers will have its condition fulfilled.

When to rotate keys

We currently support basic use cases such as:

  • Rotating a device or topic key at a fixed time interval
  • Rotating a topic key after a certain number of clients joined or left this topic

Those cover the most common scenarios requiring a key rotation. We’ve also carefully designed our engine and rules format to be flexible and easily extensible. If you have any other use cases which are not actually covered, we’d be happy to hear about them!

We’re often asked what’s the right time interval for key rotation. There is no single right answer, for it depends on a number of factor including the threat model and risks, the network reliability, the cost of sending control messages, etc.

How it works

As seen in our previous architecture post, the automation engine extends the C2 server functionalities. When enabled, it starts an internal scheduler that monitors the time-based rules, and also registers a channel on the C2 server to receive system events. On each events, the automation engine will check from the defined rules if any triggers are due, and request a key rotation for each of the rule’s targets on the C2. The trigger state then reset and is waiting again for its conditions to be met to fire again.

Client key rotation

A client’s key is its more critical key, and should ideally be better protected than topic keys, which are shared with other devices. In the symmetric key mode, the client’s key is also known to the C2, and used to protect control messages sent to that client. One of thes commands supported by control messages is SetIDKey, which offers a new client key to a remote device.

When a client key is rotated, the C2 server thus issues a SetIDKey command, containing a newly generated key, and protected with the current client key. The command is then transmitted to the client via the MQTT broker, by publishing it on the client control topic.

In the public-key mode, the C2 only knows clients’ public keys, not their private keys. Therefore client keys can’t be rotated in the public key mode.

Topic key rotation

When a topic key is rotated, the C2 server first generates a new random key, before issuing a SetTopicKey command for every subscribed clients on this topic. Each command is then protected, using the client key of its recipient, before transmitting on each client control topics.

When a topic has many subscribed clients, there might be a significant delay between the first and last SetTopicKey commands transmission (and thus reception). Some clients may thus use the old key while others are already using the new one, preventing the decryption of messages in each way. To avoid message loss, we thus need a key transition mechanism, which we implemented by defining a configurable grace period.

Grace period

The grace period is a client parameter, which defines the duration during which both the old and new key can be used, starting from the time when a new topic key is received. The client will store the newly received key, and keep the old one for a configurable amount of time. The devices then does the following:

  • When receiving a message, it first tries to unprotect it with the new key. If this fails (as indicated by invalid authentication tag), the client then tries with the old key if it is still within the validity period.

  • When transmitting a message, the new key is always used. This might prevent some devices from reading the message, however this is safest behavior in case the old key was compromised. Furthermore, using the old key would also prevent messages to be decrypted by clients whose grace period has passed.

Again, when we’re asked what’s the best grace period value, our answer is that it depends on several factors, including the number of clients subscribed to a topic, how often keys are rotated, the network’s latency and reliability, and so on. Ideally, the grace period should be chosen after analyzing empirical data. The best value of the grace period is one that sufficiently minimizes messages loss, while minimizing the amount of messages encrypted using the old key (thus, the shorter the period, the safer).


Key management, and more particularly secret rotation, can be a tedious task. With E4, we try to make it transparent, fail-safe, and easy to configure and operate. You can configure your device and topic keys rotation, either from the dedicated page on the web console, or from the command-line client, allowing to create or view active rotation policies.

You can try it yourself, and start rotating keys using our e4 client, with binaries for common architectures available on the release page. Automation rules can then be created from the demo console.

IoT end-to-end encryption with E4 (2/n): architecture and integration

The previous post in the series introduced the E4 protocol, which brings end-to-end encryption to IoT networks in a scalable way. We now describe how simple and unobtrusive E4 is to integrate in an existing infrastructure. We’ll start with a basic example of an IoT architecture, present the limitations in terms of data security, and then introduce E4 components and their integration.

An typical IoT architecture

A common industrial IoT architecture includes a multitude of connected devices, reporting their data such as measurements to a processing back-end. In the example depicted below, the MQTT transport protocol is used, such that devices and the back-end connect to an MQTT message broker in order to exchange messages according to a publish/subscribe logic.

Because devices directly publish their data as cleartext messages, this data is exposed to the message broker, which can read its content, modify it, and create fake messages on behalf of the devices. This can happen in different scenario, for example when:

  • The broker is operated by a third party, such as a cloud operator
  • The broker is compromised by an attacker, who then controls its operation
  • The broker database is compromised, and therefore all its messages

Other network components (routers, gateways, etc.) can also do the same if the connection between devices and the broker is not protected.

In other words important security properties are missing in this architecture:

  • Data authenticity and integrity of messages
  • Data confidentiality

The same concerns apply when data is sent to the devices, such as firmware or configuration updates, as well as when devices communicate with each other.

E4 integration

The E4 solution aims to protect IoT data without making any change to the message broker (or similar component), and in a way that it mostly independent of the transport protocol (in this example, MQTT). As you can see in the image below, our server component (C2) connects to the message broker like any other device, and other network components (devices and back-end) integrate our software library in order to support the E4 security layer. The subsequent sections explain how this integration is done.


We defines a few terms:

  • E4 clients (or just "clients"): In E4, clients are anything able to publish or receive messages. In our examples, the devices, sensors or processing backend are all identified as clients. E4 clients must each have a unique identifier, and a secret key.
  • C2 server (or just "C2"): The back-end component of E4, which is seen by the network as just another device. C2 sends control messages to E4 clients and performs security monitoring operations, among others.
  • Topics: MQTT topics are the message queues where messages will be published and read from. In E4, topics can be associated with a secret key, which clients will use to protect messages tagged with this topic.
  • Protect/Unprotect: Instead of just encryption/decryption, E4’s security layer can also provide integrity, authenticity, and replay protection. That’s why we refer to the message transformation as "protection" rather than only encryption.

Modifications to clients

To integrate E4, the main modifications take place at the applications level, which need to send or receive messages on the clients. They need to integrate the E4 library in order to:

  • Protect a message before publishing it. This ensure that intercepted messages can’t be read nor modified by unauthorized parties.
  • Unprotect a message after receiving it. This allow to retrieve the original message payload from a protected message.
  • Subscribe to the device’s control topic. This allow the C2 server to send control messages to this unique client.
  • Store an identifier and related key material.
  • Process control messages sent by the C2.

C2 integration

The C2 is E4’s key management server, whose main roles are to:

  • Keep track of client devices and their associated cryptographic keys.
  • Identify communication topics, and their associated cryptographic keys.
  • Send control messages to the clients.
  • Perform analytics to monitor the network.

The C2 exposes an API (gRPC or HTTP) allowing to register all your clients and topics, and securely provision keys to devices in a manual or automated way. To do so, it only needs to reach the MQTT broker, as a normal client (ideally with MQTT QoS parameter set to 2).

Besides its core service, C2 provides additional and optional services:

  • A simple web-based UI, to manage clients and topics manually. See our public demo
  • A command-line tool (c2cli), allowing scripting and batch processing for your clients and topics management.
  • An automation engine to define, manage and automate key rotation policies (which will be presented in a future post in this series).

As depicted above, additional services directly connect to the core C2 service, meaning there is still no change to make to your existing infrastructure.

C2 database

The C2 can use popular SQL RDBMSs (such as MySQL, PostgreSQL, SQLite) to store your devices and topics. All the cryptographic keys are stored encrypted, and only decrypted when needed, that is, when transmitting them to clients in control messages.

In its simplest setting, database records are encrypted using a key controlled by the C2 service. Depending on the security needs and available technology, the following components can be used to manage the database encryption key:

  • HSM via PKCS#11 interface
  • Dedicated key management service such as Hashicorp’s Vault
  • Cloud-based key management services such as AWS KMS

Control messages

In order to control each devices internal state, such as their identity key (used by the C2 server to encrypt the device’s control messages), or the list of topic keys (used to encrypt or decrypt the data transmitted or received by the client), the C2 service emit control messages, which can be of one of the following types:

  • SetTopicKey to set a key for a given topic, allowing the device to read or publish messages on this topic.
  • RemoveTopic to remove a topic key from the client, preventing the device to read or publish messages on the topic.
  • ResetTopics to remove all the topic keys stored by th client.
  • SetIDKey to set the device identity key, required to process control messages.

As we’ll describe in a future post, E4 support symmetric-key and public-key cryptography modes. In the public-key mode (which is the safest), the following messages are used:

  • SetPubKey to add the public key of another device in the local storage, allowing to authenticate the message sender.
  • RemovePubKey to remove a stored public key from the client’s storage.
  • ResetPubKeys to remove all the public keys stored by the client.

Control messages are protected using the current device key, and published by the C2 on the device’s control topic (created from the client unique identifier we mentioned above).

The processing of control messages is implemented in the client software, as you can see for example in E4’s Go client.


E4 allows you to protect your IoT data with minimal changes required, and a short integration and testing period. E4 does not require any change to the message broker, nor additional hardware or software capabilities on the clients.

E4 is also robust and resilient to outages: although the C2 services are designed for scalability and high-availability, devices can still communicate reliably if these are unavailable or are temporarily down for maintenance..

If you’re interested in learning more or have any question, feel free to contact us!


IoT end-to-end encryption with E4 (1/n): it's open-source!

We’re thrilled to announce a major milestone for Teserakt, with the launch of our flagship product E4 as open-source software.  We want to make Teserakt’s IoT protection solution as easy to try as possible, and available to any user from hobbyists to large corporations. This is why our client library is now free to use, enabling anyone to integrate strong end-to-end encryption into their applications.

We go even further: Although our server is not open-source, we run a public demo version of our web interface, available without any registration or email identification. Using this demo in combination with our open-source client application, anyone can test our key management server with no effort.

E4 is the product of two years of research, interacting with customers from industries such as aerospace, agriculture, automotive, energy, healthcare, and physical access, to understand real applications’ security needs and technical constraints. E4 is also ideal for mobile applications, to protect personal or other sensitive data.

This is the first of a series of posts about E4, its architecture, components, and internals, which we’ll be publishing during the coming weeks. Meanwhile, technical and commercial information about E4 is now available on E4’s page.

The Q&A below gives a general overview of E4, before more details in the upcoming posts. Don’t hesitate to contact us directly at [email protected] if you have specific questions or would like access to a private instance of the E4 server.

What is E4?

E4 is Teserakt’s innovative data protection software solution for IoT networks, consisting of 

  • A client library, used to encrypt and decrypt data, and 
  • A key server to manage devices rights manually or automatically.

What exactly is now open-source?

We open-source E4’s client library, available in the C and Go languages. It can be integrated into a wide range of embedded platforms, as well as mobile applications or cloud services, in order to enable end-to-end data protection.

E4’s key server is not open-source, but is not required to test the client library’s capabilities. Without the server, the client library can be used with fixed keys and without management and monitoring features.

Do I need the server for my application?

E4’s key server is used to manage devices remotely in order to provision keys, grant and revoke rights to devices, ensure perfect forward secrecy, automate key rotation policies, monitor message for anomalies, and so on.

Enterprise, production deployments will likely need the server, while personal projects and prototypes can work with only the client library. The server is offered on a commercial basis along with technical support, software maintenance, and extra features integration.

What network protocols do you support?

The client library is agnostic of the network protocol, as it works on top of the network layer in order to encrypt/decrypt data, and to process control messages from a server.  

Our server works by default with MQTT (the IoT protocol used by AWS’ IoT Hub and Google Cloud IoT platforms), and can be configured to work with other protocols such as Kafka, AMQP, Zero-MQ. To know if we support your protocol, please contact us at [email protected].

How to try it?

It takes less than 5 minutes! To try E4 without writing your own application, we created a simple interactive client application that you can use in combination with our public demo server interface. You can directly download the client’s binary for your platform or build it yourself, and then follow the instructions.

What cryptography does E4 use?

E4 can run in two modes, symmetric or public-key cryptography. The symmetric mode is optimized for the most constrained platforms, and only uses AES-SIV and SHA-3. The public-key mode uses in addition Ed25519 signatures and X25519 key exchange. Details of our crypto protocols will appear in a subsequent post. Note that we also support a cipher suite including only FIPS 140-2 primitives.

At what address can I find… ?