WEP に続き TKIP も役に立たなくなってしまいました

WPAへの新しい攻撃手法を発表する．．．明後日，台湾(JWIS2009)で
WEP をもの凄い速く解読できるようにしてしまった
森井昌克さんのチーム? が今度は TKIP を凄い速い解読方法を作ってしまったそうです。

TKIP ってのは確か WEP を少し改良しただけのものでした。
WEP が持つ脆弱性が報告されたのが 2001 だったそうなので
それから 8 年、解析が進んでも何も不思議ではないですよねぇ。

自宅・職場の無線 LAN の設定を見直してみましょう。

SSLトラフィックを傍受する“ヌルターミネーション攻撃”――専門家が報告

SSLトラフィックを傍受する“ヌルターミネーション攻撃”――専門家が報告
ウェブブラウザのセキュリティーホールが報告されていました
既に Firefox 3.5.2 では対応されているようですが
SSL証明書の CN などの解釈で NULL が入っていると
それが文字列の終わりを示すと解釈してしまって
偽の証明書でも本物だと思って受け入れてしまうというものだそうです

man-in-the-middle がこれによって成功してしまうと
暗号化されてると思って送った大切な情報が
盗聴されてしまうことになります

Black HatのNull証明書攻撃(その1？)
こんな素敵な解説がもぉ出ているます

• こんな証明書を受け入れるブラウザが悪い
• こんな証明書を出しちゃう認証局が悪い

ブラウザは、Firefox に続いて他のセキュリティーホールを持つブラウザも
更新されるでしょうから早くアップデートしましょう
Firefox と IE 以外のブラウザも、ダメだったのかな??

そもそも、ブラウザにルートが入ってるような認証局が
こういう証明書を出さなければ良い話なのですが
どこか出しちゃったところがあるみたいですね、どこだろう??

ブラウザは、常に最新のものに保ちましょう!

『ブラウザの「SSL証明書が無効」という警告、5割以上のユーザーが無視』って

ブラウザの「SSL証明書が無効」という警告、5割以上のユーザーが無視
と slashdot でタレコミがされていました
「カーネギーメロン大の研究者ら」の報告書の内容の紹介だそうです。

確かに、古いブラウザの場合には小さな alert window が出るだけでしたから
適当に yes とか ok とか押してしまって進む人も居たでしょうけど
近頃のブラウザでもまだ気にせず進んでしまう人がいるんでしょうか

といいつつ無視して進んでしまうこともあるのですが
それは自分で立てたサーバで一時的に暗号化だけ欲しい場合や
検索結果のリンクがメーリングリストのアーカイブなのに何故か SSL で
しかもその証明書が無効なものの場合くらいです
後者は、でも、ちょっとドキドキしながら進んでます

いっそ、全てのブラウザは
無効な証明書使ってるサイトを開けなくしちゃいましょうか??

SSL 証明書使ってても確認しないとフィッシングサイトかもしれない

最近のフィッシングの傾向に関する記事がありました

• SSL証明書を使う詐欺サイトが急増、乗っ取りサーバで運営 - ITmedia エンタープライズ

本国の方のシマンテックの blog の紹介で元はこちら

• Phishing Toolkit Attacks are Abusing SSL Certificates | Symantec Connect

内容はというと、
近頃フィッシングサイトの構築方法として
SSL を使ってるサーバを乗っ取って有効な SSL 証明書を使いつつ
元のサイトとは全く関係の無いフィッシングサイトを表示させるそうです。
これは怖い。乗っ取りというだけでも十分怖いのに。

実在認証の付いている証明書であれば
証明書の中身を見ることによって表示内容と証明書のずれに気付くかもしれません。
EV SSL 証明書が使われていればアドレスバーなどに表示される組織名などで
乗っ取られてしまっているサイトだと気付けるかもしれません、
但し EV SSL 対応のブラウザの利用が前提ですが、もぉ十分普及してるようです。
ドメイン認証のみの証明書の場合は、対策のできませんねぇ、この場合。

まぁ、そもそも乗っ取られないように気をつけなくてはいけないし、
乗っ取られたことになるべく早く気付いて対応することが大切ですよね。
フィッシングに利用されてしまう場合、その乗っ取られたサーバというのは
どのくらい放置されてしまっているのか? という方が気になります。
上手にされちゃうとポツリと1枚だけフィッシングサイトを置かれてしまい
気付かぬままということもありそうです．．．。
アクセスログで気付ければいいですが数か少ないと難しそうですねぇ。

