第20回情報科学技術フォーラム（FIT2021）のトップカンファレンスセッション、ソフトウェアシステム(8/26（木）9:30-12:00)に発表した「Reboot-Oriented IoT: 廃棄可能なIoTデバイスにするためのTEE内ライフサイクル管理」のスライドです。元ネタはACSAC2021のReboot-Oriented IoT: Life Cycle Management in Trusted Execution Environment for Disposable IoT devices です。 採択過程でRejectの歴史やConditional Accpetの対処を話しました。

1. 1
Reboot-Oriented IoT:
廃棄可能なIoTデバイスにするための
TEE内ライフサイクル管理*
産業技術総合研究所
サイバーフィジカルセキュリティ研究センター
須崎有康
*Kuniyasu Suzaki, Akira Tsukamoto, Andy Green, and Mohammad Mannan, Reboot-
Oriented IoT: Life Cycle Management in Trusted Execution Environment for Disposable
IoT devices, Annual Computer Security Applications Conference (ACSAC) 2020
ACM Digital Library https://dl.acm.org/doi/10.1145/3427228.3427293
FIT2021トップコンファレンス 4‐2 ソフトウェアシステム

2. 2
本⽇の発表内容
 ACSACとはどんな会議︖
 ACSAC20で発表したRO-IoT(Reboot-Oriented IoT)とは
 既存のIoTセキュリティの問題点
 TEE (Trusted Execution Environment)による⾃律的なOS管理
 使われる技術︓Watchdog Timer, kexecによるネットワークブート, メモリフォレンジックによるプロセス監視、PKI
証明書によるライフサイクル管理
 採択までの経緯
 Rejectの歴史
 ACSAC20採択までの道のり
 まとめ

3. 3
ACSACとはどんな会議︖ 1/2
 Annual Computer Security Applications Conference (ACSAC)
 主催はApplied Computer Security Associates (ACSA)
 論⽂はACM Digital Libraryで公開される
 毎年12⽉頭に⾏われるセキュリティ会議
 アメリカの南部の都市で⾏われる。寒いから?
 5⽇間。最初の2⽇はWorkshopとTutorial。残りの３⽇が本会議。ポスターセッションあり。
 今まで参加した感想
 実⽤的な研究論⽂が多い。
 ⽇本から毎年1-2本の発表あり。

4. 4
ACSACとはどんな会議︖ 2/2
 Google Top 20からは落ちてしまった。
 Texas A&M UniversityのGuofei Gu先⽣によるランキング

5. 5
本⽇の発表内容
 ACSACとはどんな会議︖
 ACSAC20で発表したReboot-Oriented IoTとは
 既存のIoTセキュリティの問題点
 TEE (Trusted Execution Environment)による⾃律的なOS管理
 使われる技術︓Watchdog Timer, kexecによるネットワークブート, メモリフォレンジックによるプロセス監視、PKI
証明書によるライフサイクル管理
 採択までの経緯
 Rejectの歴史
 ACSAC20採択までの道のり
 まとめ

6. 6
既存のIoTのセキュリティの問題点
 IoTは今後スマートシティ、AI Edgeなどで地理的に分散され、管理者もいない状態で数が増
えること予想されている。
 管理はネットワーク経由のM2M: Machine to Machineが提唱されいるが、セキュリティ対策、
ソフトウェアの更新、ライフサイクル管理(廃棄管理)などが明確でない。
 M2Mでは管理者がいないので攻撃の判断が難しい場合やOSが乗っ取られて対処できない問題がある。
 ソフトウェアやデバイスがサポート対象外になる際の⼿続きが不明である。
 廃棄を明確にしないとサイバーデブリとして動き続ける。ゴミになるだけでなく、乗っ取られて攻撃の踏み台になる。
 デバイス側が⾃律的にリカバリする機能や機能停⽌が求められる。
 RO-IoT (Reboot Oriented IoT)で対処
 使われる技術︓TEE、Watchdog Timer、ネットワークブート、メモリフォレンジック（ホワイトリスト）、PKIベー
スライフサイクル管理

