RISC-Vのセキュリティ技術(TEE, Root of Trust, Remote Attestation)

1
RISC-Vのセキュリティ技術
(TEE, Root of Trust, Remote Attestation)
須崎有康(Kuniyasu Suzaki)
1,2)
1) セキュアオープンアーキテクチャ・エッジ基盤技術研究組合 (TRASIO)
2) 国立研究開発法人産業技術総合研究所 (AIST)
JASA 組込みシステム技術協会
第6回 RISC-V Webセミナー
2022/May/25

2
Self Introduction (Kuniyasu Suzaki,須崎有康)
 TRASIO受託NEDOプロジェクト「セキュアオープンアーキテ
クチャ基盤技術とそのＡＩエッジ応用研究開発 FY2018-
2022」でRISC-VベースのTEEの研究
 本講演はこちらの成果を中心に話します
 今までの講演
 RISC-V Day Tokyo 2021 Spring「Trusted RV: セキュアコプロ
セッサを有する64bit RISC-V TEEとその上のソフトウェア」
 RISC-V Security Forum 2021 “Trusted RV: Trusted
Execution Environment, Secure Coprocessor, and their
Programming”
 Reference 参考資料
 Trusted Execution Environmentによるシステムの堅牢化, 情報処理20/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/

3
発表内容
 RISC-V とTEE
 TEE (Trusted Execution Environment) の問題点
1. Root of Trust
2. プログラミング環境
3. TA(Trusted Application) 管理
4. Remote Attestation
 TRASIOで開発しているセキュリティ技術
 ハードウェア
1. Trusted-RV Platform (64-bit RISC-V + 32-bit RISC-V Secure CoProcessor)
 ソフトウェア
2. TEE プログラミング環境 (GlobalPlatform TEE Internal API)
3. TA (Trusted Application) 管理 (TEEP: Trusted Execution Environment Provisioning)
 将来展望

4
本日覚えていた頂きたいこと(take away point)
1. RISC-Vにはメモリを隔離するPMP(Physical Memory Protection)の機能がある。
PMPを使ってTEE(Trusted Execution Environment)を実現している。
2. TEEは一時的な隔離実行環境なので、長期的な鍵保存には Root of Trustハードウェア
機能が必要。
3. ハードウェアが健全であること、TEE内のアプリが意図したもの（改ざんされていない）ことなど、
健全性をリモートで確認するためのRemote Attestationが必要。

5
RISC-Vとは
 RISC-V International が管理するOpen ISA(Instruction Set Architecture)
 仕様自体がフリーなため、多くの実装あり (Chisel, Verilog, SystemVerilog, VHDL)
 ETH: PULP(Parallel Ultra Low Power)(Swiss)
 MIT: Sanctum, MI-6,Carbon Nano-Tube RISC-V
 IIT-Madras: SHAKTI (India)
 U-Tokyo: RSD (32-bit Out-of-Order, superscalar) (Japan)
 UC Berkeley/SiFive: Rocket(In order)/Boom(Out of Order)
 Esperanto: ET-Maxion, ET-Minion
 Western Digital: SweRV (Controller of SSD&HDD)
 NVIDIA: NVRISCV
 Andes: AndesCore (Taiwan)
 Alibaba(Pingtouge):XuanTie 910 (2.5GHz 16 Core) (China)
 SyntaCore: SCR Family (Russia)
 CloudBare: BM, BR, BI Series (Russia)
Academia
Industry
幾つかはOpen Source
自社製品で活用
発祥元。リファレンス
として多く使われる

6
RISC-V Securityのスコープ
 Security HCより
 https://github.com/riscv-admin/security/blob/main/topics/RiscV%20security%20direction%20Nov%202021.pptx
 RISC-V Summit2021のArchitecture Design for Security: Do’s and Don’ts が詳しい。
 https://www.youtube.com/watch?v=sQyrxvswY38&ab_channel=RISC-VInternational
命令セットアーキテクチャの
関係度合いで露分け
本日の対象

7
RISC-V InternationalのTEEの立ち位置
 Technical Working Groups
 https://riscv.org/community/directory-of-working-groups/ より