いやぁ、恐しいです。

SSL 証明書は、そのサーバの運営者を認証する目的で発行されています

高木浩光さんの日記で EV SSL サーバ証明書のことがお題にされてました
高木浩光＠自宅の日記 - EV SSLを緑色だというだけで信用してはいけない実例
タイトルに EV SSL を入れてらっしゃいますが議論の中心は SSL 証明書の共用に関してでした

HTTPS と SSL 証明書によって何が実現されるかというと

• サーバのなりすまし防止 (証明書によるサーバ認証)
  
• 通信経路における盗聴の防止 (暗号化で)
• 通信経路における改竄の防止 (暗号化で)

なりすまし防止が分かりづらいんですよね

なりすまし防止の為に何がなされているかというと、

• そのサーバのドメインの所有者がどこの誰なのか・何て会社なのか (実在認証)
  
• 通信が確かに認証されてる FQDN のサーバとされている

ということ保証がされています

前者は SSL 証明書に記載されているわけですが今まで見るのが面倒だったので
アドレスバーやらロケーションバーに表示してしまった方が分かりやすいというのが
EV SSL サーバ証明書の売りの 1 つなはずなのに
「共用 SSL では結局誰に情報送ってるか分からないじゃないの!」ってのが高木さんの主張
もっともだ

EV SSL だと更に、バラバラだった実在認証の審査基準を業界で統一して
弁護士さんの意見書が必要だとか中々厳しいことを課してるってのがミソみたいです
EVC ガイドライン公開にあたっての注意文 - JCAF 日本電子認証協議会 で審査基準が見れます

で、なりすましの後者の方ですが、高木さんの仰っている
「格安のDV SSL（domain だけ validate する）」の部分です
domain/FQDN に関してだけ審査していて、それがどこの誰のものかまでは認証しません
確かに手間も減るのでお値段も「格安」となるのですが
なりすまし防止という点ではちょっと弱くなってしまっています
その domain が誰のものかって分かってれば全く問題ないんですが

で、普通の証明書は EV という基準ではないけど実在認証がされていて
ではどんな基準かというと各認証局が独自で定めた基準ってことになります

• 普通の SSL 証明書 (各認証局独自の基準でドメイン・実在認証)
• EV SSL 証明書 (統一基準 (厳しめ) でドメイン・実在認証)
• DV SSL 証明書 (各認証局独自の基準でドメインだけ確認)

なんかややこしいですね
こんなややこしいの知らなくても EV さえ知ってれば十分だ!
という分かり易いことになればいいんですが

EV SSL 証明書を使ってアドレスバーに社名などの表示を
更にそれを日本語でしてくれるととても分かりやすいので
是非ともどのページもそんな感じになったらいいなぁ

PKI DAY 2009 が開催されました

もぉ終わってしまったんですが
JNSA PKI相互運用技術WG主催セミナー PKI Day 2009−＜様々な分野に展開されるPKIの最新動向＞
が開催されてました

RFC 5280 と 3280 の比較がされていたりして
勉強中の身としては是非とも参加したかったんですがスケジュールが合わず
でも資料が公開されているので勉強させて頂きます

SHA-1 の耐衝突性がまた下がったそうです

RSS リーダーで見たのに放置していたんですが

• SHA-1の脆弱性が更に進む

とのことで、
63 bit から 52 bit に耐性が落っこちてしまったそうです。

MD5 も 2005 年に耐性落ちたと思ったら翌年にはパソコンで衝突作れるようになったり
何かブレークスルーがあるとこういうのはあっという間に話が進むので
今後の動向が気になります。
まだ実際に衝突してるデータが作られたわけではないのだそうですが．．．。

SHA-1 で chosen prefix attack が成功なんてことになってしまうと、
今出回ってる SSL サーバ証明書は全滅になってしまいますし、
ほんと、SHA-1 で安心してないでさっさと SHA-2 に移行しろってことなんでしょうか。
2013 年にはどうなってるかなぁ。

Automatic Differential Path Searching for SHA-1

