IT security is a very important cornerstone that is often neglected and can have catastrophic consequences. Ritter Technologie GmbH attaches great importance to a seamless security concept that grows with its requirements. We adhere to the MITRE / LIST recommendations and our security measures are regularly checked for security gaps by external specialists. Automatic tests are not only an important basis at the software level; where possible, the hardware is also automatically checked for irregularities.

The certification body of TÜV SÜD Management Service GmbH certifies that the company Ritter Technologie GmbH, Essener Straße 2-24, 46047 Oberhausen (Germany) has implemented and applies an information security management system in accordance with the "Statement of Applicability" for the adjacent scope. Through an audit, report no. 707066405, proof was provided that the requirements of ISO/IEC 27001:2013 are fulfilled. This certificate is valid from 12.12.2020 to 11.12.2023.

The scope of the information security management system of Ritter Technologie GmbH extends to the Oberhausen site, Essener Straße 2-24, applying DIN EN ISO 27001:2013, for the service profile "Innovative and secure IT solutions, consulting, infrastructure, data center operation, software & services".


  • Security concepts: e.g. CRS, OWASP against SQLi, XSS, LFI, RFI, PHPci
  • Use of BSI standards 2020
  • Manual and automatic tests e.g. Cypress / Postman
  • 27K-certified data center and hardware / software development


  • Stability of the component in terms of functionality
  • Mainly use of open source products to carry out your own source code reviews (create a fork if necessary)
  • Only use active projects

The greatest risk is if the open source projects are abandoned. In this case, further developments must take place in-house or a switch must be made to alternative products.

The products are also tested and checked by external specialists for IT security.


We have already implemented a process to check all code repositories daily for new CVEs on a daily basis. This process uses Trivy, which automatically publishes reports and creates them in tickets for the relevant departments. The Trivy integration for Buildroot will be done through a parser for the PKG statistics generated by Buildroot.


Each IEC60870-104 server process can only connect to 1 client, redundant passive connection excluded. If several client systems such as Salvador and SCADA want to connect to the RTU, it is therefore necessary to have 2 IEC6087-104 server processes running on the RTU. This can be done via the mapping file by creating 2 configuration objects. Each IEC60870 server process has its own IOA object space. If you want to provide monitoring/control objects for both 104-server processes, it is necessary to create 2 objects within the mapping. 1 object for each server.

This procedure makes it possible to specify exactly which monitor and control objects are to be made available for each server process. An IP filter is provided for this purpose.



Access based on IP filter, secured by Ipsec VPN


All configurations are provided by Node-Red and are checked automatically.


During initial commissioning and when the expiration date is reached, the RTU retrieves a certificate from the PKI server via SCEP. This certificate is used to establish the IPsec connection from the RTU to the customer network. Optionally, it is also used for communication between the RTU and DEMAS. Requirement: Provide a suitable root CA for DEMAS, as the customer PKI generates the certificates.


Security - Confidentiality and integrity of network communication: on RTU
If the WAN connection is already secured via VPN, optionally deactivate further encryption and thus, of course, certificates for deep packet inspection.


  • The structure of our technical protection is generic. All Auth providers can be connected via Keycloak and NGINX.
  • We have chosen mTLS (TLS client certificate issued via local PKI (SCEP)).
  • In addition to DEMAS, any other system can optionally be secured with this generic concept.


The RTU is managed centrally by DEMAS. Direct access to the RTU via SSH is therefore possible, but not necessary. With the RTU, it is possible to define any users, passwords and group assignments in the system configuration.

A central login service manages the logins for the DEMAS and Node Red modules. This configuration is normally provided by DEMAS, but can be changed locally. In this case, the change is recognized and UUID 0 is reported back to DEMAS. This enables DEMAS to react to the change.

The files and fatal recovery scripts can only be changed or executed by users with root rights.

The user must therefore either be in the root group or in the sudo group. In the second case, the user must initiate all actions with sudo.

  • We use Strongswan IPsec to secure the WAN communication path from the RTU to the customer network. The configuration of the IPsec parameters can be defined in the system configuration.
  • The certificate used is retrieved from the PKI server during the first access and the process via SCEP.
  • Authentication between 104 server and client has not yet been implemented as it is not part of the protocol specification.
  • To secure communication, we use IPsec for confidentiality and integrity.


  • FIT (Flattened Image Tree)
    • Hashed: SHA-256
    • Encrypted : AES-256-CBC
    • Signed X.509 Cert (4096 Bit RSA Key)
  • Cert check and image decryption on boot
  • Bootloader is secured via HABv4 signature (closed source by NXP)
  • CPU provides a HABv4 secure boot feature
  • CPU loads only bootloader with correct HABv4 signature
    • Dual boot for firmware fall back
    • Cert programmed in OTP (One Time Programmable) fuses


The RTU firmware uses the FIT format. This one file contains the kernel, the device tree and the root file system. The RTU uses a RAM file system to prevent damage to the root FS. The boot loader U-Boot checks the validity of the FIT firmware image at each start, unpacks the data into the RAM and executes the Linux kernel. All changes in the root FS are lost after a restart.
The rtu-mgr process sets the settings for all services for each according to the system configuration provided by DEMAS.

The FIT image is signed accordingly. The public key is located in the bootloader because it has to verify the image. The private key is only on the RITTEC firmware build server and does not leave it. We use the maximum key format supported by U-Boot, RSA 4096 bit with SHA256.

The data in the FIT image is encrypted and the corresponding key is only hidden in U-Boot. This is not security-relevant, but only a measure against reverse engineering.

In addition, each FIT image is provided with a HABv4 signature. This is a proprietary
procedure from NXP that is implemented in the CPU. For this purpose, a private and public key is generated with an NXP tool. The private key never leaves the build server.
The public key is burned into the CPU by OneTimeProgrammable Fuses.

After the CPU is permanently locked via another OTP fuse, it can only execute correctly HABv4-signed bootloaders. The bootloader U-Boot used by us is therefore HABv4-signed, just like the FIT image of the firmware. After loading the FIT image, the bootloader first checks the HABv4 signature with the help of the CPU, then the FIT signature, decrypts the data in RAM and starts the kernel.

A firmware update is carried out by overwriting the complete inactive FIT image. The previously inactive image is activated and rebooted. All the processes described above now follow. If the image does not start, the watchdog switches back to the old image.