7. 7
TEE (Trusted Execution Environment）とは
 CPUが提供するOSとは独⽴した隔離実⾏環境
 SMMなど隔離実⾏環境はあるが、第三者が使える点が異なる。
 通常のOSが実⾏するNormal World (REE: Rich Execution Environment)に加えて、
クリティカルな処理が⾏えるSecure World を提供する。
 利⽤できるハードウェア
 Arm TrustZone, Intel SGX, AMD SEV
 本実装ではArm Cortex-AのTrustZoneを活⽤
参考資料
Trusted Execution Environmentによるシステムの堅牢化, 情報処理2020/06
https://ci.nii.ac.jp/naid/40022255769
Trusted Execution Environmentの実装とそれを支える技術,電子情報通信学会
基礎・境界ソサイエティ Fundamentals Review, 2020/10
https://www.jstage.jst.go.jp/article/essfr/14/2/14_107/_article/-char/ja/

8. 8
TEEに守られるWatchdog Timer
 乗っ取られた場合に確実に⾃律的にリカバリする機能
 Watchdog Timerを活⽤
 ハングアップなどで機能不全になった場合の備えて、⼀定時間でハードウェア割り込み(システムリセット)をかけ、
機能を戻す仕組み。
 機能が健全な場合は時間の延⻑をする。
 通常ではwatchdog timerはOSが管理しているが、OSの乗っ取りには対処できない。
 RO-IoTのアイデア
 TEEに守られるWatchdog TimerはOSが乗っ取られてもシステムリセットがかけられる。
 類似研究︓CIDER[IEEE S&P 19]はauthenticated watchdog timer (AWDT)として使うが、RO-IoTではラ
イフサイクル管理に使う。
 システムリセット後はネットワークブートでファイルシステムを含む全てを⼊れ替える。

9. 9
ネットワークブート
 カーネルやファイルシステムなどすべてのイメージをネットワークがダウンロードしてブートする。
 OSに対する攻撃はすべて対応。少なくともクリーンな状態に戻せる。
 IoTなのでファイルシステムは⼩さい。メモリ上で⼗分対応可能。
 問題点
1. ネットワークブートはPXEなどが⼀般的だが、これらではTEEを事前に設定できない。
2. TEEからノーマルワールドのOSをリブートことはできない。
 対処
1. Linuxから別のカーネルをブートできるkexecシステムコールを活⽤。Linuxの⼆重化。
 通常ブートの1段⽬LinuxでTEEの設定。
 Kexecによる2段⽬でIoT⽤Linuxをネットワークブート。
2. OSとは依存のTEE内のWatchdog Timerでシステムリセットすることでリブートする。(前のスライド)

10. 10
実⾏時の監視技術︓TEEからのメモリフォレンジック
 TEE内から登録されているプロセスのみが実⾏し
ていることを定期的に確認
 IoTではアプリが固定で少ないので対応が可能
 登録されていないプロセスがあればシステムリセット
 登録プロセスとして偽れても定期的にシステムリ
セットすることで未知の攻撃に対応
 メモリフォレンジックやシステムリセットの間隔は応
⽤に依存
 性能評価ではメモリフォレンジックを15秒毎に起こす。
 TEEが管理するWatchdog Timerによるシステムリセットはメモリフォレンジックが1万回実⾏(3⽇)されると発⽕。
 システムリセットが回避されないように30秒以内に時間をクリアするように設定。メモリフォレンジック毎にクリア。

11. 11
ライフサイクル管理
 RO-IoTではデバイス、ソフトウェア、サービスのライフサイク
ルを管理。
 ３つのライフサイクルをPKIベースの３つのTLS証明書と対
応。証明書の期限とサポートの期限がリンク。
 デバイスはルート証明書
 ソフトウェアはクライアント証明書
 サービスはサーバ証明書
 証明書の管理
 ルート証明書はDevice SupplierによってTEE内
 クライアント証明書はSoftware VendorによってTEE内
 サーバ証明書はService Providerによってserverで管理
 証明書はHTTPSでネットワークブートする度に検証
され、検証が失敗（失効）すれば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

12. 12
実装
 RO-IoTはHiKeyボード (Arm Cortex-A, 2GB
Memory)に実装。
 eMMCストレージには First Linux(ブートローダとして
働く)とTEE内のソフトウェア (Trusted OSのOP-
TEE、TA-Boot)がある。
 右図のグレー部分は暗号化されているストレージ。
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

13. 13
ダウンロードサイズと時間
 ダウンロードされるOSイメージサイズ
 Minimal 13,863KB
 initramfs.gz 8,637KB
 TA-Forensics 226KB
 Debian 69,120KB
 initramfs.gz 63,340KB
 TA-Forensics 781KB
 イメージが更新されていない場合、
キャッシュ機能があり、これを使えば
20秒程度で再起動。
 全てをダウンロードしても1分程度。

14. 14
本⽇の発表内容
 ACSACとはどんな会議︖
 ACSAC20で発表したReboot-Oriented IoTとは
 既存のIoTセキュリティの問題点
 TEE (Trusted Execution Environment)による⾃律的なOS管理
 使われる技術︓Watchdog Timer, kexecによるネットワークブート, メモリフォレンジックによるプロセス監視、PKI
証明書によるライフサイクル管理
 採択までの経緯
 Rejectの歴史
 ACSAC20採択までの道のり
 まとめ

15. 15
投稿経緯 (Rejectの歴史)
 ACSAC 2019 (Tier 2) Submit 2019/6/16
 Reject 2019/8/24 Weak reject + Weak reject + Weak Accept
 NDSS 2020 (Tier 1) Submit 2019/9/13
 Early Reject 2019/11/2 Reject + Leaning towards reject + Leaning towards reject
 AsiaCCS 2020 (Tier 2) Submit 2019/12/9
 Reject 2020/2/16 Weak reject + Weak Accept + Weak reject + Weak reject
 SysTor 2020 (OS系の会議) Submit 2020/3/4
 Reject 2020/6/9 Weak reject + Weak accept + Weak accept + Weak reject
 ACSAC 2020 (Tier 2) Submit 2020/6/17 再挑戦?

16. 16
ASCAS2020投稿
 実はもうあきらめムードだった。
 別のランクの低い会議あり、そちらにするか考えていた。
 ギリギリ、Early Rejectなら投稿が間に合いそうだった。
 投稿時に共著者に送ったメール。
 ACSAC 2020 Submit 2020/6/17
 Conditional Accept 2020/8/17 Weak reject + Weak reject + Accept
Dear,
I submit the final version of ACSAC 2020 paper.
My paper number is 312.
If the paper will be rejected, I prefer the early reject. :-)
-------
Kuniyasu Suzaki

