May 9, 2016 1

Trust Based IoT Security mechanism for ARM based SoC’s

May 9, 2016

amit.mahadik@open-silicon.comsagar.kadam@open-silicon.com

Open Silicon Inc.

May 9, 2016 22

AgendaIOT and its Need for Security

Attacks and Threats

Security Measures

Security Classification

SHUBHAM FPGA Platform

Use cases

Summary and Conclusion

Resource Considerations

May 9, 2016 33

Things Gateway Cloud

Key Attributes•Low Power•Secure•Peer-2-Peer

Components•Sensors/Actuators

•Local Processing•Communication

Devices Gateway to Back-end

Key Attributes•Multi protocol•Secure

Components•Router

•Switch•Load Balancer

Back-endComponents

•Servers •Storage•Service Platforms

Key Attributes•Private/Public •Secure•Analytics

Human Machine Interfaces

Edge Device ASICs

Internet of Things

May 9, 2016 4

IOT and its Need for Security: It’s not optionalVulnerabilities

Communication Channel Threats Wired/Wireless

Hardware Attacks and Threats On-chip probing

IO pins, Debug ports Side channel attacks

Key Extraction Enclosure/Mechanical attacks or EMI/ESD interference.

Chip de-capping and die analysis, etc

Software Attacks and Threats Image hacking Data tampering

Malware and Viruses Snooping and Tapping Password sniffing, etc

May 9, 2016 55

Security Classification

Security Classification:• Security Class A: Device within a closed network

– Thread is limited, example: smart lock, smart oven/heater• Security Class B: Device within a subnetwork

– Thread is moderate, example: smart meter• Security Class C: Device in the open network/model

– Thread is significantly high, example: mobile phone

May 9, 2016 6

• Secure boot (Root of trust)

• Secure firmware upgrade

• Device identification/authentication (subscribing and provisioning of device)

• Data security including local storage and data over the network

• Secure application execution environment

• Secure debugging

• Advance packaging technologies to prevent probing attacks

• EMI shielding and prevent against ESD on exposed I/Os

• Do not rely on end user to supply voltage within recommended operating conditions. Implement linear regulators or DC-DC converter

• Counter measure against SCA like randomize your transaction, insert dummy cycles to have constant execution paths (like NOP, MUL) etc

6

Security Measures

May 9, 2016 7

Resource Considerations

7

• Frequency

• Memory (Flash/SRAM/CMEM/DMEM)

• Host interface (Interconnect, Interrupts, DMA, Reset)

• Cryptographic support

• Overheads at different levels.

• Configurability and power domain considerations.

• Processing Time and Power consumption

May 9, 2016 88

SHUBHAM Daughter board

TE741 Kintex FPGA

ARM Cortex

M4FI2C0

UART0

GPIO

SPI

UART2

UART3

DMEM(256K)

Sonic NOC

JTAG AXI

UART1

I2C1

IMEM(256K)

SRAM(256K)Boot(256K)DAP-Lite

LoRa/Display

QSPI

ARM Trustzone Cryptocell

XBee

BLE

WHART

HRM Sensors

All sensors

Temperature, HumidityPressure, AltitudeGas, Light

Debug Console

SHUBHAM FPGA platform

May 9, 2016 99

Factory Floor Sensor HUB

Carriots Platform

User Interface through HTML

BrowserW-

HART WH Manager

LoRa

Z-BeeUSB

LAN

Outdoor Floor Sensor HUB

In room Sensor HUB

May 9, 2016 1010

Cryptocell IPHardware Block

• Support for popular Encryption Algorithms• Version controlling feature • Life cycle state (LCS) Indicator• Easy to integrate Software module for achieving use

cases like Secure Boot, Firmware over the air update (FOTA), content management, User Authentication

May 9, 2016 11

Secure boot

11

Security framework involves evaluating certificate chain of trust of key and content certificate.

Device Flash contains -OEM Public key HASH

-Device root and keys info -Latest Version of the Certificate

Key Certificate Contains -Private OEM key and its password

-Public key HASH of content certificate -Certificate versioning information Certificate Chaining Process

Content Certificate Contains -Private Key of content certificate and its password

-AES encryption key if used -SW images .bin names and load addresses in Device Flash

-Certificate versioning information

May 9, 2016 12

Secure boot (cont…)

12

May 9, 2016 1313

• In the typical IoT subsystem where the data it sent to cloud using a gateway

device, the data is sent over wireless communication channel which needs to

be secured.

• The End device data e.g. data from the sensors, data stored in external

memory like FLASH can be secured at runtime using the IP.

• The IP provides a software interface (library) which exposes APIs to the

programmer to leverage the cryptographic services.

• User Data/Content can be stored in a secure fashion using the library APIs.

Data Management

May 9, 2016 14

Firmware Over The Air Update (FOTA)

14

New application binary is sent from GUI

Carriots cloud

Lora

Temp

Altitude

SHUB platform

SHUBCM4F +

Kintex FPGA

OLED

W-HART

LoRa

Z-Bee

OTA: MQTT basedmetadata and

Application binary chunkpackets

OTA: REST APIsmetadata and

Application binary chunkpackets

OTA :raw binary packets

over Low Power RF link

Air Quality

FLASH

New application is written into the flash memory

OSI A9 based gateway platform

May 9, 2016 1515

• End device hot target due to vulnerabilities

• Secure radio communication channel

• Encrypted Application image

• Chain of trust verification

• Booting application

Securing FOTA

May 9, 2016 1616

• Gate count: Around 30609 Gates

• Boot Code Analysis:

Summary

Chain of Trust verification

Application size

30 sec 10 KB

Total ELF Size Code Section Size

(.text)

Data Section Size

(.data + .bss)

Minimum Stack and Heap Size

With Security Blocks

311 KB 63.4KB 4.92 KB 4KB

Without Security Blocks

197KB 35.2KB 0.63KB 2KB

May 9, 2016 17

Conclusion

17

• Determine what to protect, why you are protecting it, and who you are protecting against • No one solution fits everyone

• Do not release product with a plan to implement security later• It usually never happens

• Be aware of latest attack methodologies & trends

• Careful consideration on hardware and software partitioning

• As design is in progress, allocate time to analyze and break product

• Nothing is 100% secure