Protect Your Cloud Onboarding with the Latest Lpc54s0xx Microcontroller

Protect Your Cloud Onboarding with the Latest LPC54S0xx Microcontroller

Donnie Garcia MICR Systems & Applications Engineering

June 2019 | Session #AMF-SOL-T3647

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. © 2019 NXP B.V. Agenda

• Relevance of IoT Security • IoT Security: Threats, Principles and Lifetime • AWS at a Glance • LPC54S0xx: Protecting Cloud On-boarding • Q & A

COMPANY PUBLIC 1 NXP Solutions for Edge Computing IoT Nodes Edge Gateways Cloud Infrastructure

HOME ETHERNET GATEWAY SWITCH Data Machine Analytics Learning

WIRELESS INDUSTRIAL ROUTER CONTROLLER

Customer Solution App App App Multiple Cloud Frameworks NXP SW Platform NXP SW Platform Thin Application Middleware Edge Middleware Edge Management RTOS Agent RTOS, Linux, Android Agent

NEW: SE050 Secure Device Management

NXP Kinetis, LPC, i.MX-RT Family NXP Layerscape, i.MX Family NXP EdgeScale Suite

COMPANY PUBLIC 2 Relevance of IoT Security

COMPANY PUBLIC 3 Consumer IoT Device Attack Trends

• Profitability motivates the IoT attacker • DDoS attacks are enabled by dark web store fronts • As the value of devices and the data they handle increases, Ransomware or device lock out attacks will rise • IoT devices with weak cybersecurity allow attackers https://www.rsaconference.com/writable/presentations/file entry into protected networks _upload/sem-m03d-profiting-from-hacked-iot-devices- coin-mining-ransomware-something-else.pdf

COMPANY PUBLIC 4 Legislation

