個人情報の暗号化通信と暗号化ファイルの紛失
以前の私のエントリー「個人情報の暗号化通信は漏洩にあたるか？」で投げかけた「流出した暗号化ファイルと傍受された暗号化通信データの違い」とそれに基づく漏洩時の謝罪の要否に関する疑問について、高木浩光さんが大変素晴らしい考察を示してくださったので、これについての私の考えを記しておく。
このような議論を通じて本来あるべき姿を模索することは意義のあることだと思うので、ご指摘、ご意見等があればぜひともお寄せいただきたい。
- 流出した暗号化ファイルと傍受された暗号化通信データの違い, 高木浩光＠自宅の日記, 2006年8月14日
企業が個人情報ファイルを紛失した際に、単に「暗号化していますので問題ありません」で済まされないのは、まず、少なくともどんな暗号アルゴリズムを用いていたかを明らかにしなければ、客観的に「問題ない」とはできないからだ。そして、お墨付きの暗号アルゴリズムを使用していたとしても、鍵の作り方がどうなっていたかと、鍵の管理をどうしているのかを明らかにしなければならない。
紛失時の対応として、暗号アルゴリズムや鍵の強度、管理方法などについて明らかにすべきという考え方は理解できる。ただし、実際に紛失時にこのような事項を発表を行うとすると、顧客の感情を考慮すれば結局謝罪せざるを得ないだろう。（←実はここがポイント？）あらかじめ最低限の暗号化の仕様を定義し公開しておき、暗号化されたデータそのものは個人情報とはみなさないなどの考え方があっても良いのではないかと思う。
本来の趣旨からはずれるが、同様の要求は等しく暗号化通信に対しても求められるだろうか？
この考えに従うと、顧客等から見えないところで個人情報がインターネットを通過するような通信が行われる場合、その全ての保護手段や管理の状態を公開すべきだということになる。つまり顧客が直接サーバに対して入力するWebインターフェースにおけるSSL/TLSの使用は入力者本人から見えるので問題ないが、社内業務インフラの一部としてSSL/TLS, VPN, SSH, SFTP等をインターネットを介して使用している場合についてもその事実についても公開する必要があるということになる。
理想的には暗号化したとしても顧客等の情報をインターネットを介し通信しないことが望ましいかもしれないが、現実には全ての企業が完全クローズドなネットワークで業務を完結させることは困難と思われる。
これに対して、一般的に行われているファイルの暗号化では、まず鍵の生成方法は自由であり、鍵ファイルの保存を必要としないものでは、パスワード（人間が思い浮かべた文字列）をそのまま鍵にしているものがあるし、パスワードと暗号化用ソフトウェア内蔵の鍵（リバースエンジニアリングによって判明し得る）から生成しているものもあり、それらでは、どんな暗号アルゴリズムと鍵長を用いようとも、強度はパスワードのレベルまで落ちていると見なされるだろう。
ここでは「一般的に行われているファイルの暗号化では、まず鍵の生成方法は自由」としてユーザが使用する鍵またはパスワードの強度不足が指摘されている。ここで指摘されているようなパスワードやパスワードから生成した鍵の使用では十分とは言えないという点については指摘のとおりだと思う。この対策としては、ランダムに生成され十分な長さを持つ鍵ファイルや耐タンパー認証トークン等を使用することで十分な鍵の強度を確保すればよいだろう。
次に、鍵ファイルを保存する方法の場合、鍵の生成方法まで規格化されたものを使用すればよいが、鍵ファイルを秘密にしておかなければならず、それが同時に流出している可能性があるならば、鍵ファイルの使用にパスワードを要求するようになっていても、安全性はパスワードのレベルだと見なされる。
「それが同時に流出している可能性があるならば」との前提は、本来あってはならないことでそれ自体が問題である。ここでは鍵ファイルが同時に流出している「可能性がない」ことを確認できれば暗号化通信との差はないということになる。
SSLが信頼されているのは鍵がセッション終了時に消去されるところにポイントがある。一般に、通信の暗号化では鍵は短期間で捨てられる（ようにプロトコルを設計できる）のに対し、ファイルの暗号化では、その目的上、いつかそのファイルを復号しなくてはならず、それまで鍵を捨てずに温存しておかざるを得ず、どうやってもそこが通信の暗号化にはないリスクとなる。
ここでは、暗号化ファイルの「鍵の存在」が問題視されているが、重要なのは攻撃者が鍵を入手することが不可能なことであって、鍵が存在するか否かではないだろう。したがって、例えば鍵が安全な場所に過去にわたり保管されており、攻撃者が鍵を入手することが事実上不可能であることを示せれば「鍵がセッション終了時に消去され」ていることと同等とみなしてもよいのではないか。（鍵の存在がポイントというのであれば紛失が発覚した時点で鍵を破棄し以前に鍵の漏洩がないことを確認すれば良いだろう。）
SSLであってもサーバ秘密鍵とセッションで使用された乱数がどこかに保存されていれば通信の暗号化であってもファイルの暗号化と同じリスクがあることになる。そもそも一般的な暗号は鍵が安全に保護されていることを前提に安全性を担保しているものなので「鍵は安全に保護されていない」ことを前提とするならば、全ての暗号化は意味のないものになってしまう。
そうすると、暗号化された個人情報ファイルを流出させたときに謝罪しなくてよいためのひとつの条件として考えられるのは、「そのファイルはもう復号することを予定しておらず、鍵を消去している」と示すことではないか。
上記の考えから、「暗号化された個人情報ファイルを流出させたときに謝罪しなくてよいためのひとつの条件として考えられるのは」、「ファイルを復号するための鍵は十分な長さを持ち、過去にわたりその鍵が適切に保護されており、攻撃者がこれを使用することは事実上不可能であることを事前に示しておくこと」、とは言えないだろうか？
暗号化した通信手段を用いても、こと個人情報のやり取りに関しては漏えいの範疇に入るとなると、VPNとかも普通にNGなんですよね。
個人情報保護法の対象にするのでなく、どちらかというと不正アクセス禁止法とかの対象になるべきだと思います。暗号化してるものに関しては、むりくり複合化して不正に情報を取得した人が罰則の対象になるというか。
暗号の強度によって法的に判定するといろいろ面倒がありそうなので、暗号化したデータは元のそれとは別物と考えて「暗号化されているかどうかを問わない」という一文を無くすのが一番妥当じゃないでしょうか。
顧客には盗聴された可能性があるということで報告する必要があると思いますが、必要以上に情報を出さなくても良いかなと。
まぁ、価格.comみたいな開き直り方はどうかとも思いますが。
1.内部統制報告書に関する ＱandＡ(前半)
Ｑ１ 内部統制報告書とはどのようなものですか？ 金融商品取引法24条の4の4は、「当該会社の属する企業集団及び当該会社に係る財務計算に関する書類その他の情…
顧客情報などのデータが紛失した場合、どのような強固な
暗号化方法であったとしても漏洩の可能性は否定できない
という理由で監督官庁への報告、そして該当顧客への謝罪
（大抵の場合は告知）が必要になるのが現実です。
＃今のところ暗号高度云々ではなく件数の方が重大
一方、電子割符で分割されて他方が手元に残っているケース
などの場合の、もう片方のデータの紛失（大抵データ量は
こちらが多い）をどう扱うのか。片方が手元にあるのだから
紛失したデータは無意味なデータであると認定できれば良い
のですが。一部弁護士からそういう解釈も出ているようです。
暗号強度、あるいは鍵の長さが十分かどうかは時代によって変わるものなので、どうしても十分かどうかが示されなければならないのなら、政府等の公的機関がどの程度なら大丈夫なのかを示し、その内容を定期的に更新していくしかないでしょうね。
すなわち過去に漏洩した暗号化ファイルは、将来より高性能な処理機を用いれば容易に解読される可能性が高いのではないでしょうか。
電子計算機の性能向上の度合いは今のところ一定の範囲内に収まっているので、どの程度の期間で安全を保てるのかという点で見切りをつけるほかにないと思います。
法律上は事項の概念との兼ね合いも考慮が必要でしょう。
× 事項
○ 時効
失礼いたしました。
Donaldさん, Blacklightさん
コメントどうもありがとうございます。
北海道警察のWinny漏洩事件の判例などから考えますとメジャーな暗号が破られていないと一般に認知されている状態では当該暗号によって情報がその時点で保護されていると考えても良いのではという気もします。
もっともその暗号がいつまで安全かということについては、実際にその時が来るまではわかりませんので、暗号が破られた時点で漏洩の危険が高まったと考えられその場合に公表・謝罪などという方法もありえるかもしれません。鍵の強度も含めインターネット通信で使用されているものと同程度暗号化を行い、鍵をきちんと管理していることが証明できれば良いのかなと思います。
本件についての法的な議論は以下のURLでも展開されました。ご参考まで。
http://maruyama-mitsuhiko.cocolog-nifty.com/security/2006/08/post.html#more