今日まで、ブロックチェーンテクノロジー、暗号通貨、そしてそれがどれほど優れているかについて書いていないのは怠け者だけです。 ただし、この記事ではこのテクノロジーを賞賛することはありません。ただ、その欠点とそれを取り除く方法についてのみ説明します。

Altirix Systems でプロジェクトの XNUMX つに取り組んでいたとき、ブロックチェーン外部のソースからのデータを安全かつ検閲に耐えて確認するという課題が生じました。 XNUMX 番目のシステムのレコードの変更を確認し、これらの変更に基づいてスマート コントラクト ロジックの XNUMX つまたは別の分岐を実行する必要がありました。 一見したところ、このタスクは非常に簡単ですが、プロセスに参加している一方の当事者の財政状態がその実装の結果に依存する場合、追加の要件が表示されます。 まず第一に、それはそのような検証メカニズムに対する包括的な信頼です。 しかし、まず最初に。

問題は、ブロックチェーン自体が自律的で閉鎖的なエンティティであるため、ブロックチェーン内のスマート コントラクトは外の世界について何も知らないことです。 同時に、スマート コントラクトの条件は、多くの場合、現実のものに関する情報 (フライトの遅延、為替レートなど) に関連付けられています。 スマート コントラクトが適切に機能するには、ブロックチェーンの外部から取得した情報が信頼でき、検証されている必要があります。 この問題は、Town Crier や DECO などのオラクルを使用することで解決されます。 これらのオラクルにより、ブロックチェーン ネットワーク内のスマート コントラクトが信頼できる Web サーバーからの情報を信頼できるようになり、これらは信頼できる情報プロバイダーであると言えます。

オラクル

お気に入りのサッカー クラブがロシア カップで優勝した場合、スマート コントラクトによって 0.001 btc がビットコイン ウォレットに送金されると想像してください。 実際に勝利した場合、スマート コントラクトはどのクラブが勝ったかに関する情報を転送する必要があります。ここで多くの問題が発生します。この情報をどこで取得するか、スマート コントラクトに安全に転送する方法、およびスマートコントラクトで受け取った情報は本当に現実と一致しますか?

情報源の問題では、2 つのシナリオが考えられます。XNUMX つは試合の結果に関する情報を一元的に保存する信頼できる Web サイトにスマート コントラクトを接続する方法、もう XNUMX つは複数のサイトに一度に接続し、ほとんどのサイトから情報を選択する方法です。同じデータを提供するソース。 情報が正しいことを確認するために、TLSNotary (データの信頼性を証明するための TLS 変更) を使用する Oraclize などのオラクルが使用されます。 しかし、Google には Oraclize に関する十分な情報があり、Habré に関する記事もいくつかありますが、今日は情報伝達に少し異なるアプローチを使用する Oracle である Town Crier と DECO について説明します。 この記事では、両方のオラクルの動作原理と詳細な比較について説明します。

タウンクライヤー

Town Crier (TC) は、3 年の CCS'2016 で IC16 (The Initiative for CryptoCurrency and Contracts) によって導入されました。 TC の背後にある主なアイデアは、Web サイトからスマート コントラクトに情報を渡し、TC によって配信される情報が Web サイト上の情報と同じであることを確認することです。 TC は TEE (信頼された実行環境) を使用してデータの所有権を認証します。 TC のオリジナル バージョンでは、Intel SGX と連携する方法が説明されています。
Town Crier は、ブロックチェーン内の部分と、OS 自体内の部分 (TC Server) で構成されます。

TC コントラクトはブロックチェーン上にあり、TC のフロントエンドとして機能します。 CU（ユーザースマートコントラクト）からのリクエストを受け付け、TCサーバーからレスポンスを返します。 TC サーバーの内部には、エンクレーブをインターネット (双方向トラフィック) に接続し、エンクレーブをブロックチェーンに接続するリレーがあります。 Enclave には、ブロックチェーンからリクエストを作成し、デジタル署名されたブロックチェーンにメッセージを返すコードである progencl が含まれています。progencl にはスマート コントラクト コードの一部が含まれており、実際にその機能の一部を実行します。

