Company Public – NXP, the NXP logo, and NXP secure connections for a smarter world are trademarks of NXP

B.V. All other product or service names are the property of their respective owners. © 2018 NXP B.V.

Security Architect - Automotive

John Cotner

i.MX 8 Security Overview

October 2018 | AMF-AUT-T3363

COMPANY PUBLIC 1

"There are only two types of companies: those that have been

hacked, and those that will be. Even that is merging into one

category: Those that have been hacked and will be again."

- Robert Mueller, sixth director of the FBI

“A system is good if it does what it’s supposed to do and secure

if it doesn’t do anything else.”- Dr. Eugene “Spaf” Spafford, Purdue

COMPANY PUBLIC 2

Secure

Processing

Secure

Networks

Secure

Gateway

Secure

InterfacesM2M Authentication &

Firewalling

Secure Messaging

Separated Functional

Domains

Code / Data

Authentication

(@ start-up)

Resource Control

(virtualization)

Intrusion Detection

Systems

(IDS)Secure

OTA

Updates

Code / Data

Authentication

(@ run-time)

Firewalling

(context-aware

message filtering)

Message Filtering &

Rate Limitation

Core Security Principles in Automotive Systems

Prevent

access

Detect

attacks

Reduce

impact

Fix

vulnerabilities

COMPANY PUBLIC 3

i.MX 8 Security

COMPANY PUBLIC 4

i.MX 8 Series Security Architecture Overview

Public Key (Hashes)

Cortex-A

CPUs

Se

cu

rity

Con

tro

llerPartitioned

Secure

RAM

Ta

mp

er

Dete

ct

RT

CSecure

Debug(TZ, NS)

External

Memory

JTAG

Private Key Bus

DDR Controller

HDCP

1.x/2.x

HDMI-TX

Cortex M4(s)M

onoto

nic

Counte

r

Se

cre

t

Encrypted

Flash

IEE for On-the-Fly

Decryption/Encryption

Busses with Resource Domain, TrustZone Access Controls, and SMMU

Trust

Zone

DTCPHDCP

1.x/2.x

HDMI-RX MLB

System

Controller

Cry

pto

Engin

es

Bus

Masters

Boot ROM

VPU

Hig

h A

ssura

nce

Runtim

eR

OM

Replay Protection

Security State

Active

Se

nso

rs

OT

PA

larm

sDevice Unique Secrets

do

ma

in

do

ma

in

Flex-SPI

MMCAU

COMPANY PUBLIC 5

Security Features

• SECO Security Microcontroller (Cortex-M0+,133Mhz)− Isolated security domain

− Higher protection for root secrets and key management functions

• DTCP (Digital Transport Content Protection) – Authentication engine with secure interface for key loading

• IEE (Inline Encryption Engine) – Cryptographic protection of data in external memory

• ADM (Authenticated Debug Module) – Secure debug, Lifecycle handling, Access and Violation control

• Enhanced CAAM− 64KB Secure RAM

− Cryptographic acceleration on cryptography Algorithms

− RTIC (Runtime Integrity Checker) : Ensures integrity of the memory contents

COMPANY PUBLIC 6

Security Features (2 of 2)

• SNVS (Secure Non-Volatile Storage)− Secure State Machine

− 10 external tamper pins that can be configured to support 5 active meshes or 10 passive meshes

− Analog sensors for temperature, voltage, frequency tamper detection

• Encrypted “execute in place” (XIP) capability from QSPI

• xRDC – HW isolation at chip level (Resource Domains)

• Cryptographic binding of resource domain identity for secure storage− Key storage in external flash

• Fast secure boot− ECDSA up to 1024 module with SHA-512

• Fast signature verifications using P-256 Elliptic Curve for V2X

COMPANY PUBLIC 7

i.MX Product Security Features Overview Feature i.MX6Q/D/S i.MX6SX i.MX6UL i.MX7S/D i.MX8QM i.MX8QXP

Security Controller (SECO) x x x x ✓ ✓

AES128/192/256, SHA1/256, DES/3DES ✓ ✓ ✓ ✓ ✓ + SHA 384/512 ✓ + SHA 384/512

Elliptic Curve DSA (up to P521/B571)

RSA (up to 4096)x x ✓ ✓

✓

High performance

✓

High performance

Crypto Accelerator Unit (CAU)

(DES, AES co-processor instruction)x x x x ✓ ✓

