Micorosoftから提供されたパッチを適用する前と後でのWindows証明書ストアの変化を見てみましょう。パッチ適用前の証明書管理コンソール（certmgr.msc)の状態は以下のようになります。
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サーバーをデフォルトの状態で運用しているのではないかという指摘があり、まさにその通りな感じでした。
このセッションで感じたのは、暗号アルゴリズムに関する設定の難しさです。検証結果にもありましたが、ブラウザ側でも次世代のアルゴリズムをサポートしていますので、サーバー側では、そろそろ古いアルゴリズムは切り捨ててしまってもよいのではないかと思いました。
（次回に続く）
登録:
コメント (Atom)