• Convergence on IoT security guidelines from many angles (foreign and domestic) • OWASP (Open Web Application Security Project has a nice list

https://www.youtube.com/watch?v=YxC1kcZDMyc& feature=youtu.be

COMPANY PUBLIC 5 Threats, Principles and Lifetime

COMPANY PUBLIC 6 Attacks Occur in Many Forms: Different Types and Locations

• Physical – making use of physical properties or deficiencies in the device Attack type • Logical – by sending malicious messages, the software will misbehave

• Local – adversary must be in the proximity Adversary’s of the device location • Remote – adversary can be anywhere

COMPANY PUBLIC 7 IoT Security Threats and General Protection Principles

Threat Spectrum Solution Rationale Against Threats

Physical Logical 3 Physical 2 Logical

If an attacker can get local If an attacker can get local • All local interfaces: access to the device, make a access to the device, aim to • Power analysis – Exploiting JTAG cost/benefit trade-off and protect protect against local logical Local • Light attacks – Serial against relevant local physical attacks. Reason: can be • Glitching – USB attacks over the lifetime of the automated and executed by – … device laymen

1 • Buffer overflow Aim to protect against remoteBuffer attacks. overflow • Rowhammer Remote Rowhammer Heartbleed Reason: scalable attacks can be automatedHeartbleed and executed by • Cache Timing Cache timing • Flooding/DoS laymen from anywhere in theFlooding/DoS world

Level of importance to ensure security against threats High Higher Highest

COMPANY PUBLIC 8 A Connected/smart Device is Vulnerable Throughout its Lifecycle

Product lifecycle Procure, Develop, Manufacture, Distribute Onboard, Operate and Update Decommission

Local Attacks (physical and logical) Local Attacks (physical or logical) – Per Device Local Attacks (physical and • Extract keys/certificates • Tamper the IC to obtain access to data and SW and re-use logical) • Overproduction of original device for remote attacks (Trojan horse, DoS on Cloud, …) • Extract credentials (user • False certificate/private key injection • Especially dangerous for non-diversified Symmetric key data, keys, certificates) • Malicious image loading protection: “Break one, Break all” • Inject malware to network • Ccounterfeits of devices • IP Theft Remote attacks – Scalable to all devices Remote attacks could be made against • Create unauthorized connection to extract data, abuse Remote attacks are possible infrastructure functionality or inject malware to turn device into a bot by re-commission the device • Perform malicious software update to do the same to attack the network or cloud

COMPANY PUBLIC 9 Derived Features for IoT Devices

System is able to securely go through its different life stages, including: Secure system Power-up / Boot phase, debug, OTA updates of FW and SW and lifecycle decommissioning

A device must provide means for protected secure root key provisioning Crypto & Key and storage of key and certificate credentials, and handle the security of protection derived keys.

Minimize the attack surface by isolating HW (like memory and Resource isolation processing) and SW resources used for platform security features from (HW and SW) other parts of the IoT system

Run time integrity and The run-time integrity of a system is ensured and can be (remotely) attestation validated – This validation is (remote) attestation

COMPANY PUBLIC 10 LPC54S0xx Security Technology

COMPANY PUBLIC 11 LPC54Sxx Block Diagram

High performance with high-end Graphical User Interface and security RAM ARM Cortex-M4F Up to 360 KB • Cortex-M4F, 180MHz Up to 180 MHz − Up to 360 KB RAM Includes MPU ROM − 16KB EEPROM CORE MEMORY − XIP from QSPI via SPIFI − External Memory Ctrl (up to 32 bits) Ext. Mem. Ctrl SPIFI DMA Up USB Audio to 32ch PLL PLL UARTS I2C FM+ FLEX Key Features (10) LIN 2.2 Power Control (10) COMM • Graphic LCD with resolutions up to 1024 x 768 (Choose Single Vdd power supply, POR, BOD, SPI (10) reduced power modes I2S (2) any 10) • CAN-FD controller x2 (LPC54608) • eSPI interface (slave and LPC bus device functionality) Clock Generation Unit 12 or 96 MHz, System PLL TFT LCD CAN FD (2) • Digital mic subsystem supporting voice detection SYSTEM HS USB (1) FS USB (1) Ethernet AVB

• Hi-Speed and Full Speed USB Matrix Bus Multilayer − USB: 1x HS (H/D) w/on-chip HS PHY 32-bit Timers (5) SCTimer/PWM DMIC Subsys SDIO

− XTAL-less FS USB Dev Smart Card (2) GPIO Up to 170 Multi-Rate Timer WWDT • FlexComm: flexible serial connectivity eSPI INTERFACES • Advanced Security Option: RTC Alarm Timer − AES-256, SHA-2, True RNG TIMERS AES-256 OTP RNG

− PUF for key storage ADC 12b 12ch SHA-2 PUF Temp Sensor − HW diversified OTP Key Storage 5Msps ANALOG SECURITY (Optional) − Secure boot using 2048-bit RSA authentication and SHA-2 verification − Encrypted boot using AES-GCM mode

COMPANY PUBLIC 12 LPC54Sxx Security Sub-system

• ROM supporting secure boot methods − Authentication, Encryption, combination options ROM Firmware • AES Engine − Supports 128, 192 or 256 bit keys

− Encryption modes: Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedback SHA Engine RNG I/O (Serial) (OFB), Counter (CTR), Galois Counter Mode (GCM) • SHA Engine − Support SHA1 (160 bit) and SHA2 (256 bit) AES Engine • Physically Unclonable Function (PUF) − Device unique root key (256 bit strength) − Can store key sizes 64 bit to 4096 bit − Index 0 Keys routed to AES engine via direct HW bus PUF with Dedicated • 128-bit UUID per device OTP Unique ID RAM − RFC4122 compliant • Random Number Generator (RNG) − FIPS 140-1 compliant • HW diversified OTP key − Key stored in OTP is scrambled using device unique ID COMPANY PUBLIC 13 OTP

COMPANY PUBLIC 14 OTP Layout – LPC54S0xx NXP programmed data OTP provides tamper proof storage for 127 0 key material and boot control Bank0 Word3 Word2 Word1 Word0 • OTP is organized as four 128-bit banks Lower 128-bits RoT Key Hash Bank1 Word3 Word2 Word1 Word0 • Each 32-bit word can be read/write lockable Upper 128-bits RoT Key Hash (PUF enabled, no USB) Word3 Word2 Word1 Word0 • Bank 1 (either): Scrambled 128-bit AES key (PUF disabled) − Lower 128 bits of RoT key hash Bank2 − Customer data (encrypt only) Word3 Word2 Word1 Word0

• Bank 2 (either): USB Vendor/Product ID (Customer Spare *)_ − Upper 128 bits of RoT key hash Word3 * Word2 * Word1 Word0

− Scrambled 128-bit AES key (PUF disabled) NXP programmed data Customer − USB vendor/product IDs Bank3 Word3 Word2 Word1 Word0 − Customer data (encrypt only, PUF enabled) Programmed at NXP factory • Bank 3 – word 0 of controls secure boot behavior along with key revocation list Programmed by Customer in factory/field COMPANY PUBLIC 15 PUF

COMPANY PUBLIC 16 SRAM PUF Technology

3 1 Process Variation Silicon Fingerprint

The start-up values create a 100% random Naturally occurring variations in the attributes of and repeatable pattern that is unique to transistors when chips are fabricated (length, width, each chip thickness) 4 2 SRAM Start-up Values SRAM PUF Key (KPUF)

Each time an SRAM block powers on The silicon fingerprint is turned into a secret the cells come up as either a 1 or a 0 key that builds the foundation of a security subsystem

SRAM PUF Benefits • Device-unique, non-reproducible • Leverages entropy of mfg. • No key material fingerprint process programmed

COMPANY PUBLIC 17 SRAM PUF Advantages

SRAM PUF Technology • Key generated by device SRAM PUF entropy • No traces of sensitive data

Anti-fuse Security Other Solutions FLASH • Key programmed EEPROM externally • Permanent physical Fuses alteration • Key visible in structure ROM

Cost COMPANY PUBLIC 18 Key Provisioning Based on SRAM PUF

1. Enrollment Mode • SRAM PUF response (R) is a noisy fingerprint of the chip R Fuzzy Helper Data SRAM PUF Extractor (Activation Code) • PUF IP implements the Fuzzy Extractor or Helper Data 2. Key Reconstruction Mode Algorithm − Error correction SRAM PUF Helper Data − Privacy Amplification R’ • Two operation modes: Fuzzy Extractor − Enrollment mode − Key Reconstruction Mode PUF Key

COMPANY PUBLIC 19 PUF Key Store

Helper LPC PUF Features data/Activation Code • 256 bit strength Root key Key Code APB Register I/F • Supports wrapping of keys PUF IP Index 0 − 64 to 4096 bits keys Key Code Secret HW bus Index 1 − Generation of Intrinsic keys (random key) Key Code − Index 0 accessible Index 2 through HW secret bus Crypto AES Lib Key Code − Other indexes through Index 0 register I/F LPC

QSPI Flash

COMPANY PUBLIC 20 Key Management

COMPANY PUBLIC 21 Key Management – HW AES Key Paths • Critical keys feed directly to AES engine via HW bus • No access to secret keys Unique ID (Index 0) via SW readable KEYMUX registers − Except during provisioning OTP Key 128-bit key b01 fuses scrambler AES Engine • PUF derives unique root 128, 192 and 256-bit key key (KPUF) per device b10 from SRAM fingerprint Index 0 Keys − Eliminates complexity of SRAM PUF SW selectable generating unique keys per

device during provisioning Non Index 0 Keys readable through PUF register interface − Protects credentials on a per device basis

COMPANY PUBLIC 22 Secure Boot ROM

COMPANY PUBLIC 23 LPC54Sxx Secure Boot ROM Features

• Support following secure boot mode − Authentication only image: Public Key signed image − Encrypted image: Symmetric key encrypted image with and MAC authentication − Enhanced secure image: Symmetric key encrypted image with Public Key authentication

• Support Public Keys & Image Revocation

• Support redundant boot image on external SPI flash

COMPANY PUBLIC 24 Secure Boot ROM – Option Details • Secure Boot − Authentication only images: ▪ RSA signature verification with public key (2048-bit modulus and 32-bit exponent) ▪ Image key certificate support with revocation capability ▪ Uses OTP to authenticate public key • SHA256 digest of public key should be stored in OTP

• Encrypted Boot ▪ Uses AES-GCM mode to decrypt and authenticate image • 256-bit key using PUF OR • HW diversified 128-bit key using OTP

• Enhanced images support based on security policy

COMPANY PUBLIC 25 Key Store Details • Activation code − ~1KB of data generated during PUF enrollment Used for Activation Code encrypted − Helper data (~Error Correction Code) Image Key Code images to reconstruct root key (AES256-GCM) (Intrinsic or User ) − Generated during provisioning

• Key codes FW Update Key Code (User) − User keys ▪ Pre-shared keys Key Store ▪ Provisioned during manufacturing − Intrinsic keys ▪ Random keys

COMPANY PUBLIC 26 Key Management

COMPANY PUBLIC 27 Key Management Table Authentication Only, No Encryption (See Slide 47)

Key Description Owner Key Generation Key Use Key Storage Name Use a certificate authority OEM Root of Generated by the image RSA 2048 Private key used for Used to sign the image key -OR- Trust creation tool (python script). creating signatures of the image key -OR- certificate which is part of Private Use of key material can be Trusted OEM machine must certificate image data Key password protected in this tool have OpenSSL and should CA have a strong RNG and be “Air Gapped” Used to validate the image Root of Associated RSA 2048 public key for Tool can generate HEX output certificate which is holds the Part of the boot image trust authenticating boot code. This key is of the hash of the public key to Image Public key. Not a OEM Public inserted into the image certificate be stored in OTP which is secret key, checked for Hash stored on chip OTP for Key which becomes part of the boot data checked during booting integrity by Root of Trust integrity check Hash. Generated by the image Trusted OEM machine must Image RSA 2048 Private key used for creation tool (python script). have OpenSSL and should Private creating signatures of application OEM Use of key material can be have a strong RNG and be Key binaries password protected in this tool “Air Gapped” Associated RSA 2048 public key for Image authenticating boot image. This key is Generated by the image Used to validate the boot Public OEM Part of the boot image inserted into the certificate which creation tool (python script) image upon every reset Key becomes part of the boot data

COMPANY PUBLIC 28 Key Management Table Signed and Encrypted (Enhanced with PUF); See slide 49 for Fuse settings and previous slide

Same keys as detailed in previous slide, but also, the below

Key Name Description Owner Key Generation Key Use Key Storage PUF Boot AES256bit symmetric key OEM Tool generates AES Decrypt the signed Built during manufacturing time. Encryption which is used to encrypt key image (GCM) The plain text key is given to PUF Key (Image application code and data. and encrypted for in system LPC Chip Set PUF storage in external flash. Key) KEY encrypts this key

KPUF Hardware AES256 bit symmetric key LPC Chip Generated by the Used to create other Intrinsic to PUF unique key which is used to protect the chip itself (PUF keys that go in the PUF Boot Encryption Key. SRAM Fingerprint key store (like the based) PUF Boot encryption key) Activation Not a Key, but data needed LPC Chip (external Generated during Not a key, but helper External Flash (see slide 64) Code to support the PUF Flash) the enrollment phase data needed to of PUF support PUF

COMPANY PUBLIC 29 Multiple options for establishing unique identity for the Chip Chip specific unique and protected keys 1) RFC4122 along with Secure boot compliant secure boot flow Unique ID functions provide protect OEM the foundation 2) OTP Key installed cloud for establishing

