2008年7月5日(土曜日)

償い

読み終わったのでメモ。

償い (www.amazon.co.jp)

「自分が助けた人が殺人鬼だったら?」というテーマは、あんまり消化されていないような……。

「償い」にコメントを書く

WASForum Conference 2008: Webセキュリティのマルプラクティス – 思い込みによるソフトウェアエラーをなんとかしろ

法律っぽい話の後は、最後のセッション「マルプラクティス」。まあ、早い話が「あるある」ネタなのですが、携帯サイトから投票できる仕組みがあったりいろいろ面白い仕掛けが。

生の雰囲気が伝わらないといまいち面白くないかもしれない上、進行が速かったのでメモがついて行けていないところが多く、情報欠落気味です。

マルプラクティスとは

mal-practice
間違ったプラクティス
辞書を引くと「医療過誤」とあるが、ちょっとイメージ違うかも
「ベストプラクティス」の反対語みたいな感じ

マルプラクティス

プログラミング・マルプラクティス

サニタイズのみ
フィルタのみ
コードレビューしない
ソースコード検査しない

オープンソース・マルプラクティス

コスト0だから選び放題
ASP.NET / Java+Struts / Ryby+RoR …… 組み合わせ無限
Webサーバ×ミドルウェア×DBの順列組み合わせが無数に
その組み合わせは誰も知らない?
「バルカン化」……みんなラテン語語源なのに微妙に違う

※ASP.NET はオープンソースではないと思いますが。

ブランド・マルプラクティス

「データベース業界トップシェアのA社製品だから、問題があるはずがない!」

情報マルプラクティス

「脆弱性情報さえウォッチしておけばよいのだ!」
CVE/JVNに載っていないものは脆弱性ではない?
情報に頼りすぎるのは……
例:「お上が言えば良いのだ!」

このあたりから、中島社長へのリスペクトが感じられるようになってきます。

GUIマルプラクティス

とりあえず「グイ」を作成
マネージャに見せる!
できあがったように見える!
(もうできてるじゃん、すぐ完成だよね→納品早まる)
ちゃんと作る時間なし!

カタカナで「グイ」と書かれると面白いですが、それよりも……。

WAFマルプラクティス

とりあえず「ワフ」入れておけば良いですよ
よし買った!
だけど結局、電源入れてない
WAFの機能を使うとアプリケーションが動かなくなるので、ロードバランサーとしてしか使っていない :-)

これですよ。カタカナで「ワフ」と書かれると、すごく間の抜けた何かに見えてきますね。

監視マルプラクティス

アクセスログでかすぎ! 全部見ていられないよ!
カスタムのログ解析ツール? なにそれ?
SQLインジェクションに気づかない
急にサイバー戦争の渦中に放り込まれる
異常アクセスを報告したことがない

中島社長へのリスペクト。ちなみにこのとき、「皆さんはログどうしてますか?」という話に対して「放置で /var あふれた」と書き込んだのは私です。これ某所の実話でして、フォレンジックどころじゃないですね。

永遠のβマルプラクティス

問題あるかもしれないし!
とりあえずβとか謳っとけ
ずーっとβ
→品質に対するコミットメントを下げている?

ドキュメンテーション・マルプラクティス

「ここはWebアプリケーションでACL書けば良いからプログラムではチェック不要ね。」
「はい」
→あれ、そんなことドキュメントのどこにも書いてないぞ?
開発:「Webサーバでチェックするはず」と思ってチェック機能を省略
SI:「Webアプリでチェックするはず」と思って設定を省略

テスト・マルプラクティス

開発の早い段階でソースコード検査を実施!
でも運用前に動的検査やってない
上司曰く「一度テストしたじゃない」
(色々あるテストの違いをどうやって説明したものか。テスト費用の見積もりの説明が必要)

他人事マルプラクティス

開発・インテグレータ・運用者が火花を散らす
「それは開発の品質問題でしょ!
「いや現場で監視で何とかしろ!
「インテグレータがワフ入れてないから!
Not our problem!

沈黙のマルプラクティス

顧客を前に、言えない!
うちのWebアプリにはあんな問題やこんな問題が……