Eurocrypt 2009 rump session の発表資料の中で
Cameron McDonald, Josef Pieprzyk, Phil Hawkes さん達の SHA-1 collisions now 2⁵² って
プレゼンが公開されています。

SHA-1 は 160bit なので誕生日攻撃しようとすると 80bit の計算が必要です
2005 年に Xiaoyun Wang さんによって 69bit、更に 63bit まで短縮されてました
プレゼン資料によるとそれが去年の 11 月に 57bit に落ちていたのが
今回 52bit まで短縮されたということなのだそうです、が

流石にプレゼン資料だけだと何が言えてるのか判断しかねるのですが、特に

Until now, the best complete differential path (to our knowledge)
has complexity 2⁶³

ってどういう意味なんですかねぇ
Stéphane Manuel さんのページには 57bit まで落とした論文が載ってるのですが
ちょっとだけ読んだら Xiaoyun Wang さんの方法の disturbance vector ってのを
より簡単に作る方法を皆で考えているようなので
条件によっては上手く disturbance vector が作れるってことなのかな?

ともかく、MD5 も SHA-1 もガンガン研究が進んでるようなので
どうやって SHA-2 に移行するべきかってのを分かっていかないといけませんねぇ

杜撰な研究者の日記: MD5: 高速の解読法発見

• 杜撰な研究者の日記: MD5: 高速の解読法発見

ほんとに! って思ったんですが具体的に何が成されたのか良く分かりません
論文? は

• Finding Preimages in Full MD5 Faster Than Exhaustive Search

これみたいですけど、イントロだけ読んでもなぁ
preimage が分かっちゃうの?
前提条件は??

『「10大脅威」の相関図 』がちょっと素敵

• IPAが「10大脅威」の相関図を作成、攻撃手法の“多様化”解説
  

去年あったセキュリティーに対する攻撃を振り返って
色々みんなで言い合った結果が発表されているようです

攻撃方法を知ることは利用者にとっても管理者にとっても大切なことですよね

• 何か危ないらしいけど平気だろう
• 何か危ないらしいけどどうしたら良いか分からないなぁ

みたいなことが無いように最新情報に目を向けとかないと

で、1 つ 1 つの脅威ってのもあると思うんですが
1 つ破られるとその後ドミノ倒し的に色々情報が!! なんてこともあり得ると思うので
相関図ってのはとっても素敵だなと思いました

でも、ちょっと残念なのは少し見辛いかなぁ
紙ベースのものをディスプレイで見てるのがいけないのかなぁ

新たな中間者攻撃にはEV SSLの活用を――ベリサイン

• 南京錠の画像でだます：新たな中間者攻撃にはEV SSLの活用を――ベリサイン

これは、BlackHat で公表された

• 
  New Techniques for Defeating SSL/TLS

に対するアンサーソングですね。
こりゃどんな攻撃だったかというと

• BlackHatで発表された攻撃手法(sslstrip)について

にある通り、
エンドユーザーの SSL や HTTPS に対する理解の浅さを利用したり
巧妙な? 見た目の偽装によって中間車攻撃に気付かせない工夫をする
という、良く考えると中々怖い攻撃だなと思うんですが
(自分がどれだけ SSL 通信に敏感になっているか分かりませんし、いわんや例えばうちの母親)
EV だったら見た目からして分かりやすいし大丈夫だよ!! ってこと言ってらっしゃいます。

「見た目からして分かりやすい」っていうのは
EV SSL サーバ証明書を使ってるサイトを見にいくと、対応ブラウザであれば

• アドレスバーなど分かりやすい部分が緑いろっぽくなる
• アドレスバーなどに証明書所有者や発行者の名前が表示される

ので、そのサイトが一体誰によって運営されてるか分かりやすくなる、というものです

そんなん EV SSL じゃなくたって審査してある証明書だったら表示したらいいじゃない
と思う方もいらっしゃいますでしょうが、上は技術的な話の一部でして
審査基準も統一ルールが定められてて中々厳しい内容になっていたりして
多分、だから、その審査基準の下で名前表示してもいいよね、ってことなんだと思います。
たぶん。

