自堕落な技術者の日記 : Microsoft - livedoor Blog（ブログ）

Microsoft

2014年09月12日23:23

カテゴリ: 暗号; SSL証明書

ChromeのSHA1証明書のアラート表示ポリシの問題点

SHA1withなんとかで署名されたSSLサーバー証明書に対するGoogle Chromeの将来の取扱いポリシについて、Googleのブログで9月5日に情報公開され、ちょっとビックリした人も多いんじゃないでしょうか。私は、「こりゃちょっと問題だなぁ。」と思ったので今日はブログで書いてみようと思います。

SHA1が充分な暗号強度がなくなりつつある話

暗号の専門家ではないので、よくわからないのですが、例えばコレなんかをみてみるとSHA1ハッシュアルゴリズムの暗号強度が充分でなくなってきていると言われており、暗号に関する日本で主要なガイドラインであるCRYPTREC暗号リストではSHA1は「運用監視暗号リスト」、危殆化リスクが高まっているが互換性維持のため仕方なく使って良いリストに入っています。

このような状況を受けて、製品ベンダー、証明書発行サービスなどのサービサーなどはSHA1からSHA2への移行をようやく始めたところなのかなと思います。

米国の標準化機関であるNISTは2011年1月に「NIST SP 800-131A Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lenghs(暗号アルゴリズムと鍵長の使用に関する勧告)」を発行しており、その中で「SHA1を使った署名の生成と検証は2013年12月31日以降、認められない。」としていますが、NIST内でもSHA1証明書を使ったサイトがまだ残っているそうで、「自分も守れてないじゃ～～ん」みたいな状態になっているそうです。

2013年11発表のMicrosoft製品のSHA1移行ポリシー

幾つかの業界や製品では先行してSHA1からの移行ポリシーを策定、公表しているものもありますが、SSLサーバー証明書に関しては幅広い製品やサービスで使われ、SHA1を使っている比率も高く移行は難しいのだろうと思います。本来ならCA Browser ForumのBaseline Profileで規定されてもよかったのだろうと思いますが、SHA1からの移行については言及されていません。そんな中、2013年11月12日に発表されたMicrosoft製品に関して公開された2つのSHA1移行ポリシーはちょっと衝撃的でした。

Windows Root Certificate Program - Technical Requirements version 2.0: このプログラムはWindows製品の「ルート証明書プログラム」という、Windowsの信頼するルート証明書に加えてもらうためには、どのような基準を満たさなければならないかを定めたものですが、「対象の認証局は2016年1月1日以降、SHA1証明書を発行をしてはならない。」としています。
Windows PKI Blog: SHA1 Deprecation Policy: 「Windows製品では2017年1月1日以降、SHA1のSSLサーバー証明書を受理しないためエラーとなる。」としています。すなわち、Windows製品でSSLを使えるようにするには、SHA1 SSLサーバー証明書を2016年12月31日までにSHA2にリプレースしなければならないという事だそうです。

SHA1 証明書がそろそろ偽造の危険性があるという認識も高まっており、充分な猶予期間もありますし、その頃には、SSLサーバー証明書を扱う全ての製品のSHA2対応もかなり進んでいるでしょうから、よく考えられた妥当なスケジュールなのかなと思います。

これに関して注目すべきポイントは以下の2つかと思います。

中間CA証明書やルート証明書のSHA1については言及していない。
2016年1月1日と、2017年1月1日という2つのマイルストーンを守りさえすればよい。

このMicrosoftのSHA1移行ポリシーのアナウンスを受けて、主要なSSL証明書発行サービスは、SHA1証明書の発行は2015年12月31日までとアナウンスをしています。

2014年9月5日に公開されたGoogle ChromeのSHA1 証明書対応ポリシー