ミーティング・マルプラクティス

「セキュリティはちゃんとしていますよね」
「……」
「大丈夫ですよ、ガハハ」
セキュリティに関するミーティングのはずが、和やかに過ごそうとして

報告マルプラクティス

「先週の問題はつぶしましたが、今週新しい問題を直しています」
「いったいいつになったら仕上がるんだ!」

要約マルプラクティス

「要するにどういうことだ」
要してはいけない!
Webセキュリティの問題は複雑なのだ、勉強しろ!

調達マルプラクティス

「これだけの予算で何とかしろ」
「前にワフを買ったが、今度はチェッカーか。いったいいくつ買えばいいんだ」
製品ではない、プロセスと人なのだよ!

営業マルプラクティス

「この製品さえ買えば安心です!」
発火セーフ!
そんな製品ないって……

仕様マルプラクティス

仕様なのか脆弱性なのか
新しい脆弱性……瑕疵担保でやっちゃって良いのか
悪徳車検業者
スキャン、以上!
どんなテストをやったのかの情報がない
なにがしか問題が発見されたらテスト終了?

スケジュール・マルプラクティス

「月曜までに直してください」

顧客対応マルプラクティス

とりいそぎ、お客様情報が漏洩した可能性が……。
(ぶっちゃけ2000人以下だ)
調査の結果カード番号も……
3%還元します
状況を勘案し、1,000円相当を
※二転三転する、noticeになっていない

メンテナンス・マルプラクティス

「新たな脆弱性が出てきたので修正工数を……」
「そんなの予算に積んでないから無理」
「駄目な計画立てておいて涼しい顔」
年度計画に盛り込んでおくべき

インベントリ・マルプラクティス

「当社には脆弱なWebアプリはいくつあるんだ」
「それは分かりません、ただ対策は……」
※アプリは2000個ある
リスク資産を棚卸しできていない
開発した資産を把握できていない
古いアプリケーションを捨てていますか?

コンプライアンス・マルプラクティス

PマークとISMS……
内部統制……
文書化、文書化
※現場の問題が別にある

マルプラクティスの話はここまで。ここからは、名前に「マル」とつけば何でもありの「●プラクティス」の世界に突入して行きます。

●プラクティス

Webアプリケーションに詳しくもないプログラマを丸抱え
インハウスで開発したものの、まるでだめ
結果、はまる
まるでだめ
コピペで丸写し
エスケープコードを丸呑み
業者に丸投げ
買ったけど電源入れてないから丸損
発火セーフ入れても丸腰
やってることがまるでちがう
でもそのことはマル秘
注入工具で丸出し
面目は丸潰れ
会社は丸焼け
社長は丸坊主
やったやつは丸儲け
困る

この後、会場からも「マル」のネタがいくつか提供されましたが、メモしきれず。

最後に

最後に、以下の言葉で締めくくられました。

「失敗のパターンから学ぶ、成功への一筋の光」

感想

1日目の中島社長のセッションを聞いていると2倍楽しめるセッションとなりました。まあ、そうでなくても、何のことを言っているのか全く分からないという人は少なかっただろうと思いますが。

本人に直接言ってあげたほうが……と思わなくもなかったのですが、これは特定個人の問題ではないわけでして。ありがちな失敗のパターンをいかに共有していくのか、というところが課題になるでしょう。

「WASForum Conference 2008: Webセキュリティのマルプラクティス – 思い込みによるソフトウェアエラーをなんとかしろ」にコメントを書く

関連する話題: WAF / セキュリティ / ハッカーセーフ / WASForum Conference

WASForum Conference 2008: Security Wars EpisodeⅢ

SDLの話に続いて、高橋郁夫弁護士によるお話。

スライドが英語と日本語のチャンポンで、非常にメモがとりづらかったです。というわけで、申し訳ないのですがメモの精度は低いです (いや、他が精度高いかと言われるとつらいですが)。最後の方はホントにただの羅列で全然まとめられていません。

登場シーン

謎のハミングとともに黒マスク、黒マントの人物登場。まあ、タイトルから分かると思いますが。

自分のハミングなら著作権侵害は大丈夫だろう