Onboarding TLS Stacks (Arm diversified by credentials trust in the Mbed TLS) use chip Unique ID device functions hardware can be used to managed keys Based on create encrypted protections Counterfeit Cloud private key credentials ROM provides device policies, data stored in material become part of an immutable Option for AES the secure boot secure boot flow Integrity System system is New firmware 3) PUF engine to use protected by image that is to support OTP or PUF applied to the generated key protected for hardware system must can operate in a recovery from generated keys integrity and system run away managed keys pass the secure similar capacity update confidentiality scenarios boot flow Hardware Option for AES Keys are acceleration for During Arm MPU for engine to use ROM support for AES and SHA-2 Communication Secure protected by manufacturing OTP or PUF up to 8 dedicated memory (SHA-256) DataConfidentiality cloud credentials partitioning for generated keys revocations interface to HW firmware Secure are encrypted logical security AES engine with chip specific unique & Hardware protected keys acceleration for AES and SHA-2 (SHA-256

Key Management Secure Boot

COMPANY PUBLIC 30 AWS IoT at a Glance

COMPANY PUBLIC 31

Amazon Web Services and AWS IoT All AWS Services AWS All

COMPANY PUBLIC 32 AWS IoT Device and Cloud Views

COMPANY PUBLIC 33 Amazon FreeRTOS at the Device

Thermostat Camera LED Thing Thing Thing

Embedded User Application

Greengrass Shadow MQTT WiFi Mgmt. Discovery Library Agent Library FreeRTOS Kernel Amazon FreeRTOS Internal Libraries

Vendor Drivers MCUXpresso SDK with Amazon FreeRTOS

Hardware

COMPANY PUBLIC 34 AWS IoT: What Can Go Wrong?

COMPANY PUBLIC 35 Actual Events, Names and Faces Have Been Changed…

• Developer D from one Company is working jointly with Developer E from a different Company on benchmarking performance for a new processor and memory architecture • They decide together to use an Amazon FreeRTOS example as a “typical IoT application” • Developer D sets up an AWS account and gets the “MCUXpresso SDK Remote Control” application working and enables Show-Run- Time stats for Amazon FreeRTOS • Excited about the results and working towards a deadline Developer D shares his work with Developer E.

COMPANY PUBLIC 36 D E

Developer E: Now has access to Developer Developer D: Uses personal credit card to D’s Wifi SSID and password. With the device create AWS account, creates device credentials Developer E can make a credentials for App, sets default policies for the counterfeit device and use it to push large device and the Smart phone App that controls amounts of data to Developer D’s AWS it, uses home WiFi Credentials to get the app account leading to data fees charged to working then post the package for Developer E personal Credit Card of Developer D

COMPANY PUBLIC 37 Amazon FreeRTOS Examples are Part of MCXpresso SDK

Great Examples! Device private key stored as plain text in a header file

Unauthenticated entities are Device Name, WiFi Credentials allowed are plain text COMPANY PUBLIC 38 AWS Vulnerabilities: What Needs to be Protected

COMPANY PUBLIC 39 AWS Security Goals Statement https://docs.aws.amazon.com/iot/latest/developerguide/iot-security-identity.html

COMPANY PUBLIC 40 Other Application Specific Needs

• WiFi Credentials Requirements for IoT Data • Passwords • Personal Identifiable Integrity Information (Privacy) • Payment Information Authenticity • Sensor Integrity/ Availability Application Integrity (Conditional)1)

