openIDって実は「ゼロ知識証明」？

openID ネタです....結構 openID がらみのサービスが増えてるようですが、以前のエントリでも紹介しましたが、openID には、

勝手に認証サーバ(IdP)を立てることができるが、その認証サーバが厳格でまっとうな認証をしてくれるかどうかの保証がない！

というちょっと厄介な性質があります。ですから

1. 1. 「悪い」認証サーバの情報を公開し、それに従って判断する（ブラックリストタイプ）
2. 2. 一部の有名で信用できる認証サーバ以外は、サービス(Consumer)が利用しない（ホワイトリストタイプ）

....でまあ、どうやら openID の「現実の利用」は 2. になりそうです....

前者ならばやはりOpenIDアプリの側でOpenID URLごとにアクセスコントロールする必要があります。繰り返しになりますがアプリ制作者側の 支持はあまり得られないように思います。後者ならば長期的に見て資金力がありブランディングに成功したプレイヤーにidentity provider が集約され得るということです。それはプロトコルの策定過程がオープンだったというだけでMicrosoft PassportやGoogle AuthSub APIと変わりありません。 （opeID-ja のディスカッションの中から..）

そうなるとオトナな事情を主な原因として、

「すべて」のＩＤ・パスワードを単一にする

というのが実現できなさそうな雰囲気が漂っている（まあ、それでも使う人はいるわけですが....）というのが現実、なのですね。

ちょっといろいろと考えたのですが、この openID って、実は本質は、

サービス(Consumer) に、認証サーバ(IdP)の認証情報を提供するが、しかし、一切の認証情報がサービス側には漏れない

という状態であれば、全然問題がないわけです。Delegate のややこしい仕組みに何か惑わされがちですが、実際

○○のアカウントでログインできます

を謳う「パチモンOpenID対応サービス」も世の中にはあって（「OpenIDの普及がフィッシングサイトを助長する？」）、それだと「本当の○○のアカウント」を要求し、サービスが開示されたアカウント情報を使って、○○のサービスに実際にログインを試行して、自身のサービスへのログインを許可する...というものだってあるわけです。

勿論この「パチモンOpenID対応サービス」は、そのアカウント情報を「内部で保持しない」という紳士協定で動いているものですから、悪用しようと思えばいっくらでも出来てしまうわけです....勿論コレはまずいですが、ちょっとこれをヒネると、

認証サーバの認証情報を持っていることを、認証情報自体を開示することなしに、サービスに証明する

という魔法のようなことが.....実は出来ない話ではないのです。

これ、数学的には「ゼロ知識証明」のそのままの話です。これスゴク面白い話題ですよ！！ 一般向けだと「情報セキュリティの科学―マジック・プロトコルへの招待 (ブルーバックス) 」くらいしか書籍がないのがツラいところですが、簡単に言えば、公開鍵暗号の応用編（どっちか言えば電子署名かな）みたいな手法で、そういう

ちょっと魔法な認証とか情報伝達

をするやり方です。そういうツモリで、openID 風のやり方を考えるのならば、こんなプロトコルはどうでしょう？

1. 1. 認証サーバ(IdP)側で、アカウントを発行するときに、アカウント・パスワードと同時に、公開鍵暗号の公開鍵と秘密鍵を生成して、「アカウント・パスワード・秘密鍵」を保存する。そして、ユーザには「公開鍵・アカウント・自身の認証の「口」であるURL」のセットになったテキストを返す。
2. 2. 認証サーバ(IdP)が提供するサービスにログインするには、パスワードを公開鍵で暗号化してパスワード代わりに使う。勿論この時、ちょっとしたソルトを加えて毎回パスワードとして使われるテキストが同じでない...というのもGoodである。で、認証サーバでは受け取ったテキストを秘密鍵で解読し、保存されたパスワードと一致するか確認して認証する。
3. 3. 外部のサービス(Consumer)がこの認証サービスを利用して、自分用の認証をするには次のようにする。1. で提供された「公開鍵・アカウント・認証サーバのURL」をそのまま外部のサービスに開示する。認証を行いたいサービスは、提示された公開鍵によって、ランダムに生成された文字列を暗号化する。そして、それを認証サーバのURLに対してリクエストする。
4. 4. 認証サーバ(IdP)では、送られた暗号文を、内部で保持する秘密鍵で復号して単に返す。
5. 5. 外部のサービス(Consumer)は、認証サービスから送られた復号結果と、自身が選んだランダムな文字列とを比較し、一致すれば、開示された公開鍵に対応する秘密鍵を認証サーバのアカウントが保持することが（ほぼ完全に）証明できる。

このプロセスでは、外部のサービスには認証サーバのサービスにログインできる情報であるパスワードは開示されません。ただ公開鍵が提示されるだけです。認証サーバとのやり取りを通じては、要するにこれを悪意で観察すれば、いわゆる「選択平文攻撃」をしているのと同じ程度の危険性がある...という程度の問題です。これは、一般的な暗号メールで利用する場合の使い方と同様なので、暗号メールの安全性と同じくらい...という結論です。

で問題の、どんな認証リクエストも受け入れる、悪意ある認証サーバが作れるか...というとこれ、

送られてきた暗号文をどうにかして正しく復号してやらなくてはならない....

というとっても難しい（というか、できない）ことをしなければならなくなります。

まあ、ちょっと本来のパスワードと公開鍵と２つあるので、ダブルパスワードっぽい雰囲気もないではないですが、とはいえ、ソルトを使った「毎回違うテキストでログイン」というのもいいでしょ。

問題は...というと、悪意あるサービス(Consumer)が、内部に開示された情報をこっそり保存すると、同じようにこの認証サービス(IdP)を利用する別なサービス(Consumer)に、なりすましログインが出来てしまうことです。何かいい防御手段がないかなぁ....（ごめん）

まあ、このプロトコルはホントに「これぞ、ゼロ知識証明！」というようなものではなく、単なる公開鍵暗号の応用に過ぎないのですが、 ゼロ知識証明には驚くような面白いトピックが満載です。一度調べてみると完全に視野が広がりますよ！（関心を持ったら、「暗号と認証」もいかが？　この本はタイトルにそぐわず、内容はほとんどゼロ知識証明の話です）