Safety first - further Components

ZRTP

The security of communication with ZSipOs is based on the ZRTP protocol. "Z" stands for Zimmermann, the crypto pioneer and inventor of PGP.
The procedure was published in 2011 as RFC 6189 [4].

ZRTP uses the Diffie-Hellman method to generate a secret session key for each connection in a tap-proof manner. This is then used for a VoIP data connection according to the SRTP protocol and deleted after "hanging up". This makes it impossible to subsequently decrypt a recorded call.

ZRTP requires no shared secrets and no public key infrastructure (PKI).

Diffie-Hellman key exchange does not provide security against a "man in the middle" attack. To exclude this, a "short authentication string" is generated from the session keys and shown on the display on both terminals. The SAS is compared verbally by the known dialog partners. If it matches, a “man in the middle” is excluded.

Key Continuity

If a ZRTP connection has already been established with the remote station, both sides "remember" the "shared secret" of the last connection and use it to establish a new one.

The SAS comparison can be omitted, an intermediary remains locked out.

This means that in the normal case, i.e. if a secure connection has already been established with the remote station, full confidentiality is established without the user having to perform additional operating steps. If a connection is established with a remote station with which a SAS comparison had already been carried out previously, the trustworthiness is immediately displayed.

seL4 Mikrokernel

Vulnerability

A normal operating system, such as Linux or Windows, is constructed much like a large building: there are strong walls on the outside, but also many doors, windows or other access points. Each of these entrances is well secured, but there are many and mistakes creep in again and again.

Once an intruder has overcome one of these access protections, he can move freely throughout the building. He has access to all data and can spy on or change them at will.

Solution

We use seL4 as a microkernel system core. The purpose of this setup is to limit the consequences of an intrusion.

There are still different entrances with different access protections. But if an intruder has overcome one of them, he can no longer move freely in the system. The functionality is divided into different tasks. These are extremely isolated from each other. This separation has also been formally verified in the case of seL4 [5]. The communication between different tasks can only take place via the mechanisms of the microkernel, direct data access to other tasks is not possible. If the attack succeeds via an interface, then there is only compromised the task behind, the rest of the system remains protected

RISC-V CPU

Vulnerability

We find a rich spectrum of open source solutions. Starting with the operating system (e.g. Linux) to application programmes (e.g. Open Office).

However, with the common solutions, an important part remains in the dark: the CPU.

Even though its function is documented by the manufacturer, it is not possible to check the documentation for completeness. Additional commands or variants of documented commands could be built in - an "extension" which a programmer cannot recognise. In addition, it is possible to activate hidden functions only for certain data (semantic attack). This means that attackers can even penetrate systems with open software. This would not be recognisable even with knowledge of the software.

There is no reason to assume that this possibility has not been used.

Solution

We build an "open CPU".
Based on explicit logic elements, the result would fill a warehouse.
The development of a CPU as an integrated circuit would consume a multi-million budget.

FPGA

But there is a third way: freely programmable gate arrays enable us to build any complex logic circuit with commercially available ICs. A RISC CPU is defined on the basis of the hardware description language Verilog: RISC-V.

This provides us with a completely open hardware and software platform.

Implementation: ZSipOs

ZSipOs is based on the RISC-V project (https://riscv.org). A complete circuit is available in the hardware description language Verilog. This is translated and then "burned" into the FPGA. The use of the FPGA also offers us the possibility to realise additional hardware functions, e.g. for the connection of external components.

In addition, we can outsource time-critical algorithms directly into hardware modules formed by the FPGA. In the ZSipOs architecture, this is used for symmetric encryption AES and the hash function SHA-1 with fixed block length.