Get Started Guide

  • 2021.3
  • 10/21/2021
  • Public Content

Security

This section highlights the security features offered by the Edge Insights for Autonomous Mobile Robots (EI for AMR) platform and provides an overview of the security features. For further reading, refer to the specific documents listed below.

Shim Layer - Protect your application data

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.

Edge Insights for Autonomous Mobile Robots Platform

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.

Security Use Cases and Features

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:
Secure Boot
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:
Document Title
Intel Document ID
Document Link
Intel® Converged Boot Guard and Intel® Trusted Execution Technology (Intel® TXT)
575623
Tiger Lake platform - Firmware Architecture Specification
608531
Intel® Trusted Execution Technology (Intel® TXT) DMA Protection Ranges
633933
Intel® Trusted Execution Technology (Intel® TXT) Enabling Guide
Trusted Platform Module Specification
Authentication
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:
Document Title
Intel Document ID
Document Link
Trusty TEE Software Architecture Specification
607736
Intel® Dynamic Application Loader (Intel® DAL) Developer Guide
Virtualization
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:
Document Title
Intel Document ID
Document Link
Intel® 64 and IA-32 Architectures Software Developer Manuals
Encryption
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:
Document Title
Intel Document ID
Document Link
Tiger Lake platform Intel® Total Memory Encryption (Intel® TME)
620815
Whitley Platform Memory Encryption Technologies -TME/MK-TME deep Dive
611211
Intel® 64 and IA-32 Architectures Software Developer Manuals
Filesystem-level encryption (Linux*)
Intel® Advanced Encryption Standard Instructions (AES-NI)
Firmware Update
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:
Document Title
Intel Document ID
Document Link
Tiger Lake platform - Firmware Architecture Specification
608531
Secure Debug
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:
Document Title
Intel Document ID
Document Link
Tiger Lake platform - Firmware Architecture Specification
608531
2019 Spring Client Customer Debug Methodologies and Tools
612942
Tiger Lake platform enDebug User Guide
630604
Anderson Lake Secure Debug User Guide
614222
Docker* Installation and Usage
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.

Product and Performance Information

1

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.