Infineon Trust Platform Module + Raspberry Pi 3 B

Table of contents

RoadTest: Infineon Trust Platform Module + Raspberry Pi 3 B

Author: manojroy123

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: nothing

What were the biggest problems encountered?: There is a huge amount of learning and memorization that needs to be done to just even get started with the product. Someone who is thinking of using this module should be thinking it in terms of long term value it can provide else it will waste a lot of your time to learn to use the module.

Detailed Review:

Unboxing of Infineon Trust Platform Module + Raspberry Pi 3 B

The box has a size of 22cm X 30cm as shown in the figure 1


inside the box you get the Infineon Trust Platform Module , Raspberry Pi 3 B and 8 gb sd card with its adapter as shown in figure 2, 3 and 4 respectively

Figure 2

Figure 3

Figure 4


Description and Overview

Infineon Trust Platform Module:-

The Infineon OPTIGA  TPM (Trusted Platform Module) family is a standardized security controller family which provides a wide range of security functions for embedded platforms.

Some question that needs to be answered with respect to security function for embedded platform

What is embedded security ?

Embedded systems security provides mechanisms to protect an embedded system from all types of malicious behavior.

define embedded security system ?

Embedded systems security is a cybersecurity field focused on preventing malicious access to and use of embedded systems. Embedded systems security provides mechanisms to protect a system from all types of malicious behavior. Cybersecurity specialists work with systems design teams to ensure the embedded system has the necessary security mechanisms in place to mitigate the damage from these attacks.

What are the various cyber security terms ?

  • An attack vector is a path an attacker or malicious process could take to compromise a system. Flash drives, the Internet, network protocols and disks are embedded systems attack vectors.\
  • An attack surface is a target point of exposure, or the end goal of the attack vector. For example, a network driver, a user application and a file system are attack surfaces.
  • threat actor is a source (software or a person) with malicious intent.
  • An attacker is an individual performing a malicious act in real time.
  • vulnerability is a weakness that can be exploited by a threat actor to perform unauthorized actions within an embedded system or computer.

Software security vs physical security for embedded system ?

Two types of security apply to embedded systems: physical security and software security.

  • Physical security, such as locked doors and surveillance cameras, keeps an unauthorized person present on location from accessing an embedded system, physically damaging it or stealing it. Physical security limits access to sensitive areas and equipment. Physical security may also include attributes of a device itself, including immutable memory technology, such as eFuses to store secure bootloader keys, tamper-resistant memory, protected key stores and security enclaves to protect sensitive code and data. 
  • Software security manages and responds to malicious behavior happening in the system, both during the initialization process and during run time. Software security features include authentication of a device to a network, firewalling network traffic and stringent hardening of system software to name a few.

Qualities of embedded system that affects security ?

Connected System

The most secure embedded system is one that is turned off, and the next most secure system is completely isolated. When embedded systems were islands of technology that contained minimal information, embedded software security was less important. Embedded systems are now often connected to a communications network that exposes the system to more threat actors.

 Cyber Attack target

The monetary value of data, the ability to cause serious harm, and the interoperability and connectivity of modern embedded systems, including mission-critical systems, make embedded systems popular targets. Cyberattacks on embedded systems range from disabling vehicle anti-theft devices and degrading the performance of control systems to directing printers to send copies of documents to the hacker and accessing a smartphone’s data. Cyberattacks on embedded systems create an urgent need for everyone from developers to end users to help prevent, manage and patch vulnerabilities.

All elements of the hardware and software architecture need to be secure. Each of the components of embedded system architecture creates an attack surface, from the firmware and embedded operating system (OS) to middleware and user applications. The embedded OS, a foundational piece of embedded systems security, plays the leading role as the backbone of security for an embedded system.

Product Lifecycle

Some embedded systems are in the field for decades, others for just a few years. Many mission-critical systems, such as cars, defense systems and power plants, have a long service life — 20 years or more. Older embedded systems often don’t get updated because the hardware is obsolete and doesn’t support the new software. Designing a system to be secure can greatly increase the viability of keeping systems safely in service and at reduced risk of attack.

