Enigma Japanのブログ

仮想通貨Enigma(エニグマ)についてガチ解説していくEnigmaJapan.infoのブログです!

Enigmaのオフチェーン・アイデンティティ・クレームについて

この記事は公式ブログの記事である「Off-Chain Identity Claims with Enigma 」を翻訳したものです。Benyさんが翻訳なさったものを一部編集して掲載しました。元ファイルはこちら! EnigmaJapanのTelegramにあります。

今回は、Enigmaソリューションシリーズのパート2。お題は、Enigmaの画期的なプロトコルによって実現可能なリアル分散型ソリューションの試験的導入について

f:id:udoncryptocurrency:20180422174444p:plain

背景

最近世間を騒がせた事故―Facebook、Uber、Equifaxの情報漏洩―からも明らかなように、企業同士でどうやってデータをシェアしていくのか、今、私たちに大きな課題が降りかかってきてます。分散型アプリ(Dapps)※によるアイデンティティ(身分証明)サービスは、ユーザーにより多くのコントロールを可能にすることになりそうです。

ブロックチェーン業界における“選択可能なシェア”という概念は、アプリから個人情報の開示を要求された時に、それを許可するか否かの選択ができるという意味です。しかし、これはまだ十分ではありません。アプリケーションはまだ個人情報へのアクセス権を持っており、データの悪用やディスクロージャーといったリスクを伴います。言い換えれば、「アプリケーションにあなたの情報が送信された時点で、それはもう彼らの所有する彼らの情報である」ということです。今日のアプリケーションがまさしくそうです。(選択可能なだけではまだ情報漏洩のリスク回避には十分ではないということ。)分散型の時代を、もっと良くしていかなきゃいけないと思います。Enigmaなら、ユーザーが情報の開示をせずにクレームを作成することを可能にできるでしょう。

なぜこれが重要なことなのか?

  1. ユーザーへサービスを提供するため、規制要求を満たすため、サービス向上のために情報が必要な企業が、個人情報に対する負うべき責任を負わずして、未だ重要なインサイト(ユーザー・消費者心理、ニーズ)へのアクセス権を持つことができます。これは、来たるGeneral Data Privacy Regulation(GDPR)―2018年5月施行予定―における特に重要項目になってくるでしょう。

  2. ユーザーは、情報漏洩―シャドー・プロファイル―や、今後データの誤用されるリスクから守られます。

インテント(目的)事項

アプリケーションは、個人情報に対してインテント(目的)を設けるべきです。彼らのサービスに色んな面で貢献していくべきです。私たちが個人情報をプライベートな状態に保ったり、アプリケーションが非公開に個人情報を処理するには、この‘演算’が、あなたとアプリケーションとの契約における重要なポイントになってます。具体的に言うと、‘アプリケーションがその都度個人情報の処理を行う’ということがポイントです。なぜ‘その都度’かというと、処理されようとしているあなたの情報を知る必要があるからです。これは、アプリケーションごとに個人情報が蓄積され、ユーザーの承諾無しでその情報が売られるている現在のパラダイムとは異なります。

f:id:udoncryptocurrency:20180422174440p:plain

アプリケーションが持っていないデータを処理する時、その処理が本質的にアプリケーションのインテント(目的)を表す状態になります。これによって、ユーザーにとっての透明性と安全性の両方を改善します。

みんなにとって利益がある

データを持ちつつもその情報を守ることの責任‘義務’は負わず、責任を持って取り扱いながら今日のアプリケーションと全く同様にパワフルなアプリケーションが可能になれば、分散型アプリケーションは現在のアプリケーションに代わるものとして好ましいものになるでしょう。これが、Enigmaが描いている将来像です。

現在のソリューション

今やブロックチェーンの名が公に知られるようになり、オンチェーン上でデータを保存することは望ましくないと言えます。たとえ暗号化されているとしても、それぞれのパーティのプライベートキーは結局妥協点になってしまうからです。そのシナリオだと、今から何年経ったとしても、今日取り扱われている個人情報はリスクに侵されるでしょう。(注意:Enigmaだと、プライベートキーは決して他の人に知られることは無いです。)

