<前の日記(2006年08月10日) 次の日記(2006年08月13日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1543   昨日: 2734

2006年08月12日

流出した暗号化ファイルと傍受された暗号化通信データの違い

少し前に武田さんが、

  • 個人情報の暗号化通信は漏洩にあたるか?, 武田圭史, 2006年6月10日

    (略)では逆に128bit SSL相当あるいはそれ以上の強度で暗号化したファイルを紛失した場合において、その事実を公表・謝罪する必要があるのかという疑問が生まれる。

    紛失したファイルを第三者が拾得した場合と、暗号化した通信を第三者が傍受する場合のどちらのリスクが大きいかということになるかとは思うが、実際のところインターネット上での個人情報の暗号化通信と、暗号化された個人情報ファイルの紛失の差異について、どのような認識が一般的なのだろうか。

という疑問を呈されていた。

企業が個人情報ファイルを紛失した際に、単に「暗号化していますので問題ありません」で済まされないのは、まず、少なくともどんな暗号アルゴリズムを用いていたかを明らかにしなければ、客観的に「問題ない」とはできないからだ。そして、お墨付きの暗号アルゴリズムを使用していたとしても、鍵の作り方がどうなっていたかと、鍵の管理をどうしているのかを明らかにしなければならない。

SSLとの対比で言うと、SSLでは通信データ(ハンドシェイク完了後の)の暗号化に用いる鍵に、

  1. 鍵の生成方法がSSLのプロトコルとして規定されている。
  2. 鍵はセッション終了時に消去される。

という性質がある。

これに対して、一般的に行われているファイルの暗号化では、まず鍵の生成方法は自由であり、鍵ファイルの保存を必要としないものでは、パスワード(人間が思い浮かべた文字列)をそのまま鍵にしているものがあるし、パスワードと暗号化用ソフトウェア内蔵の鍵(リバースエンジニアリングによって判明し得る)から生成しているものもあり、それらでは、どんな暗号アルゴリズムと鍵長を用いようとも、強度はパスワードのレベルまで落ちていると見なされるだろう。

次に、鍵ファイルを保存する方法の場合、鍵の生成方法まで規格化されたものを使用すればよいが、鍵ファイルを秘密にしておかなければならず、それが同時に流出している可能性があるならば、鍵ファイルの使用にパスワードを要求するようになっていても、安全性はパスワードのレベルだと見なされる。

SSLが信頼されているのは鍵がセッション終了時に消去されるところにポイントがある。一般に、通信の暗号化では鍵は短期間で捨てられる(ようにプロトコルを設計できる)のに対し、ファイルの暗号化では、その目的上、いつかそのファイルを復号しなくてはならず、それまで鍵を捨てずに温存しておかざるを得ず、どうやってもそこが通信の暗号化にはないリスクとなる。*1

「SSLは許されるのに、暗号化ファイルは許されないの?」という疑問に対する答えは、安全であることの信頼性について、暗号化ファイルがSSL通信並みになることは、それがいつか復号されることを予定しているものである限り、あり得ないからということではないか。

そうすると、暗号化された個人情報ファイルを流出させたときに謝罪しなくてよいためのひとつの条件として考えられるのは、「そのファイルはもう復号することを予定しておらず、鍵を消去している」と示すことではないか*2。そのような場合があるかというと、鍵は安全に消去したが、なぜか暗号化ファイルは消さなかった(もしくは、安全に消去できていなかった)という場合があるかどうかだ。

Windows XP SP2の同時接続数制限

という記事が出た。すばらしい。私も「Winny稼動コンピュータ数調査の追試をしてみた」では、SP1を使わざるを得なかったのだが、早速「BIOT」を使わせていただいたところ、SP2でも、SP1のときと同じ性能を得ることができた。

*1 ただし、ここでは流出が起きるような事態を想定しているので、通信の暗号化においても、通信の端点(サーバ)から流出が起きる場合を考慮しないと公平でない。まず、セッション鍵がサーバから流出するケースでは、そのタイミングで生きているセッションの通信が傍受されたときに復号され得ることになるが、元々その場合は、サーバ内で復号されたばかりのデータも流出し得るのだから、それは暗号化の問題ではない。次に、(訂正)セッション鍵の交換に使われる秘密情報(たとえば、RSAを用いる場合の秘密鍵が流出した場合を検討すると、流出以降の暗号化通信は安全でないものとなるが、流出以前に行った暗号化通信については、安全である(傍受された通信データは復号されない)と見なすことができる。

訂正(8月30日) 脚注1にミスがあったので訂正。Diffie-Hellman + RSAを想定していたはずだった(DHE-RSA-*)。この場合RSA鍵は認証に用いられ、それが流出するとman-in-the-middle攻撃によりそれ以降の秘密が損なわれる件を言いたかったつもり。しかし……(つづく)

*2 暗号化アルゴリズムと鍵生成の方法にお墨付きのある規格化されたものを用いていたことを示し、かつ、消去するまでの間の鍵の管理体制が適切であったことを示すのに加えて。

本日のTrackBacks(全1件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20060812]

以前の私のエントリー「個人情報の暗号化通信は漏洩にあたるか?」で投げかけた「流出した暗号化ファイルと傍受された暗号化通信データの違い」とそれに基づく漏洩時の謝罪の要否に関する疑問について、高木浩光さんが大変素晴らしい考察を示してくださったので、これにつ..

検索

<前の日記(2006年08月10日) 次の日記(2006年08月13日)> 最新 編集

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
<前の日記(2006年08月10日) 次の日記(2006年08月13日)> 最新 編集