Better safe than sorry – additional components
ZRTP
The security of communication with ZSipOs is based on the ZRTP protocol. ‘Z’ stands for Zimmermann, the cryptography pioneer and inventor of PGP. The protocol was published in 2011 as RFC 6189.
ZRTP uses the Diffie-Hellman algorithm to generate a secret session key for each connection that is secure against eavesdropping. This key is then used for a VoIP data connection in accordance with the SRTP protocol and deleted once the call is ended. This makes it impossible to decrypt a recorded conversation retrospectively.
ZRTP does not require any shared secrets or a Public Key Infrastructure (PKI).
The Diffie-Hellman key exchange does not provide protection against a ‘man-in-the-middle’ attack. To prevent this, a ‘Short Authentication String’ (SAS) is generated from the session keys and displayed on both end devices. The SAS is verbally compared by the parties involved, who are known to each other. If it matches, a man-in-the-middle is ruled out.
Key Continuity
If a ZRTP connection has already been established with the remote station, both sides ‘remember’ the ‘shared secret’ from the last connection and use this to establish a new one.
The SAS comparison is not required, and an intermediary remains excluded.
This means that, under normal circumstances – i.e. when a secure connection has already been established with the remote station – full confidentiality is ensured without the user having to perform any additional steps. If a connection is established with a remote station with which a SAS comparison has already taken place, trustworthiness is immediately indicated.
seL4 Mikrokernel
Risk
A standard operating system, such as Linux or Windows, is structured much like a large building: there are strong outer walls, but also many doors, windows and other access points. Each of these access points is well secured, but there are many of them and errors inevitably creep in from time to time.
If an intruder has overcome one of these access controls, they can move freely throughout the entire building unhindered. They have access to all data and can spy on or alter it at will.
Solution
We use seL4 as the microkernel system core. The aim of this architecture is to limit the consequences of a breach.
There are still various access points with different access controls. However, if an intruder has breached one of these, they can no longer move freely within the system. Functionality is divided into different tasks. These are extremely isolated from one another. In the case of seL4, this separation has also been formally verified [5]. Communication between different tasks can only take place via the microkernel’s mechanisms; direct data access to other tasks is not possible. If an attack succeeds via an interface, therefore, only the task behind it is compromised; the rest of the system remains protected.
RISC-V CPU
Risk
We find a wide range of open-source solutions, ranging from operating systems (e.g. Linux) to application programmes (e.g. OpenOffice).
However, with standard solutions, one important aspect remains in the dark: the CPU.
Although its functionality is documented by the manufacturer, it is not possible to verify that the documentation is complete. Additional commands or variants of documented commands could be built in – an ‘extension’ that a programmer cannot detect. Furthermore, there is the possibility of activating hidden functions only for specific data (semantic attack). This allows attackers to penetrate even systems running open-source software. This would remain undetectable even with knowledge of the software.
There is no reason to assume that this possibility has not been exploited.
Solution
We are building an ‘open CPU’. If built using discrete logic components, the result would fill a sports hall. Developing a CPU as an integrated circuit would require a multi-million-pound budget.
FPGA
But there is a third way: freely programmable gate arrays allow us to build any complex logic circuit using off-the-shelf ICs. A RISC CPU is defined using the Verilog hardware description language: RISC-5.
This gives us a fully open hardware and software platform.
Implementation: ZSipOs
ZSipOs is based on the RISC-V Project (https://risc-v.org). A complete circuit is available in the hardware description language Verilog. This is compiled and then ‘burned’ into the FPGA. The use of the FPGA also allows us to implement additional hardware functions, e.g. for connecting external components.
Furthermore, we can offload time-critical algorithms directly into hardware modules formed by the FPGA. In the ZSipOs architecture, this is used for the symmetric AES encryption and the SHA-1 hash function with a fixed block length.