Intel SGX エンクレーブは、ecall を通じて実行される API を備えた共有ライブラリと考えることができます。 Ecall は制御をエンクレーブに転送します。 エンクレーブは、終了するか例外が発生するまでコードを実行します。 エンクレーブの外側で定義された関数を呼び出すには、ocall を使用します。 Ocall はエンクレーブの外で実行され、エンクレーブによって信頼できない呼び出しとして扱われます。 ocall が実行された後、制御はエンクレーブに戻ります。

エンクレーブ部分では、Web サーバーで安全なチャネルが構成され、エンクレーブ自体がターゲット サーバーと TLS ハンドシェイクを実行し、すべての暗号化操作をその内部で実行します。 TLS ライブラリ (mbedTLS) と HTTP コードの縮小バージョンが SGX 環境にエクスポートされました。 また、Enclave には、リモート サーバーの証明書を確認するためのルート CA 証明書 (証明書のコレクション) が含まれています。 リクエスト ハンドラーは、イーサリアムが提供する形式でデータグラム リクエストを受け取り、それを復号化して解析します。 次に、要求されたデータグラムを含むイーサリアム トランザクションを生成し、skTC で署名して Relay に送信します。

リレー部分には、クライアント インターフェイス、TCP、ブロックチェーン インターフェイスが含まれます。 クライアント インターフェイスは、エンクレーブ コードを検証し、クライアントと通信するために必要です。 クライアントは、ecall を使用して構成証明リクエストを送信し、att (構成証明署名) とともに skTC によって署名されたタイムスタンプを受信します。次に、att は Intel Attestation Service (IAS) を使用して検証され、タイムスタンプは信頼できるタイム サービスによって検証されます。 ブロックチェーン インターフェイスは、受信リクエストを検証し、トランザクションをブロックチェーン上に配置してデータグラムを配信します。 Geth は公式の Ethereum クライアントであり、Relay が RPC 呼び出しを介してブロックチェーンと対話できるようにします。

TEE と連携すると、TC は複数のエンクレーブを並行して実行できるため、情報処理の速度が 3 倍向上します。 15 つの動作エンクレーブの速度が 20 tx/秒だった場合、65 の並列実行エンクレーブでは速度は 26 tx/秒に増加します。比較のために、ビットコイン ブロックチェーンの最大速度は XNUMX tx/秒です。

DECO

DECO (Decentralized Oracles for TLS) は CCS'20 で導入され、TLS 接続をサポートするサイトで動作します。 データの機密性と完全性を保証します。
TLS を使用した DECO は対称暗号化を使用するため、クライアントと Web サーバーは暗号化キーを持ち、クライアントは必要に応じて TLS セッション データを偽装できます。 この問題を解決するために、DECO は証明者 (スマート コントラクト)、検証者 (オラクル)、Web サーバー (データ ソース) の間で XNUMX ウェイ ハンドシェイク プロトコルを使用します。

DECO の仕組みは、証明者がデータ D を受け取り、D が TLS サーバー S から来たものであることを検証者に確認するというものです。もう XNUMX つの問題は、TLS がデータに署名しないため、TLS クライアントがデータ D を証明することが難しいことです。データはそのサーバーから受信されました (来歴の困難さ)。

DECO プロトコルは、KEnc および KMac 暗号化キーを使用します。 クライアントは Q リクエストを Web サーバーに送信し、R サーバーからの応答は暗号化されますが、クライアントとサーバーは同じ KMac を所有しているため、クライアントは TLS メッセージを偽造できます。 DECO の解決策は、要求に応答するまでクライアント (証明者) から KMac を「隠す」ことです。 現在、KMac は証明者と検証者 (KpMac と KvMac) に分かれています。 サーバーは KMac を受信し、キーの一部に対して KpMac ⊕ KvMac = KMac 演算を使用して応答を暗号化します。

XNUMX ウェイ ハンドシェイクを設定することにより、クライアントとサーバー間のデータ交換はセキュリティが保証された状態で実行されます。