Confidentiality (Conditional) 1)

1) Conditional requirements depend on the device – they are not always required COMPANY PUBLIC 41 What we can do better…

Protect device private keys with encryption/software

Set real AWS policies Only store encrypted WiFi credentials COMPANY PUBLIC 42 LPC54S0xx: Protecting Cloud On-boarding

COMPANY PUBLIC 43 LPC540xx/LPC54Sxx Block Diagram

High performance with high-end Graphical User Interface and security RAM • Cortex-M4F, 180MHz ARM Cortex-M4F Up to 360 KB Up to 180 MHz − Up to 360 KB RAM Includes MPU ROM − 16KB EEPROM

CORE MEMORY − XIP from QSPI via SPIFI Ext. Mem. SPIFI − External Memory Ctrl (up to 32 bits) DMA Up USB Audio Ctrl to 32ch Key Features PLL PLL 2 UARTS I C FM+ LIN 2.2 FLEX (10) • Graphic LCD with resolutions up to 1024 x 768 Power Control (10) COMM Single V power supply, POR, BOD, (Choose dd SPI (10) • CAN-FD controller x2 (LPC54608) reduced power modes I2S (2) any 10) • eSPI interface (slave and LPC bus device functionality) Clock Generation Unit CAN FD (2) 12 or 96 MHz, System PLL TFT LCD • Digital mic subsystem supporting voice detection SYSTEM HS USB (1)

