Anonify: A Blockchain-Agnostic Execution

Environment with Privacy and Auditability

Version 1.0.0

須藤 欧佑 1 恩田 壮恭 1 中村 龍矢 1

1LayerX Inc.

June 4, 2020

ブロックチェーン技術は, 複数の企業や組織間で状態遷移の正しさを互いに検証し,

暗号学的に改ざん不可能な状態データとして記録, 共有することを可能にする. この特

性を活かし, 参加者間の協業を促進する取り組みが活発に行われている. しかし, 異なる

参加者間で状態データの共有を行う性質上, 本来は他参加者に公開するべきでないデー

タも公開してしまうプライバシ問題が大きな課題の一つとしてあげられる. ブロック

チェーンにおけるプライバシ問題解決のための取り組みが多く行われている一方, これ

らの取り組みの多くは秘匿データに対する可用性問題,パフォーマンス課題,状態遷移表

現力の欠如, そして秘匿性と監査性のトレードオフなどの様々な技術的課題が存在する.

本稿では, これらの課題を解決するブロックチェーンのプライバシ保護システムであ

るAnonifyを提案する. AnonifyはTEE (Trusted Execution Environment) を用いるこ

とにより, ブロックチェーンの参加者間で明らかにしたくないデータを保護しながら,

高い可用性と柔軟なビジネスロジックの実行を実現する. 加えて, 特定の主体がデータ

を読み取ることが可能となる監査機能も提供する.

また, Anonify上のアプリケーション例として ERC20規格同等のトークンの状態遷

移ロジックを実装し, その評価を行った.

1 はじめに

ブロックチェーン技術はネットワークに参加するノード間で状態遷移ロジックを共有

することを可能にする. しかし, ブロックチェーン上のデータは第三者が閲覧すること

が可能であり, 個人情報・プライバシ保護の課題が存在する. 各ユーザアカウントは固

1

有のアドレスで識別され, エンタープライズにおけるユースケースではこのアドレスと

個人のアイデンティティは紐づいている, もしくは推測されやすい場合が多い. ブロッ

クチェーンを閲覧できる主体にとっては, 特定のトランザクションがどのユーザから送

信されたか, 何のデータをどのユーザに向けて送っているのか, という一連のプライバ

シ情報が明らかになってしまう.

しかしながら, 多くのブロックチェーンではプロトコルとしてデータの秘匿性や送

受信者の匿名性は保証されていない. 例えば, 送金アプリケーションにおいて第三者は

ノードにアクセスすることで特定のトランザクションの送信者アドレス, 受信者アドレ

ス, 送金額を自由に閲覧することが可能である. つまり, ブロックチェーンネットワー

クを複数企業で横断して構成する場合, 他社に自社の取引情報などがいつでも閲覧可能

になってしまう.

このような問題に対処するために, ブロックチェーン上でのプライバシ保護に取り組

む研究開発が多く行われている. 例えば, 機密性の高いデータはネットワーク全体にブ

ロードキャストせず,取引当事者ノードだけで共有するアプローチがある. このような手

法は, Quorum1やHyperledger Besu2の機能であるPrivate (Group) Transaction, Corda3

のNon-validating notary, Hyperledger Fabric4のPrivate Data といったエンタープライ

ズ向けブロックチェーンの機能として実装されている. このアプローチでは, 秘匿した

いデータをグローバルにアクセス可能なブロックチェーン上で直接扱わずに二者間あ

るいはグループ間のみで共有することで, 比較的シンプルにプライバシ保護を実現して

いる.

一方で, このようなアプローチの場合, 秘匿化対象のデータを参加者が外部に漏洩す

ることはプロトコルで防ぐことができず, それを検知することもできない. よって, プラ

イバシ保護のためには, 他参加者がデータを漏洩しないことを信用する必要がある. ま

た, トランザクションを共有されていない参加者は状態遷移を検証できないため, ある

ビジネスロジックの共同利用者間ではデータを隠すことはできない. 例えば, あるユー

ザが自分に送金されたトークンが正当であるか確かめるには, そのトークンに関する過

去のトランザクションを全て検証する必要がある. しかしこのとき, そのトークンの過

去の全ての取引に関して, 送受金したユーザのアドレスと送金額が閲覧できてしまう.

以上のように, エンタープライズ向けブロックチェーンに実装されているデータの共有

相手を制限する手法は, 他参加者を信用せずにプライバシ保護することや, 利用者間で

のプライバシ保護を実現することができない.

この問題に対処しているアプローチとして, 第三者には明らかにしたくない状態デー

1https://www.goquorum.com/2https://www.hyperledger.org/projects/besu3https://www.corda.net/4https://www.hyperledger.org/projects/fabric

2

タもブロックチェーンでグローバルに共有する手法が存在する. ブロックチェーン上に

全てのデータが記録されるため, ネットワーク全体で状態遷移の検証が行われ, 状態遷

移の履歴としてデータがグローバルに記録されていく. この場合, 第三者が不正に閲覧

できないように保護するために, 一般的に状態データは暗号化される. 加えて, 状態遷

移が正しく行われたこと, つまり状態データの暗号文が正しく生成されていることを保

証する性質も求められる. この性質は, (計算)完全性と呼ばれる.

完全性をブロックチェーン上で効率的に検証できる主な手段として, 機密性の高い

データを明らかにせずそのデータが正当なことを暗号学的に保証するゼロ知識証明や,

ハードウェアレベルのセキュリティ機能であるTEE (Trusted Execution Environment)

に基づくAttested Executionがある. ゼロ知識証明をベースにした手法については 第

7.1節で述べるが, 送金以外の汎用的な状態遷移ロジックを実行するには証明生成時の

計算オーバーヘッドが依然として大きく, 実際のアプリケーションへの応用は現実的で

はないことが課題の一つとしてあげられる [1]. 具体的には, 証券決済における買い注文

や配当のロジックのように単なる金額の移動だけではなく, 証券・投資家情報に基づく

バリデーションや状態の書き換えなどがロジックに含まれる場合は, 純粋な暗号技術だ

けでは算術回路の性質上困難である.

そこで, 本稿ではこれらの課題を解決したブロックチェーン上のプライバシ保護シス

テムであるAnonifyを提案する. Anonifyは事前に定義された状態遷移ルールをTEEで

実行し, その命令を暗号化しブロックチェーン上に記録する. これにより, プライバシ

を保護した上で幅広いビジネスロジックの実行を可能とする. 加えて, 特定の監査主体

にのみに状態データを開示する仕組みも提供する. Anonifyの実装は公開5されている.

Anonifyでプライバシー保護の技術ベースとなっているTEEはプロセッサレベルの

セキュリティ機能であり, TEEによりプライバシ保護と状態遷移ロジックの完全性を実

現する. TEEの特徴的な機能として後述するAttestationによって TEEで実行するプ

ログラムが正しいことをブロックチェーン上で検証することが可能になる. 状態遷移は

特殊な算術回路で計算されず, 汎用プロセッサでプログラム処理されるので表現性の高

い状態遷移をハイパフォーマンスで実行できる.

第 7.2節で述べているTEEを用いてブロックチェーンのプライバシ保護を行う関連

プロジェクトとの大きな違いとして, Anonifyでは特定の監査主体に監査機能を提供可

能であることがあげられる. 多くのユースケースで, 全ての状態データを全ての参加者

に対して秘匿化するのではなく, 特定の監査主体が参加者の状態データを閲覧可能であ

ることが求められる. 例えば, 金融取引のそれぞれの取引情報は参加者に対して秘匿化

しつつ, 当局には取引情報が開示されるようなケースがあげられる. このようなユース

ケース要件を満たすために, Anonifyでは状態データの秘匿化と監査性を両立できる設

5https://github.com/LayerXcom/anonify

3

計となっている.

本稿の構成を述べる. まず, 第 2章でAnonifyを構成する各技術的コンポーネントを

紹介する. 次に, 第 3章でAnonifyの概略および満たすべき性質, 基本的なワークフロー

