Side of "Reboot-Oriented IoT: Life Cycle Management in Trusted Execution Environment for Disposable IoT devices" ACSAC (Annual Computer Security Applications Conference) 2020

1. 1
Reboot-Oriented IoT:
Life Cycle Management in Trusted Execution Environment
for Disposable IoT devices
Kuniyasu Suzaki 1)
, Akira Tsukamoto 1)
,
Andy Green 2)
, Mohammad Mannan 3)
1)
National Institute of Advanced Industrial Science and Technology
2)
Warmcat
3)
Concordia University
Annual Computer Security Applications Conference (ACSAC) 2020
10 December 2020 13:30-14:45 Session “System and Hardware Security”
Paper on ACM Digital Library https://dl.acm.org/doi/10.1145/3427228.3427293

2. 2
Outline
 Background for IoT Security
 Concept of Reboot-Oriented IoT
 Network boot protected by TEE (Occasional)
 Live Memory Forensics protected by TEE (Periodical)
 Life Cycle Management based on PKI and protected by TEE
 Implementation
 RO-IoT on Linux and OP-TEE with Arm TrustZone
 Watchdog timer for autonomous reboot protected by TEE
 Performance
 Conclusion
Occasional > Periodical

3. 3
Background for IoT Security
 IoT devices targeted by RO-IoT
 Smart cities and smart farming assumes many IoT deices are geologically distributed
and managed by M2M (Machine to Machine).
 IoT devices works as AI Edge of Fog-Computing and use Linux to run intelligent applications.
 The devices are desired to be disposable when they finish the role. Self-destruction
technologies or ITU E-Waste policy are developed, but …
 Concerns
 General Security issues are not solved.
 If IoT devices are hijacked by malware (ex., Mirai), it is difficult to recover because no
administrator on each device.
 The supply chain includes some stakeholders which have responsibilities (device,
software, and service). These stakeholders want to ruin the device when the
responsibilities are terminated because unmanaged IoT devices become Cyber Debris.
They donʼt want to support the expired devices.

4. 4
Reboot-Oriented IoT
 Purpose
 To prevent IoT from unknown attacks
 To offer suitable life cycle management
 Contributions and challenges
 3 special security mechanism protected by TEE (Trusted Execution Environment)
1. Occasional Network Reboot to recover from unknown attacks
 The IoT runs OS on memory only and reboots (re-installs) OS.
2. Periodical Memory Forensics to detect unknown attacks
 Assumption: AI-Edge IoT runs a few intended applications only.
 RO-IoT allows to run the whitelisted application only.
3. Life Cycle Management to prevent becoming cyber debris
 PKI certificates (CA, Server, and Client) are linked to the lifetimes (Device, Software, and
Service).
Example
Occasional > Periodical
42 hours 15seconds
=15sec *10,000

5. 5
Secure Rebooting
 Reboot (i.e., Re-Installation) is a suitable way to recover from unknown
attacks.
 Related works; CIDER[IEEE SPʼ19], Misery Graphs[IEEE TIFSʼ17], YOLO[SPIEʼ19],
TPM2.0 Authenticated Countdown Timer, etc.
 Challenges
1. Secure network boot
 The OS image is downloaded by HTTPS and verified by TEE.
The connection of HTTPS is terminated by TEE and securely downloaded in TEE.
 TEE has no mechanism to reboot an OS. So, the OS image is transferred to REE and rebooted.
 The reboot mechanism utilizes the Linuxʼs kexec.
 The download OS runs memory only, i.e., total reinstallation.
2. Secure autonomous rebooting
 watchdog timer protected by TEE.
In order to implement TEE and reboot mechanism easily, small Linux is used as a bootloader(detail in implementation).

6. 6
Secure Memory Forensics
 Assumption: IoT runs a few applications only.
 RO-IoT applies whitelisting security on
memory forensics protected by TEE.
 Memory forensics in TEE (TA-Forensics) has
DB for whitelisting apps and retrieves the
task_struct of Linux kernel.
 If unknown application is found, TA-
Forensics causes system rest.
 TA-Forensics sets the watchdog timer and
must be activated periodical to set again to
prevent system rest.
 If the TA-Forensics runs more than thresh
hold, it causes system rest occasionally.
System rest causes secure reboot.

7. 7
Secure Life Cycle Management
 RO-IoT assumes
 Life cycle of Device
 Life cycle of Software
 Life cycle of Service
 The life cycles are linked to PKI of HTTPS
(TLS) certificates (CA, Client, and Server).
 CA Pub Cert is included in TEE by Device
Supplier.
 Client Pub Cert is included in TEE by Software
Vendor.
 Server Pub Cert is managed by the server of
Service Provider.
 The certificates are verified in the TEE when