FS USB (1) Ethernet AVB • Hi-Speed and Full Speed USB Multilayer Multilayer Matrix Bus 32-bit Timers DMIC − USB: 1x HS (H/D) w/on-chip HS PHY SCTimer/PWM SDIO (5) Subsys − XTAL-less FS USB Dev Smart Card GPIO Up to 170 Multi-Rate Timer WWDT (2) • FlexComm: flexible serial connectivity eSPI RTC Alarm Timer INTERFACES • Advanced Security Option: AES- TIMERS OTP RNG − AES-256, SHA-2, True RNG 256 − PUF for key storage ADC 12b 12ch SHA-2 PUF Temp Sensor 5Msps − HW diversified OTP Key Storage ANALOG SECURITY (Optional) − Secure boot using 2048-bit RSA authentication and SHA-2 verification

− Encrypted boot using AES-GCM mode

COMPANY PUBLIC 44 LPC54Sxx Security Sub-system

• ROM supporting secure boot methods − Authentication, Encryption, combination options ROM Firmware • AES Engine

− Supports 128, 192 or 256 bit keys

− Can store key sizes 64 bit to 4096 bit − Index 0 Keys routed to AES engine via direct HW bus • 128-bit UUID per device PUF with Dedicated − RFC4122 compliant OTP Unique ID • Random Number Generator (RNG) RAM − FIPS 140-1 compliant • HW diversified OTP key − Key stored in OTP is scrambled using device unique ID

