ちょっと古いネタですが、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アルゴリズムに対するアタックについても「直ちに現実的な脅威につながることはない」というコメントを出しています。正直、暗号アルゴリズムについては、一般的な知識しかないので、この発表はとても安心できました。
2011年10月28日金曜日
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)