2014年9月5日に「Google Online Security Blog: Gradually sunsetting SHA-1」にて、Google ChromeのSHA-1証明書にするポリシーの変更が発表され、一部の人は驚きを持って読んだのではないかと思います。 ITmediaエンタープライズでも「Google、「SHA-1」サポート中止のスケジュールを発表(2014.09.08)」として紹介されました。(何点か間違いがあるので、原文を参照するのがいいでしょう。)

これは簡単に言ってしまうと、「SHA-1のSSLサーバー証明書によってHTTPSの接続表示を近々(大きく)変えますよ」というアナウンスです。

Google ChromeのHTTPSステータス表示

Google ChromeのアドレスバーにおけるHTTPSのステータス表示は以下のようになっているようです。

表示	内容
	EV証明書でない正常なHTTPS接続の場合
	secure, but with minor errors 例えばHTTPSとHTTPのコンテンツの混在の場合などに出る。
	neutral, lacking security 平文のHTTPなど、セキュリティが無い中立の状態。
	affirmatively insecure 危険だと断言できる場合。
(参考) EV SSLサーバー証明書で正常にHTTPS接続できている場合

Google Chromeは証明書チェーンがSHA1かどうかチェック

WindowsのSHA1移行ポリシーはエンドエンティ証明書、すなわちSSLサーバー証明書がSHA1かどうかだけをチェックしており、中間CA証明書がSHA1かどうかは関係無かったのですが、Google Chromeの移行ポリシーは、全ての中間CA証明書もチェックするので注意しなければなりません。

で、ChromeでSHA1証明書でHTTPS接続した場合どうなるのか？

