← 先月分 | 翌月分 →

Copyright © 2001,2002 Yasuhiro (Spiegel) ARAKAWA
このページは GNS を使用して作成しています

開発日記 (2002年08月分)

2002年08月04日

危ない!? 住基ネット 4 で取り敢えず纏め

これから住基ネットがどうなるにせよ, かなり不愉快な思いをすることになるだろう。 腹をくくるべし。 以下比較的まとまっているページを紹介。 個人的にお勧めは下の2つ。 特に 「文字コードから見た住基ネットの問題点」 は具体的に書いてあって分かりやすい。

確かに住基ネットが国外に与える影響は少ないかもしれない。 しかし,住基ネットによって私達が国外から与えられる屈辱ははかり知れないものがある。 考えてもみよ。 こんな稚拙なシステムしか組めない国の企業が提供するコンピュータ・ネットワーク製品の (あるいはこの国の専門家を名乗る人の言説の) どこに信頼性を見いだせばいいのだろう。 どれだけセールストークを駆使しても 「実績=住基ネット」 がその「実」を雄弁に物語ってしまう。 もし,ある企業が住基ネット開発に携わったことがバレてしまったら, (例えその企業が仕様決定プロセスに参加していないとしても) 一気に信頼を失ってしまうのではないだろうか。 住基ネットを稼働させてしまったことは, 我々の業界にとって大きな機会損失を意味する。

OpenOffice 1.0.1 日本語版

OpenOffice.org 日本ユーザー会速報

おぉ! 縦書き対応。 漸く日本語環境としても使えるようになってきたということか。 いや,まぁ, 私は縦書きは使わんけど。

2002年08月17日

Opera 6.05

Opera 6.05 がリリースされている。 例の 「Opera FTP View Cross-Site Scripting Vulnerability」 以外に OpenSSL 絡みの障害についても改修されているらしいので, 必ずアップグレードすること。 日本語版はどうしてもリリースが遅れてしまうので (6.04 すら出てない 6.05 日本語版出てます (8/22)), アテにすべきではない。

OpenPGP の脆弱性

Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG
PGPに理論的セキュリティーホールが存在、“ごみメール”には注意を

最近はあり得る可能性は全て実現してしまうので, 注意するにこしたことはない。

2002年08月18日

住民票コードの是非

例のハガキが届いていた。 なんか自治体によっては透けて見えるとか色々あったらしいが, うちの方はちゃんと透けないようにしていた。 しかし, 本当に数字しか使ってないんだな。

私は住民票コード付与についてはそれほど問題だとは思っていない。 住基ネットに限らず私達は既に符号で管理され量で評価されている。 牛も人間も (概念的な「データベース」も含めて) データベース管理において平等で等価なのである。 これは戦後私達日本人が一貫して追い続けてきた (「ゆたか」ではない) 「便利」な社会の大きな実績のひとつだ。 感情的な部分や倫理上の問題としてはいろいろあるのかもしれないが, 管理の仕方としてはありふれた方法であり今更どうこう言うことではないだろう。 (人の符号化が倫理に反する行為だというのなら, 世の中にある殆どのコンピュータ・システムはインモラルだ)

しかし運用は別。 「文字コードから見た住基ネットの問題点」(8/5に改訂版が出ているので要チェックだ) での提言にもある通り, 住民票コードはデータベース管理上の内部キーとしてのみ使うべきで国民に対して開示する必要はない。 住民票コードの民間利用は禁じられているとはいえ開示してしまえば流用される危険は拭えない。 法で規制されているからといってアーキテクチャの方を緩めるのは間違ったシステム運用方法だ。 普通は逆。 アーキテクチャ上できるだけ悪用や流用ができないように設計しておいて, アーキテクチャでカバーしきれない部分を規範や法で規制していくのがセオリーである。 住基ネットのようなやり方では 「将来は民間の流用も許してしまうようになるのでは」 と勘繰られてもしかたがない。 (ゴシップなどで簡単に首がすげ変わる (誰にでも交換可能な) 大臣の 「約束」 など信用できる筈がない)

多くの専門家が指摘しているように, 住基ネットは基本思想や設計レベルでダメなシステムなのである。

今日の住基ネット関連リンク

他にもいろいろあったけど,取り敢えずこんだけ:

ネガティブ・キャンペーンは有効か

上記のように考えると 「国民共通番号制に反対する会」 のキャンペーンは問題が多いように思う。 もちろんこういう方向からアプローチしていくことは有効だと思うけど, 結果的にこのキャンペーンは 「わたしは番号になりたくない」 という私達の利己的でネガティブな感情を増幅させただけで政治的には何の影響も及ぼさなかったように思う。

