2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
Trusty TEE
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Trusty は、Android 用の Trusted Execution Environment(TEE)を実現するセキュアなオペレーティング システム(OS)です。Trusty OS は、Android OS と同じプロセッサ上で稼働しますが、ハードウェア レベルとソフトウェア レベルの両方で、システム内の残りの部分から分離されます。Trusty と Android は並列稼働します。Trusty は、デバイスのメイン プロセッサとメモリのすべてにアクセスできますが、完全に分離されています。分離されているため、悪意のあるアプリをユーザーがインストールした場合や Android 内に脆弱性があった場合でも、Trusty は保護されます。
Trusty は ARM プロセッサと Intel プロセッサに対応しています。ARM システムの場合、Trusty は、ARM の Trustzone™ を使用してメイン プロセッサを仮想化し、セキュアな Trusted Execution Environment を構築します。Intel x86 プラットフォームの場合も、Intel のバーチャライゼーション テクノロジーを活用することで同様のサポートを提供します。
図 1: Trusty の概要図
Trusty は以下の要素で構成されています。
- Little Kernel をベースとする小さな OS カーネル
- セキュア環境と Android との間でデータを転送するための Linux カーネル ドライバ
- カーネル ドライバ経由で高信頼アプリ(セキュアなタスクやサービス)と通信する Android ユーザー空間ライブラリ
注: Trusty および Trusty API は変更される場合があります。Trusty API の詳細については、API リファレンスをご覧ください。
Trusty を選ぶ理由
これまでの他の TEE オペレーティング システムの場合、サードパーティ ベンダーからバイナリ blob として提供されるか、内部で開発していました。内部で TEE システムを開発する方法や、サードパーティから TEE のライセンス供与を受ける方法の場合、システム オン チップ(SoC)ベンダーや OEM にとって高コストになることがあります。信頼性の低いサードパーティ システムと金銭的なコストが組み合わさることで、Android のエコシステムが不安定になります。Trusty は、Trusted Execution Environment を実現する信頼性に優れた無料のオープンソース システムとしてパートナーに提供されています。Trusty は、クローズドソース システムでは不可能なレベルの透明性を実現します。
Android はさまざまな TEE 実装をサポートしており、必ずしも Trusty を使用する必要はありません。ただし、各種の TEE OS は、高信頼アプリをデプロイする方法がそれぞれ異なります。このように細分化した状況は、高信頼アプリのデベロッパーが多様な Android デバイス上でアプリが正常に機能するように取り組む際、悩みの種となる可能性があります。Trusty を標準規格として利用することで、アプリ デベロッパーたちは、各種 TEE システムの細分化に悩まされることなく、アプリを簡単に作成してデプロイできるようになります。Trusty TEE を使用することで、デベロッパーやパートナーは、透明性を確保し、コラボレーションを促進し、コード インスペクションやデバッグを容易に行うことができます。高信頼アプリのデベロッパーたちは、共通のツールや API に収斂していくことで、セキュリティ脆弱性が入り込むリスクを軽減できます。また、一度アプリを開発した後は、追加の開発を行うことなく、さまざまなデバイスタイプを横断して再利用できるようになります。
アプリとサービス
Trusty アプリは、バイナリ ファイル(実行ファイルとリソース ファイル)と、バイナリ マニフェスト、暗号署名を 1 つにまとめたものとして定義されます。Trusty アプリは実行時、Trusty カーネルの下、分離独立したプロセスとして非特権モードで実行されます。各プロセスは、TEE プロセッサのメモリ管理ユニット機能を利用して、それぞれ独自の仮想メモリ サンドボックス内で実行されます。Trusty が従う実際のプロセスはハードウェアのビルドによって異なりますが、たとえば、プロセスのスケジュールは、カーネルが、セキュアなタイマーチックに基づく優先度ベースのラウンドロビン スケジューラを使用して設定します。Trusty アプリはすべて同じ優先度になります。
図 2: Trusty アプリケーションの概要。
サードパーティ製の Trusty アプリ
現在のところ、Trusty アプリはすべて、単一のパーティによって開発され、Trusty カーネル イメージを使用してパッケージ化されます。イメージ全体に対して署名が行われ、ブート時にブートローダーによって検証されます。現在のところ、サードパーティによる Trusty アプリの開発はサポートされていません。Trusty は新しいアプリの開発をサポートしていますが、その際には細心の注意が必要です。新しいアプリごとに、システムのトラステッド コンピューティング ベース(TCB)の領域が増えます。高信頼アプリは、デバイスの機密データにアクセスし、それを使用して演算やデータ変換を行うことができます。TEE 内で稼働する新しいアプリを開発することで、イノベーションの可能性が広がります。ただし、TEE の定義により、このようなアプリを配布するには、一定の信頼情報を添付する必要があります。この信頼情報は通常、デジタル署名の形式をとります。デジタル署名は、アプリが稼働する製品のユーザーが信頼するエンティティによって提供されます。
用途と例
TEE は、モバイル デバイスの分野で急速に標準になりつつあります。ユーザーの日常生活はますますモバイル デバイスに依存するようになっており、セキュリティに対するニーズが高まっています。TEE を搭載したモバイル デバイスは TEE を搭載していないデバイスよりも安全です。
TEE 実装を備えたデバイスの場合、メイン プロセッサは通常、「信頼できない」プロセッサと見なされ、RAM の特定の領域や、ハードウェア レジスタ、1 回だけ書き込み可能な fuse(デバイス固有の暗号鍵などの機密データをメーカーが格納する領域)にアクセスすることはできません。メイン プロセッサ上で稼働するソフトウェアは、機密データを必要とするすべての操作を TEE プロセッサに委任します。
Android エコシステム内で最も広く知られている例は、保護対象コンテンツ向けの DRM フレームワークです。TEE プロセッサ上で稼働するソフトウェアは、保護対象コンテンツの復号に必要なデバイス固有鍵にアクセスできます。他方、メイン プロセッサが認識できるのは暗号化されたコンテンツだけに限られるため、ソフトウェア ベースの攻撃に対して高度なセキュリティ機能と保護機能が実現します。
TEE の用途としてはほかにも、モバイル決済や、セキュア バンキング、多要素認証、デバイス リセット保護、リプレイ保護機能付きの永続ストレージ、PIN / フィンガープリントのセキュアな処理、マルウェア検出などがあります。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-10 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-10 UTC。"],[],[],null,["# Trusty TEE\n\nTrusty is a secure Operating System (OS) that provides a Trusted Execution\nEnvironment (TEE) for Android. The Trusty OS runs on the same processor\nas the Android OS, but Trusty is isolated from the rest of the system\nby both hardware and software. Trusty and Android run parallel\nto each other. Trusty has access to the full power of a device's main\nprocessor and memory but is completely isolated. Trusty's isolation\nprotects it from malicious apps installed by the user and potential\nvulnerabilities that may be discovered in Android.\n\nTrusty is compatible with ARM and Intel processors. On ARM systems,\nTrusty uses ARM's TrustZone to virtualize the main processor and create\na secure TEE. Similar support is also available\non Intel x86 platforms using Intel's Virtualization Technology.\n\n\n**Figure 1**. Trusty overview diagram.\n\nTrusty consists of:\n\n- A small OS kernel derived from [Little Kernel](https://github.com/littlekernel/lk)\n- A Linux kernel driver to transfer data between the secure environment and Android\n- An Android [userspace library](https://android.googlesource.com/trusty/lib/) to communicate with trusted applications (that is, secure tasks/services) via the kernel driver\n\n**Note:** Trusty and the Trusty API are subject\nto change. For information about the Trusty API, see the [API Reference](/docs/security/features/trusty/trusty-ref).\n\nWhy Trusty?\n-----------\n\nOther TEE operating systems are traditionally supplied as binary\nblobs by third-party vendors or developed internally.\nDeveloping internal TEE systems or licensing a TEE from a third-party\ncan be costly to System-on-Chip (SoC) vendors and OEMs.\nThe monetary cost combined with unreliable third-party systems creates an\nunstable ecosystem for Android. Trusty is being provided to its partners\nas a reliable and free open source alternative for their TEE. Trusty offers a level of\ntransparency that isn't possible with closed source systems.\n\nAndroid supports various TEE implementations so you are not restricted\nto using Trusty. Each TEE OS has its own unique way of deploying trusted\napplications. This fragmentation can be a problem for trusted application\ndevelopers trying to ensure their apps work on every Android device.\nUsing Trusty as a standard helps application developers to easily\ncreate and deploy applications without accounting\nfor the fragmentation of multiple TEE systems. Trusty TEE provides developers\nand partners with transparency, collaboration, inspectability of code, and\nease of debugging. Trusted application developers can converge around common\ntools and APIs to reduce the risk of introducing security vulnerabilities.\nThese developers will have the confidence that they can develop an application\nand have it reused across multiple devices without further development.\n\nApplications and services\n-------------------------\n\nA Trusty application is defined as a collection of binary files\n(executables and resource files), a binary manifest, and a\ncryptographic signature.\nAt runtime, Trusty applications run as isolated processes in\nunprivileged mode under the Trusty kernel. Each process runs\nin its own virtual memory sandbox utilizing the memory management\nunit capabilities of the TEE processor. The build of the hardware\nchanges the exact process that Trusty follows, but for example,\nthe kernel schedules these processes using a priority-based,\nround-robin scheduler driven by a secure timer tick.\nAll Trusty applications share the same priority.\n\n\n**Figure 2**. Trusty application overview.\n\nThird-party Trusty applications\n-------------------------------\n\nCurrently all Trusty applications are developed by a single\nparty and packaged with the Trusty kernel image.\nThe entire image is signed and verified by the bootloader during boot.\nThird-party application development is not supported in Trusty at\nthis time. Although Trusty enables the development of new\napplications, doing so must be exercised with extreme care; each\nnew application increases the area of the trusted computing base\n(TCB) of the system.\nTrusted applications can access device secrets and can perform\ncomputations or data transformations using them. The ability to\ndevelop new applications that run in the TEE opens up many\npossibilities for innovation. However, due to the very definition\nof a TEE, these applications cannot be distributed without some\nform of trust attached. Typically this comes in the form of a\ndigital signature by an entity trusted by the user of the\nproduct on which the application runs.\n\nUses and examples\n-----------------\n\nTEEs are fast becoming a standard in\nmobile devices. Users are relying more and more on their mobile\ndevices for their everyday lives and the need for security is always\ngrowing.\nMobile devices with a TEE are more secure than devices without a TEE.\n\nOn devices with a TEE implementation, the main processor is often\nreferred to as \"untrusted\", meaning it cannot access certain areas\nof RAM, hardware registers, and write-once fuses where secret data\n(such as, device-specific cryptographic keys) are stored by the manufacturer.\nSoftware running on the main processor delegates any operations that\nrequire use of secret data to the TEE processor.\n\nThe most widely known example of this in the Android ecosystem is the [DRM framework](/docs/core/media/drm)\nfor protected content. Software running on the TEE processor can\naccess device-specific keys required to decrypt protected content.\nThe main processor sees only the encrypted content, providing\na high level of security and protection against software-based attacks.\n\nThere are many other uses for a TEE such as mobile payments, secure banking,\nmulti-factor authentication, device reset protection,\nreplay-protected persistent storage, secure PIN and fingerprint processing,\nand even malware detection."]]