The EI for AMR includes open-source components, which may be affected by vulnerabilities. A shim layer can help to protect your program data against an attack initiated via these vulnerabilities.

The main task of the shim layer is to reduce the attack surface by verifying the data (such as size, value range, memory range, etc.) transferred via a function call to or from a library or an executable and protect the customer code and data via this mechanism.

Due to architecture constraints, only the developer of the application code can implement the matching shim layer correctly.

The following picture shows a potential implementation of a shim layer around the customer application like a shell.

Keep in mind, complex checks and more layers might have an impact on the overall system performance.

In general, it is highly recommended to check regularly for updates and vulnerabilities on the component web sites.

The main EI for AMR platform is based on the 11th generation Intel® Core™ processor with accelerators primarily used for AI inference and vision processing. The platform inherits many security elements from the processor.

The EI for AMR platform offers various security features that customers can leverage in the context of Autonomous Robotics Applications. They are listed as follows:

Ensure the system boots from a trusted source and is not manipulated by an attacker. To establish a secure boot, a chain of trust is set up; the root-of trust is unmodifiable by nature. Typically, the root-of trust is a key burned in fuses in the device or ROM based program code.

Intel devices support secure boot with Intel® Trusted Execution Technology (Intel® TXT) and offers via the Intel® CSME, a software implementation of the Trusted Platform Module (TPM).

More information about the described use cases and features can be found in the following documents:

Authentication helps to develop a secure system. A run-time authentication system is the next step following secure boot. Any program code can be authenticated before it will be executed by the system. This powerful tool enables AMR suppliers to guarantee a level of security, and safety during run-time. Executing code from an unknown source or malware wouldn’t be possible.

The Intel® Dynamic Application Loader (Intel® DAL) is a feature of Intel® platforms that allows you to run small portions of Java* code on Intel® Converged Security and Management Engine (Intel® CSME) firmware. Intel has developed DAL Host Interface Daemon (also known as JHI), which contains the APIs that enable a Linux* operating system to communicate with Intel DAL. The daemon is available both in a standalone software package and as part of the Linux* Yocto 64-bit distribution.

More information about the described use cases and features can be found in the following documents:

Virtualization is another important element to increase the level of security and safety. It helps to establish freedom from interference (FFI), as it’s requested for safety use cases, and workload consolidation. Intel devices have supported this use case with Intel® Virtualization Technology (Intel® VT) for decades.

More information about the described use cases and features can be found in the following documents:

Encryption is required for many security use cases. The EI for AMR platform supports the common encryption algorithms like AES or RSA in hardware. This will increase the encryption/decryption performance and the security level. Typical use cases are the encryption of communication messages, a file system, or single files for IP protection or the creation of a secure storage for security relevant data like crypto keys or passwords. Another use case is memory encryption; the EI for AMR platform supports this with the Total Memory Encryption (TME) feature.

More information about the described use cases and features can be found in the following documents:

To improve the security and safety status over the lifetime of a device, the internal firmware (e.g. BIOS) must be updatable. In this case the update packages are signed by the supplier (e.g. Intel, OEM etc.).

More information about the described use cases and features can be found in the following document:

Debugging is an important feature during product development. During in-field usage, debugging might also be needed to analyze field returns. To prevent anyone from accessing internal resources via the debugger, a secure debugging system is developed. In this case an engineer who wants to use the debugger has to authenticate via a valid token which has to be offered to the system (e.g. storing it in flash). Tokens must be signed by a key which was stored during manufacturing flow into the device fuses.

More information about the described use cases and features can be found in the following documents:

Docker is not a primary use case of EI for AMR systems. Docker uses virtualization on the OS-level to deliver software in packages called

containers

. The EI for AMR package is delivered in this form. It is up to you to decide whether or not to re-use this approach in the final product.

The host system owner can improve the security level of the Docker installation and Docker during run-time. For this, it is useful to check if your system follows Docker best practices.

Additionally, it would be good to check your Docker installation with the CIS Docker benchmark. This benchmark checks several aspects of the installation and run-time configuration and gives you a good indication of improvements.