Certifiable RNG ✓ ✓ ✓ ✓ ✓ ✓

Run Time Integrity Protection x x ✓ ✓ ✓ ✓

Isolated security applications (e.g. SHE) x x x x ✓ ✓

High Assurance Boot (RSA, ECDSA) ✓RSA ✓RSA ✓RSA ✓RSA ✓ ✓

Encrypted Boot ✓ ✓ ✓ ✓ ✓ ✓

Secure Debug ✓ ✓ ✓ ✓ ✓ Domains ✓ Domains

Always ON domain ✓ ✓ ✓ ✓ ✓ ✓

Secure Storage (non-volatile) ✓ ✓ ✓ ✓ ✓ ✓

Tamper Detection Signal ✓ ✓ ✓ Active ✓ Active ✓ Active ✓ Active

Volt/Temp/Freq Detect x x ✓ ✓ ✓ ✓

Inline Encryption x x ✓ BEE x ✓ IEE ✓ IEE

Manufacturing Protection x x x ✓ ✓ ✓

Resource Domain Isolation x ✓ x ✓ ✓ ✓

Content Protection ✓ 6Q 1.x only x x x ✓ HDCP 1.x/2.x,

DTCP✓ DTCP

COMPANY PUBLIC 8

SECO

COMPANY PUBLIC 9

SECO Overview

SCU MU0

Watchdog

OTP

ADM

CAAM

HA

L

HA

L

SECO

Secure RAM

M0+

TCM

low

TCM

high

SNVS

ROM

MU1

MU2

MU3The rest of

the system

Manager of the CAAM

and other NXP Security-

Reliant Subsystems• Energy efficient M0+ core

supporting 133MHz

• Interrupt Controller with up to 32

IRQs

• Security controls through

Authenticated Debug Module

(ADM)

• Dedicated 80KB ROM, 80KB

RAM with Error Correct Code

(ECC)

• Dedicated One-Time

Programmable (OTP) keys

• Fabric switch to Shared

Peripherals, Local Peripherals,

and Private Crypto Key Bus

COMPANY PUBLIC 10

SECO Features

• Secure boot (container/image

authentication)

• Services provided to AP/SCU

cores via Message Unit

interface

• Lifecycle configuration

• Fuse programming

• Debug enablement

• IP secret installation (DTCP

keys, HDCP keys, …)

• CAAM management

− Job Ring assignment

− Secure Memory

• SNVS management

− HW security state machine management

• ADM management (locks, timers,

LC, ...)

• Power management

• Attestation of SECO FW

COMPANY PUBLIC 11

SECO enables proper Crypto Key Management

Crypto Hardware(Rudimentary Key Designation Feature)

Application A(Keys managed in

SECO)

SECO(Full Featured Crypto Key

Management)

SECO FW

Host Layer

Dynamic Environment w/focus on

Function and Performance

Application B(Keys managed in

software) B’s Keys

Managed

A’s Keys

Managed

Hardware RoT and HW Controls

Robust

Environment

w/focus on

Security

Security HW

Key Management in

non-secure

environment

increases chance of

exposure

Crypto hardware only

not capable of fully

controlling key usage

Automotive Security

Specs require

isolated HSM/SHE

modules for full

featured crypto key

life cycle

management and

specific usage

SECO + Crypto

Hardware offers

comprehensive and

secure key

management

COMPANY PUBLIC 12

SHE

COMPANY PUBLIC 13

SHE SECO firmware

• Authenticated as part of the SoC boot process, NXP signed

• Support for all required SHE functionality

• SHE (GPL free) driver provided, ensuring accessibility from any targeted OS/SoC domain

• Off-chip non volatile storage support:

− eMMC w/RPMB partition can be used for implementing SHE Non-Volatile storage

− RPMB (Replay Protected Memory Block) uses Authentication mechanism (HMAC) to protect against:

▪ Anti-roll back attacks

▪ Read/write/erase from CPU applications (or offline attack)

− Data are stored encrypted on the RPMB partition

▪ Key used for the encryption is

• Unique per chip (derived from the i.MX OTPMK, or ZMK)

• Not known outside SECO

COMPANY PUBLIC 14

SHE driver – OS independent, non-GPL driver

• SHE services generic driver for the i.MX8 chip families

• Easily portable to different OS or Bare metal implementation

• Development details:

− c99 standard, standard Makefile

