Implementing a Security Architecture for any IoT system under hardware constraints (limited RAM, flash, computational overheads) is a big challenge. Additionally, the EU's security mandate under the Cyber Resilience Act (CRA) will not allow CE certified connected products without a coherent security architecture anymore (full enforcement by 2027).
Our Security Architecture
Symbiotic Security represents a paradigm shift in IoT security architecture, where hardware, software, network components and even human operators work together synergistically to overcome their respective limitations. For example, while hardware is naturally static and is as such potentially more resilient to malicious modifications, software can help push past those boundaries. At the same time, a well-crafted hardware design can reinforce the weaker position of the software it executes. Ultimately, all essential architectural pillars must be considered during the initial design stages to form a solid security ‘powerhouse’. As such, we do not separate the device side (hardware & software) and the IT side. Instead, we think holistically and respect all the building blocks at once.
On the device side of our service spectrum, we offer bare metal and RTOS solutions based on ARM Cortex M0 through M85. Our portfolio specifically targets demo projects (bootloader and application) to showcase the full bandwidth of options as well as the flexibility that comes with this approach. An auxiliary PC utility software highlights the additional safeguards for the device inspection and registration procedure. A flexible and extensible infrastructure unit provided by our partner Peak Solution GmbH complements our product as opposed to the usual experience where customers and developers must marry their end devices up with some generic cloud-based infrastructure service.
Please refer to our partner’s website for more information on the server-side technology:
In general, secure IoT stands and falls with the concept of "Security-by-Design". To that end, critical components such as production (Electronics Manufacturing Services, EMS), initial configuration, key and certificate deployment are all smartly intertwined within our technology. Furthermore, our design extends well into the realm of the usual target environment to aid customers with the practical aspects such as enrolment, product life cycle and reprovisioning to boost the underlying sustainability and cyber resilience.
Inadequate Solutions (State of the Art):
- Manufacturer-embedded secrets:
violates CRA's no hard-coded credential requirement - Trusted Platform Module (TPM)-based attestation:
expensive and still requires pre-shared manufacturer keys - Manual configuration:
error-prone and not scalable for millions of devices - Even software-based OTA solutions rely on static secrets which makes them inferior and much more constrained
- Modern Physical Unclonable Function (PUF) solutions improve physical security, but remain static, and therefore unsustainable in the case of a compromise
The Main Challenge with Connected Devices Today
The Initial Enrolment Problem represents a decade-long limitation specifically in the Public Key Infrastructure (PKI)-domain. To this day, it constitutes a fundamental paradox in traditional IoT security:
- Secure enrolment requires pre-existing secure channels
- => Establishing secure channels requires authentication
- => Authentication requires pre-shared secrets or credentials
(shared with Electronic Manufacturing Service (EMS) or supply chain)
Break out of This Vicious Circle!
It all starts with the decision to refrain from pre-injecting secrets, cryptographic keys or PKI certificates into an IoT device during the manufacturing stage. The added values speak for themselves:
- Take the supply chain out of the equation
- Reduced attack surface, reduced manufacturer burden (e.g. EMS & OEM) thanks to full transparency and zero trust assumed
- The enrolment (PKI & firmware injection + "bonding" with the infrastructure) is left to the full discretion of the device owner, operator and their target environment
The Three Pillars of the Zero Knowledge Initial Enrolment (ZKIE) Scheme:
- bare metal 'smart' bootloader
- Enrolment: Initial Registration Tool (IRT)
- ZKIE server (bootstrap authentication, secure firmware repository, PKI, Over-The-Air (OTA) and automation workflows)
The device owners and operators need only focus on three components/services:
- An application firmware for the device in question
- The deployment option for the ZKIE server (self-hosted, Software-as-a-Service etc.)
- Interfacing with the existing Identity Provider (IdP) and the specific authentication mode (e.g., by means of the IRT tool, with or without FIDO 2FA etc.
The Principle of Operation
The end-customer can either leverage our full-service provision (ZKIE server) to automate the process of certificate generation and deployment or choose to attach to their existing PKI for full security and governance compliance.
Either way, no application firmware is preinstalled on the device.
Device enrolment is carried out via the following steps:
- The IoT device is sold, delivered and installed only with the minimalist ZKIE bootloader
- Once physically connected, the installer or operator activates the device enrolment with the help of the IRT tool as an additional gatekeeper
- The device creates a unique verifier and transfers it via the IRT tool’s secure Out-of-Band (OoB) channel to the ZKIE server
- The installer (i.e., human operator) is authenticated by e.g. FIDO two-factor authentication towards the target infrastructure
- The device fetches its designated server URL (via the mutually authenticated and encrypted OoB channel) to later connect to
- The server can correlate the device based on its verifier with the designated infrastructure tenant
- The server creates the corresponding PKI certificates, related configuration details and assigns a firmware to the device in question
- The device opens a zero-knowledge communication channel to the ZKIE server
- The server sends the PKI certificates, the firmware and specific configurations to the device
- Now the device can go straight into the production mode using its fresh certificate to participate in the mandatory TLS (Transport Layer Security) communication with any infrastructure backend
- On suspicion of any security breach or malicious modification, the device in question can be remotely wiped.
After that, the device automatically falls back into its bootstrap phase to go through the ZKIE process again.
At this point, the device generates a fresh secret key rendering even the successful attack ineffective.
As the secure wipe and fallback mechanism naturally triggers the ZKIE workflow as well as the subsequent firmware delivery, it can also be leveraged in the same straightforward way to install firmware updates (OTA) in the field. Thus, even if any of the upper communication layers were to be considered ‘broken’ (e.g., TLS due to expired certificates or incompatible settings), the bootloader would take the device back to square one by leveraging generic TCP/IP only.
The potentially malicious application layer is no longer responsible for OTA updates.
Consequentially, the owning infrastructure will automatically revoke the compromised device identity / certificate while at the same time regenerating a new untarnished one to be supplied to the device without delay. This is a key benefit to support business continuity and cyber resilience as prescribed by the CRA regulation.
Components and Interfaces of the ZKIE architecture
We provide bootloaders for several different MCU vendors while offering bootloader customisation based on the customer’s MCU choice and other specific needs.
To support customer applications we also offer our own development PCB, the GENESIS platform.
It features two Renesas EK boards: the RA4 MCU for any peripheral connections (e.g., specific customer field bus applications) as well as the RA8 as a main core MCU.
The RA8 sports considerable capacity in terms of power, speed and performance to pave the way for the most demanding customer applications. However, it is possible to substitute it with a different MCU subject to any requirements, given the connectivity hardware offload to the WIZnet W5500 TCP/IP stack (W6300 coming soon).
We are Renesas RA ecosystem partner here as well:
Additionall information about our GENESIS-Board in this article:
Author:
