㊙️

TEE（Trusted Execution Environment）入門[基礎編]

kiyo

2025/09/17に公開

本記事は、スマートフォンの生体認証からクラウドまで TEE（Trusted Execution Environment） を俯瞰します。

Part 2 では、ブロックチェーンにおける実用例であるAutomata 1RPC と Unichain（Flashblocks）について深掘りします。

記述は 2025-09-16 時点の公知情報に基づきます。


 TL;DR
TEE は CPU 内の隔離実行環境。OS や root からも分離された領域で、機密データとコードを保護し、リモート・アテステーションで「正しいバイナリが想定どおりの設定で動いているか」を検証できる。

スマホでは、iOS の Secure Enclave や Android の TrustZone/TEE が 生体情報テンプレートをデバイス外に出さず、アプリや OS には認証可否のみ返す設計。

AWS Nitro Enclaves は EC2 上にネットワーク/ストレージ/対話なしのエンクレーブを作る。親は Nitro ベース & vCPU 要件あり。親 OS は Linux/Windows 可、エンクレーブ OS は Linux のみ。

 1. TEE とはOS や root でもアクセス不可能なハードウェアレベルの隔離領域を作り、以下の処理を安全に行う仕組み。
機密データの保管
暗号演算や認証処理
証明書付きの起動検証
Arm TrustZone、Intel SGX/TDX、AMD SEV-SNP など形式は色々ありますが、共通点は「鍵を握るロジック＋メモリが常に暗号化され、ホスト OS からは覗けない」ことです。
できること
CPU 内の隔離領域でコードとデータを実行・保持

リモート・アテステーションによるバイナリ測定値（ハッシュ）＋設定の検証
鍵・シークレットの安全な取り扱い（TEE 外へ生データを出さない前提設計）
できない／気をつけること
ハード依存の脆弱性をゼロにはできない（サイドチャネル攻撃のリスク）
正しさの根拠はハード＋ファームウェアの信頼に依存（暗号学的完結ではない）
証明の粒度は「このコードがこの設定で TEE 内で走った」まで（計算結果の数学的完全性は ZK の領域）

 2. スマートフォンの TEE（Secure Enclave / TrustZone）最も身近な事例として、スマートフォンの生体認証が挙げられます。
iOS / Secure Enclave
iPhone の Face ID／Touch ID テンプレートが入っている Secure Enclave は典型的なTEEの一種である。アプリやOSから生体テンプレートなどの生データにはアクセス不可。
アプリは LAContext などで 成功/失敗のみ受け取る。
Android
TrustZone/TEE で生体データの取り扱いを分離。
認証可否のみがアプリ層へ渡る。テンプレートは TEE 領域で管理。
ポイント：テンプレートや秘密鍵は TEE 外へ出さないこと。アプリ設計では「可否フラグ」を前提に UX を組むことになります。

 3. AWS Nitro Enclaves 概要AWS Nitro EnclavesはEC2インスタンス内にEnclaveと呼ばれる分離されたアプリケーション環境を作成するための機能であり、TEEの実装が可能です。

 3.1 前提EC2（親）上に、ネットワークなし／ストレージなし／SSH なしの極小 OS（Linux）の Enclave VM を起動。
データの加工・復号・署名など「見せたくない処理」をエンクレーブ内で完結。
Enclaveを利用することで、個人情報、医療、金融、知的財産データといった機密性の高いデータを保護および安全に処理可能。

 3.2 要件と構成親インスタンス：Nitro ベース、vCPU 要件あり（一般に 4 vCPU 以上、Graviton 系は別要件）
親 OS：Linux / Windows Server 2012 R2+
エンクレーブ OS：Linux のみ
通信：vsock（親⇔エンクレーブのみ）
Nitro Enclaves アーキテクチャ（親⇔エンクレーブ）


 3.3 アテステーションの流れNitro Hypervisor が署名付きアテステーション文書をエンクレーブ内からの要求に応じて生成
文書には PCR（Platform Configuration Register） 等の測定値を含む
Verifier（KMS など）が文書の署名・ナンス・PCR 適合を検証 → OK なら秘密を開示

※ PCR (Platform Configuration Register) 」とは、プラットフォーム構成レジスタといい、enclaveに固有な暗号化測定値である。基本的にPCRはenclaveの作成時に自動的に生成され、作成後にenclaveに変更が加えられていないことを外部から検証できるようにするためのもの。
Nitro Enclaves のリモート・アテステーション
代表的な PCR（短縮版）


PCR
内容（要約）


PCR0
Enclave Image のハッシュ

PCR1
Linux カーネル／ブートストラップ

PCR2
アプリケーション

PCR3
親の IAM ロール

PCR4
親のインスタンス ID

PCR8
EIF 署名証明書


 3.4 単体 EC2 で Nitro Enclaves を有効化（最小構成）するterraform例弊社Omakaseはブロックチェーンバリデータ運用を事業の軸としており、原則すべてのインフラをIaCで管理しているので、以下terraformでの実装例を紹介します。