について述べ, 第 4章で各サブプロトコルの技術的な詳細を説明する. 第 5章でAnonify

の実装とパフォーマンス評価の結果について記載している. 第 6章では, ここまでの章

で定義されたAnonifyプロトコルに対する拡張提案を議論する. 第 7章ではAnonifyの

関連研究の紹介と, Anonifyとの比較を行っている. 最後に, 第 8章で本研究を結論づ

ける.

2 Anonifyの要素技術

本章では, Anonifyを構成する主要な技術的要素について述べる.

2.1 ブロックチェーン

ブロックチェーン技術はネットワークに参加するノードが状態遷移の正しさを互い

に検証し, 暗号学的に改ざん不可能な状態データとして記録, 共有することを可能にす

る. Anonifyでは, TEEで実行される状態遷移の完全性を検証する処理を行う基盤とし

て, そして暗号化された状態遷移の履歴を複数主体間で共有するためにブロックチェー

ンを用いている. したがって, Anonifyで利用することが可能なブロックチェーンには,

第 4.3節で述べるTEEの検証ロジックがスマートコントラクトとして実装可能である

こと, および TEEがフルノードを介してトランザクションを読み書きできることが求

められる. 暗号化された状態遷移の履歴はノード間でレプリケーションされ, 復号鍵を

保持しているTEEはいつでも合意された最新の状態にアクセスすることが可能である.

2.2 TEE (Trusted Execution Environment)

TEE (Trusted Execution Environment)は特定のアプリケーションが他のソフトウェ

アから隔離された Enclaveで実行されることを保証するプロセッサのセキュリティ機

能である. TEEの基本的なセキュリティ要件とインターフェース定義は標準化団体

GlobalPlatform6が行なっている.

TEEではハードウェアレベルの設計により, OS, ハイパーバイザなどの強い権限を

持つシステムソフトウェアも保護領域のメモリに対して不正にアクセスできないように

なっている. つまり, システムソフトウェアからのマルウェアに対してもアプリケーショ

ンが保護される. このようなセキュリティ性質により,従来より格段に隔離性が高い環境

6https://globalplatform.org/

4

で汎用プログラムを安全に実行できるため, 機密性の高いデータを伴うアプリケーショ

ンへの応用が進められている. また,多くのTEEはメモリの隔離保護に加えAttestation

と呼ばれる機能を持ち, この機能により意図した実行バイナリが正規プロセッサで動作

していることを保証できる. すなわち, TEEは実行バイナリの秘匿性と完全性を提供す

る性質を持つ. 代表的なTEEの設計として, Intel SGX [2], ARM TrustZone [3], RISC-V

Keystone [4]などがあげられ, AWS Nitro Enclaves7も同等の性質を持つ.

一方で, TEEは全てのハードウェアリソースを物理的に隔離していないため, サイド

チャネル攻撃が複数報告されている [5, 6, 7, 8, 9]. このような攻撃に対する緩和策は,

[10, 11, 12, 13]などで提案されTEEのアーキテクチャ改善が進められている.

また, TPM (Trusted Platform Module) もプロセッサレベルの隔離実行機能の代表

的な標準規格である. TPMはプログラムがチップセットにハードコードされているの

に対し, TEEは一般開発者に隔離実行するプログラムの実装が拓かれている点で大きく

異なる. また, Google Titan8, Apple T2 [14], Microsoft Pluton9なども同様の機能を持

つが, 実装とアップデートはあくまでプロダクトベンダのみに制限されている.

2.2.1 Intel SGX

Intel SGX (Software Guard Execution) [2]は第 6世代の Intel Skylakeマイクロアー

キテクチャ以降に搭載されているプロセッサにおけるセキュリティ機能である. SGXで

は, プロセッサ起動時に固定サイズの保護領域がDRAMのサブセットとして確保され,

Enclave領域として仮想メモリが割り当てられる. 保護領域はプロセッサによりアクセ

スコントロールされ, システムソフトウェアやDMA経由ですらアクセスすることはで

きない. また, Enclave内のソフトウェアはリングプロテクションにおけるRing 3 (ユー

ザランド)の権限でしか命令を実行することはできず, Ring 0のような強い権限でアプ

リケーションを実行することはできない. Enclave内外へのアクセスをする特有の命令

である EENTERや EEXITもRing 3権限の命令である.

SGXの特徴的な機能として SealingとAttestationがあげられる. Sealingは on-chip

の鍵を用いてEnclaveでデータを暗号化する機能である. また,その暗号文は外部にエク

スポートしディスクに保存することができる. 復号する場合は同様に暗号文を Enclave

にインポートし, 同じ鍵でUnsealingを行う. もう一つの機能的性質であるAttestation

については次節で述べる.

7https://aws.amazon.com/ec2/nitro/nitro-enclaves/8https://cloud.google.com/titan-security-key9https://azure.microsoft.com/en-us/blog/anatomy-of-a-secured-mcu/

5

2.2.2 Attestation

図 1: Remote Attestation

隔離保護されている Enclave内で実行されるプログラムの完全性を第三者が検証す

るために, SGXでは Remote Attestation [15]という機能が提供されている. Remote

Attestationでは, 特定のEnclave内で正しい実行バイナリが動作していることを遠隔の

Attestation Serviceが保証する. なお, 同一マシン上のEnclave同士が, 同一マシンで動

作していることを互いに検証するためのプロトコルである Local Attestationという機

能も提供されているが, Anonifyでは利用していないため詳細は省略する.

Remote Attestationは, マシン外部のAttestation Serviceに特定の SGXプロセッサ

のセキュリティステータスや Enclave実行バイナリを含むデータ構造体QUOTEを送

信し, Attestation Serviceが保持する秘密鍵により署名された REPORTデータを得る

ことができる. Attestation Serviceは Intelが運営する IAS (Intel Attestation Service)

やサードパーティが運営するDCAP (Data Center Attestation Primitives) を利用する

ことができる. このREPORTには Enclave内実行バイナリや実行環境に依存したハッ

シュ値 (MRENCLAVE) が含まれ, 同じソースコードで同じ設定でビルドすれば同じ

MRENCLAVEを得ることができる. また, Remote Attestationでは, TEEとAttestation

Serviceの間にREPORTの検証を行う Service Providerと呼ばれる主体が仲介する設計

が一般的であるが, AnonifyではTEEとAttestation Serviceが直接通信を行う. なぜな

ら, TEEは受け取ったREPORTをブロックチェーンに送信し, スマートコントラクト

上で検証を行う設計となっているためである.

2.3 TreeKEM

TreeKEM [16, 17, 18]は, 複数のメンバ間でグループ鍵をバイナリツリー構造に基づ

き効率的に生成・共有するためのKEM (Key Encapsulation Mechanism) である. KEM

は, HPKE (Hybrid Public Key Encryption) [19] などの暗号プリミティブを用いて共通

鍵を暗号化する仕組みのことを言う. TreeKEMはMLS (Messaging Layer Security) と

して知られるグループメッセージングのEnds-to-Ends Encryption (E2EE) プロトコル

6

のコアとなる技術であり, IETF Working Groupのドラフトとして標準化が進められて

いる [20].

MLSでは, メンバ間の一連の暗号化メッセージのやり取りがあるフローにおいて, あ

る特定の暗号化メッセージの鍵が漏洩しても, Forward Secrecyによりそのメッセージ

以前の暗号文が解読不可能なことを保証し, Post-Compromise Securityによりそれ以

降の暗号文が解読不可能なことを保証する. つまり, グループ間でのコミュニケーショ

ンにおいて, 特定の暗号文に対する鍵が漏洩しても他の暗号文のセキュリティへの影響

を最小限にする. このMLSで中心となる技術的要素が, ツリー構造のグループ鍵決定

メカニズムである TreeKEMである. 多くのメッセージングアプリケーションで上記

のForward SecrecyとPost-compromise Securityの性質を満たすために, double ratchet