Developers need to consider hardware and software obsolescence when designing embedded systems to increase system longevity and security. Computing, networking, cyberattacks and embedded systems security will evolve over the lifespan of an embedded system in ways that cannot be foreseen by system developers. As vulnerabilities are identified, they will need to be mitigated with patches, which require software updates. Including security in the design phase helps ensure that an embedded system has a way to get updates and is capable of running new software.

Difficult to update

Some embedded systems are easier to update than others. A smart TV or smartphone can be updated regularly with minimal impact to the end user. In comparison, insecure software in a modern vehicle can put lives at risk, so software updates to vehicles are carefully orchestrated (and costly).

The type of embedded OS also affects the update process and frequency. Applying an update to an embedded system running a monolithic OS, such as Linux®, is difficult. When the OS and all OS services run in kernel space, applying an OS service patch requires a full OS install, OS refresh, and a full system reboot—all of which increase the scope of testing and the time to deploy.

In comparison, the architecture of a microkernel OS, such as the QNX® Neutrino® Real-Time Operating System (RTOS), makes embedded software updates much easier. OS services in a microkernel run outside of kernel space, which allows for the rebooting of a single service, without a kernel reboot, resulting in very minimal impact on kernel behavior. In addition, the footprint of a microkernel OS service update is generally small—it doesn’t necessarily require the kernel to be updated at the same time—reducing the time and cost of testing a patch.


How does a threat actor exploit an embedded system?