EpisodeⅠ: ハッカーの暗黒面

怒り、恐れ→フォースの暗黒面
限界を超えたくなる

office氏事件

2003年11月、AD2003
Excelファイルに伏せ字ではなく個人情報が掲載
12名がダウンロード

full-disclosure vs 責任ある開示
なぜ伏せ字にしなかったのか? → 自分のプレゼンをインパクトのあるものにしたかったのでは
最後の行為はアドレスバーへの文字の入力

※そのままメモしていますが、ちょっと事実と異なるかもしれない気がします。

ツナミハッカー事件

2004年12月、インドネシア津波災害
Daniel Cuthbert という大学の先生が、津波災害の寄付
サイトが怪しいので、URL に ../../../ をつけてみた
IDS が反応
逮捕、有罪!?

Winny事件

1審→150万円の罰金
あくまで技術は中立的なものと認定。具体的な状況と本人の主観を合わせて判断している
「Winnyが侵害に使われていることを認容しつつ新バージョンを公開した」ということが問われている
開発したことではなく、新バージョンをアップロードしたことが問われている
ソースコードの分析は何もなし

原田ウイルス事件

ウイルス作成罪はまだない
2008年5月16日有罪判決、懲役2年執行猶予3年

※そのままメモしていますが、ウィルス作者のつけた「原田ウィルス」という名称をそのまま使うのは良くない、という議論がある事を付記しておきます。もっとも、他の名前で呼ばれてもぴんと来ないと思いますが……。

古き良き時代: 実害がなければ良い
現代社会: 本当に悪いことをしていないかどうか分からない、アクセス制御の信頼性が重要

Information Security Early Warning Partnership

この制度の日本語での名前は何でしたっけ、という話が出ていましたが、正解は「情報セキュリティ早期警戒パートナーシップ」。覚えにくい以前に分かりにくい名前で (パートナーシップって言われても……)、知らないという人が多いはず。

サイバー犯罪条約6条ハッカーツールの禁止

dual use tool
英国コンピュータミスユース法のガイドライン: ちゃんとした会社なのか、違反の意図があるのか、etc. で判断
ベネトレーティングテストの業界標準、工業標準として認定

EpisodeⅡ: 匿名軍団の攻撃

フィッシング対応

Yafoo! 偽サイト
不正アクセス禁止法違反・著作権法違反
フィッシング詐欺団男女8名検挙、首謀者に懲役8年、罰金300万円

伝統的手法の限界

被害が発生しないと何もできない
攻撃者が突き止められる前提
これでは、国際的な組織犯罪には対応できない
「大衆インターネット社会」へのパラダイムシフト
国際性・匿名性
これは「戦争」なのか?

振込詐欺救済法 (金融機関の原則との相克)
弁護士に言われたところで口座凍結なんて……
攻撃の検知と通信の秘密との兼ね合い
情報共有できない?
ドグマの肥大化
コンテンツと通信データの区別がない
通信データの過剰な保護
ISPの保護者としての役割
攻撃トラフィック、フィッシングメール、名誉毀損メッセージetc
著作権制度: フランス三振法 ISPから警告3回で遮断

感想

話の本筋とは関係ない部分ですが、officeさんの事件に関する話が微妙に不正確なのが気になりました。「アドレスバーに文字を入れた」と言われていましたが、csvmail.cgiには以下のようなコードが書かれていたので……

if ($ENV{'REQUEST_METHOD'} eq "POST") { 
    read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
} else { 
    print "Content-type:text/html\n\n";
    print "<html>\n";
    print "<head><title>ANTI SPAM</title></head>\n";
    print "<body>CAN NOT ALLOW GET METHOD.</body>\n";
    print "</html>\n";
    exit(0);
}

GETアクセスされたら「ANTI SPAM」という謎のメッセージを表示して終了し、何も起きません。javascript: で始まる文字列を入れて POST すれば良いという話もありますが、officeさんがわざわざそんな面倒なことをしたとは思いにくいですし。

事件からずいぶん年月も経ったことですし、技術的な部分については情報を公開した方が良いのかもしれないと思ったり。