protocols [21]が応用されているが, これはあくまで二者間メッセージングのためのプロ

トコルであり, 多くのメンバが存在するグループ内でのメッセージングには不向きであ

る. MLSでは, グループへのメンバの加入, 脱退, 鍵ローテーション, E2EEメッセージ

送信を double ratchet protocolsと比べ効率的に実現する. Anonifyでは, MLSの主要な

サブプロトコルであるTreeKEMを応用することで, ブロックチェーンで共有する暗号

文に対してForward SecrecyとPost-Compromise Securityの性質を満たしながら, 全て

の TEEで使う共通のグループ鍵を外部に漏洩することなく, ブロックチェーンを介し

た暗号文のやり取りを効率的に行う. さらに, TreeKEMを応用することで参加ノード

が増えた場合でも, 鍵ローテーションをノード数N に対してO(logN)で効率的に行う

ことができる.

3 Anonifyの概要

Anonifyはプライバシを保護した上で, ブロックチェーンを改ざん不可能なデータ共

有基盤として用いることを可能にするシステムである. 通常のブロックチェーンのよう

に, 状態遷移の履歴を平文のまま記録していくのではなく, AnonifyではTEEで暗号化

された命令データをブロックチェーンに記録していく. ここでの命令データには状態遷

移ロジックの指定とインプットデータが含まれる. 例えば ERC20規格10同等のトーク

ンの状態遷移ロジックを実装した場合, Transfer関数のインプットデータは送り手と受

け手のユーザ ID (アドレス) と送金額となる. 参加している TEEはブロックチェーン

から暗号化された命令データを取得し, Enclaveで状態遷移の計算を行い, TEEに記録

している状態データを更新する. Enclave内のデータはハードウェアレベルで外部から

保護され, TEEを運営している管理者自身やOSなどのシステムソフトウェアもアクセ

スできないように保護されている.

10https://eips.ethereum.org/EIPS/eip-20

7

ネットワークに参加しているTEE同士はブロックチェーンを介し, 暗号化・復号に

用いられるTreeKEMに基づくグループ鍵を共有している. これにより, あるTEEがブ

ロックチェーンにブロードキャストした暗号文を取得し, Enclave内で復号して状態遷

移を実行することでTEEの状態を更新することが可能である. つまり, ブロックチェー

ンには全ての状態遷移の履歴を暗号文として記録し, TEEには最新の状態を平文として

記録している.

Enclaveで処理される状態遷移ルールは, TEEのRemote Attestationの仕組みで強制

される. ネットワークに参加するTEEは, Remote Attestationの署名付きの結果データ

(REPORT) をブロックチェーンに送信し, スマートコントラクトでREPORTの署名検

証をすることで改ざんされていないことを検証する. それぞれのTEEは, REPORTに

含まれるEnclaveで実行されたプログラムのハッシュ値 (MRENCLAVE) がセットアッ

プ時に登録されたものと一致しているか検証する. MRENCLAVEが一致する限り, 全

てのTEEは同じ状態遷移ルールを実行していることが保証される.

つまり, 状態遷移の処理自体はそれぞれの TEEが個別に行い, 状態遷移ルールの検

証は全ての参加者がブロックチェーン上のスマートコントラクトで行うことになる. こ

れにより, 全ての参加者間でTEEで実行される状態遷移ルールが正しいことを検証し,

その状態遷移の履歴は暗号化された状態で全てブロックチェーンに記録することが可能

になる.

8

図 2: TEEにおける状態遷移および, ブロックチェーンで暗号文を共有するワークフロー. 青色のサブ

プロトコルが状態遷移時に利用される. TEE外部からのアクセス認証により検証された命令データを

TreeKEMで共有されたグループ鍵による暗号化を行い, ブロックチェーンにブロードキャストする. ブ

ロックチェーンに記録された暗号文は TEEに読み取られ, グループ鍵で復号し得られた命令にしたがっ

て状態遷移を実行し結果を状態データに反映する. 特定の認証情報を保持しているクライアントのみが

アクセス認証を通過し状態データの KVSにアクセスできる. Sealingは, on-chipの鍵で状態データを暗

号化し外部ストレージに記録するための機能を持つ. Attestationは, TEEをブロックチェーンに登録す

る際に実行プログラムの完全性を検証する.

3.1 セキュリティプロパティ

Anonifyのセキュリティプロパティを定義する. 脅威モデルとして, 攻撃者はAnonify

ネットワークにおける少なくとも 1つのTEEを除く, 全てのTEEのOSとネットワー

クスタックをコントロール可能であると想定する. コントロールされたシステムにおい

て, 攻撃者は送受信するメッセージのインターセプト, 並び替え, 遅延を任意に行うこと

ができる. ただし, 各クライアントは攻撃者にコントロールされていない 1つのTEEを

利用可能とする. この脅威モデルの下, Anonifyは以下のセキュリティプロパティを満

たす.

• Correct Execution: ネットワーク参加者間で事前に合意されたルールに沿って状

態遷移が実行されることをここではCorrect Executionと呼ぶ. これは, 第 4.3節で

述べるAttested ExecutionによるTEEのEnclave内実行プログラムの同一性の保

証と, 第 4.2節で述べる状態 IDによるTEE間の最新の状態データの一致検証によ

9

り実現される.

• Confidentiality: ハードウェアレベルで隔離保護されるTEEでの状態データの扱い

およびブロックチェーンには暗号化された命令のみを記録することにより, Anonify

で扱うデータは第三者が不正に閲覧することはできないことが保証されている. つ

まり, 状態データはハードウェアレベルで隔離保護されているTEEにのみ存在し,

外部からアクセスすることはできず, また TEE外部の通信経路およびブロック

チェーン上ではセキュアな暗号アルゴリズムで暗号化されている. ブロックチェー

ン上に記録されるデータの暗号化にはTreeKEMを用いたグループ鍵生成メカニズ

ムが用いられ, 前方秘匿性および効率的な鍵ローテーションの仕組みを導入してい

る. これにより万が一特定の暗号文の鍵が漏洩したとしても他の暗号文に対しての

影響を最小限にすることが可能となっている.

• Fault Tolerance: システム全体において正当なノードが少なくとも 1つ稼働してい

れば, ノードはブロックチェーンに記録されているトランザクションから全ての状

態データを復元し, システムに参加・復旧することができる. 稼働している正当な

ノードは参加するノードに対し過去の暗号文を復号するための鍵を共有する. つ

まり, 参加しているノードは全体アーキテクチャにおける機能として全て公平であ

り, Anonifyのシステムとして状態遷移および命令データの記録における単一障害

点は存在しない.また, システムが稼働しているとき特定のノードが離脱しても他

のノードに影響を与えることはない.

• Data Recoverability: TEEに記録している状態データが全て消失してもブロック

チェーンから全ての状態データを復元可能な性質をData Recoverabilityと呼ぶ. 全

ての状態遷移の命令データは暗号化されブロックチェーンに記録されるため, 復号

するための鍵を保持している限り, 最新の状態データをいつでも復元することがで

きる.

• Accountability: 万が一, ネットワークに参加している主体が何らかの異常な操作

を行なった場合に, その操作がどのTEEにより行われたか検出できる性質をここ

では Accountabilityと呼ぶ. Anonifyでは, 不正な署名や REPORTの提出などの

検証は全てブロックチェーン上で行われ, 署名によりどのTEEが実行した操作で

あるか全ての参加者間で共有されるためAccountabilityは保証される.

3.2 機能的プロパティ

第 3.1節で述べたセキュリティプロパティを前提とし, Anonifyの機能的プロパティ

を定義する.

10

• General-purpose: 状態遷移をTEEでの汎用プロセッサ上で実行するため, 柔軟な

状態遷移ルールを定義可能である. また, ブロックチェーン上のスマートコントラ

クトでは非現実的であった計算コストの大きな処理も可能である.

• Blockchain-agnostic: Anonifyは, 第 4.3節で述べるAttested Executionにおける署