In general, most cyber attacks follow these five steps:

    1. Get network (or physical) access
    2. Understand the underlying processes, hardware and embedded operating system (reconnaissance)
    3. Find a vulnerability in the host-based protection, such as within a programmable logic controller (PLC), embedded OS or middleware
    4. Manipulate the controller
    5. Exploit the vulnerability to attack the system or others.


      A threat actor gains control of an embedded system through one of these four paths:

        • The larger system (the host) that includes the embedded system
        • The Internet or a communications network that connects the embedded system with other devices
        • A physical device, such as a USB drive or disk with malicious code on it
        • Vulnerabilities present in the embedded software from the beginning



      The five most common types of software vulnerabilities in embedded systems are as follows:


       Buffer overflow attacks occur when a threat actor writes data or code to a memory buffer, overruns the buffer’s limits and starts overwriting adjacent memory addresses. If the application uses the new data or new executable code, the threat actor may be able to take control of the system or cause it to crash.


      If an embedded system requires user input, a malicious user or process may provide unexpected input that causes an application to crash, consume too many resources, reveal confidential data or execute a malicious command. The unexpected input could be a negative value, no input at all, a path name outside of a restricted directory, or special characters that change the flow of the program.


      Authentication proves users and processes are who they say they are. Improper authentication may allow a threat actor to bypass authentication, repeatedly try to guess a password, use stolen credentials or change a password with a weak password-recovery mechanism.


       If the programming language or the embedded OS do not restrict a program from directly accessing memory locations that are outside the intended boundary of the memory buffer, a threat actor may be able to take control of the system or cause it to crash, much like a buffer overflow attack.


      Many types of sensitive information may be exposed to a threat actor directly or to another party. Information exposure could reveal information ranging from personal data to business secrets and from system logs to message headers. Data spoofing and device hijacking are two of the ways threat actors expose sensitive information.



      A microkernel OS is structured with a tiny kernel space with services like file systems provided in user space, drivers or network stacks. Less code running in kernel space reduces the attack surface and increases security. The microkernel works with a team of optional cooperating processes that run outside kernel space (in the user space) and provide higher-level OS functionality. Only the core OS kernel is granted access to the entire system, and component isolation prevents an error in one component from affecting other parts of the system. A determined hacker, as long as they don’t have root access, can only crash one component at a time when the system runs a microkernel OS or a secure embedded hypervisor.

      The microkernel design and modular architecture of the QNX Neutrino real-time operating system enables BlackBerry QNX customers to create compelling, safe, and secure devices built on a highly reliable OS, a software foundation that helps guard against system malfunctions, malware and security breaches.


      No matter how advanced and security-aware, software alone cannot ensure embedded systems security. Hardware, software and cloud vendors must work together. For example, hardware technologies ensure device boot integrity, and on-chip security capabilities enable robust key management and encryption, which is too computation-intensive for embedded software alone. Hardware capabilities enable the OS to provide functionality, such as access control policies, encrypted file systems, rootless execution, path space control and thread-level anomaly detection.

      Why, we should use Hardware technologies for embedded security ?


      What is Root of Trust ?

      A hardware security module (HSM) or hardware root of trust manages keys, performs encryption and decryption functions, and embeds keys for OS and application use. Often these system-on-a-chip (SoC) components provide CPU offload for bulk encryption and decryption, and they may also be used to offload network cryptographic functions.

      Hardware roots of trust are increasingly available as part of the SoC but can also be integrated using discreet electronics, such as an authentication IC or a TPM. During manufacturing, a private key can be generated on a chip or injected into each chip to serve as a root of trust. When the private key is certified by a public key infrastructure (PKI), the secure device identifier can become a foundational component of trusted device connectivity. For example, a secure device identifier can help a developer or designer establish trusted communications with peer devices and cloud-based services.

      What is SECURE BOOT ?

      Secure boot leverages the signature provided by a device trust anchor, the public part of the root of PKI used to sign device code. When the embedded system boots, the boot image will be validated using this public key and the corresponding trust chain to ensure that boot-time software has not been tampered with. Establishing the provenance of the original software and of any software updates typically relies on digital signatures from a public key cryptosystem. But in some instances, a hybrid model can be used. In a hybrid model, symmetric key cryptography is used to validate software integrity and speed the boot code verification process for time-critical startup requirements. Unlike code verified with a public key, the symmetric key must remain secret, known only to the device.


      A trusted execution environment (TEE) or hardware security zone provides hardware-enforced isolation in a secure area built into the main processor, which allows the software developer to establish a device root of trust. A TEE may run in a secure mode of the processor (e.g., ARM TrustZone) or on a separated, isolated CPU core that acts as a security co-processor to the SoC. TEEs typically allow trusted applications to perform security-critical processing on behalf of the embedded system.


      A trusted platform module (TPM) provides hardware-based security functions such as a cryptoprocessor to generate, store and use internal cryptographic keys; encryption of keys and other sensitive material stored in device memory; and measurement and attestation of the integrity of a system state during the boot process.



      Executable space protection (ESP) marks specific memory regions as non-executable, so that an attempt to execute machine code in those regions causes an exception.


      Address space layout randomization (ASLR) allocates the base address of the stack, heap and shared memory regions to new locations every time a new process is executed, making buffer overflow attacks difficult because a threat actor can’t predict where the information will be stored.


      Stack canaries allow the operating system to detect a stack buffer overflow before executing malicious code. The OS places a small random integer before the stack return pointer and checks for it before overwriting memory. If the stack value has changed, the OS will stop execution and cause an exception.

      Raspberry Pi 3 B:-

      The Raspberry Pi is a low cost, credit-card sized computer that plugs into a computer monitor or TV, and uses a standard keyboard and mouse. It is a capable little device that enables people of all ages to explore computing, and to learn how to program in languages like Scratch and Python. It’s capable of doing everything you’d expect a desktop computer to do, from browsing the internet and playing high-definition video, to making spreadsheets, word-processing, and playing games.

      What’s more, the Raspberry Pi  has the ability to interact with the outside world, and has been used in a wide array of digital maker projects, from music machines and parent detectors to weather stations and tweeting birdhouses with infra-red cameras. We want to see the Raspberry Pi being used by kids all over the world to learn to program and understand how computers work.

      it is also known as single board computer. SBC for short.

      Some question that we need to answer with respect to single board computer

      What is a single board computer ?

      A single-board computer (SBC) is a complete computer built on a single circuit board, with microprocessor(s), memoryinput/output (I/O) and other features required of a functional computer. Single-board computers are commonly made as demonstration or development systems, for educational systems, or for use as embedded computer controllers.

      Why do we use single board computer ?

      They are lighter in weight, compact in size, more reliable and much more power efficient then multi-board computers.

      What is the purpose of single board computer ?

      A single-board configuration reduces a system's overall cost, by reducing the number of circuit boards required, and by eliminating connectors and bus driver circuits that would otherwise be used. By putting all the functions on one board, a smaller overall system can be obtained.

      The Experiment

      Since I don't have a lot of time to learn about the module and to learn about the Raspberry Pi  completely I will only be performing a simple basic "Message encryption and decryption" with  the system

      what is encryption ? 

      Encryption is a way of scrambling data so that only authorized parties can understand the information. In technical terms, it is the process of converting human-readable plaintext to incomprehensible text, also known as ciphertext.

      what is decryption ?

       The conversion of encrypted data into its original form is called Decryption.

      why do we use cryptography ?

      As the foundation of modern security systems, cryptography is used to secure transactions and communications, safeguard personal identifiable information (PII) and other confidential data, authenticate identity, prevent document tampering, and establish trust between servers.


      After doing some research of my fellow roadtester. I figured that the os needed in the raspberry pi should be Debian 10 Buster. This OS supports the OPTIGA TPM SLM 9670 TPM2.0 drivers

      Installation of OS and OPTIGA TPM module

      1)We have install the raspberry Pi OS using Raspberry Pi Imager as shown bellow.

      step 1

      open the Raspberry Pi Imager as shown in figure 1

      Figure 1

      step 2

      Choose operating system as Raspberry Pi OS (32-bit) as shown in figure 2 below

      Figure 2

      Step 3

      Choose memory as multi card USB device as shown n figure 3

      Figure 3

      Step 4

      Click on write to write the files on memory device as shown in figure 4

      Figure 4

      2) installing the OPTIGA TPM module on raspberry Pi

      To install the OPTIGA TPM module on raspberry Pi. Follow the steps given below

      Step 1

      Attach the OPTIGA TPM module as shown in figure 5 below

      Figure 5

      Step 2

      Start the Raspberry Pi Os as shown in figure 6

      Figure 6

      Step 3

      Open the terminal window as shown in the figure 7 below

      Figure 7

      Step 4

      Open "/boot/config.txt" in superuser mode using nano text editor by writing the following command in terminal

      sudo nano /boot/config.txt

      Over here "sudo nano" opens nano text editor in superuser mode

      Step 5

      Do the following changes as shown below in figure 8

      figure 8

      press control O to overwrite the file. The configuration made is saved.

      write command "sudo reboot now" for the TPM module to be configured during startup.

      Step 6

      To verify TPM driver is enabled or not. see the figure 9 below

      Figure 9

      3) Installing the software to use TPM module ?

      The software component that needs to be installed to operate the TPM module are as follows

      1. TPM Software Stack 2.0 (tpm2-tss)
      2. TPM2 Access Broker & Resource Manager (tpm2-abrmd)
      3. TPM2 Tools (tpm2-tools)
      4. TPM2 TSS Engine (tpm2-tss-engine)
      5. Cryptsetup (cryptsetup)
      6. PKCS#11 (tpm2-pkcs11)

      4) what is the purpose of TPM Software Stack 2.0 (tpm2-tss)

      The TPM Software Stack 2.0 (TSS 2.0) is an implementation of the Trusted Computing Group’s (TCG)
      specification and consists of various Application Programming Interfaces (APIs) to communicate with the TPM
      on different abstraction layers.

      5) TSS setup

      Three basic steps are needed to setup TSS for a project

      1)sets up the build environment

      2)install the project

      3)post installation measures

      6) How to setup build environment for TSS

      For setting up build environment you need to setup additional dependencies used in the second step for build process

      7) What are the prerequisite steps before building a build environment ?

      Create installation and code directores given below using mkdir command as follows

      mkdir /home/pi/tssSetup /home/pi/codeExamples \

      Additionally, create the user and group tss and add this user to the group using command given below

      sudo useradd --system --user-group tss

      update the distribution package using command given below

      sudo apt update

      8)What package needs to be installed for building the TSS?

      • GNU Autoconf
      • GNU Autoconf Archive, version >= 2017.03.21
      • GNU Automake
      • GNU Libtool
      • C compiler
      • C library development libraries and header files
      • pkg-config
      • doxygen
      • OpenSSL development libraries and header files, version >= 1.1.0
      • libcurl development libraries
      • Access Control List utility (acl)
      • JSON C Development library

      The following are dependencies only required when building test suites.

      • Integration test suite (see ./configure option --enable-integration):
        • uthash development libraries and header files
        • ps executable (usually in the procps package)
        • ss executable (usually in the iproute2 package)
        • tpm_server executable (from
      • Unit test suite (see ./configure option --enable-unit):
        • cmocka unit test framework, version >= 1.0
      • Code coverage analysis:
        • lcov

      Most users will not need to install these dependencies.

      9)How do you install those package for building TSS ? 

      sudo apt -y install autoconf-archive libcmocka0 libcmocka-dev \
      procps iproute2 build-essential git pkg-config gcc libtool automake \
      libssl-dev uthash-dev autoconf doxygen libjson-c-dev libgcrypt20-dev \

      10) How do you download TSS for your build environment ? 

      change directory to tssSetup using followng command

      cd /home/pi/tssSetup

      Download the TSS in tssSetup directory using following command

      git clone -b 3.0.x

      11) What is bootstrapping ?

      get (oneself or something) into or out of a situation using existing resources.

      12) How do you bootstrap TSS ?

      cd tpm2-tss


      13) What happens during installation ?

      During installation, the software will generate a udev rule granting the system user tss permission to access the TPM device. For this rule, the installation path and the prefix will be adjusted with two parameters. For FAPI the flags sysconfdir, localstatedir and runstatedir will be set. The sysconfdir defines the location of the FAPI configuration and profile files. The localstatedir defines the location of the system keystore and runstatedir defines the location to store event logs.

      14) How do you configure the TSS ?

      by writing the following command

      ./configure --with-udevrulesdir=/etc/udev/rules.d \
      --with-udevrulesprefix=70- --sysconfdir=/etc --localstatedir=/var \

      15)How do you compile and install the TSS ?

      write the following command to so it


      sudo make install

      16) what happens during post installation ?

      Once the installation is complete, udev needs to be instructed to reload its rules and apply the new rule. Finally,
      an update of the run-time bindings might be necessary.

      17) What are the Post-installation steps for TSS ?

      sudo udevadm control --reload-rules && sudo udevadm trigger
      sudo ldconfig
      cd /home/pi/tssSetup

      18) What is the purpose of FAPI configuration ?

      When the TSS is installed, FAPI will read a configuration file to retrieve the information about necessary
      parameters. This is done by default without user interaction. The default lookup paths are defined during the
      installation with the parameters sysconfdir, localstatedir and runstatedir. Most directories are
      already created during installation. However, the user needs to create an own user keystore

      19) What is a keystore ? 

      A keystore can be a repository where private keys, certificates and symmetric keys can be stored.

      20) How do you create a keystore ?

      mkdir -p ~/.local/share/tpm2-tss/user/keystore

      21) How do you add current user to group TSS ?

      sudo adduser pi tss

      22) What is repository ?

      a central location in which data is stored and managed

      23) How to check if current user is added to group tss ?

      write the following command

      groups | grep tss

      if  you get the below output after entering the command you are added to the group

      pi adm dialout cdrom sudo audio video plugdev games users input netdev lpadmin tss gpio i2c spi

      Using TPM2 command line tool to execute basic TPM functionalities.

      What is ESAPI ?

      TCG TSS 2.0 Enhanced System API (ESAPI) Specification.

      What is FAPI ?

      TCG Feature API (FAPI) Specification

      How do you determine whether the command line is using an ESAPI function or using FAPI function ?

      if command line starts with “tpm2_” it is using ESAPI function

      if it starts with “tss2_” it is using FAPI function

      What is the purpose of TPM2 Tools for FAPI ? 

      provide generic methods to create keys and perform cryptographic operations with the TPM using the keys stored in the FAPI metadata store.

      What is the purpose of TPM2 Tools for ESAPI ? 

      If a special usage of the TPM with specific parameters is required, the ESAPI can be used to specify the TPM command parameters in detail.


      Since, I didn't have enough time to learn the module. I have to quit it over here. But, I will be using this in one of our industry 4.0 projects.