「Webセキュリティのマルプラクティス – 思い込みによるソフトウェアエラーをなんとかしろ」に続きます。

「WASForum Conference 2008: Security Wars EpisodeⅢ」へのコメント (1件)

関連する話題: セキュリティ / WASForum Conference

WASForum Conference 2008: セキュリティの作り込みはどのように行われているのか？

「OpenIDのセキュリティ」の後、お昼休みを挟んで、午後からは少し毛色の違うお話に。まずはマイクロソフトの加治佐さん、ソニーの松並さんによる、ソフトウェアの SDL (Security Development Lifecycle) についてのお話。

最初にマイクロソフトのお話から。

Microsoft の Security Development Lifecycle

「MSのSDLは重い。君たちにできることを簡単に言わないで」と良く言われる
SD3+C = "Secure by design, by default and in development" + Communications
脅威モデル : バグ以外の脅威、STRIDE分析
SDLは開発のライフサイクルではない。ウォーターフォールの中に組み込まれたり、併存する

Microsoftのセキュリティの歴史

1990年初頭 : シングルユーザOS、セキュリティに関する要求はあまりなかった
1994年 : NT3.1がマルチユーザOSとなる。セキュリティ上の脅威、ユーザを他のユーザから、プロセスを他のプロセスから守る必要
1998年くらいまで : 各製品チームが個別に対応していた。脆弱性が見つかったらマーケティング部門が対応
1997年 : 脆弱性の発見と公表が日常的に。ping of death とか INN とか phf とか
1998年 : MSRC設立(Security response center)。脆弱性受付のメールアドレスができる。アップデートリリース、メディア対応の一本化。内部の有志によるボランティアっぽい運営。
Internet Security Task Force 設立、STF推奨事項、経営の関与etc
Windows 2000 : 多くのセキュリティ機能を実装。増加するバグレポートが問題に。
SGIP STOPPER SWIの設立(secure windows initiative)
Windows XP : 魚を釣るかわりに魚の釣り方を教える。"PREfirst"
2001年 : codered/nimdaの大流行。2002年1月、有名なゲイツのメール
first security push を .NET Frameworkに実施
Windows Server 2003 : 予定出荷日間近に8000人の開発を停止して security push を実施
2004年7月から SDLの実施

まとめ

セキュリティテストは重要だが十分ではない
セキュアコーディングも重要だが十分ではない
エンジニアの啓発とトレーニング etc. が必要

この SDL を他社に適用できるのか? という話で、ここからソニーの話に移ります。松並さんがソニーの子会社 (ソニーデジタルネットワークアプリケーションズ、でしたっけ?) でライトウェイトな取り組みを始めて、その取り組みがソニー全体に広がって行っているというお話。

ソニーの製品セキュリティへの取り組み

家電製品のセキュリティ……被害は多発していない、対策の価値がエンドユーザに認知されていない
セキュリティ対策のために製品の価格を上げることは許されない (多くのコストはかけられない)

ライトウェイトアプローチ (LWSSA)

費用対効果を高める工夫をする
費用対効果の大きいものから初めて、できるところまでやる
事後に発覚する1脆弱性につきパッチ作成費用100万円 (広報費含まず、安い事例)。131件の脆弱性を事前に発見 = 1億3000万コスト削減と考えられる
計画・設計～実装段階で個々に脆弱性が入り込む
セキュリティを考慮した設計の実施、脆弱性検査→有効だが、費用対効果が悪い

プログラマにセキュアプログラミングセミナーを実施 (4時間の座学、必修)。これにより、脆弱性の指摘内容を理解できるようになる
少数精鋭のセキュリティ専門組織が、ドキュメントレビューとコードレビューを行う (4ヶ月のトレーニングプログラムを受講)

ドキュメントレビュー

脅威分析表を準備する。簡素化したエクセルシート1枚
全てを見るのではなく、セキュリティに関連する部分だけ見る。これはドキュメントのほんの一部
気になるキーワードを見つける。たとえば、「検索ボタン」というキーワードからSQLインジェクション、XSSが連想される

コードレビュー

