D



Linux Security – hardended Linux

Linux offers many possibilities to protect against cyber attacks. This is the result of, among other things, years of operation in data centres. In parallel, more and more functions are now being made available on system-on-chips (SoC) for industry, so that technologies from the server world are now also getting into the factory (virtualisation, containers, etc.).

Determining which of the components should be used, how and in which combination, requires a lot of experience on the Linux side as well as an understanding of the application, of the environment in which this device will be used and also of the business component. Not everything must or can always be achieved. Furthermore, one should never forget that security is not a one-time thing, but must be practised over the entire life cycle of the device. For more information on this topic, see Life-Cycle Management, Update and IGL Monitoring.

Security should be addressed from the very beginning of the development of a new device. This not only ensures that the right tools are used and the correct measures are implemented, but also that the development processes are set up correctly in order to guarantee security throughout the life cycle. Security also means that the development process must be "safe" in the sense that no malware can be infiltrated during development.

If all components selected are mainline Linux (kernel.org) components, it is ensured that these will remain available in future versions. This provides long-term investment security. And at the same time, all bug fixes and further developments can be taken over from the community.

All components must be adapted to the respective application (hardware, requirements). There aren't any "ready-made" solutions here. However, it helps if the know-how on how to use them is available from many applications.

Important components for a secure system include:

  • Secure / Measured Boot / chain of trust - so that the system you delivered is able to boot. With additional Linux tools, the root file system as well can be verified. Implemented solutions: iMX / QorIQ, TI Sitara, Atmel SAMA5, Xilinx Zynq, UltraScale+ and HSM / TPM chips
  • Authorisation, (user) access, logging of all accesses, storage of diagnostic information (encrypted)
  • Hardening of the system, minimisation of the attack surface, removal of all unneeded software parts (services, daemons etc.), optimised configuration of kernel and packages
  • Encryption of data (and programmes) on the device (at rest), during processing (in use) and for communication (in motion)
  • Secure device authentication and proof of identity, especially for networked devices (IIoT, onboarding)
  • Virtualisation - hypervisor- or container-based approach for "sandboxing" applications
  • Combination of HSM / TPM or TrustedZone (TZ) with a Trusted Execution Environment (TEE) with a hypervisor including the bootloader.
  • fTPM (Firmware TPM, compatible with TPM 2.0) based on ARM Trusted Zone (TZ), OTP area and eMMC with RPMB (replay protected memory blocks)
  • Secure update for the device - validation of the update on the device itself and secure build system for generating the update
  • Security monitoring - lifelong update with current security patches. More information at Life Cycle Management.

A security-optimised solution could be a Secur_OS, as we have defined it in connection with our Industrial Grade Linux. This could look something like the following graphic:

Linutronix offers optional subscriptions for this and for the Industrial Grade Linux to provide continuous maintenance, servicing and updating of the BSP.