<前の日記(2004年02月01日) 次の日記(2004年02月21日)> 最新 編集

高木浩光@自宅の日記

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

2004年02月08日

IPアドレス照合によるセッションハイジャック防止とプライバシー

イーバンク、利用PCのIPアドレスを登録できるセキュリティサービス」という記事が出ていた。

登録外のIPアドレスからログインした場合、支払いや請求など資金の移動を伴う取り引きが制限され、不正利用を防止できる。

ITmedia, イーバンク、利用PCのIPアドレスを登録できるセキュリティサービス

というもの。これは、Webアプリケーションに不正操作を防止するのには効果の高い方法だ。この件ではおそらく、他人にパスワードを使われてしまう可能性を心配しての対策だと思うが、それだけでなく、9月28日の日記「絶対に見つけられないWebアプリ攻撃は存在する」で書いたセッションハイジャック攻撃を防止するのにも有効だ*1

ただし、そのためには、すべての画面でIPアドレスをチェックしていないといけない。ログイン開始のパスワード照合のときだけでIPアドレスをチェックするというのがありがちな実装だが、それではセッションハイジャックを防げない。

それはともかく、この方法が有効だということで、消費者向けサービスでも採用されるようになり、ほとんどのサービスでIPアドレス登録・チェック機能が導入されるようになるとどうなるだろうか。常時接続あるいはIPv6が一般家庭に完全に普及し、一家に1アドレス(以上)という時代が到来すると、ついには、安全のためという理由で、IPアドレスを登録しないとどのサービスも使わせてもらえないという時代がやってくるかもしれない。

たしかにそれはセキュリティ的には安全性が高いが、プライバシー的にはリスクが大きくなっている。これまでの日記に書いたように、IPアドレスの固定化は、携帯電話におけるサブスクライバーID問題、スーパークッキー問題と同じプライバシー問題をひきおこす。

IPアドレスという下位レイヤーの識別子を人の識別のために使うというのは、手軽に利用できる(通信には必ずその識別子が存在するため)反面、識別されない自由が失われてしまう点で本質的に誤った考えだといえる。ただし……(後述)。

人の識別は下位レイヤーで「ついでに」行うのではなく、アプリケーションレイヤー(上位レイヤー)で識別手段を提供し、識別される人の自由意志に基づいて識別するべきである……という話は、5月25日の日記に書いた。

Webアプリケーションにおいて、上位レイヤーでの確実な識別手段を提供するのは、SSLのクライアント認証を普通に使うだけで可能だ。必要なときだけ、つまり、自分を識別してほしいという意思をユーザが示したときだけ、確実に識別してもらうことができる。

クライアント認証の利用はもう何年も前から可能な状態にあるわけだが、なかなか普及しない。原因は導入のコストとランニングコストが高いということだろうか。ユーザの手間(クライアント証明書のインストール)が問題なのかもしれないが、それを言うなら、上のニュースにある「IPアドレスの登録」の作業だって手間なはずだ。安全性の高いアクセス制御を希望するユーザにだけ、クライアント証明書を使わないとログインできないサービスを提供してはどうだろうか。上のニュースのサービスが有料なくらいだから、それは有料でもよいのかもしれない。

下位レイヤーで識別手段を提供するという発想は、上位レイヤーでの識別手段が現実的には費用がかかりすぎて普及しないという考えに基づくものかもしれない。しかし、そのコストはどうなのか。携帯電話のように特定の事業者なり公社なりに集中管理されるシステムでは低コストで実現可能かもしれないが、インターネットではどうか。

無数のIPアドレスの使用によるプライバシー確保

さて、上では「下位レイヤーの識別子を人の識別に使うというのは本質的に誤った考え」と書いたが、IPv6のようにIPアドレスを無尽蔵に使ってよい状況では、無数のIPアドレスを個人が一人で使うことによって、プライバシーを確保したままで堅牢なアクセス制御の実現を達成できるかもしれない。

つまり、各個人が、使用するサービスごとに異なるIPアドレスを取得して使うのだ。各サービスの独立したユーザIDに一対一対応するIPアドレスを取得するというわけだ。Webブラウザであれば、アクセス先ごとにアクセス元のIPアドレスを異なるものにすることになる。一人が数千個のIPアドレスを使うとしても、IPv6ならばアドレスは枯渇しないだろう。

ただしこのとき、IPアドレスのビット列の一部が共通になっているようでは、プライバシー確保の効果はない。IPv6の現在考えられている通常の運用では、上位64ビット(の一部)は、同じ個人に対して同じサブアドレスが割り当てられると考えられる。それでは、いくら下位ビットがランダムでも、上位ビットでトラッキングができてしまう。

接続プロバイダが個人に対して、上位ビットが異なる多数のアドレスを割り当ててくれるなら、これは実現できる話かもしれない。ルーティングの効率性を確保したまま、そうしたアドレス割り当てができないものだろうか。

「数千個」が無理なら、数十個で十分かもしれない。同じIPアドレスをいくつかのサービスに使い回ししても、誰がどのサービスに使いまわししているかがサービス提供事業者に予測不能であれば、事業者がその人をトラッキングすることはほとんどできない。

重要なサービスにはそれ専用のIPアドレスを使用し、どうでもよいサービスには同じIPアドレスを使いまわすということも考えられる。リアル世界において、メインバンク用の銀行印は他の銀行で使わないようにし、少額しか預けない銀行には同じ銀行印を使いまわすのと同じように。

ただし、プライバシーを確保できるといっても、この方法では、サービスを越えたトラッキングの防止ができるだけだ。サービス内での一時的なトラッキングを拒否するためのプライバシー確保(たとえば、匿名で商品棚を閲覧して、決済のときだけ自分を識別してもらうなど)にはさらに工夫が必要となる。ログイン前とログイン後で異なるIPアドレスを使う必要があるだろう。その切り替えはユーザの意思で行うことになるかもしれないが、あるいは何らかの自動化ができるかもしれない。

*1 ただし、ネットワークの末端でパケット盗聴して得られる情報を用いてセッションハイジャックする攻撃に対しては、同じIPアドレスからハイジャックを実行できるであろうから、そうした攻撃はこの方法では防げない。

検索

<前の日記(2004年02月01日) 次の日記(2004年02月21日)> 最新 編集

最近のタイトル

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|
<前の日記(2004年02月01日) 次の日記(2004年02月21日)> 最新 編集