# ------------------------------------------------------------
# EC2（親）— Nitro Enclaves を有効化
# 例：m6i.xlarge は 4 vCPU（Intel/AMD 系は 4 vCPU 以上が目安）
# ------------------------------------------------------------
resource "aws_instance" "enclave_parent" {
  ami                    = data.aws_ami.al2.id
  instance_type          = "m6i.xlarge"
  subnet_id              = var.subnet_id
  key_name               = var.key_name
  iam_instance_profile   = aws_iam_instance_profile.enclave_profile.name
  vpc_security_group_ids = [aws_security_group.enclave_sg.id]

  # Enclavesを有効化
  enclave_options { enabled = true }

  metadata_options {
    http_tokens = "required"
  }

  user_data = <<-EOF
    #!/bin/bash
    set -eux
    # Amazon Linux 2 向け：Nitro Enclaves CLI を導入
    amazon-linux-extras enable aws-nitro-enclaves-cli
    yum install -y aws-nitro-enclaves-cli
    systemctl enable --now nitro-enclaves-allocator.service

    # 利用ユーザを ne グループへ
    usermod -aG ne ec2-user || true

    # （任意）Enclaves用の CPU/メモリを予約
    cat >/etc/nitro_enclaves/allocator.yaml <<YAML
    cpu_count: 2
    memory_mib: 1024
    YAML
    systemctl restart nitro-enclaves-allocator.service
  EOF

  tags = { Name = "enclave-parent" }
}


 3.5 EKS で Nitro Enclaves を有効化（最小構成）するterraform例
# Launch Template（AMI は指定しない＝EKS 管理 AMI を使用）
resource "aws_launch_template" "enclave_lt" {
  name_prefix = "eks-enclave-lt-"

  # Enclavesを有効化
  enclave_options { enabled = true }

  metadata_options {
    http_tokens = "required"
  }

  # EKS 最適化 AMI（AL2）向け：ブートストラップ＋ Nitro Enclaves 導入
  user_data = base64encode(<<-EOF
    #!/bin/bash
    set -eux

    # 1) EKS ノードのブートストラップ（AL2の場合原則必須）
    /etc/eks/bootstrap.sh ${var.cluster_name}

    # 2) Nitro Enclaves CLI の導入（Amazon Linux 2 ベース）
    if command -v amazon-linux-extras >/dev/null 2>&1; then
      amazon-linux-extras enable aws-nitro-enclaves-cli || true
      yum install -y aws-nitro-enclaves-cli
    else
      # AL2023 等のAMIの場合
      dnf install -y aws-nitro-enclaves-cli || true
    fi

    systemctl enable --now nitro-enclaves-allocator.service

    # 3) ノード上のデフォルト割当（必要に応じて調整）
    cat >/etc/nitro_enclaves/allocator.yaml <<YAML
    cpu_count: 2
    memory_mib: 1024
    YAML
    systemctl restart nitro-enclaves-allocator.service

    # 4) 利用ユーザ
    usermod -aG ne ec2-user || true
  EOF
  )
}

# Node Group（インスタンスタイプは 4 vCPU 以上を推奨）
resource "aws_eks_node_group" "enclave_ng" {
  cluster_name    = var.cluster_name
  node_group_name = "enclave-ng"
  node_role_arn   = aws_iam_role.node_role.arn
  subnet_ids      = var.private_subnet_ids

  scaling_config {
    desired_size = var.desired
    min_size     = var.min_size
    max_size     = var.max_size
  }

  # 例：Intel/AMD 系
  instance_types = ["m6i.xlarge"]
  ami_type       = "AL2_x86_64"

  launch_template {
    id      = aws_launch_template.enclave_lt.id
    version = "$Latest"
  }

  update_config { max_unavailable = 1 }
  tags = { "eks/addon" = "nitro-enclaves" }
}


 まとめTEE のコアは「隔離（isolation）＋アテステーション（検証可能性）」です。OS/root からの分離を前提に、"このバイナリがこの設定で TEE 内で動いた" を第三者に示せることが特徴です。注意として、TEE はハードウェア信頼に依存し、サイドチャネルをゼロにはできない点に注意が必要です。

なお、本文の Terraform 例は、単体 EC2／EKS ノードの両パターンで Nitro Enclaves を有効化する最小実装の雛形です。自環境ではインスタンスタイプ・vCPU・AMI（AL2/AL2023）・ユーザーデータのブートストラップ方式（bootstrap.sh / nodeadm）を調整してください。

次回Part2では、Automata 1RPC と Unichain（Flashblocks） を題材に、TEE がブロックチェーンでどう実用されているかを掘り下げます！

 参考リンク（公開情報）TEE の基礎解説（Trustonic）: https://www.trustonic.com/technology/tee/
iOS Secure Enclave の概観（解説記事）: https://medium.com/better-programming/app-security-in-swift-keychain-biometrics-secure-enclave-3c6b2b2a2b6d
Android/Knox における TEE と生体認証の扱い（Samsung）: https://www.samsungknox.com/en/blog/using-biometrics-for-authentication-in-android
Remote Attestation（Confidential Computing Consortium）: https://confidentialcomputing.io/posts/what-is-remote-attestation/
AWS Nitro Enclaves（概説・測定値）: https://docs.ata.network/pom/attestation-module/machine-attestation/aws-nitro-enclaves, https://aws.amazon.com/jp/blogs/aws/aws-nitro-enclaves-isolated-ec2-environments-to-process-confidential-data/

PCR	内容（要約）
PCR0	Enclave Image のハッシュ
PCR1	Linux カーネル／ブートストラップ
PCR2	アプリケーション
PCR3	親の IAM ロール
PCR4	親のインスタンス ID
PCR8	EIF 署名証明書

OmakaseテックブログPublication

Omakaseは、SOC2 Type II認証およびISO 27001認証を取得した、日本国内のバリデータ運用事業者です。 2018年よりノード・バリデータ運営を経験しているインフラエンジニアと共に、国内最多数の対応チェーン数(2025年4月時点)を実現しています。

TL;DR

1. TEE とは

2. スマートフォンの TEE（Secure Enclave / TrustZone）

3. AWS Nitro Enclaves 概要

3.1 前提

3.2 要件と構成

3.3 アテステーションの流れ

3.4 単体 EC2 で Nitro Enclaves を有効化（最小構成）するterraform例

3.5 EKS で Nitro Enclaves を有効化（最小構成）するterraform例

まとめ

参考リンク（公開情報）

Discussion