静的コード解析ツールを使い、結果を分析・整理
警告が脆弱性につながるかどうかを判定すると、判定コストが修正コストを上回る場合がある
簡単に修正できる場合は無条件に修正する

LWSSA2.0

LWSSA1.0の限界 : 専門組織が全ての製品をチェックするのは無理。技術分野が広すぎる(ブルーレイとか)
LWSSA2.0 では……
- 開発者自身にセキュリティレビューを実施してもらう
- 核技術領域の開発者にセキュリティを教える
- 専門組織の中でセキュリティレビュアートレーニングプログラムを受ける。年間10名ほど、セキュリティレビューOJT

問答など

SDLはどのくらい大変?

大変です。日本にいても英語で書かないといけない。携帯の端末IDについて本国に説明したりとか……。
超大変。ドキュメント間の関係性とか分からない
「脅威分析があまりに大変で仕事にならない。ホントにやってるのか?」と聞かれたこともある。

インセンティブはあるのか?

ない
スキルを身につけたい人が自ら実践
これをやっていないと製品を出せない決まり。製品が出せないということは、開発者の存在意義がなくなるということ (やらざるを得ない)

レガシーコードはどう取り扱う?

最近になって着手 (費用対効果が高い、現在のコードから着手)
古いコードは問題が出やすい、10年前のコードとかもう意味が分からない
Windowsは互換性を重視している。「メモリリークするけど動かなくなるから仕方ない」とかコメントが書かれていたりする。:-)
分からないコードは入れない、ばっさり捨てる覚悟で

失ったものは?

楽しいプログラミング、簡単なツールの提供ができない (外には出せない)

Webアプリ開発に応用できそうか?

できるんじゃないか
会社自体が数名の場合はできそう

パッチのコストの話が興味深かったが、MSでは?

各国語版でのテストプロセスがとても大変
具体的には言えない (が、高い)

感想

Webの話じゃないじゃん!

とはいえ参考になりました。「後から脆弱性が発覚してパッチをリリースする」ということになるとコストが高くつくので、事前にやっておくことでコストが抑えられる……という話は説得力があります。

MSの真似をするのは難しいでしょうが、軽量版でできるところまでやる、というアプローチは面白いですね。どこまでやるのかがポイントでしょうが……。

「Security Wars EpisodeⅢ」に続きます。

「WASForum Conference 2008: セキュリティの作り込みはどのように行われているのか？」にコメントを書く

関連する話題: セキュリティ / WASForum Conference

WASForum Conference 2008: OpenIDのセキュリティ

「携帯電話向けWebのセキュリティ」に続き、ZIGOROuさんによる「OpenIDのセキュリティ"」。こちらもスライドが公開されている (d.hatena.ne.jp)ようなので、感想のみ。

……「ピアノを弾く」は「ひく」で良いのですが、「アクセスを弾く」などは「はじく」と読むのが一般的なのではないかと思いました。

※それだけかよ! という声が聞こえてきそうですが、申し訳ないことにOpenIDってよく知らないのですよね。勉強しないとですね。

「セキュリティの作り込みはどのように行われているのか」に続きます。

「WASForum Conference 2008: OpenIDのセキュリティ」にコメントを書く

関連する話題: セキュリティ / WASForum Conference

WASForum Conference 2008: 携帯電話向けWebのセキュリティ

「SQLインジェクション対策再考」に続いては「携帯電話向けWebのセキュリティ」。GREEの藤本さんによるお話です。

自転車とGREEについて

自転車はGIANTがオススメ
GREEは2006年11月に携帯にシフト、携帯からのアクセスがぐんぐん増加

携帯の諸々

Referer来ないかもしれない。auとSoftbankはおおむね来る。来ないなら来ないで統一されていれば良いものを……
Cookieは、au来ます、Softbankは来ないかも。

Referer漏洩問題について

そもそも他サイトにリンクしないこと。ドコモ公式では必須
端末不具合によって、何故かメールから叩いたURLに前のサイトのRefererが出ることが……
セッション格納情報でチェックする? UA……Referer漏洩時点でばれている。端末固有情報?
SIDを変えまくるという対策だと、戻ると死んだりする
ユーザがGREEにGREEのURLを貼ることは多い (URLにはセッション追跡情報がついている)。GREEではURLをパースしてがんばっている
携帯ではHTMLソースは読めない? →スマートフォン経由だと読める場合があるので油断してはならない

