OPTIGA Trust E evaluation kit

From Embedded Lab Vienna for IoT & Security
Jump to: navigation, search


This summary gives an overview of the cryptographic applications of the microcontroller XMC4500 Relax Kit and the Optiga Trust E/X with security features.

Used Hardware/Software

Infineon development tools

Register at www.infineon.com to find all the important information about the XMC4500 board and the Optiga Trust E/X evaluation kit. Following development tools are needed to generate code for the XMC4500: DAVE ™ version 4. Alternatively, the Keil MDK can be used.

Download-Link for Dave ™ version 4


Download-Link for Example Codes


The DAVE ™ package contains the IDE and all required libraries (DAVE ™ APPs, XMC ™ Lib, Device and Board Support Package, and Device Descriptions).

First Steps

Quick Start - Simple LED Blinky


OPTIGA ™ Trust E-Evaluation Kit


The Infineon Technologies OPTIGA ™ Trust E-Evaluation Kit evaluates and demonstrates the OPTIGA ™ Trust B Authentication Device. This kit features a PC plug-in board based on the XMC microcontroller and comes with software that provides the user with an intuitive graphical user interface. The OPTIGA ™ Trust E Evaluation Kit allows the user to try out OPTIGA Trust E applications, including authentication, adding cryptographic certificates, and read/write data. This evaluation kit can either be used to debug the Host Lib code or to demonstrate the key features of the OPTIGA ™ Trust E through the intuitive PC GUI.

The OPTIGA ™ Trust E helps protect services, business models and user experience. This security solution uniquely identifies objects and protects PKI networks based on their one-way authentication mechanism. In addition, the OPTIGA Trust E protects the quality and safety of products.

The OPTIGA Trust E is based on Elliptic Curve Cryptography (ECC) with 256-bit, AES128 and SHA-256. This security technology greatly enhances the security of the entire system. In addition, the OPTIGA Trust E covers a wide range of applications to protect the authentication, security and confidentiality of embedded devices. These include mutual authentication, secure communication, data store protection, lifecycle management, secured updates, and platform integrity protection. The out-of-the-box facility, with full system integration and pre-programmed essentials, reduces design, integration and deployment requirements. As a ready-to-use solution, the OPTIGA Trust E comes with OS, embedded application and full host-side integration support.

Security Features

Cryptographic support: ECC256, AES128, SHA-256, TRNG (TrueRandomNumberGenerator), DRNG (DigitalRandomNumberGenerator)


  • High-end security controller
  • Ready to use solution
  • One-way authentication with ECDSA
  • Mutual authentication with DTLS client (standard RFC 6347)
  • Secure communication with DTLS
  • Compliant with USB Type-C ™ authentication standard
  • I2C interface
  • Cryptographic support: ECC256, AES128, SHA-256, TRNG, DRNG
  • Standard and extended temperature ranges
  • Complete system integration support
  • Common Criteria certified EAL6 + (high) hardware
  • Cryptographic Toolbox based on ECC NIST P256, P384 and SHA256 (register, verify, key generation, ECDH, session key derivation)


  • Industrial control and automation
  • Consumer electronics
  • Smart Home
  • Medical equipment

AES - Advanced Encryption Standard

Advanced Encryption Standard, AES for short, is a symmetric encryption method. Since the end of 2001, Rijndeal has been officially standardized as AES in the US by NIST (National Institute of Standards and Technology). It is used for the encryption of documents and communication connections. AES is not patented and therefore freely usable.

Rijndael and AES are block ciphers based on a substitution-permutation network (SPN). The procedure alternates between substitution and permutation at each step. The transformation of the plaintext occurs in several rounds of the same structure. The plaintext is not processed as a whole, but in blocks.

For Rijndael, block length and key length can be independently 128, 160, 192, 224 or 256 bits. For AES, the block length is set to 128 bits and the key size to 128 (10 rounds), 192 (12 rounds), and 256 bits (14 rounds). The AES decryption necessarily requires that the same steps be followed as with encryption. Just in reverse order. It is, in a way, a weakness of AES.

ECC - Elliptic Curve Cryptography

Crypto-systems and methods based on elliptic curves are referred to as ECC methods. ECC procedures have been part of the NIST (National Institute of Standards and Technology) standards since 1999. ECC methods are among the asymmetric encryption methods. The number after the hyphen refers to the key length. Typical applications of ECC are the key exchange and signature procedures. Also, Mozilla Foundation products (including Firefox, Thunderbird) support ECC with min. 256 bit key length.