a HTTPS connection is established at secure
reboot. If a certificate is invalid, RO-IoT does
not boot the OS.
Device
Factory
Service
Provider
Fresh eMMC
Provisioning Server (Port 444)
EstablishTLS
with
provisioning
ServerCert
Download
Booting URL
& Client Cert
& PackageCert
Establish TLS
with
Download
Server Cert
& Client Cert
Download
ROMFS
License
Termination
Service
Termination
Device
Termination
Server Public Cert
Booting Server (Port 443)
SOKKey
Device
Supplier
Software
Vendor
Provisioning Server Private Key
Provisioning Server Public Cert
Client Private Key
Client Public Cert
Package Private Key
Package Public Key
DownloadURL
Secure Storage Encrypted
by Key inTA‐Boot
Ext4 on FirstLinux
Download Server PrivateKey
Download Server Public Cert
request
request
request
fip.bin
(Secure Storage AES Key,
ImageCache AES Key)
Provisioning URL
CA Private Key
CA Public Cert
ROMFS signed by
Package PrivateKey
fip.bin encrypted
by SOC Key
Build in TA‐Boot
Provisioning URL
CA PublicCert
Download URL
Client Public Cert
Client Private Key
Package Public Key
romfs encrypted by
Key inTA
Secure Storage Encrypted
by Key inTA‐Boot
Ext4 on FirstLinux
fip.bin encrypted
by SOC Key
Build in TA‐Boot
Provisioning URL
CA PublicCert
Download URL
Client Public Cert
Client Private Key
Package Public Key
Secure Storage Encrypted
by Key inTA‐Boot
Ext4 on FirstLinux
fip.bin encrypted
by SOC Key
Build in TA‐Boot
Provisioning URL
CA PublicCert
CA
Server Public Cert
Operation
Setup

8. 8
Implementation
 2 types of Linux
 First Linux: As a bootloader with kexec
 The bootloader supports OP-TEE. TA-Boot on OP-TEE
downloads the IoT OS image with HTTPS.
 TA-Forensics is launched on the first Linux because it
must be hidden from the second Linux.
 The downloaded image is moved to REE (Linux) to
boot it with kexec.
 Second Linux: As a IoT OS
 Applications are monitored by TA-Forensics.
 TA-Forensics is passive, and the activation must be
controlled by an application on the second Linux.
Activation Mechanism: TA-Forensics are
periodically activated because it causes
rebooting with watchdog timer if it is not reset.
Poweron
BL1: BootROM
SecureWorld NormalWorld
TA‐Boot
(BoringSSL, Libwebsocket)
TA‐Forensics
kexec
TA‐
Client1
eMMC
ROMFSfile
Secure
booting
Normal
operation
(live
memory
forensics)
Rebooting
Termination of service, or license, or IoT device
If a TLS certificate
fails.
Download
Server
TEE‐Supplicant
TA‐Forensics,
kernel,
dtb,
Initramfs.gz
(TA‐Client2)
signature
SecondLinux
TA‐Forensics
Invoked
by TA‐Client1
Survive after
kexec
memory
forensics
Invoked
by TA‐Client1
TLS
BL2:
Trusted Boot
Firmware
BL31:
Secure Monitor
BL32:
OP‐TEE
BL33:
First Linux
TA‐
Clinet2
TEE‐
Supplicant
IoT
Application
Connected
by TA‐Client2

9. 9
Implementation
 RO-IoT is implanted on HiKey board (Arm
Cortex-A, 2GB Memory).
 eMMC includes the bootloader (First Linux)
with OP-TEE image (TA-Boot).
 TA-Boot includes BoringSSL and LibWebSockets
for HTTPS.
 The bootloader has a mechanism to cache
an OS image. If the OS image is not
updated, the bootloader use the saved OS
image to eliminate the download time.
BL2: TrustedBoot
Firmware(29KB)
BL31: Secure
Monitor(33KB)
BL32: SecureOS
OP‐TEE(286KB)
BL33: First Linux
ROMFS(7,100KB)
Kernel(5,464KB)
dtb(37KB)
intramfs.gz (1,598KB)
intramfs.gz
ForNetwork
dhcp
netdate
ip
For OP‐TEE
TEE‐Supplicant (197KB)
TA‐Client1 (17KB)
TA‐Boot(1,173KB)
ForBoot
kexec
For Updatefib.bin
dd
SecureStorage
encrypted by key inTA
Download URL
Client Public Cert
Client Privatekey
ROM
Key in SOC
Run in normal world
Run in secure world
TA‐Boot
For HTTPProtocol
LibWebSockets
ForSecurity
BoringSSL
Keys
CA Pub Cert
Provisioning URL
AES Key for SecureStorage
AES Key for ImageCache
URL
URL of Provisioning Server
eMMC
fip.bin(7,590KB)
encrypted by key in SOC
First Linux FS(EXT4)
Imagecache
encrypted by key
inTA
BL1: BootROM

10. 10
Performance of Reboot (Reinstallation)
 Downloaded OS image
 Minimal 13,863KB
 initramfs.gz 8,637KB
 TA-Forensics 226KB
 Debian 69,120KB
 initramfs.gz 63,340KB
 TA-Forensics 781KB

11. 11
Performance of memory forensics on TEE
 Watchdog timer is set to cause within 30 seconds.
 The time reset is issued every15 seconds.
 The memory forensics must finish within 15 seconds (until next time rest is issued).
 We evaluated the memory forensics on TEE with 0, 100, and 200 extra
processes.

12. 12
Future Work
 Target applications of RO-IoT were AI Edge, which allowed short-time
suspension.
 Next target is mission critical applications (mobility and life support for
smart city).
 RO-IoT with partial OS update mechanism.
 RO-IoT with fault tolerant mechanism.

13. 13
Conclusions
 Return-Oriented IoT makes IoT device disposable with 3 security
mechanisms protected by TEE (Trusted Execution Environment).
1. Occasional Network Reboot replaces whole OS image on memory and recovers from
unknown attacks
2. Periodical Memory Forensics detects unknown attacks
3. Life Cycle Managements linked to PKI certificates prevents becoming cyber debris