個人情報保護法に反対するキャンペーンのときもそうだったが, 何故かこの手のマスコミ主導のネガティブ・キャンペーンは問題の本質を微妙にずらしてしまう。 おそらくキャンペーン自体が目的化されてしまうからだろう。 「目的のためには手段を選ばず,手段のために目的を忘れる」 という奴である。

今の時点からみれば 「メディア規制法反対キャンペーン」 も 「国民共通番号制反対キャンペーン」 も住基ネットの持つリスクをより上昇させる実績しかあげられなかった。 私は今回のマスコミの 「住基ネット」 への関り方について非常に悪い印象を持っている。 いろいろ勘繰ることもできるが,まぁ止めておこう。

今回の教訓は私達にとって重要である。 内容の善し悪しに関らずマスコミ主導のネガティブ・キャンペーンには一定の距離を置くべきだ。 お祭り体質と忘却癖は日本人のお家芸だそうだが, そろそろ冷静に合理的・論理的に考え続けるよう体質改善を図るべきではないだろうか。

日本のエンジニアはインモラル?

中村正三郎さんのページの8/15の記事を見て暗澹となる。 日本のプログラマってのはそんなにインモラルにみえるのかなぁ。 山師的な発想で短期的に荒稼ぎしようってのならともかく, 「各自治体から送られてくる個人情報を盗」 むようなことをやってたら, すぐに仕事が来なくなって食いっぱぐれてしまうんですけど。 企業倫理や職業倫理というのは全然崇高なものじゃなくて, ユーザから信用を得て仕事を続けていくための切実でリアルな規範なのだけど。

日本の職業プログラマ諸君, 私達の世間における評価は所詮この程度だ。

無線LANのセキュリティ

LAC SNS Spiffy Reviews: 無線LANのセキュリティ設定実態調査 (PDF)

WEPのセキュリティ面の危うさは単純に鍵長の問題ではない。 (かといって56bit以下の鍵を使うのは論外。 56bitというのはかつての米国の暗号輸出規制で適用された値。 つまり56bit以下の鍵長であれば (少なくとも) 米国ではクラック可能なのである) WEPの問題は端末識別管理や暗号鍵の管理が繁雑でズサンであるということだ。 したがって, いくら鍵の強度を上げても暗号化システム全体の強度は上がらないのである。 今はどうか知らないが, 初期の製品では生の暗号鍵をユーザが手入力するものまである。 これは明らかに 「看板に偽りあり」 である。 WEPは暗号化アルゴリズムを内蔵しているが暗号化システムであると考えてはいけない。 「暗号化システム」 を名乗るからには運用を含めて鍵やデータを保護する仕組みを提供していなくてはならない。

家庭での運用は適当でもいいんだろうけど (盗聴し放題のコードレスホンを平気で使うような家にWEPが必要とは思えないし), 業務で使うなら無線LANの運用には有線以上の注意を払う必要がある。 少なくとも上記のようなマヌケな製品を選択しないこと。 カタログレベルで製品を精査し不足している部分は (VPNなどを併用して) 一定のセキュリティ強度を保証すること。

2002年08月24日

PGP 8.0 など

PGP関連ニュース:

PGP Corporation では PGP 8.0 のリリース準備も始めているらしい。 日本語環境のサポートはないのかなぁ。

今日の住基ネット関連リンク 2

住基ネットの「本当の危険」が語られていない

この記事はなかなか面白い。 特に後半の 「アーキテクチャ的・法的な抑止策」 は読んだ方がいいかも。

2002年08月25日

ケータイから無自覚に発信される個人情報

今やケータイは単なる 「電話」 ではなく, 広範なサービスを提供するコミュニケーション・プラットフォームとして機能している。 このため, あらゆる個人情報が携帯端末に集中することになる。 ベンダやユーザはこの点をもう少し真剣に考えるべきではないだろうか。

ユーザにとってケータイは消耗品である。 (私はそうでもないが) 他の家電に比べればかなりの頻度で買い替えを行っているし, 持ち歩くものである以上壊れたり無くしたりしやすいものだ。 例えばケータイを買い替えた場合元の端末にある情報はどのように扱われているのだろう。 また,データが転送できるとして転送ツールは他人の個人情報を簡単に吸い上げることができるわけだが, それらのデータはどのように扱われているのだろう。 これらの疑問に対しどれだけのユーザが答えを知っているのか。 無くしたり盗られたりしたケータイはどうなるのか。 ケータイから口座振込が可能であるならば, 通帳やカードよりも簡単にケータイで現金を GET できるのだ。