現存するソリューションは、オフチェーン・データストアを使用し、信用された証認とクレームの組み合わせを利用して、サードパーティーからの要求に応じてユーザーが選んだ情報を与えられるような仕組みになっています。

  1. 信任状の発行:誰でも(その人自身の個人も含めて)公開もしくはプライベートに個人のアイデンティティについてのクレームを作ることができ、そのクレームは信頼されたオラクル(例えばサンフランシスコ州のような)などによって署名されます。

  2. 信任状の要求:誰でも、個人のアイデンティティについてプライベート・クレームか公開・クレームを要求することができます。

提案するソリューション

私たちは、Enigmaネットワークを使って、情報を要求する際のプロセスを修正することを提案します。データポイントが自動的に情報を要求する代わりに、クエリー形式(“アリスは21歳以上ですか?”のような)で要求することを必要とし、その計算処理の結果に基づいてアクセス権をあたえるというものです。これは、アリスが21歳以上であるという正確な結果を確保しつつ、‘アリスの誕生日’という個人を特定し得るいわゆる個人情報が決して漏洩しないという利点があります。

Enigmaで上記のようなシステムをどのように実行するかデモンストレーションを行うにあたって、私たちはいくつかの事例を使おうと思います。まず1つ目に、オンラインでギャンブルアプリケーションを使おうとしているアリスが、彼女が21歳以上であるという証明を行うときに、どのようにEnigmaがアリスに働きかけるのか、について説明します。私たちのゴールは、アリスの実際の誕生日が漏れることなく、彼女が21歳以上であることを無事に証明でき、アプリケーションからの要求を満たすことができます。それから、アパートを借りようとしているアリスとボブの例に目を向けてみましょう。

注意:ゼロ知識証明や値域証明、その他の暗号メソッドなどは、上限数・下限数のチェックも含め、プライベート・データ上で実行できる計算処理の数に制限をかけることもまたできるようになっています。これらはとても強力で貴重なツールです。Enigmaは、その他さまざまな計算処理フォームと同様に上記の計算処理を行うことができます。例えば、ZKPと値域証明はどちらも、他のパーティに情報が漏れることなくサードパーティが計算処理を終えるためにユーザーがデータを組み合わせることができないようになっています(例2でデモンストレーションします)。Enigmaは、広範囲な計算処理のサポートをすることができ、アプリのデベロッパーが簡潔に統合できるシステムを確立することが強力だと考えています。

例1―年齢認証

アリスは、Virtue PokerかFunfairのような分散型ポーカーゲームに参加できるように、彼女の年齢が21歳以上であることを証明します。これは、個人データのシェアというより新しい問題における限られたシチュエーションでの使用事例です。

  1. アリスは年齢認証の要求されるポーカーアプリケーションにアクセスします。アプリケーションは彼女の身元確認についての情報(彼女の年齢)をアリスのデバイスに要求します。アリスは、彼女のアイデンティティ・マネージャーがこの要求を行うほとんどのアプリケーションと、このデータを“暗号化された方法で”シェアできるようにしました。

  2. アリスのアイデンティティ・マネージャーが彼女の誕生日を暗号化し、その正確さの署名認証をサンフランシスコ州から受け、この暗号化されたデータをポーカーアプリケーションから選択したコントラクトフォームへ提出します。

  3. データは、安全確保された環境内で暗号化され、スマートコントラクトが実行されて演算処理が行わレます(アリスの年齢>21)。

  4. アプリケーションは、アプリケーションにアクセスすることを許可するトークンをアリスに付与します。

アリスが使用したいアプリケーションは、アリスが21歳以上であるかどうかを知る必要があるというものです。彼女の実際の誕生日は重要ではないのです。アプリケーションは、アリスのデータを用いてシンプルに計算処理を行います。もしも彼女が21歳以下である誕生日を入力すると、彼女がアプリケーションを使用することは拒否されます。たった今、アリスは彼女のデータを送信し、アプリはそれを受け取り、必要に応じてアプリ内にある彼女の‘アリス・プロファイル’へとデータがセーブされ、彼女の年齢を確かめるための演算処理を行います。

例2―アパートのレンタル