Moxie Marlinspike さんのプレゼンだと
login.yahoo.com や mail.google.com のアカウント情報が引っこ抜けたということなので
この辺りに EV SSL サーバ証明書を導入した方がいいよ!! って言ってるんだと思いますが
きっとクラウドがバリバリの Web サーバが後に沢山控えているだろうサービスで
EV SSL を実現するとなると何枚くらい証明書買ったら勘弁してもらえるんでしょうねぇ。

緑色アドレスバー、EV SSL証明書

• 緑色アドレスバー、EV SSL証明書 | エンタープライズ | マイコミジャーナル

NETCRAFT という会社が EV SSL サーバ証明書の普及率の調査結果を公表してくれてます

Extended Validation SSL Certificates 2 Years Old が元記事
One Million SSL Sites on the Web という記事によると
この会社が集めた有名な認証局による証明書の枚数が 100 万枚を越えて、
今回は 1,028,868 枚のうち 11,300 枚が EV SSL サーバ証明書だったそうです

1% かよっ! っていうとそういうわけでもないようで
更に人気サイト 1,000 と 10,000 と 100,000 などに絞って表を出してくれていて
例えば人気上位 100,000 サイトの SSL サーバ証明書の枚数が 7,012 枚で
その内 710 枚が EV SSL サーバ証明書だったそうです、10%!!

証明書の枚数の数え方が良く分からないんですが、負荷分散とか
でもまぁ、1 割っていうと中々普及している感じがしますね
日本でも銀行以外の利用も増えているようですし
効果的に利用されるといいなぁと思っております
適材適所で

CRYPTRECシンポジウム2009

• 「電子政府推奨暗号」は2つで十分？，シンポジウムで専門家が討論：ITpro

電子政府推奨暗号リストの更新に向けてシンポジウムが開かれました
今のリストは 2003 年に提出されています
10年使える暗号を目指してたらしいですが既に老朽化が激しいと
ぽんぽん変更できるものでもありませんが IT の流れからすると 10 年ってやっぱり長いんですね

「サイドチャネル攻撃耐性への評価手法に懸念」ってことですが
一般的な評価方法ってないんですかね? 最低限満たさなくてはいけない基準とか
確かに実装特有の脆弱性があるかどうかってのは評価は難しいと思うので
差分での攻撃とか、それくらいの耐性くらいは評価できないのかなぁ
SASEBO ってそういうのに使うんでしたっけ、どうでしたっけ

記事のタイトルにあるのは横浜国立大学の松本勉さんの
「（署名やブロック暗号，ハッシュ関数など）カテゴリごとに2種類あれば十分ではないか」
という提言からだそうです
今のは多すぎると、29コあります
カテゴリが8コなので16コで十分なんじゃない? ってことですね大体半分

今度からリストを

• 電子政府推奨暗号リス
• 推奨暗号候補リスト
• 互換性維持暗号リスト

に分けるらしいし、電子政府推奨暗号リスは数絞って
推奨暗号候補リストで層の厚さを見せるって感じになるんですかね
例えば現行だと署名アルゴリズムは

• DSA
• ECDSA
• RSASSA-PKCS1-v1_5
• RSA-PSS

ですが、これは DSA と ECDSA が生き残りのバトルってことになるのかなぁ
まぁ、DSA が勝つか、そしたら

ベンダーフリーであること前提でリストが絞られると分かりよくていいですね

続きを読む

研究者がMD5の衝突によりAuthenticodeで署名された実行ファイルを生成

コードサイニング、お前もか
研究者がMD5の衝突によりAuthenticodeで署名された実行ファイルを生成
って思ったんですが何となく
「あ、この方法だったらコードサイニングでもできるじゃん」
つってイージーに論文書いたんじゃないの? と邪推したくなったりもします。

ハッシュ値の間に距離のようなものが定義されていて
MD5 の計算の途中から 2 つの値の距離を徐々に短かくしていって
結果二つのハッシュ値を等しくしようとするならば
元のデータは多分大きい方が有利なんではないかと思って
特に実行ファイルは無意味なデータも格納し易い気がするし
証明書は 2kb で実行ファイルは 6kb ですか

ってまぁ、詳しい解説読んでないので完全な邪推なのですが
コードサイニング? って感じなのと合わせて
先に MD5 な SSL サーバー証明書への攻撃の方を
より深く理解したいという希望があるので
もうすこし後から勉強したらということでとりあえずご報告

