Security attacks are no longer in the realm of powerful state actors and hardened criminals. While there is no direct impact to human safety, a breached device or family of devices could result in devasting impacts to the life of the attacked entity. Loss of privacy, loss of freedoms, monetary loss... just naming a few.

With the vast amount of code being written for Automotive and IOT devices, the potential attack surface area for attackers is quite broad.

Here is the list of top 25 CWEs (Common Weakness Enumerations) found in 2021 as of today (September 2021). https://cwe.mitre.org/data/definitions/1337.html

Several of these CWEs are the result of improper coding practices. No matter how experienced a programmer is, mistakes will be made. Using tools such as static code analysers to catch such issues are helpful, but seem to be a bolted on solution. Attackers are continuously looking for such CWEs to find potential entry points into the system.

An entire class of security problems are addressed by using a language such as Rust. These become compile time errors which are caught during development, or at worse, hard runtime errors which are easier to catch during testing. Read the analogy with short circuits and loose connections here The Case for Using Rust in Automotive Systems.

Quoting from https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ ,

If you have a very large (millions of lines of code) codebase, written in a memory-unsafe programming language (such as C or C++), you can expect at least 65% of your security vulnerabilities to be caused by memory unsafety.

• Android (cite): “Our data shows that issues like use-after-free, double-free, and heap buffer overflows generally constitute more than 65% of High & Critical security bugs in Chrome and Android.”
• Android’s bluetooth and media components (cite): “Use-after-free (UAF), integer overflows, and out of bounds (OOB) reads/writes comprise 90% of vulnerabilities with OOB being the most common.”
• iOS and macOS (cite): “Across the entirety of iOS 12 Apple has fixed 261 CVEs, 173 of which were memory unsafety. That’s 66.3% of all vulnerabilities.” and “Across the entirety of Mojave Apple has fixed 298 CVEs, 213 of which were memory unsafety. That’s 71.5% of all vulnerabilities.”
• Chrome (cite): “The Chromium project finds that around 70% of our serious security bugs are memory safety problems.”
• Microsoft (cite): “~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues”
• Firefox’s CSS subsystem (cite): “If we’d had a time machine and could have written this component in Rust from the start, 51 (73.9%) of these bugs would not have been possible.”
• Ubuntu’s Linux kernel (cite): “65% of CVEs behind the last six months of Ubuntu security updates to the Linux kernel have been memory unsafety.”

The use of Rust in security critical software is gaining traction. Here are some links for further reading.

• Microsoft Security Response Center - Rust blogs
• Google security blog about adding Rust in the Android Platform

Sabaton uses Rust as the primary language.

ISO 21434 Road vehicles — Cybersecurity engineering

The ISO 21434 standard provides guidelines to manage the cybersecurity for automotive ECUs, with processes very similar to those for Functional Safety. One of the key aspects of managing security is to gain a proper understanding of the contents of the system.

It is important that each and every file on the target is there for a reason. Else it could become the vehicle for an attacker to enter the system due to some vulnerability. Linux embedded build systems like Yocto or Buildroot, rely on the build mechanisms of each software package. The automatic dependency management and inheritance capabilities of Yocto, while powerful, make it very easy to intentionally or unintentionally sneak in unwanted software.

Sabaton uses a different approach to building the system image. Each executable must be explicitly introduced into the target via a manifest. While this does take additional effort the build the system, it makes it easier to build a system that is fully understood and fully controlled.

Platform Abstraction for Security (PARSEC)

Sabaton uses the PARSEC to provide a common API to interface with hardware security and cryptographic services. Parsec is supported by arm, docker, Red-hat, and other industry leaders in the Cloud native space. PARSEC is developed in Rust and this makes it a natural choice for the Platform security API. Sabaton will have a fork of PARSEC and will implement providers to interface with the platform hardware.

Secure Boot

Security must be hard to break, but easy to manage!

Sabaton integrity checks all executable code using the industry standard dm-verity. Dm-verity hashes are protected with RSA Signatures with SHA256. Tools to sign and verify the images are integrated into the Sabaton build tools and configuration language. No playing around with hard to manage configuration layers. The Sabaton initrd library knows how to verify the metadata on the verity partitions before mounting them. See imagebuilder for how verity signatures and partition information is configured.

The Initrd is packaged with the Kernel and is verified by the secure boot mechanism of the SoC.