17. 17
Conditional Acceptの対応
 修正版を9/10までに提出する必要あり。そこでRejectされるかもしれない︕
 修正を相談できるShepherdが付く。
 作戦会議
 誰がReviewerか︖Program Committeeから推測。
 3名中１名は特定(Acceptをつけた⼈)、1名は推定可能、1名は不明。
 上記の２名に合う修正。
 以前の採択者にメールで問い合わせ。
 幾つかのコメントもらう。Conditional ではないので詳細が分からず。
 Artifactsを出した⽅が通りやすいか相談。
 Artifactsとは論⽂で使ったソースコードを検証ために公開すること。これがConditional Acceptでも同じように依
頼が来た。
 採否には関係ないとして、論⽂修正に集中した。

18. 18
Shepherdとのやりとり
 Conditional accept通知から最終版提出まで(4回PDFの修正)
 2020/8/18 最初のコンタクト。以後レビューアのコメントに従って修正。
 １回⽬PDF提出 9/5
 Shepherdからのコメント︓消費電⼒や物理的な廃棄可能性の参考⽂献が適切でない。多分この辺にこだわる査
読者がいた。以後、メインのセキュリティではない部分の修正が続く。
 ２回⽬PDF提出 9/6
 ITU‘s E-Wasteの事例を追加。 Shepherdからのコメント︓RO-IoTが扱うデバイス能⼒について記述の強化。
 ３回⽬PDF提出 9/8
 適⽤できるデバイスの範囲の記述追加。 Shepherdからのコメント︓追加無し。
 ４回⽬PDF提出 9/9
 細かい修正をして最終版。これで勝負。
 9/15に正式Accept

19. 19
まとめ
 ACSACの説明
 ACSAC20で採択されたRO-IoT
 OSとは独⽴したTEE内に重要機能を持たせたIoTライフサイクル管理技術
 Watchdog Timerによるシステムリセット管理。これによりKexecを活⽤したネットワークブートでOSの⼊れ替え。
 メモリフォレンジックによるホワイトリストアプリ監視
 ライフサイクル管理にTLSの証明書の活⽤
 採択までの苦労話。対応が参考なれば幸いです。
オリジナル論文
• Kuniyasu Suzaki, Akira Tsukamoto, Andy Green, and Mohammad Mannan, Reboot-Oriented IoT: Life Cycle
Management in Trusted Execution Environment for Disposable IoT devices, Annual Computer Security
Applications Conference (ACSAC) 2020,
• ACM Digital Library https://dl.acm.org/doi/10.1145/3427228.3427293
参考資料
• Trusted Execution Environmentによるシステムの堅牢化, 情報処理2020/06 https://ci.nii.ac.jp/naid/40022255769
• Trusted Execution Environmentの実装とそれを支える技術,電子情報通信学会基礎・境界ソサイエティ Fundamentals Review,
2020/10 https://www.jstage.jst.go.jp/article/essfr/14/2/14_107/_article/-char/ja/