IPA、暗号アルゴリズム確認制度を追加

IPA、暗号アルゴリズム確認制度を追加、だそうです
JCMVP っていうと前にサイドチャネル攻撃の評価ボードの
SASEBO のこと聞いたとき始めて聞いたんですが
"Japan Cryptographic Module Validation Program" の略で
暗号の実装がちゃんとされてるかとかの認証しようって制度でした
フツーはソフトが取るみたいですが SASEBO はハード実装で始めてだった、と

JCMVP が今までしてた色々な審査のうちの 1 つである
暗号アルゴリズムの実装部分の審査だけ取り出して
独立して認証するようになったのだそうです

暗号アルゴリズムの実装部分ってのは自動で確認できるようで
1 週間で済むとか書いてありました
他の部分は鍵の管理方法とか人が入るから時間も費用もかかるけど
実装は自動で短期間でできちゃうし大切な部分だから独立させた
ってことかな？

とあるシステムの暗号部分って感じではなくて
単純な暗号用ソフトウェアでも取れるということなのかなぁ
例えば OpenSSL とか?
Java とか GnuTLS とかも??

COMODO のリセラーの Certstar が無審査で証明書を出しちゃった

ちょっと古い話になりますが MD5 の衝突の話と合わせて
COMODO のリセラーの Certstar が審査無しで証明書出しちゃったそうです

経緯はというと、Certstar は期限切れ間近のサイトの管理者宛に
「そろそろ更新時期ですよ、更新はこちらから」
みたいな DM をばんばん出しまくっていたらしく StartCom のお客さんにも来てて
StartCom の Eddy Nigg さんは ? と思って試しに買ってみたら審査が無い
あれれ?? と思って www.mozilla.com の証明書を申請してみたら取れちゃったそうです

商品は COMODO の PositiveSSL ってやつで
これはドメイン認証、VeriSign でいうところの Class 1 なやつなので
認証局は、例えば WHOIS から管理者メールアドレスを取得して
そのアドレスに申請の確認のメールを出して何かしらの方法で確認を取るんですが
今回の場合は何の確認も無いし発行しちゃったということみたいです

COMODO は信頼回復の為に何かしらしないとダメなのかなぁ

MD5 considered harmful today: Creating a rogue CA certificate

• MD5コリジョンでインチキ認証局は作れる（ネットにとっては悪い報せ）
• セキュリティホール memo

MD5 の「衝突の脆弱性」を利用した具体的な攻撃方法が公表されてるそうです
MD5 で署名してる認証局に署名された中間認証局を偽造できるということのようです
こ、これは、やばい認証局のパスのルート証明書を全部捨てろということなのでしょうか

• MD5 considered harmful today の Section 5

がレポートのページで、MD5 で署名している認証局のリストも出ています
偽造された証明書も載ってます (悪用できないよう有効期間は 2004 年で)

既に衝突を起こす良い方法はあるみたいで
正規に入手した証明書の署名部分をコピーすることに偽造証明書が作れるようです

正規な証明書はシリアルと有効期間の情報以外はそれなりにコントロールできますし
発行が自動化されている場合、シリアルと有効期限もそれなりに予測できて
申請のタイミングによってコントロールできると

偽造する方は正規なものに似せつつも
basic constraints に CA = TRUE と Path Length = None を入れておいて
無駄な拡張部分を作っておいてそこに発行されるであろう署名前証明書の公開鍵入れたりして
あとはブルートフォースなのかな? 署名前証明書のハッシュを衝突させることができて
対応する正規な証明書の署名をコピーすると偽造中間証明書の完成!!

MD5 への攻撃にとって署名前証明書の前半部分のコントロールが大切みたいで
シリアルや有効期限がそれなりにコントロールできないとダメみたいなので
その辺りで防御策が無いこともないけど、MD5 使わないでよ、ってことだそうです

これだけでフィッシングとしては効果的ですし
DNS キャッシュが汚染されてしまった日には証明書のパスをじっくり見ないと
防ぎようが無くって結構大変なことになってる気がします続きを読む

暗号は暗号屋だし、セキュリティーはセキュリティー屋、なのか?

なぜ暗号は当事者しか読めないのか?という記事が
杜撰な研究者の日記さんで紹介されていました
記事は