名検証などのロジックがスマートコントラクトとして実装可能であり, 外部からト

ランザクションの読み書きが可能なあらゆるブロックチェーンに適用することが

可能である.

• Auditability: Anonify上の全ての状態データはプライバシ保護される一方で, 第

4.5節で述べる監査機能により, 許可された主体が状態データを閲覧し, 監査するこ

とが可能となる. 監査主体はブロックチェーン上に記録された暗号文を復号する鍵

を所有し, その鍵を用いて平文の状態データを参照することができる.

3.3 TEEでの状態データ管理

状態データである stateはEnclave上に記録される. それぞれのユーザに対する state

は以下のようなシンプルなKey-Valueストアで管理されている.

(userid, idm)→ (state, d)

useridはアクセス認証の検証情報から得られるユーザ IDであり, ユーザ公開鍵から一

意に定まる値である. この場合,対応する秘密鍵による署名を提示することでのみ, state

にアクセスすることが可能である. idmは同じ useridに対する stateの識別子であり,

idmをキーに指定することで同じ useridに対して複数の stateをEnclave内で管理でき,

複数の状態遷移を定義することができる. dは特定のキーの更新数を表す値であり, こ

れにより第 4.2節で述べる状態 IDが一意に決定する.

3.4 ワークフロー

本節では, AnonifyネットワークにTEEが参加する登録フェーズ, 外部からAnonify

へトランザクションを送信する状態遷移フェーズ, そして暗号化に用いられるグループ

鍵をローテーションする鍵ローテーションフェーズのワークフローを述べる.

ここでは, 外部からトランザクションを送信する主体は, Enclaveへアクセス可能な

鍵などの認証情報を保持していることを前提とする. それぞれのワークフローにおける

要素技術の詳細は次章で述べる.

11

3.4.1 登録フェーズ

図 3: 登録フェーズ

TEEが正規の状態遷移プログラムを実行することを検証した上でブロックチェーン

に公開鍵を登録するフェーズである. Remote Attestationにより得られたREPORTの

オンチェーン検証とそれに含まれているEnclave Identity公開鍵のオンチェーンへの登

録を行う. REPORTの検証には, REPORTの署名検証やMRENCLAVEの一致検証な

どが含まれる. 登録フェーズは, 新しいAnonifyネットワークを生成するとき, TEEが

既存のAnonifyネットワークに参加するとき, REPORTタイムスタンプの有効期限が切

れた場合に実施されるフェーズである. また, 新しいノードの参加によるグループ鍵の

更新をするためにハンドシェイクパラメタのブロードキャストも行う. TEEがEnclave

を生成してから, Anonify上の特定のグループに参加するまでのワークフローは以下の

ようになる.

1. Enclave生成時に Enclaveに閉じた Identity鍵ペアを生成

2. Remote Attestationを行う. QUOTEに Identity公開鍵やNonceを含め, Attesta-

tion Serviceに送信し署名付きREPORTのレスポンスを受け取る

3. グループ鍵を共有するためのTreeKEMグループ状態に基づくハンドシェイクを生

成する.

12

4. REPORTとハンドシェイクを含むトランザクションを生成しブロックチェーンに

ブロードキャスト.

5. ブロックチェーン上でのREPORTの一連の検証を通して, Identity公開鍵をブロッ

クチェーンに記録することでTEEの参加が完了する. 新しいAnonifyネットワー

クを生成する場合は, ブロックチェーンでREPORTの検証後にMRENCLAVEを

記録する. 一方, 既存の Anonifyネットワークに参加する場合は, REPORTの検

証後にすでにブロックチェーンに記録されているMRENCLAVEと提示している

MRENCLAVEが一致するか検証を行う.

3.4.2 状態遷移フェーズ

図 4: 状態遷移フェーズ

暗号化された状態遷移の命令を共有するためにトランザクションをブロックチェー

ンネットワークでブロードキャストするフェーズである. ユーザがAnonify上でトラン

ザクションを送信し, ブロックチェーンで共有され他の TEEの状態に反映されるワー

クフローは以下のようになる. また, ユーザとは認証情報を持つ外部のエンティティを

指し, TEEの運営者が管理している場合もある.

13

1. 外部エンティティがTEEに対してアクセスに必要な認証情報と状態遷移の命令と

競合を回避しなければならない状態に関する状態 ID (第 4.2節) を含む状態遷移の

インプットを送信する. 送金アプリケーションの場合は, 状態遷移のインプットに

命令として送金額と送り手, 受け手の useridを入れ, 状態 IDに送り手の useridと

残高に基づくハッシュ値を入れる.

2. Enclave内で認証情報の検証を行い, TEEは状態遷移の命令を暗号化, Enclave Iden-

tity秘密鍵による署名, 第 4.2節で述べる状態 IDの計算を行い, ブロックチェーン

ノードにこれらのデータを含めたトランザクションをブロードキャストする.

3. ブロックチェーン上のスマートコントラクトでEnclave Identity公開鍵による署名

検証後, 暗号文を記録する.

4. ネットワーク内の全てのTEEはブロックチェーンに記録されたトランザクション

データから状態 IDを検証後, Enclave内で暗号文を復号し状態遷移ロジックを実

行, 状態データの更新をする. 送金アプリケーションの場合は, 送り手の残高が送

金額分減り, 受け手の残高がその分増える. Application KeyChainはTreeKEMに

基づく鍵の算出ロジックであり一連の処理が反映後, KeyChainの更新を行う.

3.4.3 鍵ローテーションフェーズ

図 5: 鍵ローテーションフェーズ

全ての TEEで共有しているグループ暗号鍵をローテーションするフェーズである.

Anonifyネットワークに参加しているTEEの運営者が第 2.3節で述べた暗号鍵のPost-

compromise Securityの性質を満たすために行う. このフェーズを実施するタイミング

14

はそれぞれの運営者が柔軟に設定可能である. 具体的なワークフローは以下のように

なる.

1. TEEの運営者は, 自身のクライアントを介して鍵ローテーションのリクエストを

TEEへ送信する.

2. リクエストに合わせて新しい鍵を内部で生成あるいは外部から取得を行う.

3. 新しい鍵を用いてTreeKEMのグループ状態を更新するために必要なハンドシェイ

クを計算する.

4. 全ての TEEで TreeKEMのグループ鍵を更新するために参加している TEEの公

開鍵を用いて暗号化しブロックチェーンへブロードキャストする.

5. それぞれの TEEはフェッチした暗号文を自身の秘密鍵で復号し, TreeKEMのグ

ループ状態をアップデートし, グループ鍵算出に用いられる共通のグループシード

値が得られる.

4 Anonifyのサブプロトコル

本章では, Anonifyを構成するサブプロトコルについて説明する. なお, Σは安全な

署名スキームとする.

4.1 Enclaveへのアクセス認証

特定のユーザ IDに対する状態遷移の実行や状態の取得はそのアクセス権限を保持す

る主体のみが実行可能である. ここでは, 署名検証に基づくチャレンジ・レスポンス認証

を用いる. まず, クライアントからのTEEヘのアクセスリクエストに対し, TEEは擬似

乱数 cをレスポンスする. 続いて, クライアントは秘密鍵 skuで cに署名し, TEEへ送信

する. TEEはクライアントが cに対して署名したことを, クライアントの公開鍵 pkuに

より検証する. この署名検証に成功した場合, TEEは pkuからユーザ ID useridを算出

し, そのクライアントが useridに対応するEnclave内の状態データにアクセスすること

を許可する. ただし, クライアントの公開鍵からユーザ IDは一意に定まるものとする.

15

Algorithm 1 Challenge-response authentication

1: Prover P:2: (pku, sku) := Σ.keygen(1λ)

3: receive c from V4: σc := Σ.sign(sku, c)

5: send σc to V6: Verifier V:7: c← {0, 1}λ

8: send c to P9: receive σc from P

10: assert Σ.verify(pku, σc, c)

4.2 状態 ID