− Currently supports GCC compiler

− OS depended functions are implemented in a dedicated folder

• Quality:

− Complete test coverage provided with the library

− Driver designed to meet spice level 2 requirements

− CERT and MISRA coding rules enforced

− Coverity used for static code analysis

• SHE Library Integration Document will be made available to ease porting

COMPANY PUBLIC 15

CAAM

COMPANY PUBLIC 16

• Cryptographic Acceleration

− Public Key Hardware Accelerator: ECDSA, RSA

− Encryption Algorithms: AES, DES/3DES

− Hashing Algorithms: MD5, SHA256/384/512, …

− Message Authentication Codes: HMAC, AES-CMAC, AES-XCBC-MAC

− Authenticated Encryption Algorithms: AES-CCM, AES-GCM

• RNG

• Export and Import of cryptographic Blobs

• Secure Memory Controller and Interface− 64KB with 16 partitions at 4KB page size

− Automatic Zeroization on SNVS Violation Event

• Job Rings − descriptor based command interface

− Assigned to apps cores via SCU API

• IP Slave Interface

• Support the system virtualization by Domain ID (DID) per job ring

• DMA

CAAM

Secure RAM

StreamID

TZ

Context ID (Stream ID and QoS)

TrustZone (NS=0)DID Resource Domain ID

Partition N-1DID TZ

Partition 0DID TZ

Partition 1DID TZ

System

Memory

3DES

RNG

Elliptic

Curve (521/571)

RSA(4096)

SHA-1,

256/512

AES(128/192/

256)

SNVSMaster Secret

Security State

SECO

GPIO

Manager Page

Owner

System Bus

DMA

SM

MU

Acce

ss

Co

ntr

ol

Peripheral Bus

acce

ss p

erm

issio

ns

Job Ring

StreamID

DID TZ

Job Ring

StreamID

DID TZ

Job Ring

StreamID

DID TZ

Job Ring

StreamID

DID TZ

acce

ss

pe

rmis

sio

ns

Private Bus

Security: Cryptographic Acceleration and Assurance Module

COMPANY PUBLIC 17

Secure Storage

COMPANY PUBLIC 18

Key Storage: Non-Volatile Blobs

• Key Blobs− Protects keys between power cycles

− Keys are encrypted with key derived from a device unique secret

• Cryptographic Bindings Include− Security State (Trusted, Secure, Other)

− Access Permissions

− Privilege (TZ or NS)

− Resource Domain (i.MX8)

− Key Modifier

Secure RAM

Acce

ss C

on

tro

l

Domain ID*

A’s Keys

Permissions

Privilege

Domain ID*

B’s Keys

Permissions

Privilege Chip Secret

Cipher

256-bitKeys

Domain ID*

Permissions

Privilege

Key Derivation

Encrypted Keys

B’s Key

Blob

A’s Key

Blob

i.MX8* Only i.MX8 has Domain ID binding

External Flash

COMPANY PUBLIC 19

RTIC

COMPANY PUBLIC 20

Runtime Integrity Checker (RTIC)

• Ensures integrity of the memory

contents

• Verifies memory contents during run-

time execution

• If memory contents fail to match then a

security violation is asserted

• A security violation changes the security

state of the SoC

• Virtualized Addresses, TZ and different

Resource Domains supported

RTIC

System Controller

DRAM

SRAM

S

M

M

U

/

F

I

R

E

W

A

L

L

Reference A

Reference B

Reference C

Reference D

Tightly Coupled Memory

Security State

Critical Data Part B

Vulnerable Data

Mismatch

Critical Data Part A

Peripherals

Config Regs 3

Config Regs 2

Config Regs 1

COMPANY PUBLIC 21

SNVS

COMPANY PUBLIC 22

Security State and SNVS HP and LP

• 22

47 bit counter

Power Supply

Glitch

Detectors

32 bit GP Register

32.768kHz

Syn

c

Fuses

LP

HP

48 bit Monotonic Counter47 bit counter Zeroizable Master

Key (ZMK)

SNVSSystem

Security Monitor

Master Key

Control

OTP Master

Key

CA

AM

Maste

r K

ey

External

Tamper Inputs

Tamper

Detectors

Security Violation

CAAM

Monotonic Counter

Rollover

Protection Mechanism

Security Violations

SJC WDOG

Security State

ADM

COMPANY PUBLIC 23