分散型オラクル システムと言えば、Chainlink について触れずにはいられません。Chainlink は、モジュール性を念頭に置き、イーサリアム、ビットコイン、ハイパーレジャーと互換性のあるオラクル ノードの分散型ネットワークを構築することを目指しています。システムのすべての部分はアップグレード可能です。 同時に、セキュリティを確保するために、Chainlink はタスクに参加する各オラクルにキー (公開キーと秘密キー) の組み合わせを発行するよう提案します。 秘密キーは、データを要求する決定を含む部分署名を生成するために使用されます。 答えを得るには、ネットワークのオラクルの部分署名をすべて組み合わせる必要があります。

Chainlink は、Mixicles のような分散型金融アプリケーションに焦点を当てた最初の PoC DECO を計画しています。 これを書いている時点で、Chainlink がコーネル大学から DECO を買収したというニュースが Forbes に掲載されていました。

オラクルへの攻撃

情報セキュリティの観点から、Town Crier に対する次の攻撃が検討されています。

1. TEE ノードでの不正なスマート コンタクト コード インジェクション。
   攻撃の本質は、意図的に間違っているスマート コントラクト コードを TEE に送信することで、ノードにアクセスした攻撃者が復号化されたデータに対して独自の (不正な) スマート コントラクトを実行できるようにすることです。 ただし、返される値は秘密キーで暗号化され、そのようなデータにアクセスする唯一の方法は、戻り/出力時に暗号文を漏洩することです。
   この攻撃に対する保護は、エンクレーブによる現在のアドレスにあるコードの正確性のチェックで構成されます。 これは、コントラクト コードをハッシュすることによってコントラクトのアドレスが決定されるアドレス指定スキームを使用して実現できます。

2. 契約状態の暗号文の変更が漏洩します。
   攻撃の本質: スマート コントラクトが実行されるノードの所有者は、エンクレーブ外で暗号化された形式でコントラクト状態にアクセスできます。 ノードの制御を獲得した攻撃者は、スマート コントラクト コード自体とその技術仕様が公開されているため、トランザクションの前後でコンタクトの状態を比較し、どの引数が入力され、どのスマート コントラクト メソッドが使用されたかを判断できます。
   ノード自体の信頼性を確保するための保護。

3. サイドチャネル攻撃。
   さまざまなシナリオでエンクレーブ メモリとキャッシュ アクセスの監視を使用する特別なタイプの攻撃。 このような攻撃の例としては、Prime および Probe があります。
   
   攻撃順序:

   • t0: 攻撃者は被害者のプロセスのデータ キャッシュ全体を埋めます。
   • t1: 被害者は、被害者の機密データ (暗号化キー) に依存するメモリ アクセスでコードを実行します。 キャッシュラインはキービット値によって選択されます。 図の例では、keybit = 0 で、キャッシュ ライン 2 のアドレス X を読み取ります。X に格納されているデータがキャッシュにロードされ、以前に存在していたデータが置き換えられます。
   • t2: 攻撃者は、自分のキャッシュ ラインのうち、被害者が使用したキャッシュ ラインが削除されたことを確認します。 これは、アクセス時間を測定することによって行われます。 この操作をキービットごとに繰り返すことで、攻撃者はキー全体を取得します。

攻撃保護: Intel SGX には、キャッシュ関連イベントの監視を無効にするサイドチャネル攻撃に対する保護機能がありますが、攻撃者は自分のプロセスのキャッシュ イベントを監視し、被害者とキャッシュを共有するため、プライム アンド プローブ攻撃は依然として通過します。

したがって、現時点では、この攻撃に対する信頼できる保護はありません。

Prime および Probe に似た Spectre and Foreshadow (L1TF) 攻撃も知られています。 これにより、サードパーティのチャネルを通じてキャッシュからデータを読み取ることができます。 Spectre-v2 脆弱性に対する保護が提供されており、これら XNUMX つの攻撃に対して機能します。

DECO に関連して、XNUMX ウェイ ハンドシェイクによりセキュリティが保証されます。

