Medium の DFINITY 公式の記事 Web Authentication and Identity on the Internet Computer(2021/5/20) の日本語訳です。
Internet Computer では、ユーザー名とパスワードに代わり、より高度でセキュアな暗号認証方式を採用しています。
By Björn Tackmann, Team Lead, Research | DFINITY
ウェブスピードで動作し、無制限に容量を増やすことができる世界初のブロックチェーンネットワークである Internet Computer の文脈でIDと認証が何を意味するかを理解するためには、まず、今日のウェブでIDと認証がどのように使われているかを考えなければなりません。
ウェブサイトにログインするとき、ユーザー名は通常、電子メールアドレス または 文字と数字の羅列であり、サーバー上の関連データとお客様の身元を結びつけるお客様固有のIDとして機能します。パスワードは認証のための手段です。理論上、パスワードはあなただけが知っているはずなので、サーバーはあなたのパスワードをあなたと通信している証拠と解釈します。しかし、実はパスワードはリモート認証のメカニズムとしてはあまり良くないことが分かっています。
Webサイトでパスワードを入力すると、コンピューターからサーバーにパスワードが送信され、パスワードデータベースと照合されます。残念ながら、ハッカーはこのパスワード・データベースにアクセスすることができます。最もひどいケースでは、パスワードが平文でサーバーに保存されていることがあり、これは推奨されるセキュリティ対策ではありません。しかし、パスワードが暗号化されていたとしても、それを復元するのは、ハッカーがアクセスするために投資する計算量と資金の問題に過ぎません。
Internet Computer は、データと計算を複数のデータセンターに複製することで、個々の計算プロバイダーへの悪意ある振る舞いに対するセキュリティを提供するように設計されています。複製はデータの完全性を保護する一方で、情報の漏洩を防ぐことはできません。Internet Computer でパスワードを使用すると、従来のWebと同じようにセキュリティの問題が発生します。そこで、Internet Computer では、パスワードを適切な暗号認証に置き換えたのです。
Internet Computer の認証に使用する主な暗号メカニズムは、デジタル署名方式です。デジタル署名は、かなり標準的な概念です。1970年代後半に発明され、少なくとも1990年代半ばから広く使われています。
一般的には以下の3つのアルゴリズムで構成されていると考えられます。
- 鍵の生成。これはパスワードを選ぶアナログなものだと思えばよいでしょう。鍵の生成では、2つの鍵のペアを作成します。1) パスワードのように秘密にしなければならない秘密鍵、2) 秘密鍵から派生した公開鍵。公開鍵は公開できます。
- 署名。メッセージと秘密鍵を受け取り、署名を生成します。デジタル署名をユーザー認証に利用する場合、秘密鍵を持つユーザー側でこのアルゴリズムが実行されます。
- 検証。メッセージ、署名、公開鍵を受け取り、署名がメッセージと公開鍵にマッチするかどうかを検証します。ここで重要なのは、秘密のパスワードをサーバーに保存しておく必要があるパスワードのチェックとは異なり、この場合の署名の検証は、単に公開情報に基づいて行うことができる点です。サーバは各ユーザごとに公開鍵のリストを保存しており、公開鍵も署名も秘密にする必要はありません。
Internet Computer 上のアプリケーションは、メッセージの受け渡しによって対話するキャニスタースマートコントラクトをベースに実装されています。もう少し詳しく説明すると、相互作用モデルはリクエストに基づいており、これはリモートプロシージャコールによく似ています。キャニスターAがキャニスターBを呼び出すとき、キャニスターAはターゲットキャニスターであるキャニスターB、呼び出したい関数名、関数の引数を指定します。指定された関数がキャニスターBで評価されると、キャニスターBもその関数がキャニスターAから呼び出されたことを認識します。評価が完了した後、キャニスターAは関数の戻り値をレスポンスとして取得します。ユーザーがキャニスターとやり取りする場合も、同じリモート プロシージャコールモデルが適用されます。ユーザがキャニスターを呼び出す場合、ユーザは対象のキャニスターにリクエストを送信します。このリクエストでは、引数付きの関数も指定し、ユーザーはその戻り値をレスポンスとして取得します。様々なリクエストを通じて、キャニスターはそれを呼び出すユーザのIDを知ります。
上図は、ユーザーから送信されるリクエストの概略図です。真ん中の薄いグレーの部分はリクエストの核となるもので、ターゲットキャニスターID、関数名、引数、呼び出し元のIDまたはプリンシパルを示しています。濃い灰色の部分は、認証情報、署名、公開鍵を含むエンベロープを示しています。左側で示しているように、呼び出し元のプリンシパルは、公開鍵をハッシュ化することで導き出されます。この手法は、ビットコインやイーサリアムのアドレスなど、ブロックチェーン領域で広く使われています。右側では、デジタル署名方式におけるメッセージとしてのリクエストの内容が、署名を介して公開鍵にどのように縛られているのかを示しています。Internet Computer は、このようなリクエストを受け取ると、指定された公開鍵の下で署名が有効かどうかと、公開鍵と呼び出し元プリンシパルの関係の両方をチェックします。
メッセージで指定された発信者から確かにメッセージが送られたことを確認するために、キャニスターはこれらの技術的な詳細について悩む必要はありません。すべてチェックされると、Internet Computer はキャニスターの指定された関数を評価します。チェックが1つでも失敗すると、リクエストは単に取り下げられます。
私達が使用するプリンシパルの形式について、少し触れておきます。DER形式の公開鍵から始まり、SHA-224でハッシュ化すると、28バイトの文字列ができあがります。公開鍵に由来するプリンシパルを、キャニスターのような Internet Computer の他の場所で使用するものと区別するためだけに、１バイト付加します。この29バイトは、ユーザーのプリンシパルの内部バイナリ表現です。プリンシパルをテキスト表現に変換する際、まずCRC-32エラー検出コードを先頭に付けます。次に、得られた文字列をBase32でエンコードし、最後に5文字ずつのグループを作り、ダッシュで区切っています。このフォーマットは、DNSのような Internet Protocol との互換性のために ASCII表現での64文字未満を考慮しながらも、適切なエラー検出が行えて、簡単にコピー&ペーストできるように考慮されています。
ここまで見てきた方式は、構造上まだ少し柔軟性に欠けます。ユーザーのプリンシパルを1つの暗号鍵にバインドしてしまいます。この制限により、ユーザーが異なるデバイスからキャニスターを操作することが難しくなります。その場合、これらのデバイス間で同じ暗号鍵を共有する必要がありますが、これは面倒であり、セキュリティの観点からも望ましくありません。代わりに、異なる暗号鍵間で委任を行います。上図では、黄色の鍵からオレンジの鍵への委任が示されています。このような委任は、委任された鍵(オレンジ色)、有効期限や委任範囲の制限のような追加パラメータ、委任する鍵(黄色)の署名で構成されます。
オレンジの鍵でリクエストに署名するとき、ユーザーは黄色の鍵から派生したIDを使用するために、黄色の鍵からの委任を含めることができます。委任が特に強力なのは、それらを合成できることです。例えば、オレンジの鍵は紫の鍵に委任を拡張することができます。もしこれらのことが公開鍵基盤やX.509でおなじみのように思えるなら、それは偶然の一致ではありません。 — より軽量なデータ構造を使用しているだけです。
委任の具体的な応用例として、Web認証に関するものがあります。Web認証は、World Wide Web Consortium (W3C)の最近の標準規格で、主にWebアプリケーションの2要素認証を対象としています。この規格のモチベーションは、先に示したように、パスワードには深刻なセキュリティ上の欠陥があるためです。パスワードは、フィッシングメールやマルウェアによってユーザーのデバイスにインストールされたり、サービスがハッキングされたりして、サイバー犯罪者の餌食になることが多いのです。
二要素認証とは、パスワードの他に、ウェブアプリケーションにログインする際に、追加のセキュリティ要素、通常はユーザーが所有するセキュアなデバイスを必要とすることを意味します。実際には、セキュアなUSBキーや、ユーザーのエンドデバイスに内蔵され生体認証によって起動するセキュアチップがこれにあたります。セキュアチップは暗号鍵を保存しています。暗号鍵はセキュアチップの外に出ることがないため、ユーザーのコンピュータや携帯電話がマルウェアに感染しても、安全性は保たれます。
Webアプリケーションの２要素目としてWeb認証を使用する場合、プロトコルの流れは以下になります。ユーザーがユーザー名とパスワードを入力してログインプロセスを開始した後、ウェブサーバーはランダムなチャレンジを生成してユーザーのブラウザに送信します。ブラウザはチャレンジをセキュアデバイスに送信し、セキュアデバイスはチャレンジに署名する前にユーザーとの対話を要求します。署名されたチャレンジはサーバーに返送され、サーバーはチャレンジの署名とユーザーの登録した公開鍵との関連性を検証します。これにより、ウェブアプリケーションにログインする際には、パスワードに加えてセキュアデバイスを保持する必要があることが保証されます。
私たちは、Web認証が電子署名を用いた認証のオープンスタンダードであり、すでに幅広いデバイスでサポートされていることを基盤としています。しかし、Internet Computer に適応させる際には、いくつかのハードルを越えなければなりませんでした。Web認証は、従来のWebのセッション指向のクライアント・サーバーモデルを前提としており、ユーザーはアプリケーションにログインする際に一度認証を受け、以降は同じセッション内でその後のメッセージを送信します。これに対し、Internet Computer は、各リクエストを個別に認証するモデルを実装しています。特に、ブラウザと Internet Computer の間にはステートフルなセッションが存在しないため、セキュリティデバイスによって署名されるチャレンジを生成できるサーバは存在しません。しかし、典型的なウェブ認証フローでは、セキュアなデバイスは、サーバーから送信されたチャレンジにデジタル署名を提供することを思い出してください。
同じプロトコルでリクエスト認証を実装するには、一般的なリクエスト認証方式と同様に、リクエストそのものをチャレンジとして使い、セキュアデバイスで署名させることになります。もう一つの課題は、ウェブ認証では署名のたびにユーザーとの対話が必要なことです。Internet Computer が提供する典型的なフロントエンドでは、1つのページロードが複数のリクエストに対応することがあります。我々は、各リクエストを明示的に確認することをユーザーに要求したくないので、前述の委任メカニズムを使用しています。ウェブ認証を使ってキャニスターとやりとりするとき、まず短期間のセッションキーを生成します。次に、Web認証を使用して、そのセッションキーに向けた委任に署名します。こうすることで、1人のユーザーとの対話で、Internet Computer への複数のリクエストを引き起こすことができます。
上図の翻訳
(1) キャニスターページをロードします
(2) “ICへサインインします”
(3) 確認: あなたのIDを使いますか？
(4) アプリケーションキャニスターにリダイレクトします
左補足: セッションの署名鍵ペアを生成し、公開鍵をリダイレクトに含めます。
右補足: 委任をセッション公開鍵に署名し（有効期限付き）、署名された委任をリダイレクトで返します。
Web認証は暗号鍵をセキュアに保管するには最適ですが、その鍵はデバイスだけでなく、特定のキャニスターにもバインドされます。この理由は、ブラウザセキュリティモデルにあります。このモデルでは、同じウェブブラウザで実行される異なるアプリケーションからアクセスできる状態を、オリジンによって厳密に分離しています。Web上では、オリジンはおおよそ1つのWebサイトに対応すると考えることができます。Internet Computer では、各オリジンは1つのキャニスターに対応します。このように厳密に状態を分けることはセキュリティ上重要ですが、鍵のバックアップ または 複数のデバイスから同じキャニスターにシームレスにアクセスするためのサポートのような機能は、すべての操作をキャニスターごとに分けて行う必要があるため、面倒です。この問題を解決するために、Webでおなじみの ”Google または Facebookでサインイン” 機能に似たIDプロバイダーである Internet Identity サービスを利用することで、この問題を解決しています。
ユーザーがあるキャニスターのフロントエンドを最初にロードしたとき、そのフロントエンドは ”ICでサインイン” ボタンを提示できます。ユーザーがこのボタンをクリックすると、ブラウザは Internet Identity サービス（ユーザーがキーとIDを管理するための特定のアプリケーション）のポップアップを開きます。そこでユーザーは、キャニスターフロントエンドがユーザーのIDを使用することを許可するかどうかを決めることができます。ユーザーが承認すると、ブラウザはキャニスターフロントエンドにリダイレクトされ、 ユーザーのIDでキャニスターにアクセスできるようになります。このメカニズムでも、セッションキーと委任のメカニズムが使用されます。キャニスターフロントエンドはセッションキーペアを生成し、公開キーを Internet Identityに転送します。ユーザーが確認すると、Internet Identityは委任を生成し、それをキャニスターフロントエンドに返します。ビッグテックプロバイダーを経由してサインインする場合の利点として、IDプロバイダーの完全な認証フローはユーザー側で行われるため、プライベートなユーザーアクションの露出が非常に少なく、したがってトラッキングも非常に少なくなります。
ユーザートラッキングについて言えば、Internet Identity は、ユーザーがログインするキャニスターフロントエンドごとに異なるIDを与えます。これはセキュリティとプライバシーにとって素晴らしいことです。そうでなければ、Internet Identity は、ユーザーの単一プリンシパルですべてのフロントエンドにログインできるようになってしまいます。そのユーザーが無関係なサービス、たとえば掲示板やショッピン グサイトとやり取りすると、これらのサイトでのユーザーの行動を裏で相関させることができてしまいます。さらに悪いことに、掲示板のフロントエンドが悪意を持ってショッピングサイトのキャニスターを呼び出し、ユーザーの名前で注文をすることもあり得ます。そこで、Internet Identity サービスは、ユーザーがログインするフロントエンドごとに異なるIDを生成し、フロントエンドはホスト名で区別されます。こうすることで、異なるサービスでのユーザーの行動はそう簡単に追跡されません。フロントエンドは、ユーザーのIDを使用して Internet Computer 上の任意のキャニスターを呼び出すことができますが、それはこれまで呼び出しを実行するフロントエンドに関連付けられた ID のみです。
上記のメカニズムおよび Internet Identity で使用されるメカニズムは、最近リリースした Internet Computer Interface Specification で詳細に規定されています。 — そして、開発者コミュニティがこれをもとにどのようなものを作り上げていくのか、楽しみにしています。
_____
Internet Computer を支える技術の詳細については、今後のリリースにご期待ください。
sdk.dfinity.orgでビルドを開始し、forum.dfinity.orgの開発者コミュニティに参加してください。