COMPANY PUBLIC 45 SRAM PUF Technology

3 1 Process Variation Silicon Fingerprint

Each time an SRAM block powers on The silicon fingerprint is turned into a secret the cells come up as either a 1 or a 0 key that builds the foundation of a security subsystem

SRAM PUF Benefits • Device-unique, non-reproducible • Leverages entropy of mfg. • No key material fingerprint process programmed

COMPANY PUBLIC 46 Key Management – HW AES Key Paths

• Critical keys feed directly to AES engine via HW bus • No access to secret keys (Index 0) via SW readable registers − Except during provisioning

• PUF derives unique root Unique ID KEYMUX key (KPUF) per device from SRAM fingerprint OTP Key 128-bit key −Eliminates complexity of b01 AES generating unique keys fuses scrambler Engine per device during 128, 192 and 256-bit key provisioning b10 − Protects credentials on a Index 0 Keys per device basis SRAM PUF SW selectable

Non Index 0 Keys readable through PUF register interface

COMPANY PUBLIC 47 PUF Key Store

Helper data/Activation LPC PUF Features Code • 256 bit strength Root key APB Register I/F Key Code PUF IP Index 0 • Supports wrapping of keys − 64 to 4096 bits keys Key Code Secret HW bus Index 1 − Generation of Intrinsic keys (random key) Key Code Index 2 − Index 0 accessible through Crypto AES HW secret bus Lib Key Code Index 0 − Other indexes through LPC register I/F QSPI Flash