第 3.1節で定義された脅威モデルにおいて攻撃者は, TEEのネットワーク I/Oのイ

ンターセプトや, 不正なブロックチェーンノードの稼働により, 不正な状態データから

状態遷移の命令を送信することが可能である. これにより, 例えば以下のような攻撃が

考えられる.

• ブロックチェーンに記録されたトランザクションのTEEへの反映を遅延もしくは

スキップすることで, ある状態遷移が実行される前の状態において命令を生成する

攻撃. 送金アプリケーションでは, 攻撃者は自身のTEEにおいて, 自身の送金トラ

ンザクションの反映を遅らせ, 送金額が残高から引かれる前に本来の残高以上の金

額を送金する命令の作成が可能となる.

• ブロックチェーンに記録されていないトランザクションをTEEへ反映することで,

不正な状態遷移が実行された後の状態において命令を生成する攻撃. 送金アプリ

ケーションでは, 攻撃者が管理する 2つのユーザAとBに関し, AからBへの送金

トランザクションをネットワークにブロードキャストしないまま, 自身のTEEに

反映することで, Bが本来の残高以上の金額を送金する命令の作成が可能となる.

これらの攻撃により生成されたトランザクションがブロードキャストされた場合に,

その他のTEEが状態遷移フェーズにおいて検出できるよう, Anonifyは状態 IDという

仕組みを提供する. 具体的には, 遷移前の状態データから導出される状態 ID stateid を

以下のように定義し, 上記の攻撃で攻撃者が利益を被る状態に対する状態 IDをトラン

ザクションに含める. 例えば, 残高以上の金額を送金が実行されないように送金者の状

態 IDは含め, 受金者の状態 IDは含めない.

stateid = hash(userid ∥ idm ∥ state ∥ d)

16

idmは, 同じ useridに紐付く状態の識別子であり, stateが状態データを表す. そして,

ブロックチェーンに記録されたトランザクションによりTEEに新しい状態を反映する

際, Enclave内で更新しようとしている状態データが状態 IDと適合するか検証する. こ

れにより, 不正な状態データに対する状態遷移の命令を他のTEEが検出でき, トランザ

クションの署名からどのTEEで不正が起きたのか特定が可能である.

4.3 Attested Execution

Anonifyでは, 状態遷移の処理はオフチェーンのTEEで行い, オンチェーンで状態遷

移が正しく行われていることの検証を行う. このように, ブロックチェーンネットワー

クに参加する全てのTEEが確かに正しい状態遷移ロジックを実行していることを保証

する仕組みをAttested Executionと呼ぶ. Attested Executionは TEEの登録時に行う

Remote Attestationの仕組みを利用し, トランザクションをブロードキャストするたび

に実行されるサブプロトコルである. Remote Attestationは, プロセッサ製造時に組み

込まれた固有の鍵を用い, プロセッサが生成するデータ構造体 (MRENCLAVEを含む)

を署名し, Attestation Serviceに送信する. Attestation Serviceは署名検証を行い, CPU

のセキュリティバージョンやCRL (リボケーションリスト) の検証によりCPUの正当

性状態やMRENCLAVEを含むデータ構造体を署名し, TEEヘレスポンスする.

Remote Attestationにより, 状態遷移プログラムの完全性を保証する. TEEがAttes-

tation Serviceに送信したQUOTEリクエストに対し, REPORTとその署名 σattが返さ

れる. Enclaveを初期生成する時に Enclave Identity鍵ペア (pke, ske)を生成し, pkeを

wv,cに含め, ブロックチェーン上に登録する. これにより, Attested Executionは pkeに

よる署名検証に置き換えることができる. なぜなら, (pke, ske)はEnclaveの実行プログ

ラムに依存するため, skeによる署名がRemote Attestationと同じ完全性を与えること

ができる. このRemote AttestationはオンチェーンへのTEEの登録時のみに行われる.

Algorithm 2 Setup Attested Execution

1: Prover P:2: (pke, ske) := Σident.keygen(1

λ)

3: rn← {0, 1}λ

4: // Remote Attestation

5: (wv,c, σatt) := attestation(pke, rn)

6: send (wv,c, σatt) to V7: Verifier V:8: receive (wv,c, σatt) from P9: assert Σatt.verify(pkatt, σatt, wv,c)

10: register pke

17

4.4 TreeKEM

ブロックチェーンを介し複数のTEE間で, 暗号化に使用するグループ鍵を効率的に

管理するために TreeKEM [16]を応用する. TreeKEMは, バイナリツリーのインデッ

クスを iで表現し, 自身のリーフノードは鍵ペア用いて (pki,e, ski,e), 自身以外のリーフ

ノードは (pki,e, ·)と表現できる. eは, グループのエポックであり, グループ鍵のロー

テーションやメンバの追加, 脱退によりエポックはインクリメントされていく. ここで,

ノードの秘密鍵 ski,eと親ノードの secreti,eは以下のように導出される.

ski,e := kdf(“node”, secreti,e)

secreti,e := kdf(“path”, secreti±1,e)

このようにして自身の鍵ペアと他参加者の公開鍵から導出されたルートノードをシー

ドとすることで, グループに参加するメンバーに共通の鍵を生成することができる. 鍵

ローテーションによりエポック eはインクリメントされ secreti,e+1が自身の新しいリー

フノードにセットされ, 新しいグループ鍵を導出するためのパラメタがブロックチェー

ンを介してブロードキャストされる (詳細は [16]を参照). 以上のように, 鍵ローテー

ション操作あるいはメンバーの追加・削除によりルートノードが更新され, TreeKEMの

グループ状態が S0,S1, ...,Snと遷移していく.

一方,それぞれのグループ状態のルートノードから鍵導出関数によりApplication Key

である ke,f,g (f : グループ内におけるメンバーのインデックス, g: Application Keychain

のインデックス)が導出される. メッセージをブロックチェーンから受け取り, 復号する

際にApplication Keychainが以下のように進む.

ke,f,g := kdf(f, ke,f,g−1)

ブロックチェーンに記録する命令データに対する暗号文は以下のように表記される.

Ce,f,g := Enc[ke,f,g](idfn ∥ input ∥ padding)

idfnは事前に決められた状態遷移ロジックに対する識別子である. paddingにより input

のサイズの違いを吸収し, 全ての暗号文を同じサイズにすることで暗号文サイズから実

行する状態遷移の情報が漏洩しないようにする.

4.5 暗号鍵管理と監査

鍵 secreti,eを生成・管理する手法は, 監査機能の提供有無により以下の 2つに分類で

きる.

• 監査機能を提供しない場合: TEEで secreti,eを生成・管理するためハードウェア

レベルで外部からのアクセスを防ぎ, 監査機能の提供は行わない.

18

• 監査機能を提供する場合: 監査主体が外部で secreti,eを生成・管理する.

前者の方法では, TEEでの擬似乱数をシードに secreti,eを生成し, SealingなどTEE

に閉じた鍵で secreti,eを暗号化して外部ストレージに記録し管理する. 後者の方法で

は, 特定の監査主体が状態遷移を監査できるよう, 監査主体が外部の鍵管理サービスで

secreti,eを生成し, 利用時にTEEがそれをリクエストする. 監査主体は secreti,eをTEE

の外部で保持しているため, ブロックチェーンにアクセスして取得したCe,f,gを自身が

管理している secreti,eとブロックチェーン上の e, f, g の情報から ke,f,gを生成し, 暗号

文を復号できる.

5 実装とパフォーマンス評価

本章では, Anonifyの実装とそのパフォーマンス評価を述べる. AnonifyはRust SGX

SDK11を用いてRustで実装し, パフォーマンス評価はMicrosoft Azureで 2コアの Intel

Xeon E-2176G 3.70 GHz CPU, 8GB RAM, Ubuntu 18.04.4 LTS上でSGXが動作可能な

VM環境で行った. また, Ethereumのトークン規格である ERC2012を参考に, transfer,