SNVS Features

• Security state machine that transitions to fail state upon security violations and gates access to internal SoC secrets (OTPMK/ZMK).

• 10 external tamper pins that up to 5 active tampers (5 inputs and 5 outputs) or 10 passive tampers (inputs only)

• Security sensor detection of physical attacks using temperature, voltage, frequency detection

• Monotonic Counter

• General purpose registers

• Zeroizable master key (ZMK)

• Real time counter

• High Performance and Low power domain

* SNVS features are enabled via SECO/SCU API

COMPANY PUBLIC 24

ADMAuthenticated Debug Module/Secure

Debug

COMPANY PUBLIC 25

Coresight Authentication Supported with Debug Domains

• For i.MX8, Multiple Debug Domains exist –

• Supports the CoresightAuthentication Hierarchy

• Debug Apps Core with SECO locked down, for example

• M4’s can be disabled too

SECO

SECO Debug

System Controller Debug Enable

System Controller Trace Enable

TZ Debug Enable

TZ Trace Enable

Normal Debug Enable

Normal Trace EnableSCU

Normal World

TrustZone

COMPANY PUBLIC 26

Secure Debug - JTAG Challenge/Response

ADM

OCOTP_CTRLJTAGC

Chip Unique ID,

Pass/Fail

Normal Debug Secret

Pass/Fail

Chip Unique ID

TrustZone Debug

Secret (128 bits)

JTAG Password

Response[127:0] ||

Selection[1:0]

Chip Unique ID[63:0]

TDO

TDI

Command,

JTAG Password

Response[127:0] ||

Selection[1:0]

Debug

Password

Server

Debug Enable

66

Normal Debug

Secret (128 bits)

TrustZone Debug Secret

Fuses Valid

TZ Pass/Fail

App Cores Trustzone and Normal World Debugging

1. User requests debug through JTAG interface

2. SOC responds with chip unique ID

3. Server finds corresponding secret (TZ or normal world)

4. User submits secret through JTAG interface

5. Secure JTAG module compares secret to pre-configured secret

6. If a match, debug is enabled (for TZ or normal world)

COMPANY PUBLIC 27

• System Controller Debug or SECO Debug require Signed Commands to open debug on Closed parts (with no fuse DEBUG disablement)

• SECO receives a signed message through MUs.

• Message payload specifies the target subsystem and permission (DBGEN, NIDEN…)

• Once signature is validated, SECO enables the debug to the desired sub system with the requested permissions.

Enabling Debug on SCU and SECO

SCU, SECO Secure Boot Authentication

Passes!

DEBUG

enabled

SCU or SECO

Secure Boot

Software

Image

(with

Debug

Enable)

Compare

Digest Hash

Digest Hash

(SHA-256)

Digest Hash

Public Key

Signature

Digest Hash

(SHA-256)Verification

Ok

decryption

Failed!

No

DEBUG

SCU or SECO

Secure Boot

Software

Image

(with

Debug

Enable)

Compare

Digest Hash

Digest Hash

(SHA-256)

Digest Hash

Public Key

Signature

Digest Hash

(SHA-256)Verification

Ok

decryption

COMPANY PUBLIC 28

NOF OCF

NFRPFRFFR

FWS

Life cycle update• The life cycle update procedure involves

ADM and SECO.

• ADM implement a fuse programming mask to allow transition to certain life cycle only (as indicated in the figure). Only certain fuses can be blown based on the current life cycle.

• Attempt to update life cycle without involve ADM will result in a life cycle mismatch.

• SECO provide two separate API (MU messages):

− Update life cycle

− Return life cycle (signed message)

COMPANY PUBLIC 29

IEEInline Encryption Engine

COMPANY PUBLIC 30

IEE• DDR encryption and decryption in AES-XTS mode

• QSPI flash decryption (also execute-in-place (XIP) ) in AES-CTR mode

• I/O DMA direct encrypted storage and retrieval (AES-CTR 128)

• Multi-core resource domain separation

• Transparency to software during encrypted access (i.e. no configuration, control, or interrupts)

• Secure on-chip key loading using private bus between CAAM and IEE

• Differential power analysis (DPA) resistance

• Tamper detection response which key is erased and access to IEE is blocked

Use cases include: • Execute-in-place code decryption from QSPI

primarily• Encryption of sensitive data at rest• Ciphering of I/O serial data• CAAM still used for higher importance data