Roughly speaking, ECC methods are based on operations with pairs of points on certain elliptic curves. Despite the complexity, the mathematics behind the ECC methods has been sufficiently well researched. Most cryptographers recommend ECC methods to be preferred. The use of elliptic curves requires that both communication partners support the same curve. That means you can not just use any curve. It has to be a specific one.

SHA - Secure Hash Algorithm (SHA-1 / SHA-2 / SHA-3)

The Secure Hash Algorithm, SHA for short, and all its versions, are cryptographic hash functions. These are used to calculate a check value for any digital data (messages) and are among other things the basis for creating a digital signature. The check value is used to ensure the integrity of a message. If two messages produce the same check value, the equality of the messages should be guaranteed in their normal discretion, without prejudice to specific attempted manipulation of the messages. That's why we require a cryptographic hash function, the property of collision safety: it should be virtually impossible to create two different messages with the same test value.

SHA was developed by the US secret service NSA on behalf of the US standardization authority NIST. SHA is used in all popular web applications and network protocols. PGP, SSL, IPsec and S / MIME. And of course with different signature methods. For example, for signing certificates. The original SHA is referred to as SHA-1 to distinguish it from its successors SHA-2 and SHA-3. SHA-3 should not replace SHA-2, but is an alternative. Should SHA-2 be broken at some point, you can go to SHA-3.

Objective and results of the project

The first objective was to test a simple Led toggling program to determine wether the XMC4500 board is working as it is supposed to. To do that the DAVE ™ 4 environment was used as it is recommended by Infineon. After the download and installation of Dave ™ 4 according to the Quick installation guide that came with the download, the Segger JLink needs to be installed and the libraries need to be updated as well. The first example code can be tested by downloading it on the Dave application itself, then building and debugging it. In this case, there was a problem. The microcontroller was not recognized by the program, the JLink couldn't be found. Following approaches were taken: Update of the Segger JLink, checking the preferences of Dave ™ 4 if correct board was assigned, trying other example codes, etc. The next approach was to see if the microcontroller would run on Keil MDK, A simple LED blinking examples code was installed and successfully run on the Keil environment. This meant that the microcontroller was actually able to connect to the PC. The next move was to try out older versions of Dave (Dave ™ 3), which also didn't work. So an older version of the Segger JLink was installed, and finally the board could be connected to Dave, it worked on both Dave ™ 3 and Dave ™ 4. The Led toggling code worked properly.

AES: The AES example code can be installed through the Dave ™ 4 Project Library. The installation is described on the corresponding Readme-file. Another problem appeared after running the code trough the debugger. The application was supposed to let the Led blink if the values of the key and the decryption output matched. But even though they did the Led still wouldn't toggle. The approach was to configure USART to be able to connect the microcontroller with TeraTerm so that the user can see if the algorithm worked correctly. But because of the fact that the XMC4500 was only recognized by the Dave application and not by the PC itself, there was no COM-Port found by TeraTerm. Therefore the final step was to set one of the other Leds as the output and to let the Led blink at the start and turn it off after the values matched by setting the 'Initial Output Level' of the Digital I/O pin to high.

ECC & SHA: There are no example codes distributed from Infineon for the ECC and SHA algorithms, but a few C example codes can be found on the internet. The example codes that were tested for these projects can be found on the 'References' part of this aritcle. There were error messages on all of these example codes. Almost all the time the problem was the included library. Either there were some files missing or the files coulnd't be found on that path. Another problem was that the code was not compatible with the Dave ™ 4 interface. The example codes were modified to try to solve these error messages. Either the paths of the files were changed or new library files were added. But with each modification, new error messages popped up. For this project especially the Optiga Trust X Framework code on Github seemed to be a good choice for cryptographical algorithms for Dave ™ 4. But, again, the problem was to integrate the two branches of the code, develop & master, so that the library files were complete. But even though the paths to the files were changed in the code or/and the location of these files were changed, the error messages couldn't still be resolved. There are probably other underlying problems for these errors.

Unpredictable Problems with Dave ™ 4: There is barely any documentation on how to use Dave ™ 4 or solutions to problems on writing code or handling error messages, not even on the Infineon webpage. The example codes just explained how to get the code running but they didn't say what the application is really supposed to do, the user doesn't really know what the input & the output should be or what to do in case of an error.