出典：日経Windowsプロ 2004年8月号
　pp.84-89



（記事は執筆時の情報に基づいており，現在では異なる場合があります）

ということでちょっと? 古いですけど

• シーザー暗号 -> 共通鍵暗号 -> 公開鍵暗号

という王道進行で暗号の解説がされています

で、何で杜撰な研究者の日記さんで紹介されていたかというと、
RSA の解読の困難さの根拠である素因数分解の難しさの話で
1024 bit な素数ってのは

log_10(2^1024) = 1024 * log_10(2) > 1024 * 0.301 > 300

なのでまぁ 300 桁はあります
512 bit つったら桁数半分としても 100 桁越えているわけで
4 年前でも 100 桁の素因数分解が大変とか言っちゃダメじゃないの?

ってツッコミ入れてらっしゃいました
「効率良く」ってことで「効率って何」って話もあるけど、と断りつつ

なんてこと言いながら自分は

• 暗号は何年くらい持てば安全と言うのか
• 暗号はどの程度の設備で解かれなければ安全と言うのか
• 国家レベルとか個人レベルとかで安全の基準は 1 つなのか
  

とかって確かな認識があるわけではないので
512 bit な RSA が危険ってどういう危険なのかも良く分かってないし
そういうことも勉強していかないといけないなぁと思いました
CRYPTREC の報告書とか読んだらそういうの分かるようになるの???

私も知らない PKI

あなたの知らない PKI というタイトルの特集記事がありました
全6回のうち3回までが掲載されていますが、目次は

1. PKIのコア要素として、公開鍵暗号技術の概説
2. PKIのコア要素として、電子証明書と認証局の概説
3. PKIに関係する法令・制度として、電子署名の法的有効性などについて
4. PKIに関係する法令・制度として、書面の電子化、本人確認での利用など
5. PKIに関係する法令・制度として、行政機関でのPKI利用の例
6. まとめとして、PKIの現状と今後の展望

「ポリシー」って連発しましたが
第2回で認証局のポリシーについても詳しく解説されてます
理屈は好きなんですが理屈ばっかり知っても仕方がないので
理屈のうえで実用の話も聞かせてもらえるこういう特集はありがたいです

SSLを過信していませんか

SSLを過信していませんか――ネットバンキングに潜む誤解とは

怖いタイトルですね
でも、確かに、「鍵・錠のマークが出てれば安心」という認識は
セキュリティーの知識が無いよりも怖い事態を引き起こすかもしれません

SSL/HTTPS という仕組みで一体どのような対策がされるかというと

• 暗号化による、ブラウザとサーバの間の「盗聴の防止」
• 暗号化による、ブラウザとサーバの間の「データの改竄の防止」
• 公開鍵証明書による「サーバー運営者の認証」

の 3 つです

南京錠のマークを見た時点で分かるのは HTTPS 通信だということなので
通信が暗号化されていて「盗聴」や「改竄」の心配が無さそうなことは確認できますが
「サーバー運営者の認証」に関しては実際にSSL証明書の中身を見てみて
ドメイン名や組織名などをちゃんと確認しなくてはいけませんし

ただ、それが分かったからといって通信相手が信頼できる人かというとまた話は別です
認証したからには自分が想定している通信相手なのかどうか確認する必要があります
悪い人が悪いことをしようとして立てたSSL的には正しいサイトかもしれません
まぁ、その場合は証明書に組織名まで書かれるようなものは用意できないと思われますが
例え、リンク先にあるように、「なりすまし」の対策として

ユーザーを大事にしている企業では、トップページなどに「当サイトのSSL証明書には次の様に記載されております」といった形で、内容が掲示されていることもあります。

で、証明書の中身とサイトの記述が一致しているからといって
証明書の記載が確かに自分の通信したい相手であるということが確認できなければ
クレジットカードの番号などの大切な情報を送らない方が良いということです
これは例え EV SSL サーバー証明書であったとしても同じことです
EV SSL サーバー証明書は「安全」であることを保証するものではありません

また、企業情報の載っていたいお安いSSL証明書もあって
その場合はドメイン名しか証明書に書いてなかったりしますが
そのドメインが信頼できるという確かな確信があるのでなければ
やはり大切な情報を送信するべきではありません