タイトル：Dfinity の認証について一文で理解する#
日付：2021 年 08 月 16 日 14:02:50
> 著者：ddd009
> この記事では、基本的な暗号学の概念から始めて、メッセージ署名認証のプロセスを詳しく説明し、最後に Dfinity が Internet Identity サービスを使用してユーザーが自分の身元（キー）を管理する方法について説明します。
基本的な概念#
通常のリクエスト情報に加えて、canister ID や関数名などの一般的なリクエスト情報に加えて、リクエストの内容にはユーザーの公開鍵とメッセージの署名も含まれています。Caller's Principal はユーザーの公開鍵をハッシュ化したものであり、後述のプロセスで詳しく説明します。受信側はメッセージを受け取った後、ユーザーの公開鍵を使用して署名の正当性を検証し、公開鍵と Caller's Principal が対応しているかどうかを確認します。
一方、canister の開発者は暗号学の詳細については気にする必要はありません。コードを書くだけで、Dfinity が自動的に認証を完了します。
この画像は公開鍵からユーザーの Principal を取得する方法を示しています。
まず、DER 形式の公開鍵から始めて、SHA-224 ハッシュ関数を適用して 28 バイトの文字列を生成します。その後、ユーザー principal と他の principal（例：canister の principal）を区別するために 1 バイトを追加します。
これらの 29 バイトはユーザー principal のバイナリ表現です。Motoko と JS では、principal 変数は Uint8 の Blob 配列であり、その中にはこれらの 29 バイトが保存されています。
その後、これらの 29 バイトをテキスト表現に変換します。まず、CRC32 エラーチェックコードを追加し、次に Base32 エンコーディングを行います。最終的に得られた文字列を 5 文字ずつグループ化し、間に「-」を挿入することで、ユーザーの principal のテキスト表現が得られます。
ちなみに、flyq による base32 のコミュニティ実装があり、vessel-package-set にマージされていますので、vessel を使用して利用することができます。
ユーザーの Principal が単一のキーにバインドされている場合、非常に不便です。複数のデバイスを持っている場合、同じキーをこれらのデバイスで使用する必要がありますが、これは便利でも安全ではありません。
Dfinity は委任キーの仕組みを使用しており、黄色のキーを使用してオレンジのキーに署名し、スコープと有効期限を含む委任を生成することができます。また、オレンジのキーは他のキーに対しても委任することができます。そのため、この方法は非常に柔軟です。
ここまで来ると、キーペア、ユーザー Principal、委任キーなどの基本的な概念についてある程度の理解ができるはずです。では、Dfinity はこれらの暗号学的技術を使用してユーザーの身元認証をどのように行っているのでしょうか？
委任署名認証#
委任キーの一つの応用は Web Auth に関連しています。Web Auth は W3C が最新の標準として発表したもので、Web アプリケーションの二要素認証を対象としています。つまり、従来のユーザー名とパスワードに加えて、サーバーからのチャレンジに対して追加のセキュリティデバイスを使用して署名する必要があります。キーはセキュリティチップに格納されており、漏洩することはありません。たとえシステムがマルウェアに感染しても、セキュリティチップ内のキーには影響を与えることはできません。この方法により、ユーザーがサーバーにログインしていることが保証されます。
上記は従来のインターネットの方法ですが、Dfinity では少し異なるプロセスがあります。中央集権化されたサーバーを使用する場合、サーバーとの状態を持つ長期的な接続を確立できるため、サーバーからのチャレンジに対して一度だけ署名すれば、その後の通信は確立した接続を使用して転送できます。しかし、Dfinity では中央集権化されたサーバーは存在せず、サービス間で状態を持つ接続を確立することはできません。また、サービスはユーザーに対してチャレンジを送信することはできません。そのため、ユーザーは送信された各リクエストに対して署名する必要があります。Web Auth を使用する場合、各署名を確認する必要がありますが、リクエストごとに Yubikey をタッチしたり指紋を認識したりするわけにはいきません。まず、短期的なセッションキーを生成し、それを Web Auth で委任署名し、最後に委任キーを使用してメッセージに自動的に署名することで、複数のメッセージに対する署名の問題を解決します。
Internet Identity#
Web Auth はキーを安全に保存するために非常に適していますが、ブラウザのセキュリティ制限のため、キーは特定の canister にバインドされています。IC 上では、canister が異なる場合は異なるソースと見なされ、この状態の分離はセキュリティ上非常に重要です。しかし、これはユーザーにとっても問題です。たとえば、同じサービスを複数のデバイスで使用するのは困難です。この欠点に対処するために、公式では Internet Identity（II）を導入しています。これは、Google のサインインと同様の SSO（Single Sign-On）サービスであり、ユーザーがキーと身元を管理するのを容易にします。
上図のように、アプリのフロントエンドはセッションキーを生成し、公開鍵を II サービスに送信します。ユーザーが同意する場合、II サービスはセッションキーに対して委任署名を行います。すべての認証プロセスはユーザー側で完了します。