transfer from, approve, mint, burnの状態遷移の命令を実装した. これらの命令および,

鍵ローテーションの命令 key rotationと, TEEの登録の命令 registerの SGXマシン上

でのトランザクション生成時間をそれぞれ測定したところ, 以下の結果となった.

関数 transfer transfer from approve mint burn key rotation register

処理時間 [ms] 0.305 0.335 0.313 0.351 0.339 0.328 415

表 1: 各メソッドに対するトランザクション生成時間

registerはRemote Attestationが外部のAttestation Serviceにリクエストを送信する

ため, 他のメソッドと比較して処理に長い時間がかかった. その他のメソッドに関して

は SGXマシン上でトランザクション生成をする.

6 Anonifyプロトコルの拡張

6.1 オンチェーンデータとのインターオペラビリティ

Anonifyプロトコルにより秘匿化されている平文の状態データは全てTEEに記録さ

れており, Anonifyプロトコル外でスマートコントラクトにより管理されているアセット

データと相互に変換はできない. 例えば, スマートコントラクトで管理されているトー

11https://github.com/apache/incubator-teaclave-sgx-sdk12https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol

19

クンをAnonifyプロトコルに反映し, 秘匿化されたトークンとして扱うことは現状でき

ない. そこで, このようなブロックチェーン上の既存のアセットデータとAnonifyプロ

トコル内のデータのインターオペラビリティを可能にするプロトコルを提案する. この

インターオペラビリティは以下で述べるインポート機能とエクスポート機能に分けら

れ, これら 2つの機能が第 3.1節で述べたAnonifyのセキュリティプロパティを満たし

ながら安全に実現できることを目標とする.

• インポート機能: オンチェーンのスマートコントラクトで管理されているデータを

Anonify内の状態データとして取り込む機能である. スマートコントラクトで管理

されているアセットデータをAnonifyプロトコルにインポートするために, エスク

ローコントラクト13などをデプロイし, Anonifyプロトコルがそのコントラクトの

イベントを読み取るように稼働させておく. クライアントがエスクローコントラ

クトの deposit関数を実行するトランザクションを送信すると, トークンはエスク

ローコントラクトにロックされ, TEEの状態データに userid, トークン量, コント

ラクトアドレスが記録される. この状態データはAnonifyプロトコル内で状態遷移

させることが可能である.

• エクスポート機能: Anonifyプロトコルで管理されている状態データをAnonify管

理外のスマートコントラクト上の状態データとして取り出す機能である. TEEが

エスクローコントラクトのwithdraw関数などを実行するトランザクションを送信

することで, 指定したトークン量を useridに対して取り出すことができる. TEE

はそのトランザクションを読み取り, useridが保持するトークンをその分減少さ

せる.

これらの機能により, 例えば証券のDvP決済において, オンチェーンのスマートコント

ラクトで管理されている法定通貨建てのトークンと, Anonifyで秘匿化して管理する証

券データをアトミックに交換することが可能となる.

エクスポート機能を実現するためには, エクスポートのトランザクションの正しさが

オンチェーンで検証可能である必要がある. ここで, 第 4.2節で述べた手法により, 攻撃

者は自身の TEEの状態データを不正に書き換えることができるため, 不正な状態デー

タからエクスポートのトランザクションを生成することが可能である. 例えば, Anonify

内で実際には受け取っていないトークン, または, 他ユーザーに既に移転したトークン

をエクスポートするトランザクションが生成可能である. このようなトランザクション

は第 4.2節の状態 IDにより, 他の TEEでは事後的に検出可能であるが, オンチェーン

で検出することはできない.

13https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/payment/escrow/Escrow.sol

20

そこで, 不正な状態データのエクスポートをオンチェーンで防止するために, TEE内

のライトクライアント機能とオンチェーンでの状態 IDの重複検証を加える. ここで, ラ

イトクライアント機能とは, ブロックチェーンのデータを全て保持せずに, あるトラン

ザクションが記録されたことを検証する仕組みである. ライトクライアント機能をTEE

内に実装することで, 攻撃者はブロックチェーンにトランザクションを記録する以外の

方法で不正にTEEの状態データを更新することが不可能となる. なお、TEE内にライ

トクライアント機能を実装する仕組みは Ekiden [22]において Proof of Publicationと

して議論されており, PoWベースの Nakamotoコンセンサス用のライトクライアント

機能が提案されている. 次に, オンチェーンでの状態 IDの重複検証とは, エクスポート

のトランザクションが含む状態 IDが既に他のトランザクションに含まれている場合に,

そのエクスポートを無効化することである. エクスポートのトランザクションに, エク

スポートする状態データに紐づく状態 IDを強制的に含ませることで, 攻撃者が過去の

状態データをエクスポートすることは不可能となる. 以上の仕組みにより, 正当かつ最

新の状態データのエクスポートのみが可能となることを保証できる.

6.2 送受金の競合の回避

Anonifyではある状態データに関して, その保有者であるユーザ自身による状態遷移

と, その他のユーザによる状態遷移とが競合してしまう場合がある. 例えば, トークン

管理等のユースケースにおいて, ユーザAが送金をするトランザクション TA と, ユー

ザ BがユーザAに送金をするトランザクション TB が同時に生成されたとする. この

とき, TAより前に, TBがブロックチェーンに記録されると, TEEにおいても TB が TA

より先に反映される. その結果, ユーザAの残高が TA の生成時点から変化しているた

め, TA の状態 IDは不正となり, TA の状態遷移は実行されなくなる. このような状態遷

移の競合は, ユースケースによっては実用上の課題となりうる.

このような問題を解決するため, Zether [23]で提案されているPending stateと同様

の仕組みを導入できる. 例えばトークン管理等のユースケースでは, 各ユーザは自分が

送金に使うトークン用のメインの状態データと, 他ユーザから送金された金額の合計を

一時的に記録する状態データを分け, 定期的にメインの状態データに合算する等が可能

である.

7 関連プロジェクト

本章では, Anonifyに関連するブロックチェーンにおけるプライバシ保護に取り組む

プロジェクトとして, ゼロ知識証明とTEEを用いたものについて説明する.

21

7.1 ゼロ知識証明

ブロックチェーンのプライバシ保護を保護するために, 送信するトランザクション

データを暗号化し, 相手に復号するための鍵を共有するアプローチがある. ゼロ知識証

明は, この時の計算の正しさ（送金額の範囲制限や暗号化処理の完全性）を送信者の秘

密鍵や送金額などの平文を明らかにせずグローバルに保証することができる. つまり,

ブロックチェーンにブロードキャストされたバイト列が特定の “正しい”暗号文である

ことを保証する.

ユーザの匿名性を保護するためのナイーブな施策としては, 利用するアドレスをその

都度, 新しく生成する方法があげられる. 本方式は, UTXO型ブロックチェーンに対す

るWalletで実装されている. 個人と紐付くアドレスが毎回新しくなるため, 一見, 匿名

性が保護されるよう思えるが, 状態に対するトランザクション同士の繋がりが特定のア

ドレス間の繋がり (Linkability) を明らかにしてしまう [24, 25]. これにより, 結局それ

ぞれの新しいアドレスと特定の主体がヒューリスティックに紐付けられてしまう. これ

を緩和するために, CryptoNote Protocol [26]ではリング署名を用いて, 複数のメンバ公

開鍵をインプットとし, 第三者からはどのメンバ公開鍵に対応する秘密鍵によって署名

されているのか識別できないようにしているが, 依然として多くのLinkability攻撃が提

案されている [27, 28, 29].

Zcash Protocolでは, トランザクション同士の Linkabilityが一切明らかにならない

ように, 未使用の状態データをAppend-onlyなMerkle Treeのリーフに記録し, 消費し

た状態データを別のプールにMerkle Treeのリーフインデックスと紐づかない形で記録

していく. Merkle Treeに記録されている特定の状態を消費するときに, 自身がその状態

を保持していること, 確かにMerkle Treeのリーフに含まれていること, 消費済みプー

