The document discusses trust-based IoT security mechanisms for ARM-based systems of things. It covers IoT architecture and security threats. It proposes using a SHUBHAM FPGA platform with a Cortex-M4F and cryptographic IP to provide features like secure boot, firmware over-the-air updates, and data security for sensors. Implementing this security would require additional gates and memory but help protect against attacks.

1. May 9, 2016
1
Trust Based IoT Security
mechanism for ARM based SoC’s
May 9, 2016
amit.mahadik@open-silicon.com
sagar.kadam@open-silicon.com
Open Silicon Inc.

2. May 9, 2016
22
Agenda
IOT and its Need for Security
Attacks and Threats
Security Measures
Security Classification
SHUBHAM FPGA Platform
Use cases
Summary and Conclusion
Resource Considerations

3. 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-end
Components
•Servers
•Storage
•Service Platforms
Key Attributes
•Private/Public
•Secure
•Analytics
Human Machine Interfaces
Edge Device
ASICs
Internet of Things

4. May 9, 2016
4
IOT and its Need for Security: It’s not optional
Vulnerabilities
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

5. May 9, 2016
5
5
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

6. 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

7. 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

8. May 9, 2016
8
8
SHUBHAM
Daughter board
TE741 Kintex FPGA
ARM
Cortex
M4F
I2C0
UART0
GPIO
SPI
UART2
UART3
DMEM(256
K)
Sonic
NOC
JTAG AXI
UART1
I2C1
IMEM(256
K)
SRAM(256
K)
Boot(256K)DAP-Lite
LoRa/Displa
y
QSPI
ARM
Trustzone
Cryptocell
XBee
BLE
WHART
HRM
Sensors
All
sensors
Temperature,
Humidity
Pressure, Altitude
Gas, Light
Debug
Console
SHUBHAM FPGA platform

9. May 9, 2016
99
Factory Floor Sensor HUB
Carriots Platform
User Interface
through
HTML
Browser
W-
HART WH
Manager
LoRa
Z-Bee
USB
LAN
Outdoor Floor Sensor HUB
In room Sensor HUB

10. 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

11. 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

12. May 9, 2016
12
Secure boot (cont…)
12

13. May 9, 2016
13
13
• 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

14. 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
SHUB
CM4F +
Kintex FPGA
OLED
W-HART
LoRa
Z-Bee
OTA: MQTT based
metadata and
Application binary chunk
packets
OTA: REST APIs
metadata and
Application binary chunk
packets
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

15. May 9, 2016
15
15
• End device hot target due to vulnerabilities
• Secure radio communication channel
• Encrypted Application image
• Chain of trust verification
• Booting application
Securing FOTA

16. 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

17. 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