SSHの鍵ペア生成サービスの是非について

なんと、秘密鍵、公開鍵を自動生成してくれるWEBサービス!!

http://d.hatena.ne.jp/daigaku-syokuin/20100905/p1

このエントリがはてブコメントで批判され気味のようだが、本当にそこまで非難されるべきサービスなのだろうか?
僕も最初はこれ駄目だろwと直感的に思ったんだが、よくよく考えてみたらちょっと条件がつくけど鍵ペアの生成自体には別に問題なんじゃね?と思い直した。


追記:(注意)このエントリの前半部は「ある閉じたシステム利用の為の鍵生成サービスの是非」について考察しています。後半部では違った結論もあるので読むなら最後までちゃんと読んでね。

鍵生成自体は問題ないんじゃね?

僕が思うにキーペア生成WEBサービス自体は以下の条件がクリアされていれば問題ないと思うのよ。

  • 通信路がちゃんとした証明書付きのhttpsであること。
  • 生成された秘密鍵がサーバ側で保存されないこと。*1

あとは裏で ssh-keygen なり走らせてごく一般的なキーペア生成処理で作ってくれてればそれでOKでしょ。
これならばサーバ側には何も残らないし、通信路上で盗聴されることもないし、ブラウザからローカルにコピペするのは完全にローカルの話なので問題ない。
一体どこに問題がるんだろうか?僕には思いつかなかった。


追記:ひとつ懸念があるとすれば「生成された秘密鍵がサーバ側で保存されないこと」の保証が難しい点です。ですが仮に秘密鍵が保存されていた場合でも以下の条件を付け足せばや悪用の心配も無くせるでしょう。

  • 生成されたキーペアをそのサービス以外で利用しない。*2

その秘密鍵で出来ることは高々その大学のSSHサーバを自分のアカウントで使い放題にされるということだけですが、そもそもシステムが生成した秘密鍵にアクセス出来る人=同システムが公開鍵登録が出来る以上公開鍵登録する権限もあると推定される=わざわざ秘密鍵を奪わずとも元から好きな公開鍵を好きなユーザに登録する権限をもっている、ってことで結局秘密鍵を得た人の権限は特に上昇してないので、問題ないかと。

真の問題はID/PASSで公開鍵登録が出来ることじゃね?

件の慶應義塾大学WEBサービスでは公開鍵の登録も同時に行なってくれてるようなので論点がごっちゃになってしまってるんだと思う。
上に述べたとおり僕は鍵生成自体は問題ないと思った。では真の問題はなにかというとID/PASSがあれば公開鍵が登録できるところが問題なんじゃね?簡単にまとめると↓こういうことです。

  1. 公開鍵の登録がID/PASSで出来る
  2. →ID/PASSを知ってれば誰でも好きな公開鍵が登録できる
  3. →ID/PASSを知ってれば誰でも好きにSSHログインが出来る

つまりセキュリティレベルを公開鍵認証レベルから共通鍵認証レベルまで落としめてしまってる真の敵は「ID/PASSで公開鍵が登録できる」ことなんです。

ID/PASSで公開鍵登録するシステムの是非

さて、問題を整理すると最後に、ID/PASSで公開鍵登録が出来るシステムは本当に問題なのか?ということに行き着きます。これについては、SSHの公開鍵認証の意義としては問題である、と言わざるをえないでしょう。
ですが、これの撤廃は現実的には難しいと思うのよね。だって最初の登録には何らかの認証が必要なのは確かで、一般的にその認証はID/PASSで行っているのが普通だからねぇ…。


それに公開鍵を登録する為の前段階の認証がID/PASSってシステムは世の中に腐るほどあって、それらはそんなに批判されてないと思うんです。
例えば僕が経験したことあるだけでも↓こんだけある。

  • sourceforgeSSHサービス利用のための公開鍵登録はID/PASSがあれば出来る。
  • AmazonEC2もID/PASSさえ知ってて管理コンソールにログイン出来れば何でも出来る。というかAmazonEC2なんてもろ管理コンソールで「Create Key Pair」させられます。
  • あとニフティクラウドもEC2と同じで管理画面からキーペアを生成します。

これってみんな慶應義塾大学のシステムとと大差ないですよね。でも特に問題になってないと思います。
業務とかだと他にも、公開鍵をメールで送ったり、IRCやIMメッセージで送ったりして相手サーバの管理者にそれを手で登録してもらうことが多いわけですが。相手はなんでそのメールやメッセージが本人から送られてきたって信頼するんでしょうか?話の流れやタイミング?なりすまし登録に関して言えばID/PASSを入手するよりある意味簡単な気がします。これについて批判している人を僕は余り知りません。


それに、sourceforgeしかりAWSしかり、最初のID/PASSによる認証以外に公開鍵を登録するのに足る本人確認って何があるでしょう?身分証明書のコピーと公開鍵を焼いたCDを一緒に送りつければ満足?
そんなことより管理画面にログイン出来るんならもっと深刻なオペレーションが出来ることも多いわけで、SSHの公開鍵生成やら自動登録だけに目くじら立てるんでなく、それを言うなら他もどうにかせにゃ意味無いでしょ。というのがシステムのセキュリティに対する僕の考えです。

追記:社会的な問題は残る

そのシステムを利用する限りにおいては上述した条件を理解して利用させる分には、まぁいいんじゃない?ってことだが問題はまだある。
それはこのサービスを使うのは学生(しかも恐らくは公開鍵認証への理解も浅く安全に使う為の方法も知らない学生)だということだ。


そもそも、SSH利用にパスワード認証ではなく公開鍵認証を強制することには「パスワード認証は高度なセキュリティが求められるサービスにおいては安全性に置いて適切でない」ことと「公開鍵認証の必要性と意義と運用における注意点」などを学生に学習させる機会を作って啓蒙する目的もあると思う。
だが、このシステムに慣れさせてしまうと、無知な学生がそれを一般的な(問題が全く無い)ものだと誤解してしまい、公開鍵認証の意義を学習するどころか、ちょっと面倒なパスワード認証と同レベルの認証などというふうに理解をしてしまうのは最悪だ。その学生にとってはこれが経験となってしまい、その過去の経験があるがゆえに将来考えを改める機会すら奪ってしまう可能性もある。例えば人に自分の過ちを指摘された際に「だって大学ではそうしてたし俺は悪くない!」という思考停止になってしまうかもしれない。


先に述べた「そのシステム上は別に問題ないんじゃ」という主張は、あくまで公開鍵認証の意義と限界を理解した上での話であって、それを理解しない人間を量産して他で危険を冒させてしまうことは問題だ。
そういった社会的な影響を考えると、やはりこの大学での鍵生成サービスは停止してキチンと手順を説明して学生自身に鍵生成をさせるようにした方が良いという結論になる。
閉じたシステムだけを考えた場合とは正反対の結論ですが、考える領域を異にしたら別の結論が出るというのはよくあることです。*3

*1:自分で作ったサービスで無い限り、その完全な保証を得るのは難しく。そうでなければ相手への信頼に依存することになります。

*2:ここで生成された公開鍵を別のシステムに登録して利用してしまうと、生成サービス側で不正に保存された秘密鍵にアクセス出来る人に対して、別システムへのログイン権限を与えてしまうことになるからね。それはマズイ。

*3:Winnyウィルス問題のときにexe踏む奴がバカwとかあったけど、個人で考えればそうかもしれんが、無知で愚かな人は沢山いてそれにより社会的被害が出ることを考えたら黙ってるわけにはいかないだろ。という話を思い出した。