ルに記録されていないこと（二重支払い防止）などをゼロ知識証明を用いて保証する.

加えて, これらのプロトコルは特定の監査主体に対してアドレスと紐付く特定の復号鍵

を渡すことで, ブロックチェーン上のそのアドレスが送信元となっている暗号文を復号

可能にする.

ゼロ知識証明によるプライバシ保護の取り組みは上記のようにUTXO型のブロック

チェーンプロトコルにおいてだけではなく, Ethereum14などのスマートコントラクトを

ベースにしたアプリケーションレイヤにおいても実装が進められている. 代表的なプ

ロジェクトとしては, 従来の zk-SNARKs(ゼロ知識証明)において問題視されていたパ

ラメタ生成 (Trusted Setup) を算術回路非依存にすることが可能な Plonk [30]をベー

スにしてプライバシ保護のフレームワークを提供するAztec15がある. その他にも EY,

14https://ethereum.org/15https://www.aztecprotocol.com/

22

ConsenSys, Microsoftらが連携して取り組むBaseline Protocol16もエンタープライズ向

けの基幹業務システムなどをゼロ知識証明を用いて機密データの保護をしようとして

いる. また以上の取り組みは現状, 比較的シンプルな送金などの状態遷移の秘匿化, 匿

名化に対するアプローチであったが, Hawk [31]や Zexe [1]のように任意の状態遷移に

対しゼロ知識証明を適用しようとする取り組みも行われている.

以上のように,ゼロ知識証明を用いて状態遷移の完全性を与えることでブロックチェー

ンにおけるプライバシ保護を行うアプローチの開発プロジェクトは活発に進んでいる一

方で, 証明時の計算オーバーヘッドや監査の困難さなど現実のアプリケーションに適用

するためには多くの技術的課題が存在する. 特に, 表現力の高い状態遷移ロジックのプ

ライバシ保護は算術回路における任意の状態遷移ロジックの計算や再帰的な実行 (ゼロ

知識証明の検証を算術回路で処理) が原因でより多く証明時オーバーヘッドが生じゼロ

知識証明を応用することは困難である.

7.2 TEE

CCF [32]は, Microsoftが進めている TEEをプロトコルに組み込んだオープンソー

スフレームワークである. 秘匿化すべきデータはTEEで暗号化し, その他のデータは平

文でブロックチェーンに記録する. CCFはTEEをブロックチェーンのプロトコルに組

み込んだ設計になっているためAnonifyのようにバックエンドとなるブロックチェーン

は選択できない. また, 暗号化に用いる鍵はそれぞれのノードで秘密分散管理されてい

るため特定の監査機関に対して監査性の機能を与えることはできない.

Hyperledger Avalon [33]は EEA (Enterprise Ethereum Alliance) が策定を進めてい

るOff-Chain Trusted Compute [34]の仕様を元に実装をしているプロジェクトである.

Avalonは TEEだけではなくゼロ知識証明や sMPCなどのソフトウェアベースで完全

性を保証する手法に対しても適用可能なように, より一般的に開発されているフレーム

ワークである. Avalonでは, クライアントからTEEを介してブロックチェーンへ送る

暗号文に対応する鍵を, それぞれワンタイムキーとしてクライアントが生成・管理して

いる. よって, TEEがブロックチェーンに記録された暗号文から状態を取得するために

は全てのワンタイムキーを複数のTEEで同期・保持する必要がある. この制約から, ブ

ロックチェーンに記録した過去の状態に基づき連続的に状態遷移を計算するような使い

方はできない. 一方, Anonifyではネットワーク全体で一意に定まるブロックチェーン

のトランザクションの順序にしたがって, それぞれの TEEで管理するグループ鍵が決

定的に求まる. そのため, 参加している全てのTEEでブロックチェーンに記録されてい

る過去の状態も永続的に活用することが可能である.

16https://www.baseline-protocol.org/

23

Ekiden [22]は, TEEを用いることによりプライバシとスケーラビリティに優れた特

徴を持つ独自のブロックチェーンを目指す. Ekidenはパブリックチェーンを前提として

おり,暗号化鍵を管理するTEEが経済的インセンティブにより分散運営される. Anonify

がエンタープライズ向けブロックチェーンをバックエンドに用いることを想定している

のに対し, Ekidenはスケーラブルかつプライバシ志向なパブリックチェーンを目指して

いる点で大きく異なる. また, Anonifyは状態データに対する外部監査の仕組みを提供

しているのに対し, Ekidenは分散されたTEEクラスタで鍵が秘密分散され管理されて

いるため監査機能は存在しない.

LucidiTEE [35]は, Visa Researchが公表しているTEEとブロックチェーンを用いた

マルチパーティー計算 (sMPC) のプロトコルである. 複数のプレイヤーが機密性の高

いデータを他者には秘匿にしつつTEEを用いて協力して計算を行う. この計算自体は

TEEで行われるが, TEEは外部との I/O部分を保護することはできない（インターセ

プトなどが悪意あるOSにより潜在的に可能）ため, 過去の状態に依存したマルチパー

ティー計算や全てのパーティに対する公平性の保証がTEE単体では困難であるためブ

ロックチェーンを用いる. 参加パーティ全員がアクセス可能なブロックチェーンに対し

て計算のインプット, アウトプットあるいは更新状態値のハッシュ値をコミットしてお

くことで上記のポリシーに従うようにマルチパーティ計算を行うことを可能にする. つ

まり, Anonifyはブロックチェーンとしてのロバスト性のある状態データの保持を目指

しているのに対し, LucidiTEEは公平性を満たした秘密計算の大規模処理を目指してい

る点で異なる. LucidiTEEは復元可能な状態を全員に可用なブロックチェーンにおか

ず, 秘密計算のための暗号化された更新状態としてローカルに記録する.

8 結論

ブロックチェーンのプライバシを保護するシステムであるAnonifyの性質とアーキ

テクチャを述べた. TEEをベースに状態データの秘匿性と完全性を保証することで, 効

率的かつ汎用的な状態遷移のプライバシ保護を実現する. 加えて, 特定の監査主体が復

号のための鍵を管理することで監査機能を提供するスキームも持つ. 今後は, TEEに記

録している状態データを暗号化して外部ストレージに保存するスナップショット機能,

自身が管理しているアカウントに対する状態データのエクスプローラ機能, クライアン

トの新しいアクセス認証方法の対応などの機能拡充や実装レベルでのセキュリティ・パ

フォーマンス向上を進めていく.

24

謝辞

BI-SGX17の開発者であり, 2019年度未踏スーパークリエータである櫻井碧氏には

Intel SGXに関する多くの有益なご助言をいただき感謝申し上げます.

参考文献

[1] Sean Bowe, Alessandro Chiesa, Matthew Green, Ian Miers, Pratyush Mishra, and

Howard Wu. Zexe: Enabling decentralized private computation. In 2020 IEEE

Symposium on Security and Privacy (SP), pages 820–837, 2018.

[2] Victor Costan and Srinivas Devadas. Intel sgx explained. IACR Cryptology ePrint

Archive, 2016(086):1–118, 2016.

[3] Sandro Pinto and Nuno Santos. Demystifying arm trustzone: A comprehensive

survey. ACM Computing Surveys (CSUR), 51(6):1–36, 2019.

[4] Dayeol Lee, David Kohlbrenner, Shweta Shinde, Dawn Song, and Krste Asanovic.

Keystone: A framework for architecting tees. arXiv preprint arXiv:1907.10119,

2019.

[5] Ferdinand Brasser, Urs Muller, Alexandra Dmitrienko, Kari Kostiainen, Srdjan

Capkun, and Ahmad-Reza Sadeghi. Software grand exposure:{SGX} cache attacksare practical. In 11th {USENIX} Workshop on Offensive Technologies ({WOOT}17), 2017.

[6] Jo Van Bulck, Nico Weichbrodt, Rudiger Kapitza, Frank Piessens, and Raoul