9月5日に発表された、ChromeでSHA1証明書にHTTPS接続した場合のURLアドレスバーのHTTPSステータス表示が、この半年で3回出てくるChromeのバージョンによって、どう変わっていくのかを整理したのが下の表です。

	Chrome 39 開発版の途中まで～2014.09.26 38安定版まで (～2014.11上旬)	Chrome 39 開発版の途中から (2014.09.26～ 2014.11.09) 39安定版リリースから (2014.11上旬～	Chrome 40 開発版の途中から (2014.11.09～ 2015.Q1) 40安定版リリースから (2015.01?～	Chrome 41 開発版の途中から (2015.Q1～ 2016.12.31) 41安定版リリースから (2015.03?～	2017.01.01～
有効期限が2016年5月31日までのSHA1証明書
有効期限が2016年6月1日から12月31日までのSHA1証明書
有効期限が2017年1月1日以降のSHA1証明書
Windowsの場合(Chrome同等の表示として)

表を見ていただければわかる通り、Microsoft WindowsのSHA1移行ポリシに比べて、Chromeはかなりアグレッシブな設定になっており、開発版は2014年9月26日のアップデートから、安定版は2014年11月頃リリースの39から正常なHTTPS接続でないかのようなステータス表示となってしまいます。

今回のChromeのSHA1対応ポリシの問題点

今回のGoogle ChromeのSHA1証明書に対する対応計画は様々な問題があると考えていて、論点を整理したいと思います。

最も重要だと思うのが、ブラウザ毎にHTTPSのエラーや問題に対する表示の意味が異なってしまうという点です。今回のSHA1証明書の表示の計画がブラウザベンダー毎に異なるのはユーザが混乱することになり、良くなかったと思います。本来ならCA Browser ForumのBaseline Profileなどで、業界で意思統一されたSHA1証明書の移行計画を示し、EV証明書のように準拠するブラウザは同じようなステータス表示にするべきだったと思います。
2つの有効期限の異なる証明書があって、その有効期限により表示状態が異なるということは問題です。今回はSHA1署名アルゴリズムの暗号危殆化を問題に取り上げているのですから、有効期限の長短にかかわらず、ある時点での暗号危殆化の程度は全く同じであり、同じものに対しては同一のHTTPSステータス表示にすべきではないでしょうか。
2017年1月1日からを、SHA1証明書を使ってはならない日と定めたとして、2年3ヶ月以上も前にユーザに表示を変えて伝える必要があるのでしょうか。2017年1月1日まではSHA1証明書を使って良いとするなら、いかなる警告もそのことで出す必要がなく、これはユーザも、ウェブサイト運営者も混乱させるだけです。2年以上も前に表示が異なってしまうことで、ユーザはサイトへクレームや問い合わせを入れるようになり、ウェブサイト管理者は仕方なく2年前倒しでSHA2証明書への移行を迫られることになります。
最近のモダンなブラウザではSHA2証明書に対応していますが、古いJavaや、組込み機器、ICカード、ガラケー(フィーチャーフォン)などSHA2証明書に対応できない環境は、未だに多数あります。これらの環境と歩調をあわせながらSSLサーバー証明書のSHA2移行を進める必要があったのではないでしょうか。
前述のOSなどのレベルでアルゴリズムとしてSHA2署名をサポートしていたとしても、検証などで使おうとするSHA2証明書のトラストアンカとなるルート証明書が「信頼するルート証明書」ストアに入っているかどうかは別の問題。例えば全てのお客様や、全社員のWindows XP SP3に対してルート証明書を追加させるという事はかなり困難。
Netcraftの2014年5月の調査によれば、インターネット上のウェブサイトのうち92%がSHA1証明書のままであり、SHA2証明書へ移行済なのはわずか7%にすぎません。HeartBleed脆弱性の影響で証明書のリプレースが多くあったため、SHA2への移行は進んだようですが、それでもたった7%です。このような状況で2014年9月にはHTTPSステータス表示を変えるというのは急すぎないでしょうか。(追記 SSLPulseによると2014年9月時点でSHA2は15%だそう)
SHA1証明書に対する表示変更のポリシーを2014年9月5日にアナウンスしてから、わずか21日後の2014年9月26日の開発版アップデート、安定版では2014年11月頃の39リリースで、影響を受けるサイトが出始めます。充分な猶予期間、準備期間を持てるように例えば半年や1年といったスパンで事前アナウンスをする必要があったのではないでしょうか。
SSLサーバー証明書は一般に2年や1年といった有効期間のものを購入される組織が多いと思いますが、例えば2014年6月1日から、アナウンスのあった2014年9月5日に2年物のSHA1証明書を購入し設定したウェブサイトは、早速2015年の1Qには、問題があるかのような黄色表示になります。事前に知らされていれば、1年物を買うとかSHA2証明書を買うとか対策ができたかもしれません。これは、あまりに不親切でユーザやサイト管理者の事を考えていない行為だと思います。
2017年1月1日以降が有効期限であるSHA1証明書が、2017年1月1日以降は使えなくなるという事は理解できるとして、2016年6月1日から2016年12月31日の間に有効期限がある証明書を分けてアラート表示をする必要があるとは思えません。

参考にすべきページ

今回のChromeのSHA1移行について問題提起や対策などを示している良いページがあるので、紹介しておきたいと思います。

CSO Online: Do you agree with Google's tactics to speed adoption of SHA-2 certificates?: CA Security Councilの中の人の問題提起。オンラインショップクリスマス商戦の時にこのような問題を起こすのや良くないとも言っている。Windows Server 2003ではhotfixなしでは非対応だと。他にも参考になるアドバイスがある。意見も募集している。
BLOG: IVAN RISTIC: SHA1 deprecation: what you need to know (2014.09.09): SSLの状態を調べられるQualysのSSLLabsを作っていたり、SSLの設定ガイドなどを書いているIvanさんのページで、今回のGoogle Chrome SHA1移行について、どのように対処するのが良いか解説しています。いつも冷静な分析をされる人ですが、今回に関し批評が無いのは寂しい。
CA Security Council: List of Operating Systems, Browsers, and Servers Which Support SHA-256 Hashes in SSL Certificates (last update Sep 8, 2014): 最新のSHA-256サポート状況のリストです。参考になります。でも、OSや環境レベルでSHA2をサポートしたと言っても、これから使おうとしているSHA2証明書のトラストアンカとなるルート証明書が信頼するルート証明書ストアに入っているかは別の問題。

おわりに

Google Chromeは良いブラウザだと思うし、便利だし、大好きなんですが、CRLSetの問題と、今回のSHA1対応の件はちょっとヒドイなぁと思います。サイトの運営者の方は、最初のマイルストーンの9月26日まで、あまり余裕がないので、至急自分の環境を調査して対策を取った方がいいと思います。今日はこんなところで。

本ブログの関連記事

(訂正)バージョン番号の修正(2014.09.17)

バージョン38が既にリリースされていると勘違いして、今回のSHA1アラート表示の修正が、マイナーで入るのかと勘違いしたため表のバージョンの表記がおかしくなっていましたので修正しました。バージョンの確認はこちらでできるようになっており、直近のメジャーですと以下のようなリリース履歴であるとわかりました。すみませんでした。(影響日やバージョンについて再修正しました9/17 12:50)

安定版メジャー 37.0.2062.94 2014.08.26 for Win,Mac,Linux
安定版メジャー 36.0.1985.125 2014.07.16 for Win,Mac,Linux
安定版メジャー 35.0.1916.114 2014.05.20 for Win,Mac,Linux
安定版メジャー 34.0.1847.116 2014.04.08 for Win,Mac,Linux

通常は安定版(Stable Channel)のリリースは6週間おきだそうですが、40安定版についてはクリスマスシーズンを挟むので時期が未定なのだと思います。

タグ：: #Windows; #SHA256; #SHA2; #Microsoft; #Google; #Chrome; #SHA1; #SSL; #サーバー証明書; #証明書

2008年12月30日00:15

カテゴリ: タイムスタンプ; 電子署名

Microsoft Authenticodeのタイムスタンプについてお勉強(第3回：最終回)

自堕落な技術者の日記 : Microsoft Authenticodeのタイムスタンプについてお勉強(第2回) - livedoor Blog（ブログ）

例えば Microsoft Outlook 2003 の場合、実行ファイル(outlook.exe)を右クリックしてプロパティを開くと「署名」のタブがあります。これがMicrosoft Authenticodeコード署名です。ここで書かれている「タイムスタンプ」って一体何なの？」というのが今回のテーマです。

年末バタバタしていたいので、間が空いてしまってすみません。

このシリーズではMicrosoft Authenticodeのコード署名に付与されるタイムスタンプが何であるのかについて書いています。結局、ここまでSigningTime属性のついた単なるカウンタ署名でるということがわかりました。

前回の説明でもう気付いちゃった人はいるかもしれませんが、Microsoft Authenticode用のタイムスタンプ要求には署名値というわけのわからない構造化もされていないオクテットに対して勝手に署名してくれるので、ぶっちゃけちゃうと中身は何でもいいわけです。

今回、最終回はこのあたりのぶっちゃけちゃった話をしたいと思います。

一般的な署名フォーマットとしての話

PKCS#7やCMS SignedDataでは、「あるデータに対して署名しましたよ～～～」と示すものなので、例えばPDFファイルや適当なデータに対してAuthenticode用タイムスタンプ要求を送信したとしても、内容の如何にかかわらず詐欺や偽の文書であろうがちゃんとPKCS#7あるいはCMSの署名の型で返してくれます。それも、Windows証明書ストアの信頼するルートから辿れる証明書(の鍵)で署名されたドキュメントになってしまうわけです。

Windows証明書ストアの信頼するルートを盲目的に信頼してしまっている署名検証アプリケーションはとってもヤバイことになってしまうのでは、、、と心配になってしまいます。

汎用の署名アプリケーションでは、PKCS#7やCMS SigneDataのフォーマットを使うことがよくありますが、署名者証明書のルートがそのアプリケーションで限定されたものにしておき、Windows証明書ストアのルートだからといって署名を有効としドキュメントが有効な署名に基づいているとしてしまうような事は避けないといけません。

偽RFC 3161タイムスタンプトークン(その１：失敗編)

Authenticodeタイムスタンプサービスには、任意のデータに対して署名要求を投げられるわけですから、例えば騙したい時刻のオレオレTSTInfoを作っておき、RFC 3161風味のトークンも作れてしまうのでは、、、と思ったわけです。

RFC 3161のタイムスタンプトークンはCMS SignedDataの形になっているわけですが、署名対象のデータとしてTSTInfo(OID 1.2.840.113549.1.9.16.1.4)の型のデータを持っているわけですが、通常Authenticode用タイムスタンプの取得でdata型()となっているところをTSTInfo型にして送信してみますと、、、、、まぁ、当然といいましょうか、、、、「TSTInfo型は知らない！」ということで要求は失敗します。

まずは、一安心です、、、、、

偽RFC 3161タイムスタンプトークン(その２）

では、data型というのはあきらめるものの、署名対象のデータとしてASN.1 TSTInfo型のデータとして送信してみると、、、、、

う～～～む、無事にというか、RFC 3161タイムスタンプトークン風味のものを取得できてしまいます。

これがヤバメだと思うのは、、、、

・Windows証明書ストアやSun Javaの信頼されるルートから辿れる署名である
・タイムスタンプ風味のデータは拡張鍵使用目的(extendedKeyUsage)拡張で
　timeStampingを持つ証明書に紐付く署名である
・TSTInfoの時刻は全くオレオレであり、(拾った鍵、危殆化した鍵が
　有効だった時刻に)時刻を詐称することが可能である
・本物のRFC 3161タイムスタンプトークンとの違いは、CMS SignedDataの
　　署名対象のデータ型がdataになっていることぐらいである。
・PKCS#7やCMS SignedDataはASN.1 BERかDERエンコードできるが、
　　Authenticode用タイムスタンプは正しくDERになっている。
　　(RFC 3161 TSP over HTTPではDERであることが生成要件になっている)

仕様を改定すべきと思う点

RFC 3161ベースのタイムスタンプトークンを発行するタイムスタンプ局(TSA)の証明書には拡張鍵使用目的(extendedKeyUsage)拡張でコード署名用タイムスタンプなどの汎用のタイムスタンプ局をあらわすtimeStampingの値ではなく、何か別の値を持たせて厳密に区別したほうがいいのではないかと思います。

Authenticode用タイムスタンプサーバーがエラーとなりdata型の値しか受けられなかったのは「たまたま」であり、TSTInfo型の要求を受けられるようになっていたら問題はとても深刻です。

そのためにもRFC 3161用のTSA証明書には専用のOIDを付けておく必要があるのではないかと思います。

また、署名を行った場合、対象となるデータを「承認した」とか「作成した」とか「表明する」とか何らかの署名意図があるわけですが、EKUでtimeStampingがある証明書で署名した場合、「署名対象のデータが、SigningTimeがある場合にはその時刻、SigningTimeがなくTSTInfoがある場合にはTSTInfoの時刻がに存在した」ことのみを表明するものであり、内容の正当性」については保証しないことを仕様で言及しておく必要があるのではないかと思います。

署名サーバーで注意すべき点

プロプライエタリな署名サーバーや、今回のAuthenticode用タイムスタンプサーバー、RFC 3161タイムスタンプサーバーなど、何らかの署名サービスを提供するサーバーは署名の目的を表明しておくか、署名する内容について広義の検証をしておく必要があります。

当面、検証側の実装が注意すべき点

今手元にRFC 3161タイムスタンプを扱うCAdESやXAdESなどの長期署名フォーマットの実装では、Authenticode用サーバーから出てきた偽のRFC 3161タイムスタンプ風のタイムスタンプトークンデータを扱う際に、ASN.1のパージングでエラーになる実装があったり、そのまま受け入れてしまったり、、、といろいろでした。

現状、このようななんちゃってタイムスタンプトークン受け入れないための検証ソフトウェアのベストカレントプラクティスを考えてみましょう。

・＜ベストプラクティス＞
　　・信頼するTSA証明書用のルートを限定しておく
　　・Windows証明書ストアの信頼するルートをTSA証明書のルートとして信頼しない
・＜仕方なく＞
　　・RFC 3161タイムスタンプトークンの署名対象のcontentTypeがTSTInfo型
　　　　であることを厳密に確認する。
　　・RFC 3161タイムスタンプトークンにSigningTime属性が入っていたら
　　　　まず疑ってみる。警告を出す。

タグ：: #コード署名; #タイムスタンプ; #Authenticode; #Microsoft

2008年12月20日08:55

カテゴリ: Windows; PKI

MSのOCSPレスポンダ証明書の問題

MS KB960549 Some third-party Online Certificate Status Protocol (OCSP) clients may reject a response from an OSCP responder if this OCSP responder receives a Response Signing certificate from a Windows Server 2008 certification authority

Some third-party OCSP clients require that the value of the NoRevCheck extension is an ASN null value. Therefore, these third-party OCSP clients reject the response from the OCSP responder.

Windows Server 2008ではOCSPをネイティブサポートするようになっているんですが、Microsoft CAが発行するOCSPレスポンダ用の証明書のNoRevCheck拡張(※これってNoRevAvail拡張の間違いじゃないっすか？)があるときに、サードパーティのOCSPクライアントではNoRevCheck拡張の値がASN.1 NULLであることをチェックするそうなんですが、Microsoft CAが発行する証明書は拡張の値オクテットはASN.1 NULLではなく空のオクテットになっていて、そのために検証に失敗することがあるようなんです、、、、、時間があるときに環境探して見てみたいです。

HotFixも出ているってことなんすよね、、、、

というわけで、メモメモ、、、、

タグ：: #Microsoft; #OCSP

2008年12月20日08:33

カテゴリ: コンピュータ

MSよりOOXML,ODF相互運用資料

マイクロソフト、Office 2007 SP2とODFの相互運用に関する技術情報を公開 : Microsoftウォッチ - Computerworld.jp

マイクロソフト、Office 2007 SP2とODFの相互運用に関する技術情報を公開

　米国Microsoftは12月16日、「2007 Microsoft Office system（以下、Office 2007） Service Pack（SP）2」で、ODF（OpenDocument Format for Office Applications）をサポートするための詳細な技術情報を公開した。

だそうなので、メモメモ、、、、今日は天気がよさそうですね。

タグ：: #OOXML; #ODF; #Microsoft; #Office

2008年12月20日01:09

カテゴリ: 電子署名; タイムスタンプ

Microsoft Authenticodeのタイムスタンプについてお勉強(第2回)

自堕落な技術者の日記 : Microsoft Authenticodeのタイムスタンプについてお勉強(第1回) - livedoor Blog（ブログ）

例えば Microsoft Outlook 2003 の場合、実行ファイル(outlook.exe)を右クリックしてプロパティを開くと「署名」のタブがあります。これがMicrosoft Authenticodeコード署名です。ここで書かれている「タイムスタンプ」って一体何なの？」というのが今回のテーマです。

今回は第二回目ってことで、コード署名の中身を見てみましょう。

1. Microsoft Authenticodeコード署名の構造

コード署名は実行プログラムやDLLの末尾についています。正しい取り出し方というのはよくわかんないんですが、それほど大きくない実行ファイルならばバイナリエディタ等で開いてみて末尾３～４キロバイトあたりで"00"が並んでいる後で、きりのいいアドレスで

?0 0? 00 00 00 02 02 00-30 82 ...

のようになってたら30 82から最後までがPKCS#7のコード署名部分になります。

図02 コード署名の検索

取り出してASN.1構造を見てみるとこんな感じになっていました。

図01 コード署名の場所と構造

つまるところ、コード署名のタイムスタンプっていうのはRFC 3161のようなタイムスタンプではなくて、Authenticode用のタイムスタンプサービスによるSigningTime属性のついた単なるカウンタ署名(副署名)だったってことがわかりました。だから、プロパティダイアログでもタイムスタンプが副署名のところに出てくるわけです。

2. Authenticode署名用タイムスタンプのプロトコル

タイムスタンプがRFC 3161タイムスタンプでないことがわかったので、当然タイムスタンプを取得するためのプロトコルも独自のものになっています。タイムスタンプの要求と応答はHTTP(S)を用いて行われます。

3. Authenticode署名用タイムスタンプの要求

Authenticode用タイムスタンプの要求メッセージはASN.1 DERエンコーディングになっており構造は以下のようになっています。

カウンタ署名の対象となる、コード署名者の署名値をラップしているだけの構造です。

SEQUENCE {

  OBJECT IDENTIFIER

    timestampCountersignature (1 3 6 1 4 1 311 3 2 1)

  SEQUENCE {

    OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)

    [0] {

      OCTET STRING

        ... (コード署名の署名値) ...

      }

    }

  }

これをBase64エンコーディングしたものをContent-Typeをapplication/octet-streamにしてPOSTで送っているだけです。

4. Authenticode署名用タイムスタンプの応答

Authenticode署名用のタイムスタンプ応答は、署名対象として要求で指定されたバイト列に対して署名を施したPKCS#7署名データをBase64エンコードしたものです。

5. コード署名にタイムスタンプを付与するフロー

Authenticodeコード署名にタイムスタンプを付与するフローを示します。手順はざっくりこんな感じ。

① フツーに(タイムスタンプ無し)コード署名を行う
② コード署名の署名値のバイト列を取り出す
③ 上記、署名値よりタイムスタンプ要求を生成する
④ タイムスタンプサーバーに要求を送信する
⑤ タイムスタンプサーバーより応答(PKCS#7署名データ)を取得する
⑥ 上記署名データからSignerInfoの構造の部分を取り出す
⑦ コード署名の非署名属性群フィールドに上記SignerInfoをカウンタ署名属性
　　として格納する

図03 タイムスタンプの付与

というわけで、今日はMicrosoft Authenticodeコード署名のタイムスタンプについて以下のことがわかりました。

・RFC 3161 タイムスタンプ(トークン)ではない
・ただのカウンタ署名のSigningTimeを署名時刻としている
・タイムスタンプ取得のプロトコル

次回は最終回になるかな、、、、、嵐を呼ぶ最終回になったらごめんなさい。

ではでは

タグ：: #Microsoft; #Authenticode; #コード署名; #タイムスタンプ

2008年12月18日19:20

カテゴリ: 電子署名; タイムスタンプ

Microsoft Authenticodeのタイムスタンプについてお勉強(第1回)

今日は、Microsoft Authticodeコード署名のタイムスタンプについてお勉強したことを書いてみようと思います。これはやや長くなりそう、、、

1. はじめに

Microsoft AuthenticodeはMicrosoft Windowsの実行プログラム(.exe)やライブラリ(DLL)、オフィスのマクロなどに対して、配布の過程でプログラムの不正な改ざんが行われていないかをプログラムにデジタル署名を施して保証する仕組みで、一般にコード署名と言われているものです。

Microsoft Authenticodeにはタイムスタンプをつけることができ、コード署名用のデジタル証明書が有効であった第三者機関が保証する時刻に署名行われたことを示すためのものです。

例えば Microsoft Outlook 2003 の場合、実行ファイル(outlook.exe)を右クリックしてプロパティを開くと「署名」のタブがあります。これがMicrosoft Authenticodeコード署名です。

Outlookのプロパティの署名タブ

ここで書かれている「タイムスタンプ」って一体何なの？」というのが今回のテーマです。

2. コード署名を行うには？

自分が作ったWindowsプログラムにMicrosoft Authenticodeコード署名を付けるには "signtool.exe" や "signcode.exe" といったMicrosoftから提供されているツールを使います。例えば Microsoft .NET 2.0 SDK ならば、"C:\Program Files\Microsoft.NET\SDK\v2.0\Bin\signtool.exe" にあるので探してみてください。

signtool自体はいろんな使い方があるんですが、一番簡単なのはウィザード形式で実行する方法です。コマンドラインで起動するのも面倒なので"signtool.exe"のショートカットを作っておいて、プロパティを開きリンク先のところで "signwizard" のコマンドラインオプションを付けて起動するようにしてやれば良いと思います。

signtool signwizard

あと、準備としては秘密鍵を持っているコード署名に使えそうな証明書を適当にみつくろってください。どんな条件ならコード署名に使えるのかは詳しく見てないのですが汎用なところではkeyUsage拡張にdigitalSignatureがありExtended Key Usage拡張がなければオッケーなようです。

先ほど作ったショートカットよりウィザードを起動して、「次へ」進むと最初にコード署名をする対象のEXEやDLLのファイルを選択して、、、

wizard basic 01

ここは面倒なので「通常」でよいでしょう、、、、

wizard basic 02

コード署名の署名に使う証明書を選択して、、、

wizard basic 03

このあたりはデータとしては入ってますが、表示はされないので適当に埋めといて、、、、

wizard basic 04

ここで、もしコード署名にタイムスタンプをつけるならチェックをオンにしてタイムスタンプサービスのURLを入力します。うちはコード署名証明書出してないんですがSignToolのマニュアルの例にある http://timestamp.verisign.com/scripts/timestamp.dll なんかが使えると思います。これは、お使いのコード署名証明書の発行サービスに確認してみてください。

wizard basic 05

サマリを確認しておしまいです。

wizard basic 06

簡単ですよね、、、、（＾＾；

今日はまったく本題に入れませんでしたが、長かったのでこの辺で、、、、、

3. 参考リンク

・MSDN: SignTool Tool コマンドマニュアル

タグ：: #Microsoft; #Authenticode; #コード署名; #タイムスタンプ

2008年11月21日23:41

カテゴリ: コンピュータ

ISO 29500 OOXML公開

ISO - News - Publication of ISO/IEC 29500:2008, Information technology - Document description and processing languages - Office Open XML file formats

ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) have just published the joint International Standard, ISO/IEC 29500:2008, Information technology ? Document description and processing languages - Office Open XML file formats.

ISO/IEC 29500 is a standard for word-processing documents, presentations and spreadsheets that is intended to be implemented by multiple applications on multiple platforms. One of its objectives is to ensure the long-term preservation of documents created over the last two decades using programmes that are becoming incompatible with continuing advances in the field of information technology.

Office 2007のフォーマットの標準OOXML(Office Open XML file formats)が2008.11.18に公開されました、、、、メモメモ、、、、

タグ：: #OOXML; #Microsoft; #Office

2008年10月08日20:02

カテゴリ: コンピュータ

PPTのファイルが何故デカクなるのか？

ヘロヘロですが、今日も生きています（･∀･)つ
今、無性に何故うち会社のPowerPointのファイルサイズがデカくなるのか書きたいっ！！！

時間がないので今度かならず、、、、、、

タグ：: #Microsoft; #PowerPoint

2008年09月25日22:57

カテゴリ: プログラミング; 電子署名

Visual C# 2008 Express

ちょっとXML署名関係で調べたいことがあり Microsoft Visual C# 2008 Express Editionでプログラムを作ってみました。やっぱり基本的にはSharp Developよりもよく出来ているなぁ、、、、、

たまにしか使わないので、すぐ忘れてしまいますが

（１）暗号系のプログラムを作成する際にはSystem.Securityの参照を追加する

.NET での参照の追加