TEE TGは
Security HC
の一部

8
TEEとは (1/2)
 ハードウェアが提供する隔離実行環境HIEE(Hardware-
assisted Isolated Execution Environments)の一つ
 HIEEにはBIOSが使うSMMや別チップのIntel ME, TPMがある。
 TEEは第三者がプログラミング可能であることを特徴とする。
 TEEはCPUの状態を二つに分ける
 ノーマルワールド (i.e., REE: Rich Execution Environment)
 通常のOS(Linux, Windows)が実行される
 セキュアワールド(i.e., TEE: Trusted Execution Environment)
 OSやハイパーバイザーなどの脆弱性とは無縁の環境。
 クリティカルな処理を行う。
この図はあくまでTEEの一例

9
TEEとは(2/2)
 特徴：
 （極端に言えば）一時的に隔離実行されるのみ。
 長期的な鍵保存は別の手段が必要。
 Root of Trustには安全に鍵・証明書を保存する耐タンパハードウェアが必要
 これを信頼の基点に外部からの健全性の検証（Remote Attestation）が行われる
 利用できるハードウェア
 ARM TrustZone (スマホ)
 Intel SGX (PC,サーバ)
 RISC-V は多くの実装あり。
この図はあくまでTEEの一例
（Arm TrustZoneが一番近い）

10
TEEの応用
 機密情報処理
 鍵管理
 AndroidのKeyMaster
 DRM処理
 スマホのWidevine(Google)
 WindowsのUltra HD Blu-rayビューア
 個人情報管理
 指紋認証処理
 FIDO認証
 コード・データの隠蔽
 機械学習の重み付けデータ
 プライバシー保護
 遺伝子解析
• メモリ消費が少ない
• スマートフォン
• Arm TrustZone向き
• メモリ消費が大きい
• サーバ・クラウド
• Intel SGX、AMD SEV 向き
• Confidential Computingの
ターゲットはこちら。
• RISC-V?
スマホでTEEが普及
したキラーアプリ
キラーアプリ候補？
キラーアプリになれなかった
キラーアプリ候補？

