入社して１週間くらい経って研修も暇になってきたところ、さっそく案件をアサインされました。まさかのPKIの案件でした。転職してもPKIをやるとは思いませんでしたよ。ボチボチ認証局とか作ってます。
しかし、新しい会社（大企業）に移ってみると今までの会社（零細企業）の良かった所と悪かった所がいろいろと見えて来ます。
良かった所
- 機材が豊富
- キーボードとかは自前のものを自由に使える
- どうでもいい申請とかが必要ない
- 待遇面
- 社内コミュニケーション
- 研修制度とかが多い
2012年10月15日月曜日
転職しましたけど
MTBのブログの方にも書きましたが、10月から約10年勤めた会社を辞めて、新しい会社に移る事になりました。入社してから2週間、いろいろと戸惑う事もありますが、ボチボチやっています。
入社して１週間くらい経って研修も暇になってきたところ、さっそく案件をアサインされました。まさかのPKIの案件でした。転職してもPKIをやるとは思いませんでしたよ。ボチボチ認証局とか作ってます。
しかし、新しい会社（大企業）に移ってみると今までの会社（零細企業）の良かった所と悪かった所がいろいろと見えて来ます。
良かった所
入社して１週間くらい経って研修も暇になってきたところ、さっそく案件をアサインされました。まさかのPKIの案件でした。転職してもPKIをやるとは思いませんでしたよ。ボチボチ認証局とか作ってます。
しかし、新しい会社（大企業）に移ってみると今までの会社（零細企業）の良かった所と悪かった所がいろいろと見えて来ます。
良かった所
2012年6月28日木曜日
Entristが国内でもSSL証明書を売るそうです
久しぶりにPKI業界に明るいニュースが来ました。
セキュリティ製品を手掛けるEntrust社が、国内のSSL証明書販売事業に参入するそうです。プレスリリースはこちら。
Entrustは以前から米国ではSSL証明書の販売をしていたのですが、やっと日本でも買えるようになりました（英語さえ我慢すれば今までも買えたらしいけど）。
国内のSSL市場はVerisign系列（Verisign本家と Geotrust)が相変わらずトップで、グローバルサイン、セコムトラストシステムズ、スターフィールド（本家は米GoDaddy）、ソート（Thawte）、コモド等の強敵が存在します。
コモディティ化が進んでいて価格勝負になりがちなSSL証明書市場で、どれだけ顧客のハートを掴めるか、これからの動向に注目です。
そういえば、自社の認証局ソフトウェアを使って、SSL証明書を売っているのって、ココだけかもしれませんね。せっかくだから自社製品と組み合わせたりすると面白いことができるかもしれません。
セキュリティ製品を手掛けるEntrust社が、国内のSSL証明書販売事業に参入するそうです。プレスリリースはこちら。
Entrustは以前から米国ではSSL証明書の販売をしていたのですが、やっと日本でも買えるようになりました（英語さえ我慢すれば今までも買えたらしいけど）。
国内のSSL市場はVerisign系列（Verisign本家と Geotrust)が相変わらずトップで、グローバルサイン、セコムトラストシステムズ、スターフィールド（本家は米GoDaddy）、ソート（Thawte）、コモド等の強敵が存在します。
コモディティ化が進んでいて価格勝負になりがちなSSL証明書市場で、どれだけ顧客のハートを掴めるか、これからの動向に注目です。
そういえば、自社の認証局ソフトウェアを使って、SSL証明書を売っているのって、ココだけかもしれませんね。せっかくだから自社製品と組み合わせたりすると面白いことができるかもしれません。
2012年6月15日金曜日
Direction 2012が面白そう
昨年に引き続き8/7にセキュリティ関連のカンファレンスDirection 2012が開催されるそうです。無料だし、興味のあるセッションも多いし、
できれば参加したいところ。でも、最近はいろいろ忙しくてスケジュールが合うかどうかが微妙...
できれば参加したいところ。でも、最近はいろいろ忙しくてスケジュールが合うかどうかが微妙...
2012年6月4日月曜日
KB2718704と証明書を使ったイランへのサイバー攻撃の関係
今朝、Windows UpdateでKB2718704が配布されました。月一で行われるアップデートのタイミングではないので、緊急性の高いアップデートなのでしょう。ちょっと気になったので調べてみたら、証明書関連のもので、背景にはイランへのサイバー攻撃があるようです。
2012年4月18日水曜日
CA Browser ForumのBaseline Requirementの施行が迫る
すみません、最近はMTB関連のブログばかりを書いていました。今日はPKIネタを書きたいと思います。
昨年は偽SSL証明書の発行が多発してPKI業界にとっては災難な1年でした。結構な枚数の偽証明書を発行したDiginotar社は、各社のブラウザにインストールされるルート証明書の一覧から除外され、最終的には倒産してしまったそうです。
こういった問題を放置すると、信頼性を売りにしているPKI業界としては困ったことになってしまいます。SSL証明書なんて誰も信じなくなったら、我々業界人は飯の食い上げになっちゃいます。
そこで、認証局の信頼を取り戻すべく、昨年11月にEV SSL証明書の規格を制定した団体であるCA Browser Forumが、SSL証明書を発行する認証局の標準規格を発表しました。英語版はこちらから、日本語版はこちらからダウンロードできます。
この文書が正式に施行されるのは2011年7月1日からですが、SSL証明書の販売を行う各社は先行して対応状況をアナウンスしています。例えば、GlobalSignではこんなプレスリリースを出しています。着々と準備は進んでいるようですね。
そこで、この文書の内容をちょっとだけ見てみましょう。
昨年は偽SSL証明書の発行が多発してPKI業界にとっては災難な1年でした。結構な枚数の偽証明書を発行したDiginotar社は、各社のブラウザにインストールされるルート証明書の一覧から除外され、最終的には倒産してしまったそうです。
こういった問題を放置すると、信頼性を売りにしているPKI業界としては困ったことになってしまいます。SSL証明書なんて誰も信じなくなったら、我々業界人は飯の食い上げになっちゃいます。
そこで、認証局の信頼を取り戻すべく、昨年11月にEV SSL証明書の規格を制定した団体であるCA Browser Forumが、SSL証明書を発行する認証局の標準規格を発表しました。英語版はこちらから、日本語版はこちらからダウンロードできます。
この文書が正式に施行されるのは2011年7月1日からですが、SSL証明書の販売を行う各社は先行して対応状況をアナウンスしています。例えば、GlobalSignではこんなプレスリリースを出しています。着々と準備は進んでいるようですね。
そこで、この文書の内容をちょっとだけ見てみましょう。
2012年3月28日水曜日
Windows Server 8のAD CS新機能
先日からWindows Server 8を試していますが、いろいろと変更があって戸惑います。もちろん、AD CSもいくつか新機能が追加されていますが、あまり大きな変更はないため、淋しかったり逆に嬉しかったりします。
新機能の詳細についてはこちらに出ています。Server 8では以下の機能が追加になったそうです。
ちょいと個人的に気になったポイントだけ見ていきたいと思います。
エディションごとの役割サービスの差がなくなった
2008の頃はAD CSはWindowsのエディションによっては、使えない役割サービスがありました。8では、エディションごとの区別が無くなって、どのエディションでも全ての役割サービスが使用できます。
具体的には、以下のEnterprise以上のエディションでのみ使えていたNDESとOCSPの役割サービスが、Standard Editionでも使えるようになります。
AD CSのPowerShellの対応
AD CSのインストールがPower Shellのコマンドレットから行うことができるようになったそうです。追加になったインストール関連のコマンドレットはこちらから見れます。
同時に管理用のコマンドレットも追加になりました。こちらに詳細が出ています。Certutil.exeでできなかった機能が追加になっているので、ちょっとありがたいです。
毎回、案件の度に思うのですが、Windowsの構築手順書は図ばかりで書くのも読むのも面倒なんですよね。「上記の図のように設定する」とか書かれていると、図と画面をにらめっこしたりして疲れるのです。コマンドが一発で済むようになると、かなり楽になります。
また、コマンドが充実したことによって、AD CSの全ての役割サービスがServer Coreモードでも動くようになったそうです。
証明書テンプレートがVersion 4になった
しばらく変更の無かった証明書テンプレートのバージョンが上がり、バージョン4になります。バージョン4の変更点は以下のようになります。
なお、8のデフォルトでインストールされるテンプレート構成はバージョン4を使ったものはありませんでした。
新機能の詳細についてはこちらに出ています。Server 8では以下の機能が追加になったそうです。
- Integration with Server Manager
- Deployment and management capabilities from Windows PowerShell
- All AD CS role services run on any Windows Server “8” Beta version
- All AD CS role services can be run on Server Core
- Support for automatic renewal of certificates for non-domain joined computers
- Enforcement of certificate renewal with same key
- Support for international domain names
- Increased security enabled by default on the CA role service
ちょいと個人的に気になったポイントだけ見ていきたいと思います。
エディションごとの役割サービスの差がなくなった
2008の頃はAD CSはWindowsのエディションによっては、使えない役割サービスがありました。8では、エディションごとの区別が無くなって、どのエディションでも全ての役割サービスが使用できます。
具体的には、以下のEnterprise以上のエディションでのみ使えていたNDESとOCSPの役割サービスが、Standard Editionでも使えるようになります。
AD CSのPowerShellの対応
AD CSのインストールがPower Shellのコマンドレットから行うことができるようになったそうです。追加になったインストール関連のコマンドレットはこちらから見れます。
同時に管理用のコマンドレットも追加になりました。こちらに詳細が出ています。Certutil.exeでできなかった機能が追加になっているので、ちょっとありがたいです。
毎回、案件の度に思うのですが、Windowsの構築手順書は図ばかりで書くのも読むのも面倒なんですよね。「上記の図のように設定する」とか書かれていると、図と画面をにらめっこしたりして疲れるのです。コマンドが一発で済むようになると、かなり楽になります。
また、コマンドが充実したことによって、AD CSの全ての役割サービスがServer Coreモードでも動くようになったそうです。
証明書テンプレートがVersion 4になった
しばらく変更の無かった証明書テンプレートのバージョンが上がり、バージョン4になります。バージョン4の変更点は以下のようになります。
- テンプレートの暗号プロバイダにCNGが指定できるようになった
- 同じ鍵での更新（rekeyではなく）を指定できるようになった
- 互換性タブが増えて、テンプレートが適用されるクライアントとCAのバージョンが指定できるようになった
2012年3月22日木曜日
クラウド鍵管理型暗号方式って何だ？
キーマンズネットにNTT情報流通プラットフォーム研究所が開発したクラウド暗号の特集が出ていました。記事はこちら（要ユーザー登録）。本家のプレスリリースはこちら。キーマンズネットの方が詳細に書かれています。
クラウド暗号というのは、公開鍵暗号方式の私有鍵をクラウド側に保管・管理・利用するための仕組みだそうです。PKIでは私有鍵はエンドエンティティが保管・管理・利用することになっていますが、これをクラウド側でやってしまおうという事。
いわゆるキーエスクロー（鍵預託）に近いものと思われますが、単純にキーエスクローをクラウド化すると、暗号文の復号時に復号された平分がネットワークを通してユーザーに送られてしまうのに対し、クラウド暗号ではそれが発生しないのが特徴です。
また、ユーザー側で鍵を持たないという特性から、鍵の使用に関するコントロールは完全にクラウド側が握ることになります。このため、鍵の使用前にユーザー認証（と承認）を行うことによって、特定のグループに所属するユーザーに対してのみ鍵の使用を許可したりできるのも面白いですね。
（以下、参考までに、記事を読んだ時のメモです。）
復号するユーザーは、暗号文を「乱数化標本器」を使って「撹乱」処理を行ってからクラウドに送る。この撹乱済み暗号文を「身代り」と言う。このデータは漏えいしてもOK。
クラウド側では「身代り」に対し復号化（この時点で撹乱を解除しているか、身代わりをそのまま復号化しているかは不明）して、「復号された身代り」をユーザーに返す。その後、ユーザーは、復号済みデータを「乱数化標本器」を使って復元し平分を得る。あと、このほかにも改ざん検知用のしくみもある。
つまり、クラウド<->ユーザー間ネットワークには「身代り」と「復号化した身代り」しか流れずに済むのがポイント。気になるのは「乱数化標本器」と復号処理。クラウド側で撹乱の解除を行ってから復号する場合は、クラウド側とユーザー側で何らかの共通知識が必要になりそうだし、そうでない場合は撹乱がある場合でも復号できるアルゴリズムが必要になる。面白いですねぇ。
クラウド暗号というのは、公開鍵暗号方式の私有鍵をクラウド側に保管・管理・利用するための仕組みだそうです。PKIでは私有鍵はエンドエンティティが保管・管理・利用することになっていますが、これをクラウド側でやってしまおうという事。
いわゆるキーエスクロー（鍵預託）に近いものと思われますが、単純にキーエスクローをクラウド化すると、暗号文の復号時に復号された平分がネットワークを通してユーザーに送られてしまうのに対し、クラウド暗号ではそれが発生しないのが特徴です。
また、ユーザー側で鍵を持たないという特性から、鍵の使用に関するコントロールは完全にクラウド側が握ることになります。このため、鍵の使用前にユーザー認証（と承認）を行うことによって、特定のグループに所属するユーザーに対してのみ鍵の使用を許可したりできるのも面白いですね。
（以下、参考までに、記事を読んだ時のメモです。）
復号するユーザーは、暗号文を「乱数化標本器」を使って「撹乱」処理を行ってからクラウドに送る。この撹乱済み暗号文を「身代り」と言う。このデータは漏えいしてもOK。
クラウド側では「身代り」に対し復号化（この時点で撹乱を解除しているか、身代わりをそのまま復号化しているかは不明）して、「復号された身代り」をユーザーに返す。その後、ユーザーは、復号済みデータを「乱数化標本器」を使って復元し平分を得る。あと、このほかにも改ざん検知用のしくみもある。
つまり、クラウド<->ユーザー間ネットワークには「身代り」と「復号化した身代り」しか流れずに済むのがポイント。気になるのは「乱数化標本器」と復号処理。クラウド側で撹乱の解除を行ってから復号する場合は、クラウド側とユーザー側で何らかの共通知識が必要になりそうだし、そうでない場合は撹乱がある場合でも復号できるアルゴリズムが必要になる。面白いですねぇ。
2012年3月11日日曜日
もしかしてPMBOKって役に立つのでは？
ここ最近は、PMBOKを読んでいます。いわゆる、「プロジェクトマネジメント知識体系ガイド」と言うやつです。ちょっと前に認定試験のPMPが流行りましたね。
まぁ、そういう仕事もやらざるを得なくなってきたという感じで、必要に迫られて渋々と言った方が適切なのかもしれませんが、実際に読んでみると意外と関心させられることも多く、いつもの「もっと早くやっておけばよかった」のパターンになりつつあります。
（まだ、途中ですが）読んだ後に私が関わった案件思い返してみると、納期、機能、品質、コスト等の細い成功条件を全て満たしているのは1つくらいしかなさそうです。そして、失敗の原因はプロジェクトマネジメントの不備に起因するものが大部分を占めているような気がします。
極端な例かもしれませんが、私が下っ端として参加したあるプロジェクトでは、WBSなし、スコープ定義なし、スケジュールは随時可変、権限と責任も曖昧な状況で、もはやプロジェクトと言うよりは、それに類似した何か（お手伝いとか？）のようなものもありました。
もちろんこの案件は、最終的に顧客側が「いつまでに、何ができるのかが分からん！お前のところには頼まん！！」ってブチ切れて訴訟沙汰になったりして、それはそれは悲惨な結末を迎えました。当然ですね。
まぁ、とりあえずIT技術者でPMっぽい事をしている人には、PMBOKは必読だと感じました。PMには経験や人格も求められますが、知識もそれらと同じぐらい重要だなと思います。
ちなみに、PMBOKですが日本語版はオンラインでしか買えなかったりするのですが、ひそかに八重洲ブックセンターに大量に在庫されていたりします。ちなみに、相当デカイので注意してください。私は即効で自炊しました。
まぁ、そういう仕事もやらざるを得なくなってきたという感じで、必要に迫られて渋々と言った方が適切なのかもしれませんが、実際に読んでみると意外と関心させられることも多く、いつもの「もっと早くやっておけばよかった」のパターンになりつつあります。
（まだ、途中ですが）読んだ後に私が関わった案件思い返してみると、納期、機能、品質、コスト等の細い成功条件を全て満たしているのは1つくらいしかなさそうです。そして、失敗の原因はプロジェクトマネジメントの不備に起因するものが大部分を占めているような気がします。
極端な例かもしれませんが、私が下っ端として参加したあるプロジェクトでは、WBSなし、スコープ定義なし、スケジュールは随時可変、権限と責任も曖昧な状況で、もはやプロジェクトと言うよりは、それに類似した何か（お手伝いとか？）のようなものもありました。
もちろんこの案件は、最終的に顧客側が「いつまでに、何ができるのかが分からん！お前のところには頼まん！！」ってブチ切れて訴訟沙汰になったりして、それはそれは悲惨な結末を迎えました。当然ですね。
まぁ、とりあえずIT技術者でPMっぽい事をしている人には、PMBOKは必読だと感じました。PMには経験や人格も求められますが、知識もそれらと同じぐらい重要だなと思います。
ちなみに、PMBOKですが日本語版はオンラインでしか買えなかったりするのですが、ひそかに八重洲ブックセンターに大量に在庫されていたりします。ちなみに、相当デカイので注意してください。私は即効で自炊しました。
2012年3月9日金曜日
Windows Server 8 のAD CSで使えるCSP
Windows Server 8のAD CSをセットアップしてみたところ、使える暗号サービスプロバイダに変化があることに気付きました。
まずは、Windows Server 2008の場合を見てみます。AD CSはセットアップ時にCA鍵の生成を行いますが、鍵のアルゴリズムを指定する画面は以下のようになっています。
まずは、Windows Server 2008の場合を見てみます。AD CSはセットアップ時にCA鍵の生成を行いますが、鍵のアルゴリズムを指定する画面は以下のようになっています。
暗号プロバイダの名前に「#」が付いているものがありますが、これは暗号サービスプロバイダがVistaより前の形式か、Vista以後のCNGのどちらで実装されているかに依存します。#が付いているのがCNGです。
図では分かりにくいので、暗号プロバイダーごとにアルゴリズムを整理してみました。CSP実装の方はアルゴリズムが表示されていませんが、こちらを参照して推定で書いています。
図では分かりにくいので、暗号プロバイダーごとにアルゴリズムを整理してみました。CSP実装の方はアルゴリズムが表示されていませんが、こちらを参照して推定で書いています。
- Microsoft Software Key Storage Proider
- DSA (512, 1024)
- ECDSA (P256, P384, P521)
- RSA (512, 1024, 2048, 4096)
- Microsoft Smart Card Key Storage Provider
- ECDSA（P256, P384, P521）
- RSA (1024, 2048, 4096)
- Microsoft Base Cryptographic Provider v1.0
- RSA (512, 1024, 2048, 4096)
- Microsoft Base DSS Cartographic Provider
- DSA (512, 1024)
- Microsoft Base Smart Card Cryptographic Provider
- RSA (1024, 2048, 4096)
- Microsoft Enhanced Cryptographic Provider v1.0
- RSA (512, 1024, 2048, 4096)
- Microsoft Strong Cryptgraphic Provider
- RSA (512, 1024, 2048, 4096)
次に、Windows Server 8の方を見てみます。
- Microsoft Smart Card Key Storage Provider
- ECDSA（P256, P384, P521）
- RSA (512, 1024, 2048, 4096)
2012年3月8日木曜日
Windows Server 8 のGUIに困っちゃう件
Windows 8 Consumer Preview とWindows Server 8 Betaが出ましたね。さっそく使ってみたのですが....
一言で言うと、GUIが死ぬほど使いにくいです。以下がWindows Server 8のログオン直後の状態なのですが、Windows 95からの伝統のスタートボタンはなくなってしまいました。以下、リモートデスクトップで接続した際の画面です。
では、スタートボタンはというと、
画面の左下をマウスでクリックするとMetro UIのスタート画面に切り替わります。ポイントする位置は絶対にズレてはいけません。おそらく4x4ピクセルくらいの範囲です。
コンソールセッションやリモートデスクトップをフルスクリーンで使用している場合にはカーソルを端まで持っていけば問題ないのですが、ウインドウモードだと真剣にカーソルを合わせないと駄目です。あとマルチモニター構成の場合も苦労します。
代替方法としては、キーボードからWindowsキーやCtrl + Escを使えばよいのですが、デフォルトの設定では、リモートデスクトップクライアントはWindowsキーやCtrl + Escは（リモートではなく）ローカル側に送られてしまいます。
このようなときは、リモートデスクトップの接続時オプションで、「Windowsのキーの組み合わせを割り当てます」を「リモートコンピューター」に変更すると、リモートマシンにキーが送られるようになります。
どうしてこんな酷いことになっているかと言うと、Windows 8から使われるMetro UIはタッチパネルを意識しているためです。ホットコーナーを活用するという発想なのですね。
マイクロソフトさん、私、思うんですよ。サーバー製品でタッチパネルを使う人って相当レアな人種に属するんじゃないですかね？
一言で言うと、GUIが死ぬほど使いにくいです。以下がWindows Server 8のログオン直後の状態なのですが、Windows 95からの伝統のスタートボタンはなくなってしまいました。以下、リモートデスクトップで接続した際の画面です。
では、スタートボタンはというと、
コンソールセッションやリモートデスクトップをフルスクリーンで使用している場合にはカーソルを端まで持っていけば問題ないのですが、ウインドウモードだと真剣にカーソルを合わせないと駄目です。あとマルチモニター構成の場合も苦労します。
代替方法としては、キーボードからWindowsキーやCtrl + Escを使えばよいのですが、デフォルトの設定では、リモートデスクトップクライアントはWindowsキーやCtrl + Escは（リモートではなく）ローカル側に送られてしまいます。
このようなときは、リモートデスクトップの接続時オプションで、「Windowsのキーの組み合わせを割り当てます」を「リモートコンピューター」に変更すると、リモートマシンにキーが送られるようになります。
どうしてこんな酷いことになっているかと言うと、Windows 8から使われるMetro UIはタッチパネルを意識しているためです。ホットコーナーを活用するという発想なのですね。
マイクロソフトさん、私、思うんですよ。サーバー製品でタッチパネルを使う人って相当レアな人種に属するんじゃないですかね？
2012年1月26日木曜日
Ivy BridgeではCPUに物理乱数生成器が乗るらしい
4年間使った自宅のMacbookを買い替えようと思い立ちCPUについて調査していたら、今年に予定されているIntelの新しいCPUシリーズ（Ivy Bridge）の興味深い新機能を発見しました。
Ivy Bridgeには、AVX命令の拡張としてRdRANDと言う命令が追加されます。この命令はCPU上に搭載された物理乱数生成器を使って、高精度の乱数を高速に入手できるようにするものです。
今まで高精度な物理エントロピー源を用いた乱数を使おうとすると、HSM (Hardware Security Module) やTPMを使ったりしなければなりませんでした。こういった特殊なハードウェアを用いなくても精度の高い乱数が入手できるようになるのは革新的だと思います。
また、CPU内部で乱数を生成するため、乱数の生成に関するコストはとても少なくなります。今まではデバイスへのアクセスが必要になったりして、速度はあまり早いとは言えませんでした。
技術的に詳しい話はここに記述されています。3章までは特に難しいことは書かれていないので、興味がある人はご参照あれ。乱数の基本についても簡単に書かれているので、勉強になると思います。
Ivy Bridgeには、AVX命令の拡張としてRdRANDと言う命令が追加されます。この命令はCPU上に搭載された物理乱数生成器を使って、高精度の乱数を高速に入手できるようにするものです。
今まで高精度な物理エントロピー源を用いた乱数を使おうとすると、HSM (Hardware Security Module) やTPMを使ったりしなければなりませんでした。こういった特殊なハードウェアを用いなくても精度の高い乱数が入手できるようになるのは革新的だと思います。
また、CPU内部で乱数を生成するため、乱数の生成に関するコストはとても少なくなります。今まではデバイスへのアクセスが必要になったりして、速度はあまり早いとは言えませんでした。
技術的に詳しい話はここに記述されています。3章までは特に難しいことは書かれていないので、興味がある人はご参照あれ。乱数の基本についても簡単に書かれているので、勉強になると思います。
2012年1月24日火曜日
MSのPKIのホワイトペーパーがアップデートしていた
昨年（2011年）の11月にMicrosoftのPKIのWhitepaperがアップデートされていました。こちらから見る事ができ、DOCX版もダウンロード可能です。
MicrosoftはWindows 2000の頃からPKIの実装に力を入れていて、今ではTLS、EFS、Kerberos、スマートカードログオン、IPSec、802.1x (EAP-TLS)、SMIME、NAP（検疫ネットワーク）など、OS内部のさまざまな場所で使用されています。
にもかかわらず、PKIって相変わらずマイナー感が漂っていたりします。個人的には、このようなマイナー感はPKIの導入の敷居が高いのに原因があると思います。認証局の構築・運用はPKIに関するそれなりの知識を求められ、まじめにやろうとすると構築・運用側には結構な負担が生じてしまうのです。
このホワイトペーパーは、Microsoft社内の公開鍵認証局（CA）構成について具体的に紹介されています。実際にPKIアプリケーションを使いたいんだけど、認証局はどのような構成にすればいいか悩んでいる人には参考になると思います。
また、構成方法に加えて、運用についての記述も豊富なので、「EFSを導入したいんだけど、キーアーカイブとリカバリー業務はどうやって構成すればいいの？」のようなポイントにも記述されています。
MicrosoftのPKIソリューションについて、広く薄く知りたい場合にはとても適していると思います。
MicrosoftはWindows 2000の頃からPKIの実装に力を入れていて、今ではTLS、EFS、Kerberos、スマートカードログオン、IPSec、802.1x (EAP-TLS)、SMIME、NAP（検疫ネットワーク）など、OS内部のさまざまな場所で使用されています。
にもかかわらず、PKIって相変わらずマイナー感が漂っていたりします。個人的には、このようなマイナー感はPKIの導入の敷居が高いのに原因があると思います。認証局の構築・運用はPKIに関するそれなりの知識を求められ、まじめにやろうとすると構築・運用側には結構な負担が生じてしまうのです。
このホワイトペーパーは、Microsoft社内の公開鍵認証局（CA）構成について具体的に紹介されています。実際にPKIアプリケーションを使いたいんだけど、認証局はどのような構成にすればいいか悩んでいる人には参考になると思います。
また、構成方法に加えて、運用についての記述も豊富なので、「EFSを導入したいんだけど、キーアーカイブとリカバリー業務はどうやって構成すればいいの？」のようなポイントにも記述されています。
MicrosoftのPKIソリューションについて、広く薄く知りたい場合にはとても適していると思います。
2011年11月18日金曜日
データベース暗号化ガイドライン by DBSC
ここ数年はデータベースの暗号化に関する話題が（少しだけ）盛り上がりを見せているようです。某HSM屋さんの話によると、近年はDB暗号化の割合は着実に増えて来ているそうです。数年前と比べると、セキュリティに対する意識は変わってきたのでしょうね。
さて、11/1にデータベース・セキュリティ・コンソーシアム（DBSC）から「データベース暗号化ガイドライン 第1.0版」(PDFです）が公開されていました。35ページほどの文書ですが、データベース暗号化を行う際に考慮すべき事項がよく纏められています。暗号関連のお仕事をしている人は、ざっと目を通しておくとよいと思います。
読んでみた感想ですが、対象は何にせよ暗号を行う際に一番の問題となるのが、やっぱり暗号鍵の運用だなと思いました。暗号に詳しくない人は、一度データを暗号化すれば情報漏洩を防げると考えてしまいがちですが、実際は暗号鍵の危殆化や暗号アルゴリズムの脆弱性に対応しなければなりません。
それ以外にも、暗号鍵の安全な保管や、可監査性の担保と定期的な監査の実施などの暗号システムに特有なオペレーションが多く、意外と運用面での負担が大きかったりします。また、こういった暗号システム特有の運用に関する観点は、暗号分野が専門性の高い分野であることもあり、エンドユーザさんも正確に理解できていないことが多いと思います。
最近はPKI絡みのインシデントも多いですし、今後は暗号に対する基本知識が、構築側／運用側を問わずに必須になってくるのかもしれませんね。
さて、11/1にデータベース・セキュリティ・コンソーシアム（DBSC）から「データベース暗号化ガイドライン 第1.0版」(PDFです）が公開されていました。35ページほどの文書ですが、データベース暗号化を行う際に考慮すべき事項がよく纏められています。暗号関連のお仕事をしている人は、ざっと目を通しておくとよいと思います。
読んでみた感想ですが、対象は何にせよ暗号を行う際に一番の問題となるのが、やっぱり暗号鍵の運用だなと思いました。暗号に詳しくない人は、一度データを暗号化すれば情報漏洩を防げると考えてしまいがちですが、実際は暗号鍵の危殆化や暗号アルゴリズムの脆弱性に対応しなければなりません。
それ以外にも、暗号鍵の安全な保管や、可監査性の担保と定期的な監査の実施などの暗号システムに特有なオペレーションが多く、意外と運用面での負担が大きかったりします。また、こういった暗号システム特有の運用に関する観点は、暗号分野が専門性の高い分野であることもあり、エンドユーザさんも正確に理解できていないことが多いと思います。
最近はPKI絡みのインシデントも多いですし、今後は暗号に対する基本知識が、構築側／運用側を問わずに必須になってくるのかもしれませんね。
2011年11月11日金曜日
今度はDigiCert Sdn社が不正な証明書を発行してしまった件
MicrosoftからSecurity Advisory 2641690が提供されています。先日のDiginotar社の騒動に続き、今度はDigiCert Sdn社の中間認証局が不正な証明書を発行してしまったそうです。どうやら弱い鍵アルゴリズムを使った証明書が発行されてしまったらしく、2つの中間認証局の証明書が失効されたそうです。
Micorosoftから提供されたパッチを適用する前と後でのWindows証明書ストアの変化を見てみましょう。パッチ適用前の証明書管理コンソール（certmgr.msc)の状態は以下のようになります。
パッチ適用後の証明書管理コンソールの状態は以下のようになります。2つの中間認証局が信頼されていない認証局に追加されているのが分かります。発行元はEntrustとCyber Trustですね。
しかし、最近は証明書関連のインシデントが多いですね。これが氷山の一角ではなければいいのですが。
Micorosoftから提供されたパッチを適用する前と後でのWindows証明書ストアの変化を見てみましょう。パッチ適用前の証明書管理コンソール（certmgr.msc)の状態は以下のようになります。
2011年11月10日木曜日
今更ながらWindows 7のReadyBoostを使う
Pentium 4, メモリー1GBの遅いPCでWindows 7を使うことになったので、ReadyBoostで高速化できるかどうか試してみました。結果的に体感速度は良くなったのですが、原理が良くわからなかったのでちょっと調べてみました。
ReadyBoostは簡単に言うと、USBメモリーにHDDのキャッシュを作成することによって、アプリケーションの起動を高速に行う技術です。MicrosoftではReadyBoostに使用できるUSBメモリーの要件として、以下の項目を挙げています。
一般的なHDDと比較すると、ずいぶん低い要求に感じます。何故、遅いUSBメモリーにキャッシュを作ると、体感速度が向上するのでしょうか。で、色々ググってみると。ここら辺の話は、Mark Russinovich氏著のInside the Windows Vista kernel: Part 2に記述されていました。以下に引用します。
せっかくなので、対象となったマシンのHDDと手元にあるUSBメモリー（3本）の速度を計測してみました。ベンチマークはCrystal Mark 3.01を使用しています。USBメモリーのフォーマットはNTFSです。
たしかに、HDDは4KByteのランダムアクセスが極端に遅くなっています（水色の線です）。そして、USBメモリーの方は3本とも、そこそこの速度が出ています。このアクセス特性の差を使って、HDDの弱点を補完するんですね。
ちなみに、4GBのUSBメモリーを使ってReadyBoostの効き具合をパフォーマンスメーターで確認してみたところ、以下のようになりました。USBメモリーはBAFFALOのRFU3-K4Gです。
Bytes cachedとCache space usedを見ると、4.3GByteのデータが2.5GBに圧縮されてUSBメモリーに記憶されていることが分かります。
USBメモリーに保存されているデータはAESによって暗号化されています。データの圧縮と暗号化のオーバーヘッドを考慮しても、HDDからデータを読むよりかUSBメモリーから読み込んだほうが早くなるということなんですね。これほどまでにHDDのランダムアクセスが遅いのは意外でした。
1点だけ注意点。ReadyBoostはシステム起動時にキャッシュデータをHDDからUSBメモリーに転送します。このため、起動直後はしばらくはHDDへのアクセスが続きます。毎日電源を落とす運用をしている場合は要注意です。
ReadyBoostは簡単に言うと、USBメモリーにHDDのキャッシュを作成することによって、アプリケーションの起動を高速に行う技術です。MicrosoftではReadyBoostに使用できるUSBメモリーの要件として、以下の項目を挙げています。
- 4KByteランダム読み込みが、2.5MB/sec
- 512KByteランダム書き込みが、1.75MB/sec
一般的なHDDと比較すると、ずいぶん低い要求に感じます。何故、遅いUSBメモリーにキャッシュを作ると、体感速度が向上するのでしょうか。で、色々ググってみると。ここら辺の話は、Mark Russinovich氏著のInside the Windows Vista kernel: Part 2に記述されていました。以下に引用します。
The speed of CPUs and memory are fast outpacing that of hard disks, so disks are a common system performance bottleneck. Random disk I/O is especially expensive because disk head seek times are on the order of 10 milliseconds-an eternity for today's 3GHz processors. While RAM is ideal for caching disk data, it is relatively expensive. Flash memory, however, is generally cheaper and can service random reads up to 10 times faster than a typical hard disk.つまり、 HDDの苦手なランダムアクセスを、ランダムアクセス（の読み込み）が得意なUSBメモリーに肩代わりしてもらうということですね。しかも10倍も違うそうです。
せっかくなので、対象となったマシンのHDDと手元にあるUSBメモリー（3本）の速度を計測してみました。ベンチマークはCrystal Mark 3.01を使用しています。USBメモリーのフォーマットはNTFSです。
ちなみに、4GBのUSBメモリーを使ってReadyBoostの効き具合をパフォーマンスメーターで確認してみたところ、以下のようになりました。USBメモリーはBAFFALOのRFU3-K4Gです。
USBメモリーに保存されているデータはAESによって暗号化されています。データの圧縮と暗号化のオーバーヘッドを考慮しても、HDDからデータを読むよりかUSBメモリーから読み込んだほうが早くなるということなんですね。これほどまでにHDDのランダムアクセスが遅いのは意外でした。
1点だけ注意点。ReadyBoostはシステム起動時にキャッシュデータをHDDからUSBメモリーに転送します。このため、起動直後はしばらくはHDDへのアクセスが続きます。毎日電源を落とす運用をしている場合は要注意です。
2011年10月28日金曜日
CRYPTREC Report 2010が公開されていた
ちょっと古いネタですが、6月にCRYPTRECからCRYPTREC Report 2010が公開されていました。時間があったので、さらっと読んでみましたが、なかなか興味深いネタが多かったです。
CRYPTRECは独立行政法人 情報通信研究機構（NICT）の一部門として運営されており、日本国で使用する暗号アルゴリズムの一覧である「電子政府推奨暗号リスト」の作成など、重要な作業を担っています。公開されたCRYPTREC Report 2010はCRYPTRECの2010年の1年間の活動をまとめたものです。
内容は色々ありましたが、2013年に公開から10周年を迎える電子政府推奨暗号リストの更新作業や、暗号の脆弱性に対する手法の監視活動、サイドチャネル攻撃手法の研究、FIPS-140-3ドラフトに対するコメントやFIPS-140-3制定後々のISO/IEC, JIS化に関する作業など、中身の濃い話がたくさん書かれていました。
ちなみに、CRYPTRECは先日話題になったAESアルゴリズムに対するアタックについても「直ちに現実的な脅威につながることはない」というコメントを出しています。正直、暗号アルゴリズムについては、一般的な知識しかないので、この発表はとても安心できました。
CRYPTRECは独立行政法人 情報通信研究機構（NICT）の一部門として運営されており、日本国で使用する暗号アルゴリズムの一覧である「電子政府推奨暗号リスト」の作成など、重要な作業を担っています。公開されたCRYPTREC Report 2010はCRYPTRECの2010年の1年間の活動をまとめたものです。
内容は色々ありましたが、2013年に公開から10周年を迎える電子政府推奨暗号リストの更新作業や、暗号の脆弱性に対する手法の監視活動、サイドチャネル攻撃手法の研究、FIPS-140-3ドラフトに対するコメントやFIPS-140-3制定後々のISO/IEC, JIS化に関する作業など、中身の濃い話がたくさん書かれていました。
ちなみに、CRYPTRECは先日話題になったAESアルゴリズムに対するアタックについても「直ちに現実的な脅威につながることはない」というコメントを出しています。正直、暗号アルゴリズムについては、一般的な知識しかないので、この発表はとても安心できました。
2011年10月14日金曜日
PKI Day 2011に行ってきた（その2）
前回の続きで、PKI Day 2011の各セッションを見ていきたいと思います。
セッション4： 日本におけるRSA1024-SHA-1の移行に関する政策
暗号2010年問題に関して、日本国政府の取り組みが紹介されました。政府では新たな暗号方式への移行開始時期（通称：X-DAY）と、新たな方式への移行完了日（通称：Y-DAY）についての紹介でした。
現在の政府の方針では、X-DAYは2014年度開始、Y-DAYは未定（今後、X-DAYの様子をみて検討）となっています。なんだか微妙に先送りされちゃっただけのような気もしますが、無理のないスケジュールを考えると、これくらいが丁度よいのじゃないかと思えてきました。
セッション5： 最新の欧州PKI事情
AdES (Advanced Electronic Signature) 仕様関連を中心に、EUでの仕様策定の状況についてのお話がありました。
AdES関連の仕様はEUのESIが中心となって策定されました（日本もたくさん貢献しています！）が、EC指令460を受けて、仕様の軽量化と見直しが入るそうです。公演で面白かったのは、"should"とか"may"とかの「あやふやな記述はやめようよ」という点でした。これによって、今までオプション扱いだった（？）一部の規格が、必須扱いになるようなこともありそうです。国内の長期保存関連の実装も対応が必要になるかもしれません。
あと、個人的に気になったのは、現在策定中の書留電子メール (REM: Registerd e-mail)です。ちゃんと調べてないのですが、電子メールにエビデンス情報を付記することによって、メッセージの受理とか拒否とかを電子署名的に残せるようにする規格だそうです。最近のビジネスは電子メールに依存しているので、PKIが普及するためのキラーアプリになる可能性もあるような気がします。
セッション6： パネルディスカッション「番号制度とPKI」
今回のパネルディスカッションでは、企業における番号制度に着目してのセッションでした。国民番号制度を議論しようとすると、個人情報の保護の話が出てきてしまって、話がこじれてしまうことがあります。今回はそういった話をスルーするために、企業に番号を割振る「企業コード」にフォーカスしてのディスカッションでした。
社印の代わりとして電子署名を使う場合に、社長が毎回ICカードを持ちださなきゃならないのか？等、現行の法律面との関連を踏まえての議論がありました。その他にも、政府が管理する「企業ディレクトリ」みたいなものがあったら超便利だし、個人番号の方と連携すれば更に便利になるという話もありました。
ちなみに、9/25に民主党は「共通背番号制度」法案を臨時国会に提出しないことを決めました。たしか、いわゆるマイナンバー制度は2015年に稼働開始のスケジュールだったような気がしますが、スケジュールが遅延するかもしれません。
最後に
私が最初にPKI Dayに参加したのは4年前になります。4年前と比べると、PKIの技術自体はあまり変化はありませんが、PKIを取り巻く環境は大きく変わってきています。クラウド技術は普通に利用されるようになってきましたし、スマートフォンも一気に普及しました。
こういった変化は、インターネットが既にインフラとして我々の生活に完全に定着し、十分利用に耐えるものになってきたためだと思います。しかし、インターネットは情報漏えいや成りすましなど、インフラとしては信用に欠ける部分があるのも事実であり、現段階では我々利用者はインターネットを信頼できない（もしくは信頼性の低い）インフラとして扱わなければなりません。
今後はPKIを含む暗号技術の重要性は、インターネットが社会インフラとして利用されることが多くなるにつれ、増加していくのは確実です。4年間の変化を考えると、PKIが真の社会インフラとして必須とな日は、意外と近いのかもしれません。
セッション4： 日本におけるRSA1024-SHA-1の移行に関する政策
暗号2010年問題に関して、日本国政府の取り組みが紹介されました。政府では新たな暗号方式への移行開始時期（通称：X-DAY）と、新たな方式への移行完了日（通称：Y-DAY）についての紹介でした。
現在の政府の方針では、X-DAYは2014年度開始、Y-DAYは未定（今後、X-DAYの様子をみて検討）となっています。なんだか微妙に先送りされちゃっただけのような気もしますが、無理のないスケジュールを考えると、これくらいが丁度よいのじゃないかと思えてきました。
セッション5： 最新の欧州PKI事情
AdES (Advanced Electronic Signature) 仕様関連を中心に、EUでの仕様策定の状況についてのお話がありました。
AdES関連の仕様はEUのESIが中心となって策定されました（日本もたくさん貢献しています！）が、EC指令460を受けて、仕様の軽量化と見直しが入るそうです。公演で面白かったのは、"should"とか"may"とかの「あやふやな記述はやめようよ」という点でした。これによって、今までオプション扱いだった（？）一部の規格が、必須扱いになるようなこともありそうです。国内の長期保存関連の実装も対応が必要になるかもしれません。
あと、個人的に気になったのは、現在策定中の書留電子メール (REM: Registerd e-mail)です。ちゃんと調べてないのですが、電子メールにエビデンス情報を付記することによって、メッセージの受理とか拒否とかを電子署名的に残せるようにする規格だそうです。最近のビジネスは電子メールに依存しているので、PKIが普及するためのキラーアプリになる可能性もあるような気がします。
セッション6： パネルディスカッション「番号制度とPKI」
今回のパネルディスカッションでは、企業における番号制度に着目してのセッションでした。国民番号制度を議論しようとすると、個人情報の保護の話が出てきてしまって、話がこじれてしまうことがあります。今回はそういった話をスルーするために、企業に番号を割振る「企業コード」にフォーカスしてのディスカッションでした。
社印の代わりとして電子署名を使う場合に、社長が毎回ICカードを持ちださなきゃならないのか？等、現行の法律面との関連を踏まえての議論がありました。その他にも、政府が管理する「企業ディレクトリ」みたいなものがあったら超便利だし、個人番号の方と連携すれば更に便利になるという話もありました。
ちなみに、9/25に民主党は「共通背番号制度」法案を臨時国会に提出しないことを決めました。たしか、いわゆるマイナンバー制度は2015年に稼働開始のスケジュールだったような気がしますが、スケジュールが遅延するかもしれません。
最後に
私が最初にPKI Dayに参加したのは4年前になります。4年前と比べると、PKIの技術自体はあまり変化はありませんが、PKIを取り巻く環境は大きく変わってきています。クラウド技術は普通に利用されるようになってきましたし、スマートフォンも一気に普及しました。
こういった変化は、インターネットが既にインフラとして我々の生活に完全に定着し、十分利用に耐えるものになってきたためだと思います。しかし、インターネットは情報漏えいや成りすましなど、インフラとしては信用に欠ける部分があるのも事実であり、現段階では我々利用者はインターネットを信頼できない（もしくは信頼性の低い）インフラとして扱わなければなりません。
今後はPKIを含む暗号技術の重要性は、インターネットが社会インフラとして利用されることが多くなるにつれ、増加していくのは確実です。4年間の変化を考えると、PKIが真の社会インフラとして必須とな日は、意外と近いのかもしれません。
PKI Day 2011に行ってきた（その1）
PKI Day 2011に参加してきました。今回は恒例の東京ウィメンズプラザではなく、トスラブ山王での開催となりました。開催地が変更になったのは、U-Stream配信を行うための回線を確保するためだそうです。資料と公演の内容はこちらから見ることができます。
今年もいい話が聞けました。簡単に各セッションのコメントです。
セッション1： Microsoft U-Prove
マイクロソフトのID連携 (Identity Federation)に関する公演でした。今までのID連携では、個人情報等を公開してしまう恐れがあり、プライバシー保護の観点から問題があるとのこと。マイクロソフトでは、新しいID連携サービスを模索しており、U-Proveという技術に着目している。
U-ProveではIdPが個人情報を含むトークンと含まないトークンを生成し、クライアントは個人情報を含まないトークンをSPに提供することによって、プライバシー保護を考慮した認証が可能となる点が新しいそうです。ちょっと面白そうでしたので、あとで実験でもしてみようと思います。
セッション2： 楕円曲線暗号におけるPKI
楕円曲線暗号 (ECDSA) の各プラットフォームにおけるサポート状況が報告されました。検証対象となっているプラットフォームは、OpenSSL, Windows Vista, Java SE 7です。
ECDSAには鍵長以外にもいくつかのパラメータがあり、それぞれのプラットフォームで使用できるパラメータが異なります。PKIを導入する際には、設計段階において、アルゴリズムの選定と相互運用性の確認が必要ですが、今回の検証は当たりをつけやすくなって助かりました。
検証結果では、Vistaのサポートするパラメーターが少ないのは意外でした。Suite B対応の最小限のパラメータだけを実装した感じです。あと、個人的には、Windows 7の検証もあったらうれしかったです（7では使えるパラメーターがの組み合わせが増えていたような？気がします）。
セッション3： SSLにおける暗号危殆化サンプル調査の報告
毎年恒例のSSLサーバーの定点観測のお話でした。この調査報告は、金融系と政府系のSSLサーバーが使用している証明書のアルゴリズムとSSLの暗号設定について、3年間の追跡調査を行った結果を報告しています。ちょうど、2010年問題が話題になったこともあり、興味深いセッションでした。
SSL証明書では、RSA1024 / MD5がほとんど使われなくなったそうです。各SSL証明書屋さんは、数年前からMD5でハッシュした証明書の発行を止めていたので、想定通りの結果になっています。調査結果によると、95%以上のSSLサーバ証明書がハッシュアルゴリズムにSHA1を使っているとのことでした。
SSLサーバーの暗号設定は未だ改善されていませんね。共有鍵にRC4-MD5を受け付けるサーバーも多く、昨年からの変化もあまりありませんでした。おそらくSSLサーバーをデフォルトの状態で運用しているのではないかという指摘があり、まさにその通りな感じでした。
このセッションで感じたのは、暗号アルゴリズムに関する設定の難しさです。検証結果にもありましたが、ブラウザ側でも次世代のアルゴリズムをサポートしていますので、サーバー側では、そろそろ古いアルゴリズムは切り捨ててしまってもよいのではないかと思いました。
（次回に続く）
今年もいい話が聞けました。簡単に各セッションのコメントです。
セッション1： Microsoft U-Prove
マイクロソフトのID連携 (Identity Federation)に関する公演でした。今までのID連携では、個人情報等を公開してしまう恐れがあり、プライバシー保護の観点から問題があるとのこと。マイクロソフトでは、新しいID連携サービスを模索しており、U-Proveという技術に着目している。
U-ProveではIdPが個人情報を含むトークンと含まないトークンを生成し、クライアントは個人情報を含まないトークンをSPに提供することによって、プライバシー保護を考慮した認証が可能となる点が新しいそうです。ちょっと面白そうでしたので、あとで実験でもしてみようと思います。
セッション2： 楕円曲線暗号におけるPKI
楕円曲線暗号 (ECDSA) の各プラットフォームにおけるサポート状況が報告されました。検証対象となっているプラットフォームは、OpenSSL, Windows Vista, Java SE 7です。
ECDSAには鍵長以外にもいくつかのパラメータがあり、それぞれのプラットフォームで使用できるパラメータが異なります。PKIを導入する際には、設計段階において、アルゴリズムの選定と相互運用性の確認が必要ですが、今回の検証は当たりをつけやすくなって助かりました。
検証結果では、Vistaのサポートするパラメーターが少ないのは意外でした。Suite B対応の最小限のパラメータだけを実装した感じです。あと、個人的には、Windows 7の検証もあったらうれしかったです（7では使えるパラメーターがの組み合わせが増えていたような？気がします）。
セッション3： SSLにおける暗号危殆化サンプル調査の報告
毎年恒例のSSLサーバーの定点観測のお話でした。この調査報告は、金融系と政府系のSSLサーバーが使用している証明書のアルゴリズムとSSLの暗号設定について、3年間の追跡調査を行った結果を報告しています。ちょうど、2010年問題が話題になったこともあり、興味深いセッションでした。
SSL証明書では、RSA1024 / MD5がほとんど使われなくなったそうです。各SSL証明書屋さんは、数年前からMD5でハッシュした証明書の発行を止めていたので、想定通りの結果になっています。調査結果によると、95%以上のSSLサーバ証明書がハッシュアルゴリズムにSHA1を使っているとのことでした。
SSLサーバーの暗号設定は未だ改善されていませんね。共有鍵にRC4-MD5を受け付けるサーバーも多く、昨年からの変化もあまりありませんでした。おそらくSSLサーバーをデフォルトの状態で運用しているのではないかという指摘があり、まさにその通りな感じでした。
このセッションで感じたのは、暗号アルゴリズムに関する設定の難しさです。検証結果にもありましたが、ブラウザ側でも次世代のアルゴリズムをサポートしていますので、サーバー側では、そろそろ古いアルゴリズムは切り捨ててしまってもよいのではないかと思いました。
（次回に続く）
2011年9月8日木曜日
偽物のgoogle.comに対するMicrosoftの対応
DigiNotar社のSSL証明書偽装事件の続報が入りました。どうやら、*.*.comや*.windowsupdate.com等の証明書も発行されており、被害は相当なモノになっているようです（参照）。やばいことになってきましたね。
そんなさなかに、Microsoftがセキュリティアドバイザリーを改定しました（こちら）。今回の改定によると、MicrosoftはDigiNotar社の全認証局を信頼しないようにするためのパッチを公開したそうです（こちら）。
今回のパッチの影響をもう少し詳しく見てみましょう。Windowsでは、証明書を利用するためには、証明書を証明書ストアに登録しなければなりません。この証明書ストアには「信頼されていない認証局」というカテゴリーがあり、このカテゴリーに登録された証明書（と、その下位のCAが発行した証明書）は証明書の検証時に信頼されていない証明書として取り扱われます。
実際に証明書ストアを見てみましょう。Windowsの証明書ストアはcertmgr.mscを起動すると閲覧できます。パッチを当てる前の証明書ストアの「信頼されていない証明書」を見てみると、こんな感じです。（うっは、結構入ってるじゃんw）
パッチを適用後の「信頼されていない証明書」はこんな感じになります。ピンクで示した部分がパッチを適用することによって登録された証明書です。5つのCA証明書が「信頼されていない証明書」登録されました。
では、パッチを適用した状態で偽物のgoogle.comの証明書を検証したらどのようになるのでしょうか。実験してみました。（DigiNotar社のルート認証局証明書と中間認証局証明書を証明書ストアにインポートしています）。全般タブでは失効として扱われています。
パス検証のタブを見ると、本来CA証明書のCNが表示されるところに、「Untrusted」と表示されます。ちゃんと「信頼されていない認証局」として認識されるようです。
今回の事件の真相は未だ判明していませんが、PKI業界で仕事をしている身としては強い危機感を感じます。今後は認証局や登録局に対する攻撃が増えることも予想され、PKIという技術そのものに対する信頼が崩れてしまうことも考えられます。PKI業界は今回の教訓を生かしてより信頼できる体質になるべく努力を惜しむべきではありません。対策が後手になればなるほど傷は広がります。PKIが生まれて三十余年、今、PKI業界は信頼できるインフラとしての地位をかけた生存競争の時代に突入したのかもしれません。
そんなさなかに、Microsoftがセキュリティアドバイザリーを改定しました（こちら）。今回の改定によると、MicrosoftはDigiNotar社の全認証局を信頼しないようにするためのパッチを公開したそうです（こちら）。
今回のパッチの影響をもう少し詳しく見てみましょう。Windowsでは、証明書を利用するためには、証明書を証明書ストアに登録しなければなりません。この証明書ストアには「信頼されていない認証局」というカテゴリーがあり、このカテゴリーに登録された証明書（と、その下位のCAが発行した証明書）は証明書の検証時に信頼されていない証明書として取り扱われます。
実際に証明書ストアを見てみましょう。Windowsの証明書ストアはcertmgr.mscを起動すると閲覧できます。パッチを当てる前の証明書ストアの「信頼されていない証明書」を見てみると、こんな感じです。（うっは、結構入ってるじゃんw）
今回の事件の真相は未だ判明していませんが、PKI業界で仕事をしている身としては強い危機感を感じます。今後は認証局や登録局に対する攻撃が増えることも予想され、PKIという技術そのものに対する信頼が崩れてしまうことも考えられます。PKI業界は今回の教訓を生かしてより信頼できる体質になるべく努力を惜しむべきではありません。対策が後手になればなるほど傷は広がります。PKIが生まれて三十余年、今、PKI業界は信頼できるインフラとしての地位をかけた生存競争の時代に突入したのかもしれません。
登録:
コメント (Atom)