Apps

CoresM4(s)

Fabric

Switch

SRAM

DDR

Inline

Encryption

Engine

I/O

DMA

DRAM

External

FlashQSPI

UART, etc...

IEE users on chip

M

R

C

M

R

C

M

R

C

COMPANY PUBLIC 31

XRDC

COMPANY PUBLIC 32

Resource Partitioning on i.MX 8

CM4

DISP_0

VPUIMAGING

Pixel

DMA0

CAN0

LVDS

MIPI

CSI_1

CAN1DSI

GPU0

DISP_1MIPI

CSI_0

CPU

Audio

Partition 1Safety

DID=0, non-secure

Partition 2Multimedia

DID=3, non-secure

Partition 0SCU

DID=2, secure

SCU

I2C

What is a Partition:• A collection of resources (master / slave

peripherals, memory regions)

• Has a domain ID and a security attribute

• Cores, peripherals and memory can belong

to more than one partition

How Partitioning Works:• The system controller commits peripherals

and memory regions into a specific

domains. (This is customer defined)

• Any communication between domains are

forced to use messaging protocols

• If a domain peripheral tries to access other

domains illegally, a bus error will occur.

Benefits of Partitioning:• Reporting of immediate illegal accesses

helps track down hard to find race

conditions before they go to production.

(AKA Sandbox Methods)

• Provides security on a finished product:

protects system critical SoC peripherals

from less trusted apps

UART

DDR 0 DDR 1 DDR 2

IMAGING

Pixel

DMA1

COMPANY PUBLIC 33

Secure boot & code signing

COMPANY PUBLIC 34

SoC Code Signing and Secure Boot

• The application core and system controller boot can be signed with separate super root keys

• Security Controller boot authenticates its firmware using its own super root key

• M4 firmware can be included in the Security Controller signature

Flash

OEM Trusted

Device Boot

Software

Image

Message

Digest Hash

(SHA-384)

PKI Public

Key

Code Signing

Secure Environment (OEM)

Software

Image

PKI Certs

Signature

Authentication

Manufacturing Software

Image + Signature + Public

Key stored in Boot Media

AuthenticationCompare

Digest Hash

Digest Hash

(SHA-384)

Digest Hash

BOOT

RELOAD

IMAGE

Public Key

Signature

Digest Hash

(SHA-384)Verification

Ok

PKI Public Key

Fuse Box

Public Key

Hash (SRK)

PKI Private

Key

encryption

decryption

Fuse Box Public Key Hash

(SRK)

COMPANY PUBLIC 35

CSF

Code Signing ToolsSigned

boot packagemkimage_imx8

Assemble all files in the

expected layout by the

boot ROM.

The Code Singing Tools

will sign only the second

container, generating the

real signature data.

Boot package file,

ready to be copied

to the boot medium.

For “OEM Closed”

devices.

First container files:

- SECO FW, NXP signed

Second container files:

- SCU FW (including DCD)

- M4 image

- AP IPL/ATF&UBOOT

Notes:

- The first container is provided by NXP already signed. NXP keys are provisioned in the SoC.

- The DCD functionality is built into the SCU FW, we no longer have a separate file.

- The signing keys for the second container are customer specific.

- The CSF file will use a similar, but updated syntax as on past i.MX solutions.

- The customer SRKs will need to be programmed in the i.MX 8 fuses.

Unsigned

boot package

Boot package file,

ready to be copied

to the boot medium.

For “OEM Open”

devices.

i.MX 8 Signed Boot Flow – user actions

COMPANY PUBLIC 36

i.MX 8QX/QM – Algorithms and keys

Algorithms

• RSA – 1024, 2048, 3072, 4096 bit keys

• ECDSA - p256, p384, p521

• SHA-256, 384, 512 bit*

• AES-CCM – 128, 192, 256 bit keys**

* Currently supported: ECDSA-P384 / SHA384 – sole allowed configuration for primary container

** Not supported for the primary container. Encryption not available in the current versions of the SECO FW.

Keys

• Support up to 4 Super Root Keys

(SRKs)

• Any SRK may be revoked

• Hash of SRKs stored in fuses

• The public keys are included in

the container

• 2 Root of Trust (NXP and OEM)

COMPANY PUBLIC 37

Manufacturing protection

COMPANY PUBLIC 38

Chip Distribution with

Manufacturing

Protection

Wafer Tester