1. 証明者の整合性: 侵害された証明者は、サーバーの発信元情報を偽造できず、サーバーが無効なリクエストを受け入れたり、有効なリクエストに誤って応答したりすることはできません。 これは、サーバーと証明者間のリクエスト パターンを通じて行われます。
2. 検証者の完全性: ハッキングされた検証者が証明者に間違った答えを与えることはできません。
3. プライバシー: ハッキングされた検証ツールは、公開されている情報 (リクエスト、サーバー名) のみを検査します。

DECO では、トラフィック インジェクションの脆弱性のみが発生する可能性があります。 まず、XNUMX ウェイ ハンドシェイクにより、検証者は新しい nonce を使用してサーバーの ID を確立できます。 ただし、ハンドシェイクの後、検証者はネットワーク層インジケーター (IP アドレス) に依存する必要があります。 したがって、検証者とサーバー間の通信はトラフィック インジェクションから保護する必要があります。 これはプロキシを使用することで実現されます。

オラクルの比較

Town Crier はバックエンドでのエンクレーブの操作に基づいていますが、DECO では XNUMX ウェイ ハンドシェイクを使用してデータの発信元を認証し、暗号キーを使用してデータを暗号化できます。 これらのオラクルの比較は、速度、セキュリティ、コスト、実用性の基準に従って実行されました。

タウンクライヤー
DECO

パフォーマンス
高速化 (終了まで 0.6 秒)
遅い (プロトコルが完了するまでに 10.50 秒)

セキュリティ
安全性が低い
より安全な

コスト
もっと高い
安い

実用性
特別なハードウェアが必要
TLSをサポートするあらゆるサーバーで動作します

スピードパフォーマンスA: DECO は 0.37 ウェイ ハンドシェイクのセットアップが必要で、LAN 経由でセットアップする場合は 2 秒かかります。接続確立後の通信には 0,13PC-HMAC (書き込みあたり 3 秒) が有効です。 DECO のパフォーマンスは、利用可能な TLS 暗号スイート、プライベート データのサイズ、および特定のアプリケーションの証明の複雑さに依存します。 IC10,50 のバイナリー オプション アプリケーションを例として使用すると、LAN 経由でプロトコルが完了するまでに約 0,6 秒かかります。 比較すると、Town Crier は同様のアプリケーションを完了するのに約 20 秒かかり、DECO よりも約 XNUMX 倍高速です。 同等の条件下では、TC の方が速くなります。

セキュリティ: Intel SGX エンクレーブに対する攻撃 (サイドチャネル攻撃) は機能し、スマート コントラクトの参加者に実際の損害を与える可能性があります。 DECO に関してはトラフィックインジェクション攻撃が可能ですが、プロキシを使用することでそのような攻撃は無効化されます。 したがって、DECO はより安全です。

のコスト: Intel SGX での動作をサポートするハードウェアのコストは、DECO でプロトコルを構成するコストよりも高くなります。 したがって、TCはより高価になります。

実用性：タウンクライアと連携するには、TEEに対応した専用機器が必要です。 たとえば、Intel SGX は、第 6 世代 Intel Core プロセッサ ファミリ以降でサポートされています。 DECO ではあらゆる機器を使用できますが、TEE を使用した DECO 設定もあります。 セットアッププロセスによると、DECO の XNUMX ウェイ ハンドシェイクには時間がかかる場合がありますが、TC のハードウェア制限に比べれば大したことではないため、DECO の方が実用的です。

まとめ

2020 つのオラクルを個別に見て、4 つの基準で比較すると、Town Crier が XNUMX 点中 XNUMX 点で DECO より劣っていることは明らかです。 DECO は、情報セキュリティの点で信頼性が高く、安価で実用的ですが、XNUMX 方向プロトコルの設定には時間がかかる場合があり、暗号化キーを使用した追加操作などの欠点もあります。 TC は DECO よりも高速ですが、サイドチャネル攻撃の脆弱性によりプライバシーが失われる危険があります。 DECO は XNUMX 年 XNUMX 月に導入されましたが、まだ安全であると考えるには十分な時間が経過していないことに注意してください。 Town Crier は XNUMX 年間にわたって攻撃を受けており、多くのテストを経てきたため、多くのプロジェクトでの使用は正当化されています。

出所： habr.com