COMPANY PUBLIC 48 PUF Key Store – Key Generation • Keys generated externally can be stored through PUF using SET_KEY SET_KEY operation PUF IP Plain Key • PUF controller provides Key Code generation of device unique GET_KEY cryptographic strength keys (64 to 4096 bits) using PUF IP GENERATE_KEY operation Key Code Plain Key − If key index parameter is set to 0 then key is not known to anybody. GENERATE_KEY − Any other key index are accessible PUF IP through register interface using GET_KEY operation. Key Code

COMPANY PUBLIC 49 PUF Key Store for Updated Amazon FreeRTOS Example

Helper data/Activation Code PUF Boot Encryption Key (Image Key) APB Register I/F Key Code Used for Signed and encrypted PUF IP Index 0 boot to protect system integrity

Key Code PUF 256bit Device Unique ECC Secret HW bus P-256 private key for AWS Index 1 onboarding

Key Code Symmetric Key for protecting Index 2 WiFi/connectivity credentials Crypto AES Key Code Lib Index 0 Symmetric Key for protecting LPC device sensitive personal data QSPI Flash

COMPANY PUBLIC 50 PUF Key Store for Updated Amazon FreeRTOS Example

Helper data/Activation Code PUF Boot Encryption Key (Image Key) Used for Signed and Key Code encrypted boot to Index 0 protect system integrity Protect device private keys with PUF 256bit Device encryption/software Key Code Unique ECC P-256 Index 1 private key for AWS onboarding

Key Code Symmetric Key for Index 2 protecting WiFi/connectivity credentials Key Code Only store encrypted WiFi Index 0 Symmetric Key for credentials protecting device sensitive personal data

QSPI Flash

COMPANY PUBLIC 51 Ex: PUF Key Store for Amazon FreeRTOS and Onboarding

Key storage protected by the “PUF protected” Benefits of this to onboard securely to private key AWS cloud

Helper data/Activation + Protect device private key Code needed for AWS onboarding with PUF Boot Encryption Key (Image Key) Key Code Used for Signed and encrypted boot to a device unique symmetric key Index 0 protect system integrity + Integrity is protected with the

Key Code PUF 256bit Device Unique ECC P-256 secure boot with image Index 1 private key for AWS onboarding encryption based on PUF

Key Code Symmetric Key for protecting (physically unclonable function) Index 2 WiFi/connectivity credentials + PUF encrypted WiFi credentials

Key Code Symmetric Key for protecting device to minimize risk of WiFi access Index 0 sensitive personal data code theft

QSPI Flash

COMPANY PUBLIC 52 Key Management – HW AES Key Paths • Critical keys feed directly to AES engine via HW bus • No access to secret keys (Index 0) via SW readable registers − Except during provisioning of installed key − For PUF generated key, no access

Unique ID • PUF derives unique root KEYMUX key (KPUF) per device

from SRAM fingerprint 128-bit key Key OTP fuses b01 −Eliminates complexity of scrambler AES generating unique keys Engine per device during 128, 192 and 256-bit key b10 provisioning

−Protects credentials on a Index 0 Keys SW selectable per device basis SRAM PUF

Non Index 0 Keys readable through PUF register interface

COMPANY PUBLIC 53 Secure Onboarding with LPC54Sxx

Key Store for Amazon FreeRTOS and onboarding

LPC54S Security use-cases features enabled

ROM Firmware • Enable Amazon FreeRTOS and secure onboarding to the AWS cloud, by having the key encrypted with SHA Engine RNG I/O (Serial) a PUF-protected encryption AES Engine • Securely store multiple private keys to protect system data (WiFi Credentials) • Secure boot of the device using a PUF encrypted PUF with Dedicated OTP Unique ID RAM key

NXP products used Security features of products used • LPC54Sxx IoT Microcontroller • PUF – Physically unclonable function with dedicated RAM • HW accelerated encryption (AES, SHA) secure bus to PUF key • ROM supporting secure boot methods

COMPANY PUBLIC 54 Demonstration Video