携帯ネットワークの特徴

位置情報が取れる
課金システム
IPアドレス帯域が固定(重要、絶対チェックした方が良い)

端末固有IDの偽装は可能か?

今のところ難しいようだ。ただしIPアドレス確認が必須。Softbankスマートフォン+iモードiDなどのパターンに注意
ARP Spoofingのような手法による IP Spoofing はどうか?
キャリアによって100%保証されているわけでもない

端末固有情報は一意?

iモードIDは再使用されないことになっているのでユニーク
他の端末はどうだろう……
メールアドレスの場合、別のユーザに再取得され得る
SIMカードを入れ替えると別のUAからその端末情報が送られてくることがある

常識が通用しない

パスワードは adgjmp 123456 などがほとんど
ソーシャルハックにはとても脆弱
携帯の貸し借り、SIMカード貸し借り、簡単にパスワード教えたり……

凄いユーザがいる

総当たりフォースフルブラウジングとか普通に来る
8桁とかでも破られる。たとえば、着うたダウンロードのURL末尾が 1.mmf?dfX38fJu だった場合、8桁をひたすらブルートフォースでアクセスしてくるユーザがいる

質問

携帯キャリアのIPアドレス範囲のチェックはどうしているか?: アンテナでキャリアのサイトをチェックしたりして頑張っている
逆引きするのはどうか?: それは良いかもしれない

感想

質疑応答の「逆引きで見る」という話は瞬間的に「ヤバイかも」と思いましたが、高木さんが「そのDNSが安全かどうかという問題がありますが」とナイスフォロー。逆引きで判断する場合、PTRの値はそもそも信用できないのでパラノイド検査が必須になりますが、それでも大丈夫かどうかは怪しい感じがしますね。

※ちなみにパラノイド検査というのは、逆引きで得られた名前をさらに正引きして、元のIPアドレスと一致するか確認すること。

パスワードの話は興味深いですね。携帯端末からパスワードを入力するのはしんどいので、入力しやすいものをと考えると、どうしたって脆弱なものにしかなりません。普通に考えると、こまめにログアウトさせてパスワードを入れさせて……という方が安全そうですが、携帯サイトの世界では、パスワードに依存した認証は逆に危険なのかもしれません。

「OpenIDのセキュリティ」に続きます。

「WASForum Conference 2008: 携帯電話向けWebのセキュリティ」にコメントを書く

関連する話題: セキュリティ / 携帯電話 / WASForum Conference

WASForum Conference 2008: SQLインジェクション対策再考

2日目、「EV SSL の意義と課題」に引き続いての2発目は、徳丸さんによる「SQLインジェクション対策再考」。資料が公開されている (www.hash-c.co.jp)ので、私のメモとか必要ないですね。

若干補足すると、資料のp5～p6あたりの「セミコロン削除」「SQL構文に用いるような文字列はユーザーの入力としてはありえない」という部分ですが、ブログの記事を DB に格納するときにどうするのか、という話が出ていました。プログラムの話題を書いたときにセミコロンが全部消えてしまったら困りますから、セミコロンだろうとSQL構文だろうと、きちんと格納しなければならないのです。

質問として、「過剰エスケープはどうなのか」という話が出ましたが……。「セキュリティ的にはたぶん問題ないが、\が2重に表示される」。まあ、ぶっちゃけて言えばバグですね。実際、この手のバグはけっこうあちこちにあると思います。

私の感想

「ライオン・エスケープ」ですが、楽天テクノロジーカンファレンス2007「Web開発者のための最新セキュリティ動向」で出てきた「安心クッキー」のリスペクトですね。しかし、今回の話の流れの中で出すのであれば、カカクコムで探した方が良かったのではないかと思いました。

※サウンドハウスでも良いのですが、「エスケープ」で検索しても何もヒットしなかったのです。カカクコムにはいろいろありそうです。

※「感想ってそこだけかよ!!」とつっこまれそうですが、笑いのネタは気になるので。