ケータイの持つアーキテクチャ上の欠陥も見逃せない。 上に挙げた記事の最初の2つは (ベンダは否定しているものの) 明らかにアーキテクチャ上の欠陥である。 パソコンですらあんなに無警戒に不正アクセスやウイルスの侵入を許してしまうユーザがケータイ利用に関して慎重な行動をとるとは思えない。 ケータイはネットワークを介して相手と相互に繋がっている。 だから相手がネットワーク越しにケータイ内の情報を参照するのは原理的には可能であり, アーキテクチャとしてもそれを (一部にしろ) 許容する設計になっていることを自覚する必要がある。

NTT DoCoMo が始めようとしている新サービス 「ア・ラ・iモード」 は, iモードというプラットフォームの下にあらゆる個人情報が統合されることを意味し, もし実現すれば住基ネットなど目じゃない巨大データベースが完成する可能性がある。 しかも現時点では, このデータベースの運用を規制する法は事実上存在しないのだ。

一旦外に出た情報は (内容に関らず) もはやコントロール不能である。 一度個人情報の流出や流用が行われれば, そのユーザが背負わされるリスクは予想しがたい。 これまで発覚している個人情報流出事件では, 管理する企業や団体側は 「ゴメン」 で済まそうとしているようにみえるが, 本来そんなことで許される筈はないのだ。

ユーザ側も現在無自覚に利用しているケータイ・サービスについてもっと慎重になるべきだ。 ケータイのネットワークシステムはまだ商取引が可能なほど洗練されていない。 将来的には (パソコンでできている程度には) 安全になるかもしれないが, アーキテクチャが洗練され法や規範による規制が確立するまでは今のところケータイサービスの利用について一定の保留をしておいた方が安全であろう。

バイオメトリクス技術で認証できるか

バイオメトリクス認証は万全ではない,なりすましを許す可能性あり 〜セキュリティ会議「BlackHat Briefing」の講演から〜

上記の記事はユーザ登録 (無料) しないと見れないのでご注意を。 こんないい記事をフリー公開しないなんて勿体ない。

バイオメトリクス技術は認証に使うには問題が多いが, 何故問題なのかを分かりやすく解説した記事。 必見である。

2002年08月31日

IKE ってなんだっけ?

RFC2409: インターネット鍵交換

ちうわけでIKE関連の穴を塞ぐためのパッチが公開されています。

NAI の公開鍵ID

ところで上記のパッチをチェックするためには NAI の公開鍵を取得する必要がある。 公開鍵は鍵サーバに登録されているのでそこから取ってくればいいのだが, そこからが混乱のはじまりだった。 NAI の公開鍵は以下のとおり

pub  1024R/DD2D4D77 2001-12-28 Network Associates Software Release Key 2002
     Key fingerprint = EF23 D466 1072 FB4B 698A  A9E8 B5BC C978 DD2D 4D77

しかし, Marc Horowitz 版鍵サーバで検索すると以下のようになってしまう。

pub  1024/479137D3 2001/12/28 Network Associates Software Release Key 2002
          Key fingerprint =  00 F3 C2 A5 02 3F A9 97  4A 91 70 40 D7 F7 50 6E

というわけで 「どっちが本当なの?」 ということになってしまったのである。

しかしこの鍵のpgpdumpをとってみると分かるが, この鍵はRSA鍵だがパケットバージョンは4なのである。 したがって Marc Horowitz 版鍵サーバが出力するMD5の鍵指紋は明らかにおかしいということになる。 実際この鍵を無理矢理V3形式で読むと確かに鍵IDは 0x479137D3 になる。 なお, この現象はHTTPで検索した場合にのみ発生するらしくLDAPでは発生しないそうだ。 (私は外部のLDAPにアクセスする環境を持ってないので確かめられないのだが) したがって鍵サーバの問題ではなくフロントエンドツールの問題である可能性もある。

しかし,何だって今更RSA単独鍵なんか使ってんだろ > NAI
普通に主鍵と副鍵に分ければいいぢゃん。(さもなければ署名専用の鍵を使うとか。 ってPGPじゃ署名専用鍵は作れないのか?) セキュリティ関連パッケージを販売している会社がこんなことではいけませんねぇ。 鍵を複数に分ける理由については The GNU Privacy Handbook の5章 を参照のこと。

OpenPKSD はなかなか

いいね。 現在は Key Search のみだが, pgpdump と連動する仕掛けになっている。 一般のPGPユーザにとって一番気をつけるべきなのは ADK だろう。 もちろん鍵をインポートしてから確認をすることもできるが, pgpdump による詳細情報を事前に知っておくことは大事なことだと思う。 手動で公開鍵を手に入れたいなら, まず OpenPKSD のサービスを優先的に利用することをお薦めする。 pgpdump で出力される情報については RFC2440 と見比べるとよいだろう。


[Top Page] [日記最新版]