アリスとボブがアパートを借りようとしてます。彼らは、そのアパートの借主として必要とされる支払い能力を満たしているということを証明したいと思ってます。そして、実際のお給料の額を他の人や大家さんに知られたくないとも思っています(もしもアリスがいくら捻出できるかを大家さんが知ったら、もう1年契約を伸ばすことを拒否するかもしれないのです。)その上、これらのデータを直接見ないことによって、大家さんが法的な家賃の差別をする可能性が低くなります。これらを容易に実現出来るような擬似レンタルアプリケーションを企画してみましょう。

  1. 家主は賃貸申込者の最低限の総収入額を指定します

  2. アリスとボブは、スマートコントラクトに暗号化された彼らのお給料情報を送信することをアプリケーションに許可します

  3. コントラクト内の信頼できる環境下で、データが暗号化されて演算処理が実行されます

  4. 結果が反映されますが、暗号化されたデータは決して信頼された実行環境から漏れることはないです

オフチェーン・アイデンティティデータには、現存しているアプリケーションと競合できるような、抜きん出たユーティリティを持ち合わせた分散型アプリケーションを確立することが必要とされます。AirBnBのようなアドレス情報を持たないものや、マップ検索を行わないGraigslistをイメージしてください。Enigmaは、次のような挑戦に対して他の分散型法とは違うEnigma独自のメリットがあります。

  1. 誰もデータを暗号化できるプライベートキーを持たない

  2. たとえ一瞬でも、誰かがデータを見ることはない

Enigmaは分散された未来を作ること、アイデンティティという挑戦的な事柄を探求する新しいタイプのソリューションが出来ることを約束します。将来の一部として、これからも私たちはEnigmaがどのようにスケーラビリティを持った基礎的なレイヤーとなるのか、分散型アプリケーションの隅から隅まで探求していくでしょう。

貢献してくれたCan Kisagunにたくさんの感謝を込めて。

技術的な補足

f:id:udoncryptocurrency:20180422174435p:plain

上図:EnigmaプロトコルのMVP(Minimum Viable Product)を使用して、アリスがどのように彼女の年齢を証明できるのかを表したユーザー・フローのダイアグラム

Enigmaネットワークユースケース

  1. Virtue Pokerは“init_age_check”というコントラクトを作り、Enigmaのシークレットコントラクトのレポジトリーでこれを書きます

  2. アリスがポーカーアプリケーションへ登録しようとするとき、“init_age_check”が彼女の暗号化された年齢信任状を要求します

  3. アリスは、EnigmaClientで自分の誕生日を暗号化し(サンフランシスコ州に署名してもらったもの)、アプリがその暗号化されたクレームにアクセスすることを許可します

  4. この暗号化されたデータは“init_age_check”コントラクトに送信され、そこでデータがシークレットな状態で演算処理されることが求めらレます。この時しようする関数は“age>=21”

  5. インテルSGX内で稼働しているEnigmaバーチャルマシーンにfnと暗号化されたデータを送信してるEnigmaリスナーへ送られます

  6. データは領域を飛び越えて暗号化され、要求された計算処理が実行されます

  7. アリスは21歳以上であるという正しい結果を、関数が反映します(true)

  8. この結果は、イーサリアムネットワーク上にある“init_age_check”コントラクトに送り返されます

  9. アリスは、ポーカーアプリケーションへのアクセス権が付与されたトークンを受け取ります

もしも、分散型アイデンティティと分散型リプテーションという挑戦をしているEnigmaソリューションの確立を手助けしたいと思ったそこのあなた!私たちのプロジェクトへぜひご参加ください!!

プロジェクトに関してより知りたい場合はwebsiteブログを参照してください

Enigmaプロトコルで何か作りたいですか? 申し込みはこちら

ーデベロッパーコミュニティーのニュース、Coming Soon!ー

Enigmaのチーム募集してますhttps://enigma.co/team/

Telegramhttps://t.me/enigmacatalyst

Discordhttps://discordapp.com/invite/SJK32GY

Reddithttps://www.reddit.com/r/enigmacatalyst/

Twitterhttps://twitter.com/EnigmaMPC

参考