Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Anonify

Osuke
June 25, 2020

 Anonify

Osuke

June 25, 2020
Tweet

More Decks by Osuke

Other Decks in Technology

Transcript

  1. 1 © LayerX Inc. A Blockchain-Agnostic Execution Environment with Privacy

    and Auditability Blockchain Tokyo Osuke Sudo 2020/06/25
  2. 3 © LayerX Inc. アジェンダ 1. ブロックチェーンにおけるプライバシー保護 2. Anonifyの仕組み 1.

    請求書ワークフローについて 2. Anonifyを使った請求書管理ソリューションのデモとその解説 Anonify理論編 Anonify実践編
  3. 5 © LayerX Inc. ブロックチェーンの基本性質 Block 1 Block 2 Block

    N T T T State 1 State 2 State N ハッシュ 監査性・自動検証 • 状態遷移の履歴を自動的に検 証可能 • 状態データへの改ざん耐性 • ビジネスロジックが正しく実 行されていることを監査可能 • ノード・ネットワークの故障 に対する耐性 • 特定参加者がビジネス上の理 由で離脱しても稼働し続ける • 悪意ある攻撃に対しても頑健 • 標準化されたルールの強制 • データとワークフローの一体 化 • アセットにロジックを埋め込 み 故障・攻撃に対する ロバストさ ビジネスロジックの 強制執行 T T T T T T ハッシュ
  4. 6 © LayerX Inc. ブロックチェーンにおけるプライバシー問題 ブロックチェーン From To Amount Alice

    Bob 10,000 トランザクション Alice Bob • ブロックチェーンにアクセス可能な主体は全ての取引情報(トランザクション)に記録さ れているアドレスや取引データを閲覧することが可能 ◦ ネットワークを構成する他社に対して自社の取引情報が明らかになってしまう
  5. 7 © LayerX Inc. エンタープライズ向けブロックチェーン ブロックチェーン From To Amount Alice

    Bob 10,000 トランザクション Alice Bob • QuorumのPrivate Transaction, CordaのNon-validating notary, Hyperledger Fablicの Private Dataなど機能では、機密性の高いデータはを共有しないアプローチ • 秘匿化対象のデータを参加者が外部に漏洩することはプロトコルで防ぐことができず、そ れを検知することもできない
  6. 8 © LayerX Inc. ゼロ知識証明・TEE ブロックチェーン From To Amount Alice

    Bob 10,000 トランザクション Alice Bob • 機密性の高いデータを暗号化することで秘匿性を保証しつつ、状態遷移を実行可能 • 暗号文の完全性を保証する手法として、 ◦ ゼロ知識証明:暗号学的技術のみを利用 ◦ TEE:ハードウェアのセキュリティ機能を利用 • ゼロ知識証明は汎用的な状態遷移ロジックの処理が困難
  7. 9 © LayerX Inc. 既存アプローチが抱える課題 概要 評価 既存手法 エンタープライズ・ ブロックチェーン

    (Hyperledger Fabric, Corda, Quorum 等のビルトイン機能) ゼロ知識証明 (Zcash, ZEXE 等) TEE (CCF, Ekiden 等) • 共有するノードを限定することで秘匿 化を実現 • ブロックチェーンで暗号化された状態 データを共有 • ビジネスロジックの完全性を暗号学的 に保証 • ブロックチェーンで暗号化された状態 データを共有 • ハードウェアレベルの機能でビジネス ロジックの完全性を保証 監査機能 柔軟な 状態遷移 複数者間での 秘匿性
  8. 11 © LayerX Inc. Anonifyが活用するTEEの性質 Confidentiality Enclave内のプログラムやデータを秘匿化 Execution Integrity 正しいプログラムを実行していることの保証

    ハードウェア OS Apps Enclave プロセッサセキュリティ機能TEE(Intel SGX®等)によって 隔離保護されたメモリ領域Enclave内でアプリケーションを実行
  9. 12 © LayerX Inc. Anonify TEE1 ブロックチェーン TEE2 Client 平文

    暗号文 TEE3 Client Client 秘匿化された状態データをオフチェーンで管理する汎用プライバシー保護モジュール オフチェーン処理 • ビジネスロジックの実行 (Execution Integrity) • 暗号化・復号化 (Confidentiality) オンチェーン処理 • 暗号化された命令をトランザク ションに載せて共有 • ビジネスロジックの検証
  10. 13 © LayerX Inc. TEE2 Anonifyによる送金アプリケーションの実装例 a AliceからBobへ送金する例 暗号化した状態遷移命令 ・送信元:

    Alice ・送信先: Bob ・送金額: 60 AliceはTEEでコインの送金命令を作成し、 ブロックチェーンへブロードキャスト Aliceの残高: 100 Bobの残高: 0 暗号化した状態遷移命令 ・送信元: Alice ・送信先: Bob ・送金額: 60 各TEEはブロックチェーンから命令を取得後、 命令を検証し、TEE内で状態遷移を実行 ブロックチェーン ブロックチェーン TEE1 Aliceの残高: 100 Bobの残高: 0 TEE2 Aliceの残高: 40 Bobの残高: 60 TEE1 Aliceの残高: 40 Bobの残高: 60 Alice Bob Alice Bob
  11. 14 © LayerX Inc. Anonifyが実現する6つの機能・性質 柔軟な状態遷移 ゼロ知識証明では難しい 複雑なビジネスロジックも、 汎用プロセッサで実行可能 監査機能

    特定の監査主体に対し 状態遷移の閲覧権限を付与可能 ロバスト性 他参加者ノードが故障しても 自ノードには影響なし プラットフォーム非依存 様々な種類のブロックチェーンに 対応可能 秘匿化・匿名化 取引内容や取引参加者など トランザクションの中身を 他者は閲覧不可 オンチェーンアセットとの 相互変換 オンチェーンのアセットを Anonifyへデポジットして秘匿化 & チェーン上へ引き出し可能
  12. 15 © LayerX Inc. 4つのフェーズ 鍵ローテーションフェーズ • セットアップしたグループで共有する暗号鍵をローテーションする セットアップフェーズ •

    参加するTEEがAnonifyシステムをセットアップする • オンチェーンのスマートコントラクトに参加するTEEの公開鍵が登録される 状態遷移フェーズ • 暗号化された状態遷移の命令がブロックチェーンに記録され、TEEで状態遷移が 処理される リカバリーフェーズ • 新しいTEEがグループに参加・復旧するフェーズ
  13. 16 © LayerX Inc. 4つのフェーズ 鍵ローテーションフェーズ • セットアップしたグループで共有する暗号鍵をローテーションする セットアップフェーズ •

    参加するTEEがAnonifyシステムをセットアップする • オンチェーンのスマートコントラクトに参加するTEEの公開鍵が登録される 状態遷移フェーズ • 暗号化された状態遷移の命令がブロックチェーンに記録され、TEEで状態遷移が 処理される リカバリーフェーズ • 新しいTEEがグループに参加・復旧するフェーズ
  14. 17 © LayerX Inc. セットアップフェーズ Remote Attestationに基づくセットアップ • Integirtyのセットアップ •

    TEEのRemote Attestationを活用することで、TEEで正しいプログラムが実行され ていることを保証 • オンチェーン上でRemote Attestationの検証を行う グループ鍵のセットアップ • Confidentialityのセットアップ • 参加しているTEEで暗号処理に利用する共通のグループ鍵を共有 • TEE間で通信は行わず、ブロックチェーンを介してセットアップする
  15. 18 © LayerX Inc. Remote Attestationの検証 • Attestation ServiceはIAS(Intel Attestation

    Service)やDCAP(Datacenter Attestation Primitives) • Attestation Serviceの公開鍵をスマートコントラクトに記録 • QuoteはSGXが生成する構造体 • オンチェーンでREPORTの署名を検証することでREPORTが改ざんされていないことを保 証 SGX Attestation Service ブロックチェー ン QUOTE 署名付き REPORT 秘密鍵 公開鍵 署名付き REPORT MRENCLAVE
  16. 19 © LayerX Inc. REPORT構造体 id ユニークな識別子 timestamp REPORT生成時のタイムスタンプ version

    APIバージョン isvEnclaveQuoteSt atus EPID署名に対するステータス CPUCVN CPUのセキュリティバージョン MISCSEKECT Enclave内での例外発生時のプロセッ サ状態 MRENCLAVE Enclave measurement(ハッシュ値) MRSIGNER enclave署名鍵のRSA公開鍵modulusのハッ シュ値 ISVPRODID Enclave Product ID ISVSVN Enclaveのセキュリティーバージョン REPORTDATA レポートデータ(任意) ATTRIBUTES Enclaveのattributesフラグ • MRENCLAVEはREPORTに含まれるEnclaveの設定情報やプログラムに依存するハッシュ値 • MRENCLAVEの一致をオンチェーン上で検証することで確かにそれぞれのTEEが同じプロ グラムを実行していることを保証 • しかし、毎回REPORTを送ってパースしてMRENCLAVEの一致検証をするのは重い。。。 REPORTデータ構造
  17. 20 © LayerX Inc. Enclave Identity Key-pair • REPORTDATAにTEEで生成した公開鍵を含め、セットアップフェーズでオンチェーンに登 録する

    ◦ 鍵ペアはEnclaveのプログラムに紐づく ◦ REPORTDATAも署名されているので改ざん不可 • 状態遷移フェーズで送信する暗号文などは対応する秘密鍵で署名する • これによりTEEが正しいプログラムを動かしていることを署名検証だけで検証可能に TEE Attestation Service ブロックチェー ン QUOTE 署名付き REPORT 秘密鍵 公開鍵 署名付き REPORT MRENCLAVE 秘密鍵 公開鍵 ←REPORT DATA
  18. 22 © LayerX Inc. グループ鍵セキュリティプロパティ • E2EEグループメッセージング「MLS」の中心となるサブプロトコルが「TreeKEM」 ◦ IETF WGのドラフトとして標準化が進められている

    • 以下の2つの性質を満たしつつ、参加TEE間(グループ)で効率的にグループ鍵を管理 ◦ Forward Secrecy:鍵が漏洩してもそれ以前の暗号文は復号不可能(前方秘匿性) ◦ Post-Compromise Security:鍵が漏洩してもそれ以降の暗号文は復号不可能 Forward Secrecy Post-Compromise Security Time
  19. 23 © LayerX Inc. TreeKEM • 鍵ローテーションの効率化などが理由でツリー構造でグループ鍵を管理 • 鍵が使われるごとに決定論的に新しい鍵を生成 ◦

    ブロックチェーンでTxの順番はグローバルに決まっている • 参加者の鍵追加・鍵ローテーションごとに共有するルートの鍵を更新 • リーフの秘密鍵はTEE or 外部監査主体が生成・管理 TEE1 TEE2 TEE3 TEE4 Hash 公開鍵 公開鍵 公開鍵 秘密鍵 秘密鍵 公開鍵 秘密鍵 Post-Compromise Security Forward Secrecy
  20. 24 © LayerX Inc. TEE2 TEE4が新たにグループに参加するセットアップ TEE1 • 全ての参加者が同じルートの秘密鍵に更新 TEE3

    公開鍵 公開鍵 公開鍵 公開鍵 TEE4 New秘密鍵 New秘密鍵 New秘密鍵 BC TEE4 TEE1 TEE2 TEE3 暗号化 暗号化
  21. 26 © LayerX Inc. 状態遷移フェーズ • TEEでKVSで状態を管理 ◦ (Address, id_m)

    => State • チャレンジ・レスポンス認証でKVSにアクセス 命令 {送金者:Alice, 受金者:Bob, 送金額:60} Alice => 100 Bob => 0 Assert: alice_balance > 60 Update: alice_balance - 60 Update: bob_balance + 60