Strackx. Telling your secrets without page faults: Stealthy page table-based at-

tacks on enclaved execution. In 26th {USENIX} Security Symposium ({USENIX}Security 17), pages 1041–1056, 2017.

[7] Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim, Hyesoon Kim, and Marcus

Peinado. Inferring fine-grained control flow inside {SGX} enclaves with branch

shadowing. In 26th {USENIX} Security Symposium ({USENIX} Security 17),

pages 557–574, 2017.

[8] Yuanzhong Xu, Weidong Cui, and Marcus Peinado. Controlled-channel attacks:

Deterministic side channels for untrusted operating systems. In 2015 IEEE Sym-

posium on Security and Privacy, pages 640–656. IEEE, 2015.17https://bi-sgx.net/

25

[9] Kit Murdock, David Oswald, Flavio D. Garcia, Jo Van Bulck, Daniel Gruss, and

Frank Piessens. Plundervolt: Software-based fault injection attacks against intel

sgx. In Proceedings of the 41st IEEE Symposium on Security and Privacy (S&P’20),

2020.

[10] Ferdinand Brasser, Srdjan Capkun, Alexandra Dmitrienko, Tommaso Frassetto,

Kari Kostiainen, Urs Muller, and Ahmad-Reza Sadeghi. Dr. sgx: hardening sgx

enclaves against cache attacks with data location randomization. arXiv preprint

arXiv:1709.09917, 2017.

[11] Yangchun Fu, Erick Bauman, Raul Quinonez, and Zhiqiang Lin. S gx-l apd:

Thwarting controlled side channel attacks via enclave verifiable page faults. In

International Symposium on Research in Attacks, Intrusions, and Defenses, pages

357–380. Springer, 2017.

[12] Daniel Gruss, Julian Lettner, Felix Schuster, Olya Ohrimenko, Istvan Haller, and

Manuel Costa. Strong and efficient cache side-channel protection using hardware

transactional memory. In 26th {USENIX} Security Symposium ({USENIX} Secu-rity 17), pages 217–233, 2017.

[13] Ming-Wei Shih, Sangho Lee, Taesoo Kim, and Marcus Peinado. T-sgx: Eradicating

controlled-channel attacks against enclave programs. In NDSS, 2017.

[14] us-19-davidov-inside-the-apple-t2.pdf. https://i.blackhat.com/USA-19/

Thursday/us-19-Davidov-Inside-The-Apple-T2.pdf. (Accessed on

05/29/2020).

[15] Attestation service for intel(r) software guard extensions: Api doc-

umentation. https://api.trustedservices.intel.com/documents/

sgx-attestation-api-spec.pdf. (Accessed on 04/11/2020).

[16] Karthikeyan Bhargavan, Richard Barnes, and Eric Rescorla. Treekem: Asyn-

chronous decentralized key management for large dynamic groups, 2018.

[17] Joel Alwen, Sandro Coretti, Yevgeniy Dodis, and Yiannis Tselekounis. Security

analysis and improvements for the ietf mls standard for group messaging. Technical

report, Cryptology ePrint Archive, Report 2019/1189, 2019. https://eprint. iacr.

org ….

26

[18] Joel Alwen, Margarita Capretto, Miguel Cueto, Chethan Kamath, Karen Klein,

Guillermo Pascual-Perez, Krzysztof Pietrzak, and Michael Walter. Keep the dirt:

Tainted treekem, an efficient and provably secure continuous group key agreement

protocol.

[19] Richard Barnes, Karthikeyan Bhargavan, and Christopher A. Wood. Hybrid Public

Key Encryption. Internet-Draft draft-irtf-cfrg-hpke-03, Internet Engineering Task

Force, May 2020. Work in Progress.

[20] Richard Barnes, Benjamin Beurdouche, Jon Millican, Emad Omara, Katriel Cohn-

Gordon, and Raphael Robert. The Messaging Layer Security (MLS) Protocol.

Internet-Draft draft-ietf-mls-protocol-09, Internet Engineering Task Force, March

2020. Work in Progress.

[21] Joel Alwen, Sandro Coretti, and Yevgeniy Dodis. The double ratchet: Security

notions, proofs, and modularization for the signal protocol. In Annual International

Conference on the Theory and Applications of Cryptographic Techniques, pages

129–158. Springer, 2019.

[22] Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah

Johnson, Ari Juels, Andrew Miller, and Dawn Song. Ekiden: A platform for

confidentiality-preserving, trustworthy, and performant smart contract execution.

arXiv preprint arXiv:1804.05141, 2018.

[23] Benedikt Bunz, Shashank Agrawal, Mahdi Zamani, and Dan Boneh. Zether:

Towards privacy in a smart contract world. IACR Cryptology ePrint Archive,

2019:191, 2019.

[24] Dmitry Ermilov, Maxim Panov, and Yury Yanovich. Automatic bitcoin address

clustering. In 2017 16th IEEE International Conference on Machine Learning and

Applications (ICMLA), pages 461–466. IEEE, 2017.

[25] Michael Fleder, Michael S Kester, and Sudeep Pillai. Bitcoin transaction graph

analysis. arXiv preprint arXiv:1502.01657, 2015.

[26] Shi-Feng Sun, Man Ho Au, Joseph K Liu, and Tsz Hon Yuen. Ringct 2.0: A

compact accumulator-based (linkable ring signature) protocol for blockchain cryp-

tocurrency monero. In European Symposium on Research in Computer Security,

pages 456–474. Springer, 2017.

27

[27] Dimaz Ankaa Wijaya, Joseph Liu, Ron Steinfeld, and Dongxi Liu. Monero ring

attack: Recreating zero mixin transaction effect. In 2018 17th IEEE Interna-

tional Conference On Trust, Security And Privacy In Computing And Communi-

cations/12th IEEE International Conference On Big Data Science And Engineering

(TrustCom/BigDataSE), pages 1196–1201. IEEE, 2018.

[28] Amrit Kumar, Clement Fischer, Shruti Tople, and Prateek Saxena. A traceability

analysis of monero’s blockchain. In European Symposium on Research in Computer

Security, pages 153–173. Springer, 2017.

[29] Malte Moser, Kyle Soska, Ethan Heilman, Kevin Lee, Henry Heffan, Shashvat

Srivastava, Kyle Hogan, Jason Hennessey, Andrew Miller, Arvind Narayanan, et al.

An empirical analysis of traceability in the monero blockchain. Proceedings on

Privacy Enhancing Technologies, 2018(3):143–163, 2018.

[30] Ariel Gabizon, Zachary J Williamson, and Oana Ciobotaru. Plonk: Permutations

over lagrange-bases for oecumenical noninteractive arguments of knowledge. Tech-

nical report, Cryptology ePrint Archive, Report 2019/953, 2019.

[31] Ahmed Kosba, Andrew Miller, Elaine Shi, Zikai Wen, and Charalampos Papaman-

thou. Hawk: The blockchain model of cryptography and privacy-preserving smart

contracts. In 2016 IEEE symposium on security and privacy (SP), pages 839–858.

IEEE, 2016.

[32] Mark Russinovich, Edward Ashton, Christine Avanessians, Miguel Castro, Amaury

Chamayou, Sylvan Clebsch, Manuel Costa, Cedric Fournet, Matthew Kerner, Sid

Krishna, et al. Ccf: A framework for building confidential verifiable replicated

services. Technical report, Technical Report MSR-TR-2019-16, Microsoft, 2019.

[33] hyperledger/avalon: Hyperledger avalon. https://github.com/hyperledger/

avalon. (Accessed on 04/16/2020).

[34] Enterprise ethereum alliance off-chain trusted compute specification v1.1. https:

//entethalliance.github.io/trusted-computing/spec.html. (Accessed on

04/21/2020).

[35] Rohit Sinha, Sivanarayana Gaddam, and Ranjit Kumaresan. Luciditee: Policy-

based fair computing at scale. IACR Cryptology ePrint Archive, 2019:178, 2019.

28