「携帯電話向けWebのセキュリティ」に続きます。

「WASForum Conference 2008: SQLインジェクション対策再考」にコメントを書く

WASForum Conference 2008: EV SSL の意義と課題

2日目のセッションは技術的なお話が中心になりました。まずは「EV SSL の意義と課題」についてのメモ。

SSLの課題

利用範囲の拡大とともに発行基準が多様化、匿名でも取得可能になった。
一般のエンドユーザが確認することは困難 (一般ユーザがCP/CPSを読むというのは現実的でない)
鍵マークへの信頼を逆手にとって、フィッシングサイトに悪用されるようにもなってきた

EV SSL

SSL証明書の発行審査基準の標準化 + 一般ユーザに分かる仕組み
CA/Browser Forum (CABF) による EV ガイドラインの制定 (2006/10) Vista登場の2ヶ月前
日本企業では発行できないガイドライン (組織名は登記簿謄本に記載のものと完全に一致しなければならないとされているが、日本の場合はたいてい漢字で書かれている……)
JCAF: 日本語版ガイドラインの作成、日本の法体系沿う運用の提案 (Appendix F)

これまでのSSL=南京錠ひとつ
EV SSL = 暗号:南京錠、実在証明は別途表示

審査基準

各社によって何を「実在」とするかが異なっていた
実在証明とは?
- 法的実在
- 物理的実在
- 運用実在 (実際に企業活動を行っているか。海外:金融取引はあるのか、日本:帝国データバンク)
審査発行に関する外部監査が義務づけられている。第三者の監査法人によるチェックが入るため、例外運用が勝手にできない

課題

暗号アルゴリズム世代交代への対応
対応ブラウザの普及: 対応ブラウザがないと無意味。PCは良いが、携帯などが対応していない。実は、ブラウザの実装に関するガイドラインがない
日本語の取り扱い: UTF-8の文字をどう格納するのか
企業におけるドメインの管理: 大企業でもドメインの管理がルーズな場合が多い。ドメインの所有者とサイト管理者が異なる場合がある。これは認証局にとっても悩みのタネ、二重・三重の確認が必要。ドメインは企業の知的財産なので、ちゃんと会社で管理してください!
費用対効果の理解が得られるか: EV証明書は高い。普及すれば安くなるが、安くならないと普及しない。「フィッシング対策ソリューション」と比べると安いはずだが……。

暗号アルゴリズムの2010年問題

1024bit RSA は 2010年末までに 2048 bit に移行するべし。MD5はもちろん、SHA-1 も非推奨となる(SHA-256以降を推奨)。ただし SHA-256などはまだブラウザも対応していない
携帯などは1024bit のみ対応だったりする。携帯・PCふたつのサイトを立てなければならなくなる
移行を遅らせるべき、という提案をしている。1024bit解読には10ペタflopsが必要とされる、もう少し大丈夫。2012年まで待てば、ショボイ携帯は淘汰されて影響が最小限になると推察

質問

EV for mobile というのがあるが?

ルートがふたつある特殊な証明書。ルートの片方は1024bitのみで辿れるようになっている。おそらく日本でしか発行されていない。

Firefox3 で緑にならないのは?

原因はふたつ考えられる。

ルート証明書の普及がまだかもしれない。
XP と Vista で違う。Vista は EV を見つけると新しいルートを自動的に拾ってくる。XP でも何とかする技があるが、Vista の Firefox ではうまく行かないかもしれない。

私の感想

「EV SSL は高いけど、フィッシング対策ソリューションよりは安いでしょ」という話が印象に残りました。高いお金を払って使いにくいフィッシング対策を導入し、あげくそのソフトウェアが脆弱……なんて話もあったような気がしますが、ブラウザの基本機能で確認できるのが一番ですね。

「SQLインジェクション対策再考」に続きます。

「WASForum Conference 2008: EV SSL の意義と課題」にコメントを書く

関連する話題: セキュリティ / SSL/TLS / WASForum Conference

前(古い): 2008年7月4日(Friday)のえび日記
次(新しい): 2008年7月6日(Sunday)のえび日記

水無月ばけらのえび日記