2005年01月20日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1賀詞交換会次の記事 >> このエントリーをはてなブックマークに追加

某団体の賀詞交換会に出席。

■ 関連記事

■2httpsのページにフィンガープリントがあっても…[セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

そのページの運用が信頼できるかどうか分からないのに、ルート証明書を組み込むのは心配だ。ひょっとして、そのサイトは誰でも書き込めるWikiの様なページかも知れない。
そもそも、そういう難しい判断をしなくても大丈夫な世界を構築するために、PKIがあるのだから、本末転倒である。
やはり、普通のユーザにルート証明書を組み込ませる様な運用をしてはいけない。

■ 関連記事

■3サイト証明書を使って運用しているWebサイトの責任<< 前の記事 このエントリーをはてなブックマークに追加

サイト証明書を使って運用しているWebサイトは、コンテンツの内容に責任を負わなければならないのだろうか。例えば、Wikiを運用するのはいけないことだろうか。
検討する余地があるな。

■ 関連記事

詳細はこの日の詳細から

2005年01月21日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・サイト証明書を使って運用しているWebサイトの責任[http://www.nantoka.com/~kei/diary/?200501b&to=200501203#T200501203][セキュリティ]次の記事 >> このエントリーをはてなブックマークに追加

コンテンツの中身の正誤は別レイヤ[http://www.nantoka.com/~kei/diary/board.cgi?act=read&msgid=144] だというご意見を頂いた。
技術的にはもちろんその通りだし、そういう様に思ってきたのだけれども、例えば、一部のページをサイト運営者以外が自由に更新できる様なことをするのならば、そのページの内容についてはサイト運営者が関知しないという事を明示しないとまずい気がする。

あるいは、サーバ証明書がサーバ証明以上の意味を勝手に持って、そのサイトが信用できるという意味に使われている現状がおかしいのか。

■ 関連記事

■2 フィッシング詐欺 官民で撃退 総務省など指針策定へ[http://www.asahi.com/national/update/0119/005.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

ソースは、 「フィッシング対策推進連絡会」の開催[http://www.soumu.go.jp/s-news/2005/050119_4.html] の様だ。

送信されたメールが実在の銀行やカード会社によるものかをサーバーで見分け、実在しなければ利用者に届かないようにする認証技術の導入を目指している。

は、あさっての方向に向いているのではないか。
一方で、 PKIをズタボロ[http://takagi-hiromitsu.jp/diary/20050120.html#p01] にして、次世代のフィッシング詐欺がおきる土壌を作っている現状を何とかすべきではないか。

■ 関連記事

■3「信用」の意味[セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

日本のPKIを殺した真犯人は誰か[http://takagi-hiromitsu.jp/diary/20050120.html#p01] の議論で考えたのだけれども、サーバ証明書の信用の意味が多くの人に誤解されていると思う。証明書発行会社が意図的に誤解させたのか、証明書の発行を受けた会社が誤解しているのか誤解させているのか。
アリスがウェブでお買いものをする時に必要な信用は

  1. 買おうとしている商品が信用できるものであるか
  2. ボブ商店は信用できるか
  3. そのサイトが本当にボブ商店であると信用できるか
  4. そのサイトは信用できる運用をされているか
  5. 通信路は盗聴されないと信用できるか

であって、サイト証明書が証明してくれるのは、信用のごく一部でしかない。
にも関わらず、ある認証局からサイト証明書を発行されていることをもって、上記の全てが信用できるかの様に説明しているサイトがある。
例えば、

本サービスは、信頼性の高い「通信の暗号化を実現するサーバ証明書」を発行するベリサインより認証を受けております。
これは「情報の保護」を行い、安心で安全なeビジネスを展開している会社としての証明です。
当社ウェブサイトでは、日本ベリサイン株式会社の定める高度な認証基準に基づき発行されるウェブサーバー用デジタル証明書を取得し、安全なウェブサイトを運営しております。
○○は「日本ベリサイン株式会社」より認証を受けています。
ベリサイン社は、国内・海外ともに導入実績を誇る世界最先端のインターネット認証機関であり、 セキュリティ対策には万全を期しています。
○○のウェブサイトは、第三認証機関である日本ベリサイン社より認証を受けたウェブサイトです。詳しくは、こちらをご覧ください。

の様な文言で、あたかもサイト証明書の発行を受けている事が、すなわちサービス全体が信用できるものである様な説明をしている。
分かっていてやっているのであれば詐欺的な表示であり、万が一、そう信じて書いているのであれば、サイト運営者がサーバ証明書の意味を理解していないということである。だとすると、これらのサービスのセキュリティには大きな疑問がある。

■ 関連記事

詳細はこの日の詳細から

2005年01月22日()<< 前の日記 | 次の日記 >>
この日の詳細

■1ブラウザに組み込み済みのルート証明書[セキュリティ] このエントリーをはてなブックマークに追加

試しにWindowsに組み込み済みのルート証明書を全部削除してみたら、バイナリの正当性検査やらWindows Updateやらが軒並み動かなくなって、困った事になった。
各々の証明書の用途とCP,CPSの一覧表はどこかにあるべきなのだけど見つからない。

Microsoft ルート証明書プログラム[http://www.microsoft.com/japan/technet/security/news/rootcert.asp]:

どうもこれが基準の様だけど、一覧表は見当たらない。

■ 関連記事

詳細はこの日の詳細から

2005年01月23日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 JavaScriptによる簡単なページ制御[http://www.hyuki.com/diary/200501#i20050117055842] このエントリーをはてなブックマークに追加

リッチクライアントで解決しようとしていることの多くは、「ニッチ」クライアントで解決できるのではないかという構想(妄想?)を持っている。
要素技術として、JavaScript, CSS, DHTMLを使って、予めクライアントに相当するライブラリ部分をキャッシュが効く様にダウンロードさせてしまう。
いちいちクライアントをインストールしなくても、リッチクライアントっぽいことができる。
もちろん、サーバ側でごそごそJavaScriptのコードを出力するのは大変なので、サーバ側からは、それなりにリッチなクライアントとして物事ができるライブラリに見える仕掛けにするわけだ。隙間を埋めるのでニッチクライアント。

そもそも、どうしてそういうものが欲しいと思ったかと言うと、独自のプラグインを組み込ませられる電子政府のシステムやら電子自治体のシステムが多すぎると感じたからだ。
民間のサービスだったら、そういうのを組み込むのが嫌だったらそのサービスを利用しなければ良いが、国や行政の場合は、そのシステムを否応なしに受け入れなければならない。

本当は、標準的なWebの表現力だけで作れば良いのに、独自のUIを作ろうとしすぎる。署名されているからと言って得体の知れないプラグインは入れたくないし、システムを縛られるし、そもそも積極的にバリアを作り出しているではないか。
この背景には何があるのだろうか。Webの仕組みを知らない人がUIを設計しているのか、将来を独占するために独自の何かに囲い込みたいのか。

■ 関連記事

詳細はこの日の詳細から

2005年01月24日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 「バークシャー州長崎県」と「高知県ニューバリー市」は姉妹都市か[http://takagi-hiromitsu.jp/diary/20050123.html#p03][セキュリティ]次の記事 >> このエントリーをはてなブックマークに追加

意外と素早く、「バークシャー州」では無くなった様だ。

E = den-shinsei@pref.nagasaki.lg.jp
CN = eap.pref.nagasaki.jp
OU = Nagasaki Prefecture Jyouhouseisakuka02
O = Local Governments
L = Nagasaki Area
S = Some-State
C = JP

うーん。「Some-State」ですか。なんていうかアレ。主体者名を表示する意味が分かっていないのではなかろうか。これでは認証局の信用が損なわれる。

直った様だ:

2月3日に確認したところ、この問題は解決されていた。

■ 関連記事

■2 子羊ルーター販売終了のお知らせ[http://www.wildlab.com/LAMB/pages/sale_terminate.htm]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

超小型LinuxルーターLAMB[http://www.wildlab.com/index.html] が販売を中止するらしい。発売当時は、内部情報が公開されていて「Linuxが動く箱」としてずいぶん注目されたものですが、他の選択肢も出てきて、難しくなってきたのかも知れません。
ものすごく潔いと思って感心したのが、

製品のハードウェア設計資料をパブリック・ドメインとさせていただきます。どうぞ将来のメンテナンス、その他にご活用下さい。 資料の改変、商用利用は一切制限致しませんので、現代的な製品に発展させていただければ幸いです。

として、回路図、プリント基板パターン、ROM、BIOS設定を「パブリック・ドメイン」にするという宣言。
確かにこれまでのユーザーは助かるし、ひょっとするともっと安価な互換品を発売する会社が出てきて、喜ぶユーザーもいるかも知れない。でも、なかなかできることではないと思う。

■ 関連記事

■3 続・接客について考えたこと[http://www.nantoka.com/~kei/diary/?200501a&to=200501061#T200501061]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

お返事来た。ごめんなさいで終わらずに、ご指摘感謝になっていた。理解してもらえて良かったと思う。
もっと良いお店になります様に。

■ 関連記事

■4Windowsのヘルプファイルが表示されない<< 前の記事 このエントリーをはてなブックマークに追加

FireFoxを常用する様になって、Windowsのヘルプファイルの一部が表示されなくなる現象に気が付いた。以前から、時々、ヘルプの一部の項目が表示されないということはあったのだけど、それほど困る事も無かったので放置していた。
色々やってみて、既定のWebブラウザをIEにすると直るということは分かったのだけれども、これでは日常生活が不便だし、いつ危ない目に遭うか分からない。FireFoxを通常のブラウザにしたままで直すことができないか、色々試してみたところ、「IEの(文字)エンコードで自動選択にチェック」が入っていないと、表示されないヘルプページがあるということが分かった。エンコードが変なページを無理やり見るために変更した影響だった様だ。

結局、Microsoft HTML ヘルプが、chm形式のヘルプファイルを扱う時に、IEのコンポーネントを使っていて、文字コードが設定したものと違っているとレンダリングに失敗して表示されないという仕掛けらしい。
しかし、Microsoft HTML ヘルプにエンコードを設定する方法は用意されていない様だし、これはIEの設定がどうあれ表示できないと困る様に思う。普通のユーザーがヘルプとIEの設定を結びつけてトラブルシュートする事は困難だろう。
しかし、どうしてデフォルトブラウザをIE以外に設定した時だけ発病するかは謎のまま。

■ 関連記事

詳細はこの日の詳細から

2005年01月25日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 ACCS不正アクセス事件、元研究員に懲役8月求刑[http://www.itmedia.co.jp/news/articles/0501/24/news021.html][セキュリティ] このエントリーをはてなブックマークに追加

悪いか悪くないかという話は置いておいて、罪になるのかならないのかに興味がある。 もし、検察側が主張する様に

問題のファイルは、FTP経由でアクセスするのが通常。FTP経由のアクセス時にはIDとパスワードによる認証を要求していた。CGI経由でのアクセスは、FTPによるアクセス制御機能を避ける行為で、通常利用の範囲外。不正アクセスにあたる

のをもって、不正アクセスとするならば、まさに サイバーノーガード[http://d.hatena.ne.jp/keyword/%A5%B5%A5%A4%A5%D0%A1%BC%A5%CE%A1%BC%A5%AC%A1%BC%A5%C9%C0%EF%CB%A1?kid=31852] である。ネット社会の進歩を阻害する行為だ。

サイバーノーガード戦法批判:

某IRCチャネルで、どうしてサイバーノーガード戦法が通用してしまうのかについて意見をもらった。
なかなかまとめるのは難しいのだけど、なるほどというポイントが見つかった。メモしておく。

  • サービスを提供する側は人の財産(情報)を扱うわけだから、それ相応の対策が必要だ
  • 銀行が預金者のお金を盗まれた場合、悪いのが誰であれ、銀行は預金者に対して責任を負う。
  • 「一般的なセキュリティ対策は講じていたが、盗難は魔法の様な技術を持ったハッカーによって行われた。魔法に有効な対策はない。」という主張。
  • 家庭の玄関に鍵を掛けましょうという論にすると、いや泥棒がいなければ大丈夫という反論につながってしまう。
  • ネット社会の中で利益を得ていくために必要な投資をしていない。
  • 一般の人とセキュリティについて知っている人の間で「十分な対策」の認識が全然違う。

それなりの文章にまとめたい。
ハッカーは魔法使いの様に見えるけれども、魔法使いではない。ウィザードは確かに魔法使いの様に見えるけど、やっぱり魔法使いではない。マジシャンは魔法使いの役を演じるけれども、やっぱり魔法使いではない。

■ 関連記事

詳細はこの日の詳細から

2005年01月26日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1ぐる[ぐる]次の記事 >> このエントリーをはてなブックマークに追加

いくつかのサイトを巡回。

荘内銀行続編[http://www.st.ryukoku.ac.jp/~kjm/security/ml-archive/connect24h/2005.01/msg00135.html]:

zone-h[http://www.zone-h.org/en/defacements/view/id=2001833/] によると、IIS4.0だったらしい。現在はIIS5.0で何事も無かったかの様に稼働中。アナウンスも無し。

発信者番号偽装[http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2005/01.html#20050124__furikome]:

向こうでT1契約すればできそうな感じではありますが、そこまでやってモトが取れるのかという疑問もあります。
詳しく知りたい向きは、以下の本の第13章、巧妙な嘘あたりをどうぞ。

[IT Pro] 危ない案件から会社を守る[http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050125/155212/]:

支払い関係のリスクの話。

「支払いの話になると怒る,機嫌が悪くなる」という客は要注意

あぁ。それは危険な香りがします。

ノーアポでひょっこり訪ねることはリスク管理面から見てもすごく大事なことです。お菓子持って「時間が空いたもので・・・」と言って行けばいいんですから。

このあたりになると、普通の会社の取引先の経営状態の見極め方と何にも変わらないですね。どの業界でも大事な事は大事。

働いたら負けかなと思ってる[http://www.geocities.jp/soso_evolution_x/neet1.jpg]:

あぁ。これがネタ元だったわけですね。この問題、真剣に考えないと日本の将来がないな。

買ってはいけない [ソーテック][http://www.higuchi.com/index.php?itemid=192]:

社内の連絡体制に相当の問題があった様だ。
液晶パネルの爪が折れたという修理で、依頼者の了解も取らずにハードディスクを初期化してしまったと。
もちろん、この場合のSOTECの対応には問題があるけれども、修理に出せばディスクの内容は戻ってこないことを覚悟しておいた方が良いし、セキュアなデータの保全を考えればバックアップ取ってから初期化して修理に出す必要があるかも知れない。

プロバイダ別 ntp サーバリスト[http://sonic64.hp.infoseek.co.jp/2004-12-02.html]:

福岡大学NTPサーバの混雑解消にご協力を[http://slashdot.jp/articles/05/01/21/0214236.shtml] という記事が出ていた。ウチもしばらくの間、福岡大学さんにお世話になっていたけれど、負荷分散させた方が良いだろうと思って、他の公開サーバを使っていた。
このリストで、初めてウチの上流プロバイダもntpサーバを公開していることを知った。

■ 関連記事

■2 生体認証への根本的な疑問[http://hski.air-nifty.com/weblog/2004/03/post_8.html][セキュリティ]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

結論を先に。バイオメトリクス認証機器は、バイオメトリクス情報そのものを保存してはいけない。

最近、セキュリティを強化するために、指紋認証に代表されるバイオメトリクス認証を用いる事例が多くなってきた。
特に指紋認証については、USBポートに刺す製品が非常に安価になってきていて、2万円以下で手に入る様だ。
しかし、多くの生体認証製品には大きな危険がある。リンク先で述べられている様に、

パスワード認証であれば、破られたときは、パスワードを変更すれば、正当な利用者が利用を続けることができる。ところが生体情報は、偽造されたことがわかった後、正当な利用者が利用を続けられるようにする方法が、まだ提案されていないような気がするのだ。

という問題がある。実際に、この問題は生体認証の未解決な大きな問題だ。

特に指紋認証製品については、指紋パターンをイメージとして持っている製品 *1 が多い。このデータを悪用すれば、その人になりすます事が容易に可能になる。
今後、指紋認証を使用する機会が増えてくると、色々なものに指紋認証の登録を行う事になる。 もし、その内のどれかから登録した指紋情報が漏洩するか悪用されるかすると、他の全てのシステムでなりすましの被害を受ける心配がある。さらに、その人は一生指紋認証を使う事ができなくなる。既にその人の指紋情報が秘密では無くなっているし、しかもそれは変更不可能だからだ。

このあたり、UNIXのパスワードやATMの暗証番号と比較すると問題が分かりやすい。多くのUNIXではパスワードは非可逆的な暗号化を行って格納している。正当なパスワードかどうかを調べる時には、同じ暗号化をしてみて、同じ暗号文になることを確認する。
この方法であれば、万が一暗号化されたパスワードファイルが盗み出されても、非可逆的な暗号だからパスワードそのものは危険にさらされない。攻撃者はパスワードの可能性のあるものを一つ一つ暗号化してみて、同じ暗号文になるものを探すという非効率的な攻撃しかできない。
ところがATMの暗証番号の場合は、暗証番号そのものを記録している。数字4桁だから、仮に暗証番号を暗号化しても10,000回の組み合わせを試せば良いので、暗号化する効果が期待できないという事情もある。
繰り返すけれども、暗証番号やパスワードは変更できるけれども、指紋は変更できない。

キャッシュカードの暗証番号とロッカーや携帯電話の番号を一緒にしていたために、偽造キャッシュカードでお金を引き出されるという事件が起きた。
こういう被害の発生を防ぐために、ATMに生体認証装置を取り付ける様にしたとしよう。カードを入れて指紋認証をするのだ。
一方、ゴルフ場でも盗難を防ぐために、ロッカーの鍵を指紋認証装置に変える。指紋を登録してロッカーの鍵を掛けて、開ける時も指紋で開ける事ができる。
ゴルフ場の事件[http://www.mainichi-msn.co.jp/shakai/jiken/news/20050120k0000m040171000c.html] では、支配人がマスターキーを使って、利用者が設定した暗証番号を知り *2 、偽造団に伝えていたという。
同じ事を指紋認証装置でやられたらどうなるか。ゴルフ場の指紋認証装置から登録指紋データを吸い出して、偽造指を作る。スキミングしたカードと偽造指を持って行って、一丁上がりだ。
偽造指にだまされない装置を作れば良いという主張があるかも知れないが、偽造指に騙されない装置はより多くの生体情報を取得しなければならない。それが盗まれたらどうするか、堂々巡りだ。

ゴルフ場の場合は、ロッカーの番号にキャッシュカードと同じ番号を使わないという自衛策がある。 過去の判例[http://www.ansin-jp.com/info/law_detail.php?page=120] でも、カードと同じ暗証番号をロッカーで使用するのは被害者側に過失があったとしている。
ところが指紋の場合は、違うものを使う事はできない。盗まれたら終わりなのだ。
また、繰り返すけれども、暗証番号やパスワードは変更できるけれども、指紋は変更できない。

ほとんどの指紋認証装置はもう一つの問題を抱えている。ガラス板の様なものに指を押し当てるタイプは、良質な指紋サンプルをガラス板そのものから得る事ができる。ガラス板をきれいにしておいて、ターゲットが利用した後に、粘着テープを押し当てれば良い。装置によっては、このサンプルから得た指紋画像でも騙されるものがあるという。

利用者側でやれることがあるとすると、指紋情報が盗まれる心配があるところで、指紋認証装置を使わないというのが一つの選択。指を選択できれば少しだけ安全になるけれども、指を指定している装置が多い。

指紋認証装置を導入する場合は、指紋情報が盗み出されたらどれだけの損害が発生するか考えておく必要がある。被害は個人情報漏洩の比ではないのだ。パスワードは変更できるかも知れないけれど、指紋は変更できない。
こういった意味での安全性を考えると、前述のUNIXのパスワードの様に指紋情報を直接保存しない装置が安全だけれども、私はそういう製品を一つしか知らない *3 し、まだ多くのメーカーはこの問題を重視していない様に思える。
バイオメトリクス認証が信頼して使用される様になるためには、この問題はクリアすべき課題である。
バイオメトリクス認証機器は、バイオメトリクス情報そのものを保存してはいけない。

加筆修正:

28日に 27日の記事[http://www.nantoka.com/~kei/diary/?200501c&to=200501271#T200501271] を踏まえて加筆修正をした。論旨は変えていないつもりだ。 28日[http://www.nantoka.com/~kei/diary/?200501c&to=200501281#T200501281] にも関連記事を書いた。
実は、この26日の記事を書いた時点では、Interfaceの3月号を読んでいなかったのだ。あまりにもタイムリーで驚いた。

*1: パターンマッチング法を採用している製品はパターンそのものを持っている。マニューシャ・チップマッチングは、特徴点周辺の指紋パターンを持っている。マニューシャ・リレーションはイメージそのものを持つ必要はないが、低価格の製品には使いづらい。周波数解析法は指紋像全体を用いずに照合できる。詳細は27日の日記を参照。
*2: この製品には非常に大きな欠陥がある。マスターキーを使うと利用者が設定した暗証番号の一覧が印字できる機能があったというのだ。普通に考えればそんな機能は不要で、指定したロッカーを開けるか、暗証番号が変更できるかすれば用が足りる。まるで利用者に知られずに開ける方法を提供したとしか思えない機能である。そんな機能は悪用されるためにある機能だ。利用者にしても、まさか暗証番号を取り出す機能があるとは思わないだろう。
*3: アルゴリズムをライセンスしているので製品としては複数出ている。ラインセンサータイプのものは、センサー表面に指紋が残る問題もクリアしている。Interface誌2005年3月号参照。

■ 関連記事

■3ラミネーターで片面のみラミネートするには[magic]<< 前の記事 このエントリーをはてなブックマークに追加

2枚あわせてラミネートして、縁を切り落とせば良い。厚さがあるので熱が足りずに接着が弱かったので、切り離した状態でもう一度通した。

何を作りたかったかというと:

バイシクルのカードを使っているのだけれど、これのケースが紙製で、中身より先にケースがボロボロになる事が多いので困っていた。
カードは紙製の割には、驚くほどの耐久力があるのに、ケースはそのままポケットに入れるものだからすぐボロボロになる。
で、ケント紙に印刷して
ケント紙に印刷したバイシクルのケース
こういうものを作った。A4サイズにきれいに二つ分収まる。
両面ラミネートすると、硬すぎてきれいに折り曲げられないので、片面ラミネートする必要があったのだ。完成すると、
完成したバイシクルケースのコピー品
こういった感じになる。両面の色が違うのは、ある用途に重宝する。

■ 関連記事

詳細はこの日の詳細から

2005年01月27日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・バイオメトリクス認証機器は、バイオメトリクス情報そのものを保存してはいけない[http://www.nantoka.com/~kei/diary/?200501c&to=200501262#T200501262][セキュリティ]次の記事 >> このエントリーをはてなブックマークに追加

昨日の続き。書き終えてから、読み返してみると説明不足な感があって、ツッコミがあるだろうなと思っていたところに、まさに鋭い コメント[http://www.nantoka.com/~kei/diary/board.cgi?act=read&msgid=152] を頂いた。

バイオメトリクス認証機器が保持する「バイオメトリクス情報そのもの」というのは、そこからすぐに“偽造指”が作れるものなのでしょうか? よくわからないのでその辺りの情報のポインタがあれば、教えていただけないでしょうか。

指紋認証に関して言えば、偽造指が作れるだけの情報を保持する機器と、そうでない機器がある様だ。
「すぐに」というのは難易度の問題で、当然機器内部のデータフォーマットを解析する必要は出てくる。フォーマットが秘密だったら大丈夫かというと、それは暗号で言うと「独自秘密な方式の暗号化を施しているから安全」という主張だから、当然大丈夫ではない。しかも、鍵はその機器の中にある。

指紋認証に使われる代表的なアルゴリズムとして、パターンマッチング、マニューシャ(リレーション)、周波数解析がある。
(指紋全領域の)パターンマッチングの場合、まさに指紋データそのものを照合に用いるので、偽造指が作れるだけの情報を保持していることになる。
マニューシャ方式の場合は事情が複雑で、照合に用いる特徴として何を用いているかによって、状況が変わってくる。特徴点周辺の画像を保持しているチップ・マッチングの場合は、特徴点画像をつなぎ合わせて、周辺を特徴として抽出されない様な画像で補間すれば、その画像を同様にスキャンした場合に、狙った特徴点をマッチングに用いさせることが可能だから、偽造指が作れる可能性は高いと思われる。
周波数解析の場合、アルゴリズム的に指紋画像全体のイメージを持たないで照合をするので、バイオメトリクス情報の漏洩という問題に対しては最も安全という印象を持っている。

残念ながら、「セキュリティに関わるから秘密」という意識が高いのか、実際に使われている機器がどの様な処理をしているのかについては、まとまった資料が非常に少ない。
「Security by Obscurityは間違っている」という立場からすると、安心して利用できるだけの情報が出ていない様な気がする。秘密だから安心ではないのだ。

ところが、タイムリーなことに、現在発売中の インターフェイス誌2005年3月号[http://www.cqpub.co.jp/interface/contents/2005/200503.htm] が、バイオメトリクス認証の特集を組んでおり、かなり突っ込んだ解説をしている。
先に述べた、周波数解析法の製品を開発した会社の技術者も記事を寄稿しており、そのアルゴリズムが指紋の全体像を用いていないということも確認できた。

特集全体を読んだが、 「生体認証への根本的な疑問」[http://hski.air-nifty.com/weblog/2004/03/post_8.html] への答えは無かった様だ。
バイオメトリクス情報そのものを保存しないアルゴリズムもあるのだから、こういった方向でのアプローチはもっと評価されて良いと思う。

■ 関連記事

■2読んだ本[book]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

読み終わったのでメモ。図書館で借りたもの。

[和書]奇術探偵曽我佳城全集 秘の巻[http://www.amazon.co.jp/exec/obidos/ASIN/4062737604/keisdiary-22?dev-t=DDHPHE04VROHE%26camp=2025%26link_code=sp1]:

[和書]奇術探偵曾我佳城全集 戯の巻[http://www.amazon.co.jp/exec/obidos/ASIN/4062737612/keisdiary-22?dev-t=DDHPHE04VROHE%26camp=2025%26link_code=sp1]:

■ 関連記事

■3ぐる[ぐる]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

見つけたページのURLをメモ。

リスク管理はしっかりと[http://www.geocities.jp/navyfrog993/HibiZakkan/05/Jan05/Jan05.htm]:

愚者は経験に学び、賢者は歴史に学ぶって言うんですが、ちょっと前の経験に学んでないじゃん。

「セキュリティ、どこまでやれば大丈夫?」――経産省、不安をなくす指標作りへ[http://www.itmedia.co.jp/enterprise/articles/0501/26/news098.html]:

Stressful Angelさんとこ[http://stressfulangel.cocolog-nifty.com/stressful_angel/2005/01/_127.html] から。
微妙に嫌な予感がする。こういうガイドラインは注意しないと免罪符になってしまうことがある。
「経産省のガイドラインに従って対策してある。今回の個人情報の盗難は魔法の様な技術を持ったハッカーによって行われた。魔法に有効な対策はない。従って当社には責任はない。」
とか言い出す会社がいない様な指標になることに期待する。

魔法に有効な対策はない:

有効な対策は無いわけではなくて、魔法使いの様なセキュリティ専門家を雇えば良いらしい。そういう人は ウィザード[http://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A3%E3%82%B6%E3%83%BC%E3%83%89] と呼ばれる。
某チャネルでの会話より。

ハッカーとクラッカーはWebの世界に住んでいる魔法使い[http://www.nhk.or.jp/netabra/lesson/net26/0212_1.html]:

メモリンク

■ 関連記事

■4 HDD パスワードクラッカーポッド[http://www.ubic.co.jp/VOGON-Pod.html][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

セキュリティホール memo ML[http://memo.st.ryukoku.ac.jp/archive/200501.month/8082.html] より。
こういうものがあるからには、ハードディスクパスワードで安心してはいけない。
顧客情報が入ったノートパソコンが盗まれたけれども、暗号化してあるので大丈夫という発表は信用できないということだ。

■ 関連記事

詳細はこの日の詳細から

2005年01月28日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・バイオメトリクス認証機器は、バイオメトリクス情報そのものを保存してはいけない[http://www.nantoka.com/~kei/diary/?200501c&to=200501271#T200501271][セキュリティ]次の記事 >> このエントリーをはてなブックマークに追加

予想以上に多くの反響を頂いて驚いている。もう一つ、 元記事[http://hski.air-nifty.com/weblog/2004/03/post_8.html] でHSKIさんも指摘している、「生体情報は変更ができない」という問題があまり指摘されて来なかったということに驚いた。

こういう課題はあるけれども、生体認証は使い始めるととても便利だ。
ユーザーIDあるいはIDカードとパスワードの運用だと、運用時に勝手に貸し借りを行って、セキュリティハザードになることがしばしばある。生体認証だとこの問題は起こりにくい。
甘いパスワードを使うユーザーがシステム全体のリスクを上げる事もないし、無くしたまま気づかないという問題もない。
例えば、

  1. 自分が肌身離さない携帯電話やノートパソコンに付けて、起動時や操作時のスイッチの様に使う
  2. 指紋やアイリス、顔照合をユーザーIDとして使って、暗証番号を入力する

の様な用途では、生体認証の有利な点が生かせると思う。
1の用途は、パスワードの入力でも良いところだけど、面倒だからやってないところに導入すると、利便性とセキュリティの両立を図る事ができる。自分が所持しているものだから、そこから生体情報が盗まれるリスクは少ない。当然、デバイスごと盗まれる心配はあるから、バイオメトリクス情報そのものを保存すべきではない。
2の用途は、終生変わらないバイオメトリクス情報をユーザーIDとしてしか使わないところが肝だ。ユーザーIDなので盗まれてもダメージは少ない。だけれども、本人が覚える必要が無いし、他人に貸す事ができないのが、管理上は有利だ。この場合も、やはりバイオメトリクス情報そのものを保存すべきではないし、保存せずに実現が可能だろう。

生体認証機器の場合、ユーザーIDとパスワードと違って、大事な生体情報がどういう様に格納されて照合されているかが分かりにくいところが、技術者の不安を招く事になっていると思う。
ところが、こういうセキュリティ機器は仕組みを秘密にすることでセキュリティが保てるという幻想が支配しているのか、これまでアルゴリズムの公開に消極的だったと思う。
そういう意味で、前述したインターフェイス誌の記事は一読の価値があると思う。

■ 関連記事

■2ぐる[ぐる]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

■ 関連記事

■3読んだ本[book]<< 前の記事 このエントリーをはてなブックマークに追加

これも図書館で借りた本。

[和書]シェフとギャルソン,リストランテの夜[http://www.amazon.co.jp/exec/obidos/ASIN/457697047X/keisdiary-22?dev-t=DDHPHE04VROHE%26camp=2025%26link_code=sp1]:

イタリア人から見ると、日本人はアルデンテのパスタを理解してくれる良き友人だという話を聞いた事がある。
アメリカ人はパスタは茹ですぎないと受け入れてくれないらしい。

■ 関連記事

詳細はこの日の詳細から

2005年01月29日()<< 前の日記 | 次の日記 >>
この日の詳細

■1諫早net運営委員会 このエントリーをはてなブックマークに追加

諫早net[http://www.isahaya.net/] の運営委員会に出席。その後呑み。
お食事ができる店行って、 Burns[http://www.nantoka.com/~kei/diary/?200203b&to=200203122S1#T200203122S1]M,PaPa[http://www.townpita.com/1103060598] とハシゴ。飲み過ぎたか。

■ 関連記事

詳細はこの日の詳細から

以上、10 日分です。

指定日の日記を表示

前月 2005年01月 翌月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

keikuma on Twitter

keikuma Name:前田勝之
Location:長崎市
Web:http://www.nantok...
Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

サイト内検索

Google AdSense

Powered by hns-2.19.9, HyperNikkiSystem Project