Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ARM TrustZone入門 / ARM TrustZone intro
Search
Osuke
August 08, 2020
Technology
10k
25
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ARM TrustZone入門 / ARM TrustZone intro
Osuke
August 08, 2020
More Decks by Osuke
See All by Osuke
特許データを使ったマルチモーダルAIの検証事例@LLMProd#4
osuke
0
340
dbtを中心に据えた データ分析とプロダクト開発
osuke
1
1.2k
LayerX Privacy Tech事業部紹介 Tech編
osuke
2
260
(SCIS2021) Anonify: プライバシーを保護した 検証可能な状態遷移モジュール
osuke
1
460
Rustで実装された AWS Nitro Enclaves CLIを読む
osuke
0
430
Rustのパフォーマンスに関するTips
osuke
4
4.9k
Anonify
osuke
3
1.2k
Rustのasync/awaitとスケジューラの話 / rust-async-await
osuke
9
4.2k
Privacy on Blockchain
osuke
1
1.3k
Other Decks in Technology
See All in Technology
それでも、技術なブログを書く理由 #kichijojipm / Why I Still Write Tech Blogs Even Now
shinkufencer
0
320
Network Firewallやっていき!
news_it_enj
0
260
AI時代におけるエンジニアの新たな役割──FDEとクオリアの探求/登壇資料(戸井田 裕貴)
hacobu
PRO
0
310
Webアプリ認証の全体像 / The Big Picture of Web App Authentication
kitano_yuichi
1
420
どこまでAIに任せるか 〜確率論と決定論の境界決定〜
shukob
0
440
非定型なドキュメントを効率よくリファクタする 〜えぇ!?仕様書27本の移行が1日で終わったって!?〜
subroh0508
2
610
「休む」重要さ
smt7174
6
1.6k
Oracle Exadata Database Service on Cloud@Customer X11M (ExaDB-C@C) サービス概要
oracle4engineer
PRO
2
8.5k
AI時代におけるテストの基礎の再定義 / Rethinking the Fundamentals of Testing in the AI Era
mineo_matsuya
13
4.3k
AI x 開発生産性を取り巻く予算戦略と投資対効果
i35_267
7
2.8k
AI時代の開発生産性を捉え直す — 経営と現場をつなぐ「開発組織のオブザーバビリティ」— / AI Dev Ex Conference 2026
tkyowa
1
1.3k
Devsumi 2026 Summer 人もAIも使える共通基盤を事業の加速装置にする~デザインシステム運用に学ぶ組織レバレッジ~ 渡辺 凌央
legalontechnologies
PRO
1
280
Featured
See All Featured
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
260
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Music & Morning Musume
bryan
47
7.3k
Heart Work Chapter 1 - Part 1
lfama
PRO
8
36k
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
64
56k
The Invisible Side of Design
smashingmag
301
52k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
560
Information Architects: The Missing Link in Design Systems
soysaucechin
0
1k
GitHub's CSS Performance
jonrohan
1033
470k
Applied NLP in the Age of Generative AI
inesmontani
PRO
4
2.4k
A designer walks into a library…
pauljervisheath
211
24k
Designing for humans not robots
tammielis
254
26k
Transcript
1 Arm TrustZone入門 Osuke Sudo 2020/08/08 @ARM入門勉強会
2 @zoom_zoomzo Osuke 須藤 欧佑 LayerX ソフトウェアエンジニア (LayerX Labs) 暗号技術・TEEを用いたデータの
プライバシー保護・改ざん耐性手法の研究開発
3 アジェンダ 1. Hardware Isolation 2. TrustZone a. アーキテクチャ/例外レベル b.
MMU/SoC/Secure Boot c. TEE実装/脆弱性
4 ゴール: Arm TrustZoneとはなにか・その仕組みの概要を理解する Disclaimer: TrustZoneに関する内容および使用画像は以下のレファレンスを参考 • Programmer’s Guide for
Armv8-A ◦ https://developer.arm.com/documentation/den0024/a/ • TrustZone for Armv8-A ◦ https://developer.arm.com/architectures/learn-the-architecture/trustzone-for-armv8-a アジェンダ
5 Hardware Isolation
6 • Secure Hardware:耐タンパ性を備える機密データの記録や暗号処理 • 機密性の高いデータの処理をハードウェアのセキュリティ機構で防ぐ ◦ ソフトウェアベースでは防げない攻撃を物理的に保護 • 例:
◦ 過酷なセキュリティ脅威下におけるIoTデバイスの保護 ◦ 認証器における鍵の保護 Secure Hardwares HSM TPM TEE T2 chip Titan Yubikey SmartCard SIM
7 • CPUにより論理的にメモリを分離 • メリット ◦ アプリケーション開発者がSecure World(注:Trusted表記揺れ)にソフトウェアを実装可能 ◦ 汎用CPU上処理されるので高速
• デメリット: ◦ CPUによる論理的な分離なのでサイドチャネル攻撃などが課題 TEE (Trusted Execution Environment) とは
8 TEEの種類 Arm TrustZone Intel SGX RISC-V Keystone 公開年 2003年
(Armv6K) 2015年 (Intel Skylake) 2018年 (version 0.1) 利用形態 サーバー クラウド (Azure, IBM Cloud, Alibaba Cloud) PC(Linux, Windows) スマートフォン ゲームデバイス IoT IoT 概要 モバイルデバイス型の TEEを代表するCPU サーバーやクラウドで 代表的に利用 試験段階 RISC-VのPMPを活用 したTEE AMD SEV 2016年 Google Cloud (Confidential VMs) ハードウェア由来の鍵で 仮想マシンのメモリを暗 号化
9 TrustZone
10 Arm TrustZoneとは • MMUなどでアクセスコントロールを行い、ハードウェアリソースをNormal WorldとSecure World (Trusted World) に分離
• Normal WorldはSecure Worldのリソースに不正アクセスできないようにコントロール • Secure Servicesで機密性の高い処理を行う(例:FIDO2における署名)
11 TrustZone for Cortex-A vs Cortex-M • Cortex-A:レイヤーアーキテクチャ ◦ Secure
Monitorハンドラが唯一のエントリーポイント • Cortex-M:ハンドラ/スレッドモード ◦ 低レイテンシの状態遷移を重視
12 TrustZone上の代表的なTEE Trusty OP-TEE デバイ ス ベンダ Google Linaro QTEE
Pixel, Nexus Qualcomm TEEGRIS Galaxy S10~ Samsung Trusted Core Huawei Huawei open source commercial
13 アーキテクチャ/例外レベル
14 Exception levels App Exception Level x86 Hypervisor Trusted App
Trusted OS EL0 EL1 EL2 Rich OS ring3 ring0 ring-1 App App Normal Secure Rich OS Trusted App EL3 ME/SMM Secure Monitor ②NS bit更新 ③Normalレジスタ状態の記録 ④Secureレジスタ状態の復元 ① SMC ⑤ ERET
15 例外:①SMC • 例外でより権限の強い例外レベルの処理の移譲 • 非同期例外 ◦ 命令実行により発生しない例外 ▪ IRQ
(normal priority interrupt) • Normal状態への割り込み ▪ FIQ (fast interrupt) • Secure状態への割り込み ▪ SError (System Error) • 同期例外 ◦ 命令実行により発生する例外 ▪ MMUアボート(permission failureなど) ▪ Supervisor Call(SVC命令):EL0 → EL1 ▪ Hypervisor Call(HVC命令):EL1 → EL2 ▪ Secure monitor Call(SMC命令):EL1/EL2 → EL3
16 例外ベクタテーブル • 例外ハンドラの決定 • アドレスではなく実行命令を持つ • それぞれのエントリは16命令長 • 例:
◦ AArch64でSMC命令を実行 → VBAR_EL3 + 0x400を実行
17 例外に関わる代表的なレジスタ • SCR_EL3 (Secure Configuration Register) ◦ どの例外をEL3にルーティングすべきか指定 ◦
NS Bitの指定 • SPSR_ELn (Saved Program Status Register) ◦ 例外処理後に戻る実行状態と例外レベルを保持 (PSTATE) • ELR_ELn (Exception Link Register) ◦ 例外処理後に戻るアドレスを保持 • ESR_ELn (Exception Syndrome Register) ◦ 例外理由 • VBAR_ELn (Vector Base Address Register) ◦ それぞれの例外レベルの例外ベクタテーブルのベース仮想アドレスを指定
18 ② NS Bit • SCR_EL3 (Secure Configuration Register) ◦
SCR_EL3.NS == 1:Normal ◦ SCR_EL3.NS == 0:Secure ◦ EL3のみ変更可能
19 Exception levels App Exception Level x86 Hypervisor Trusted App
Trusted OS EL0 EL1 EL2 Rich OS ring3 ring0 ring-1 App App Normal Secure Rich OS Trusted App EL3 ME/SMM Secure Monitor ②NS bit更新 ③Normalレジスタ状態の記録 ④Secureレジスタ状態の復元 ① SMC ⑤ ERET
20 MMU / SoC / Secure Boot
21 MMU • 変換テーブルのそれぞれのエントリでメモリ属性を指定 ◦ AF: Access Flag ▪ アクセス可能
-> 1 ◦ NS: Security Bit ▪ Normal -> 1 ◦ SH: Shareable Attribute ▪ マルチコアでのシェア ◦ ...
22 MMU • アドレス変換 ◦ エントリのNS bit(メモリ属性)が仮想メモリ のページを Normal/Secure どちらの物理メモ
リ空間にマッピングするかコントロール NS=1 NS=0
23 SoC
24 Secure Boot • Secure MonitorやSecure OSは改ざんされていないのか? • OS起動時にローダがマシンにとって信頼のある署名がされている場合のみローダを実行 ◦
保護された秘密鍵をRoot of Trustとして • 改ざんされたSecure Monitor/OSイメージの起動などを防ぐ Root of Trust TPMなど Secure Monitor Secure OS Chain of Trust 署名検証 署名検証
25 ARM Trusted Firmware • ATF (ARM Trusted Firmware):OS を含むソフトウェアを安全に起動す
るための機能群 • Chain of Trustにより以下のステー ジ • BL1: AP Trusted ROM • BL2: Trusted Boot Firmware • BL31: Secure Monitor • BL32: Trusted OS • BL33: Normal OS https://www.slideshare.net/linaroorg/trusted-firmware-deepdivev10
26 TEE実装/脆弱性
27 OP-TEE https://www.linaro.org/blog/op-tee-open-source-security-mass-market/
28 TEE Client/Internal Core API TEE Client API • TEEC_InitializeContext(...)
• TEEC_OpenSession(...) • TEEC_InvokeCommand(...) • TEEC_CloseSession(...) • TEEC_FinalizeContext(...) TEE Internal Core API • TA_CreateEntryPoint(...) • TA_OpenSessionEntryPoint(...) • TA_InvokeCommandEntryPoint(...) • TA_CloseSessionEntryPoint(...) • TA_DestroyEntryPoint(...) Global PlatformによるTEEの標準化API
29 TrustZoneの脆弱性 • SoK: Understanding the Prevailing Security Vulnerabilities in
TrustZone-assisted TEE Systems ◦ https://www.cs.purdue.edu/homes/pfonseca/papers/sp2020-tees.pdf ◦ IEEE S&P ‘20 • 2013~2018年に公表されたCVEから124個の脆弱性を分析 ◦ Architectual:必要な機能の欠如など(例:ASLRによるメモリ保護機能の欠如) ◦ Implementation:TrustZoneのソフトウェア実装(例:バッファオーバーフロー) ◦ Hardware:ハードウェア由来の振る舞い(例:サイドチャネル)
30 まとめ • TrustZoneはNormal WorldとSecure Worldにリソースが論理的に分離され ていて、Normal WorldはSecure Worldのリソースに不正にアクセスするこ とはできない
• NS bitに基づいてMMUがコントロール • ARM Trusted Firmwareによるシステムソフトウェアの安全な起動