Chip fabrication Chip distribution

Chip unique ID

Device Manufacture Device Distribution

DeviceDistributor

Primary Manufacturer

Contract manufacturerChip distributor

Product

• Signed configuration, software,

• Primary Manufacturer SRK (to be fused on the chip)

MP root secret(s)

Chip information signed with MP

private key, derived from chip and

Primary Manufacturer’s SRK

Authenticated channel used to download keys, proprietary software and data (that is then BLOB’ed)

See Manufacturer

Registration details

on next slide

Provisioned Product

COMPANY PUBLIC 39

Enablement

COMPANY PUBLIC 40

Enablement

• BSP− Linux and drivers

− SECO Firmware (NXP signed)

− SCU Firmware and porting kit

− ARM Trusted Firmware (ATF)

− Open Trusted Execution Environment (OP-TEE)

• Tools− Image creation tool

− Code signing tool

− Manufacturing tool

− JTAG debug scripts (Lauterbach, ARM DS-5)

• Documents− Security Reference Manual (>1000 pages)

− SECO FW API (30 pages)

− SCU FW API (100 pages)

COMPANY PUBLIC 41

Monitor code

(OP-TEE secure monitor for i.MX6/7

ARM Trusted Firmware for i.MX8)

Normal World Secure World

Cortex A Clusters

Monitor

mode

/

EL3

Super

visor

mode

/

EL1

User

mode

/

EL0

Linux/Android

Dm-crypt

I.MX BSPTZ

driver

CAAM

Driver

SNVS

Driver

OP-TEE OS

Applications/libraries

Tee lib

Open

SSLkeytool

Chromium

NSSAWS

I.MX

BSP

Hyper

visor/

EL2

Dm-verity/Dm-integrity

Crypsetup

Target:

A solid i.MX security

foundation for enablement SW

Unified across i.MX families

Consistent API and user experience

Enables most HW capabilities

Solid secure foundation for:

• Key storage

• Certificate/key enclave in TEE

• IOT device authentication

• Device identity protection

• IP protection

SECO

Driver

Secure

data path

Provisionning

Manufacturing

protection

Resource

manager

CAAM

Driver

OCOTP

Driver

TZASC

Driver

RDC

Driver

CSU

Driver

XRDC

Driver

Power

mgt

PMIC

Driver

SECO

Driver SCU

Driver

SNVS

Driver

I2C/SP

IDriver

i.MX8 QM/QX

only

i.MX 6/7/8m

Security

Infrastructure

COMPANY PUBLIC 42

Monitor code

(OP-TEE secure monitor for i.MX6/7

ARM Trusted Firmware for i.MX8)

Normal World Secure World

Cortex A Clusters

Monitor

mode

/

EL3

Super

visor

mode

/

EL1

User

mode

/

EL0

Linux/Android

Dm-crypt

I.MX BSPTZ

driver

CAAM

Driver

SNVS

Driver

OP-TEE OS

Applications/libraries

TEE lib

Open

SSLkeytool

Chromium

NSSAWS

I.MX

BSP

Hyper

visor/

EL2

Dm-verity/Dm-integrity

Crypsetup

Target:

Comprehensive i.MX security

architecture

Higher level, industry standard

security API provided (PKCS11)

Seamless integration with existing

Linux applications

Encrypted storage

Secure Keystore

HSM fully leveraging HW platform

- With CAAM

- With SECO

Extended set of Trusted Apps:

- TPM

- OTA

- Attestation

SECO

Driver

Secure

data path

Provisionning

Manufacturing

protection

Resource

manager

CAAM

Driver

OCOTP

Driver

TZASC

Driver

RDC

Driver

CSU

Driver

XRDC

Driver

Power

mgt

PMIC

Driver

SECO

Driver SCU

Driver

SNVS

Driver

I2C/SP

IDriver

i.MX8 QM/QX

only

CAAM lib

PKCS11 (multiple token)

SECO libNXP SE

lib

TA

authentication

With SRK

Storage with

key blob

encryption

PKCS11

ServiceTPM

Service

CA

Certificate

generation

NFC LibSecure OTA

Remote

attestation

Security MW i.MX 6/7/8m

Security MW

NXP, the NXP logo, and NXP secure connections for a smarter world are trademarks of NXP B.V. All other product or service names are the property of their respective owners. © 2018 NXP B.V.

www.nxp.com