11
RISC-V TEE
 RISC-VでのTEE 実装
 Sanctum [MIT,USENIX Sec’16]
 TIMBER-V [グラーツ工科大学, NDSS’19]
 MI6 [MIT,MICRO’19]
 Keystone [UC Berkeley, EuroSys’20]
 HECTOR-V [グラーツ工科大学, arXiv’21]
 uTango [arXiv’21, ミーニョ大学]
 Cure [ダルムシュタット工科大学,USENIX Sec'21]
 MultiZone [HexFive]
多くはハードウェアの拡張を伴う。KeystoneとMultiZoneはRISC-Vが標準仕様にあるPMP (Physical Memory
Protection)を使い、ハードウェア拡張なし。
TRASIOではKeystoneをベースに開発
Academia
Industry

12
RISC-V TEE ”Keystone”
 UC Berkeleyで開発しているTEE
 RISC-Vの開発メンバーが率いている (Krste Asanović先生）
 RISC-Vの特権命令仕様書で定義のある PMP(Physical Memory Protection)を活用
 CCC: Confidential Computing Consortiumでも注目されている

13
RISC-VのPMP(Physical Memory Protection)
 物理メモリにアクセス制限を掛ける仕組み
 領域を区切って権限があるもののみアクセスできる。動的に指定できる。
 U mode, S modeなどの権限に直行した制御。PMPの領域に対して各modeのソフトが作られる。
 RISC-V CPU 内に制御レジスタが最大N=16(最新のPriv1.12仕
様では64) 本あり、メモリの範囲とそれに対するアクセス制限を定義する
 番号で優先度がある。0:highest 、N:lowest
 0 (highest) はSecure Monitor、N (lowest) は Linux、残りが
TEE(Enclave)に使われる。
PMP-N
0xFFFF
0x0000
PMP0
PMP-N
PMP0 PMP1 PMP2
Secure Monitor Linux
Enclave 1 Enclave 2
初期状態
TEE実行
虫食いにできる。
Linuxはアクセスできなくなる。
pmpcfg0 pmpaddr0
pmpcfg1 pmpaddr1
pmpcfg2 pmpaddr2
Pmpcfg-N Pmpaddr-N
Higher
Priority
PMP Registers

14
pmpcfgレジスタとpmpaddrレジスタ
 pmpcfgレジスタ
 コンフィグ指定
 pmpaddrレジスタ
 レンジ指定
The RISC-V Instruction Set Manual
Volume II: Privileged Architecture
Document Version 20211203 より
Permission
eXecute, Write, Read
(1:Allow, 2: Deny)
Mode
Lock, Unlock
pmpaddlのコンフィグ(4byte単位、他)
先頭アドレス
領域

15
通常のRISC-V
Linux
OS
Normal
App2 U mode
S mode
M mode
RV64GC
Memory for AppCore
Rocket (4 cores)
Normal
App1
ROM
 Rocket コアでLinuxの実行を想定
 正確には割り込みがM modeに落ちるの
で対処が必要だが省略。

16
通常のRISC-VでのKeystone
Enclave
Runtime
Trusted
App1
TEE
Linux
OS
Normal
App2
REE
SM (Security Monitor)
U mode
S mode
M mode
RV64GC
Memory for AppCore
Normal
App1
Enclave
Enclave
Enclave
Runtime
Trusted
App2
ROM
 ハードウェアの変更はない
 PMPによるメモリ保護
 1つ(最高特権)はSecure Monitorが
M modeで利用。
 1つ(最下位特権)はREEが使い、Linux
が起動
 図中では２つのTEE (Enclave)が実行
Rocket (4 cores)

17
RISC-V Keystone
 Keystoneを有効にした場合の起動とPMPの動作

18
TEE Task Groupの活動 (PMPの開発方向)
 PMP (Physical Memory Protection)の拡張
 PMPレジスタとセキュリティ設定機能を拡張する。(最近のPriv仕様1.12でレジスタが16から64に拡張)
 RISC-Vの特権命令仕様にもかかわるのでその提案。
 sPMPの提案
 既存のPMPはマシンモードでS+U modeを分割したが、S modeのOSがプロセス単位のTEEができるように
なる拡張
U
S
M Security Monitor
(PMP Management)
OS OS OS
U
S
M Security Monitor
(PMP Manage)
OS OS
OS
(sPMP Manage)

19
RISC-V PMPと類似技術
 Arm MPU: Memory Protection Unit
 A Survey on RISC-V Security: Hardware and Architecture [arXiv21] https://arxiv.org/abs/2107.04175 より
 RISC-Vでは32/64でPMPががあるが、ArmはCortex-Mのみ？

20
TEEの問題点 (Root of Trust) 1/4
 TEE は一時的な隔離実行環境で長期的な鍵保存をするRoot of Trustになれない
 Root of Trust は基本的に耐タンパーなセキュアコプロセッサ
 Remote Attestation は Root of Trust に基づかないと信頼できない
 Root of Trustの例
 Intel の Intel ME(Management Engine). Intel Quark x86-based (32bit)
 AMD の PSP(Platform Security Processor). Arm Cortex-A5 (32bit)
 Arm TrustZone needs an extra IP
 CryptCell(Discretix -> Arm) ● CryptoManager (Rambus)
 Apple M2
 RISC-V でも IPがある
 Rambus RISC-V CryptoManager ● Silex Insight Secure Root of Trust
 OpenTitan (Open Source)
多くが商用で詳細不明。
たまに脆弱性が見つかり、ニュースになる

21
TEEの問題点 (プログラミング) 2/4
 TEEの多くは独自のSDKでプログラムを要求する
 Intel SGX
 Intel SGX SDK
 Open Enclave (Microsoft)
 Asylo (Google)
 AMD SEV
 Asylo (Google)
 Enarx (Redhat)
 Arm Cortex-A TrustZone
 Open Enclave (Microsoft)
 GlobalPlatform (GP) TEE Internal API
 RISC-V Keystone
 Keystone SKD
ソースコードレベルで互換性が無く、
異なるCPUでは使うことが出来ない。

22
TEEの問題点 (アプリの管理) 3/4
 TEEで実行されるTA(Trusted Application)は機密処理を行うが、安全にインストール、更
新、削除されているのか？
 第三者が作ったTA (例：DRM、銀行アプリ)が想定されるため、実行の安全性を保障しなければならない。
 プラットフォームからの視点 (TEE エッジデバイス)
TA は信頼できるものなのか? ダウンロードサーバは信頼できるのか?
 TAからの視点
プラットホームは信頼できるのか (改ざんやマルウェアはないっていないのか)?
TA の管理は安全に行わなければならないが、CPU毎に管理手順が異なる。

23
TEEの問題点 (Remote Attestation) 4/4
 安全な管理のためにはTAおよびプラットホームの健全性を確認しなければならい。 (正規の
TA？正規のプラットホーム？)
 Remote AttestationはTAやプラットフォームの健全性を確認する技術
 問題3で述べた管理の基本技術
Remote はプラットフォーム内の鍵を使うが信頼できるか？
（つまり、Root of Trustで守られているか？）

24
TRASIOが開発しているセキュリティ技術
2. TEEのプログラミング環境: GlobalPlatform TEE Internal API
3. TA管理フレームワーク: TEEP(Trusted Execution Environment Provisioning)

25
Trusted-RV Platformとは
 「KeystoneはTEEであり、一時的な隔離実行のみの提供」の問題に対処
 長期的な機密情報を管理できるセキュアコプロセッサ(RISC-V 32bit)をRISC-V 64bitにつ
けたTrusted RVを開発
 鍵管理ばかりでなく、Secure BootやRemote Attestationの管理も行う。

26
通常のRISC-VでのKeystone
Enclave
Runtime
Trusted
App1
TEE
Linux
OS
Normal
App2
REE
U mode
S mode
M mode
RV64GC
Memory for AppCore
Normal
App1
Enclave
Enclave
Enclave
Runtime
Trusted
App2
ROM
 ハードウェアの変更はない
 PMPによるメモリ保護
 1つ(最高特権)はSecure Monitorが
M modeで利用。
 1つ(最下位特権)はREEが使い、Linux
が起動
 図中では２つのTEE (Enclave)が実行
Rocket (4 cores)

27
Enclave
Runtime
Trusted
App1
TEE
Linux
OS
Normal
App2
REE
U mode
S mode
M mode
Zephyr
RV64GC RV32IM
Memory for AppCore Memory for Secure
Unit
AppCore (4 cores)
Shared Memory
Secure
App1
Secure
App2
Normal
App1
M mode
Secure Unit (1 core)
Enclave
Enclave
Interrupt
Enclave
Runtime
Trusted
App2
Trusted RV
ROM ROM
SU (Secure Unit)の役割
 鍵管理・証明書管理
 セキュアブート・リモートアテステー
ション管理
TRV (Trusted RISC-V)でのKeystone

28
TRASIOのTRV実装
Xilinx VC707
board
FPGA(VX485T)
AppCore
(RV64GC)
4cores
SecureUnit
(RV32IM)
1core
PCIe
for AppCore
USB Extension
+
USB Giga Ether
Pmod
Extension
(Original)
SPI
Flash
Real
Time
Clock
UART
Compact
Flash
JTAG Adapter
64bit RISC-V
Linux on REE
Keystone on TEE
32bit RISC-V
Zephyr

29
SUを使うソフトウェア構成
 SUとの通信は制限されている。TA経由のみ。
 (Normal App) -> (Secure Monitor) -> (Trusted App) -> (Secure Monitor) -> (Zephyr) -> (Secure App)
 長期的な機密情報(鍵・証明書)や機密処理の漏洩を防ぐ。
Enclave
Runtime
Trusted
App1
TEE
Linux
OS
Normal
App2
REE
U mode
S mode
M mode
Zephyr
AppCore (4 cores)
Secure
App1
Secure
App2
Normal
App1
M mode
Secure Unit (1 core)
Enclave Enclave
Runtime
Trusted
App2
Trusted RV
Enclave

30
TEEとSecure CoProcessorのレイヤー構成(セキュリティレベル)
REE only
• No isolated environment
• No hardware tamper-proof
• Critical data and processing are not protected
REE + Secure CoProcessor
• No isolated environment
• Critical processing is not protected
REE + TEE
• No hardware tamper-proof
• Critical data is not protected
REE + TEE + Secure CoProcessor
• The order is important
• REE -> TEE -> Secure CoProcessor
0 layer
1 layer
2 layers
 同様のレイヤー構成がArm TrustZoneでも提案されている。
 Intel SGXではこの構成が取れない。(Ring3のみで直接デバイスにアクセスできないため)

31
TEEとRoot of Trustの構成例(FIDO Authenticator)
 Realizing FIDO Authentication Solutions with
GlobalPlatform Technologies, 2018
 https://globalplatform.org/wp-content/uploads/2018/04/White-Paper-
Technical-FIDO-Auth-using-GlobalPlatform-Jan2018.pdf
FIDO Authenticatorの実装パターン
① REE直接
② REE+SE(RoT)
③ REE+TEE
④ REE+TEE+SE
① ②
③ ④

32
RISC-V Secure CoProcessor比較 *this table is not complete.
Google Open Titan Rambus RISC-V CryptoManager
(RT-6*0, RT-7*0)
Silex Insight eSecure
(BA470)
Trusted RV
Secure Unit
Core Ibex
(RV32IMC/EMC)
M/U Mode
Custom
(RV32IMC)
M/S/U Mode
Andes N22
(RV32IMAC/EMAC)
M or M/U mode
Custom
(RV32IM)
M mode
OS Tock OS Zephyr --- Zephyr
Comm to Main SPI GPIO/SPI --- GPIO
Shared Memory
Accelerator AES,SHA AES, SHA AES, SHA Not yet ***
Peripherals Timer, RNG Timer, RNG RNG Timer, RNG, Flash
Anti-tampering Yes? Yes Yes Not yet
Target Key Management,
Secure Boot, OTA
Key Management,
Secure Boot, OTA, User App
Key Management,
Secure Boot, OTA
Key Management,
Secure Boot, OTA
Misc. FIPS 140-2 Level 2 FIPS 140 2 level 3
PUF for Unique Key
Design with TEE
(Keystone)

33

34
TEEのプログラム: GlobalPlatform TEE Internal API
 GP TEE Internal APIは多くのスマホで使われている
 kinibi (Trustonic)
 17億台のデバイスで使われている [USENIX Sec20,PARTEMU]
 QSEE (Qualcomm)
 2019年時点の60% のAndroid スマホで使われている [USENIX Sec20,PARTEMU]
 OP-TEE(Linaro)
 Open-source 実装。 We have developed some applications and want to port them.
 GP TEE Internal APIを RISC-VとIntel SGXで走るライブラリとして実装。
 Reference
 Library Implementation and Performance Analysis of GlobalPlatform TEE Internal API for
Intel SGX and RISC-V Keystone[IEEE TrustCom2020]
 https://conferences.computer.org/trustcompub/pdfs/TrustCom2020-4sgfK5r538MStgrShyle8b/438000b200/438000b200.pdf
 Portable Implementation of GlobalPlatform API for TEE[RISC-V Global Forum 2020]
 https://riscvglobalforum2020.sched.com/event/dO37

35
ポータルなGP internal API ライブラリの実装
各TEEのSDKを活用して新しい抽象化を提供
The library is ported to Intel SGX as well as RISC-V Keystone.
 実装のチャレンジ
 GP internal APIは非常の多くの暗号スィートをサポート
• 必要なものを選んで実装。
 幾つかのAPIはCPU依存
• CPU 依存のAPIはCPU毎に作成。
 GP TEE Internal APIsを既存のSDK(Keystone, SGX)と融合
• Keystone SDK と SGX SDK は ”edger8r” and “keedger”と呼ぶEDL (Enclave Definition
Language) を含む。 EDL はOCALL (TEEからREEの呼び出し) の際にポインターやバウンダリーのチェックを行うた
め、この整合性が必要。

36
GP TEE Internal APIの実装形態
 CPU アーキテクチャ依存
 Random Generator, Time, Secure Storage, Transient Object(TEE_GenerateKey)
 CPU アーキテクチャ非依存 (Crypto)
 Transient Object(exclude TEE_GenerateKey), Crypto Common, Authenticated Encryption,
Symmetric/Asymmetric Cipher, Message Digest
Reference
1. Library Implementation and Performance Analysis of GlobalPlatform TEE Internal API for Intel SGX and RISC-V
Keystone[TrustCom2020] https://conferences.computer.org/trustcompub/pdfs/TrustCom2020-4sgfK5r538MStgrShyle8b/438000b200/438000b200.pdf
2. Portable Implementation of GlobalPlatform API for TEE[RISC-V Global Forum 2020]
https://riscvglobalforum2020.sched.com/event/dO37

37

38
TEEの管理フレームワーク TEEP(Trusted Execution
Environment Provisioning)
 TEEP
 IETP TEEP WGで議論されているTA(Trusted Application)のInstall/Update/Deleteを管理するプロトコル
 TAインストール時に関係するサーバ・クライアントをそれぞれ認証する
 プラットフォームから視点：TAは信頼できるものなのか、TAを提供するサーバは信頼できるものなのか
 TA提供者からの視点：実行するプラットフォームのTEEは信頼できるものなのか
出典：Trusted Execution Environment Provisioning (TEEP) Architecture

39
TEEPの実装
 TEE Certificateを使って
TAMがTEEを認証
 TAM Certificateを使って
TEEP AgentがTAMを認証
 Client側の暗号鍵・証明書は
Root of Trustに保存される
のが望ましい。
 TEEPではTA(Trusted
Application)からTC
(Trusted Component)に
変更
 メッセージはQueryRequest,
QueryResponse, Update,
Success, Error の5つ

40

41
Remote Attestation
 リモートの第三者がデバイスの健全性、および意図したバイナリが実行されることを確認する手段
 TEE以外でも使われる（例: TPM, FIDO）
 現在、IETFのRemote Attestationに関するプロトコルRTAS(Remote
Attestation ProcedureS)が議論されている。
 クライアントデバイス(Attester)がサービス提供者(Relying Party)からサービスを受けるために健全性のエビデンス
を渡し、証明者(Verifier)に依頼する。
① サービス提供者(Relying Parity)に健全であることを証明した
いクライアント(Attester)がその証拠（Evidence）を受けたいに渡す。
③ Verifierの検証結果からサービスを提供するかを判断。
② サービス提供者(Relying Parity)はEvidenceを検証できる
Verifierに検証を依頼。
Evidence
Evidence Result
RATS
ロゴ

42
既存のRA: Remote Attestation
 Intel SGX: Software Guard Extensions (process-based)
 EPID: Enhanced Privacy ID, Intel提供のプライバシーを考慮したRA
 DCAP: Data Centric Audit Protection, プライバシーを考慮しないRA
 Intel TXT: Trusted Execution Technology. 実行途中で信頼基点を作るDynamic Root of Trust
 AMD SEV: Secure Encrypted Virtualization (VM-based)
 RISC-V
 Keystone (但し、既存ものはRoot of Trustがない)
 Arm TrustZone (本体にはRemote Attestationの機能はない)
 Android Key Attestation https://github.com/google/android-key-attestation
 Samsung Knox Attestation https://docs.samsungknox.com/dev/knox-attestation/index.htm
 PSA Attestation API
 TPM: Trusted Platform Module 通常のWindows PCには標準準拠 (HSM-based)
 DICE: Device Identifier Composition Engine
 FIDO
 FIDO ECDAA Algorithm
 https://fidoalliance.org/specs/fido-uaf-v1.2-rd-20171128/fido-ecdaa-algorithm-v1.2-rd-20171128.html
 Android 7以降のkey attestation、 Android 8以降のID attestation
 iOS 14以降DeviceCheckフレームワークに追加されたApp Attest API
 Azure IoT、TPM、Intel SGXなどに対応
 https://docs.microsoft.com/ja-jp/azure/attestation/overview
TCG
FIDO
Alliance
Arm
SPA
青字はAttesterカテゴリの分類

43
Remote Attestation
 Keystoneが提供するRemote Attestationでは鍵の管理をRoot of Trustで行っていない。
 TRVのSecure Unitで鍵管理できるように改良。更に機能追加。
RISC-V Client
Remote Attestation Server
ZSBL
Power-on
FSBL
SM
Root of Trust
(Device Pub-key)
(SM Signature,
SM Secret Key)
ROM
Trusted Side
Untrusted Side
BBL
Linux
Enclave-App
Runtime
Connect TCP/IP
(Untrusted Comm) Load
Device Pub-key
Secure Monitor Hash
Enclave Hash
Enclave-App
Runtime
Enclave-Host
• Hash taken by SM
• Hash signed by SM
Secret key
• SM Signature
Trust-Client
Verify Enclave
Hashes and
Signatures
Report
Key Exchange
Secure Communication
(Dynamicall
y created)
Device Pub-key
SM Secret/Pub-key
SM Signature by Device Secret key
Enclave-App
Runtime
Valid
Start Enclave-App
prerequisite
prerequisite

44
今後の展開（スマホ・PCからクラウドへ）
 VMイメージをTEE内に入れてしまう機能。
 CPUでの対応
 AMD SEV: Secure Encrypted Virtualization
2016に導入され、AMD SEV-ES: Encrypted State(2017)、AMD SEV-SNP: Secure Nested
Pageと拡張が続いている。
 Intel TDX: Execution Trust Domain Extensions
 Arm CCA: Confidential Computing Architecture
 仮想化技術での対応
 Amazon EC2では仮想化技術によるTEEのNitroは既に運用
 業界団体: Linux FoundationはCCC: Confidential Computing Consortiumを
2019年に設立し、開発を促進。

45
今後の方向性予想(Confidential Computing のプロジェクト)
 The open-source landscape of confidential computing in 2021より
 https://medium.com/edgelesssystems/the-open-source-landscape-of-confidential-computing-in-2021-7f847ebfc0a9

46
TEE関連組織・規格
 GlobalPlatform
 TEE関係のAPI規格。スマートフォンで採用が多い。
 SESIP: Security Evaluation Standard for IoT Platforms
 TCG: Trusted Computing Group
 TPMの仕様を作成している組織。
 Arm PSA(Platform Security Architecture) Certificate
 IETF Protocol
 TEEP: Trusted Execution Environment Provisioning
 RATS: Remote Attestation Procedures
 CCC: Confidential Computing Consortium
 Linux Foundationプロジェクト
• 規格争い
• 主導権争い

47
まとめ
 Take-way Point:
 RISC-Vでメモリを隔離するPMP(Physical Memory Protection)を使ってTEEを実装
 TEEは一時的な隔離実行環境なので鍵などの機密情報保持にはRoot of Trustが必要
 外部から健全性を確認するRemote Attestation
 技術研究組合TRASIOでは上記に対応するハードウェア・ソフトウェア技術を開発
 Trusted-RV Platform (64-bit RISC-V + 32-bit RISC-V Secure CoProcessor)
 TEEのプログラミング環境: GlobalPlatform TEE Internal API
 TA管理フレームワーク: TEEP(Trusted Execution Environment Provisioning)
 Remote Attestation
謝辞：この成果は国立研究開発法人新エネルギー・産業技術総合開発機構（NEDO）の委託業務（JPNP16007）の結果
得られたものです。

RISC-Vのセキュリティ技術(TEE, Root of Trust, Remote Attestation)

More Related Content

What's hot (20)

Similar to RISC-Vのセキュリティ技術(TEE, Root of Trust, Remote Attestation) (20)

More from Kuniyasu Suzaki (20)

RISC-Vのセキュリティ技術(TEE, Root of Trust, Remote Attestation)