昨日某所の会合でPDF電子署名外観に関する話をしていました。検証結果の表示についてどう表示されるのかをふと確認しておこうと思いその場で Adobe Reader 9 で開いてみました。AdobeのReader/Acrobatでは標準ではPDFを開く時に電子署名があれば検証をして結果を表示してくれます。例えば検証の成功・不明・失敗を開いた例が以下となります。



ん？何か違和感が…良く見ると Adobe Reader/Acrobat 8 では署名外観の上に、成功ならチェックマークが、不明なクエスチョンマークが、失敗ならバツマークが付いていたのが表示されなくなり、ツールバーの下（PDFページ表示の上）にある署名ペインに検証結果が表示されています。比較の為に以下に Adobe Acrobat 8 で同じファイルを開いた例を示します。



この変更はどういう意図なのか等を私なりに考察してみます。興味がありましたら [続きを読む] にて。 [続きを読む]

ECOMは昨年度で終了した関係からか報告書が3月末日で公開されていました。報告書はPDF形式で私が関連したのは以下の報告書です。

　「電子署名普及に関する活動報告２００９」（PDF形式：約1.4MB）

この中でPAdES（PDF長期署名）のETSI仕様を簡単に和訳しましたので、PAdESにご興味がありましたらぜひご覧下さい。

PKI繋がりでJNSAの「PKI Day 2010」が6月29日に行われるとの案内も来ていました。PKI Dayは毎年面白い内容なので今年も参加したいと考えています。kjurさんもOpenSSL1.0.0について発表されるとのこと。楽しみです。

本日はXMLコンソーシアムWeekの３日目で、私も参加しているセキュリティ部会の発表の日でした。場所は箱崎のIBM本社ビル（写真）でした。

今年は年度末と言うこともあってか例年よりもお客様は少なかったようです。私もセキュリティ部会の活動報告の中で、XML署名ツール検証とXML署名事例調査報告の発表をしました。参加されました方の参考になったなら幸いです。なお本日使った資料も公開される予定ですが、残念ながら会員または申し込んだ方のみダウンロード可能になります。

さて署名ツール検証に関しては別途詳しい報告書も本日よりXMLコンソーシアムのサイトで公開されました。署名ツール検証に関してはこちらからダウンロード[PDF注意]頂けます。こちらはどなたでもダウンロード可能です。

署名ツール検証では、XML署名の各方式（Detached/Enveloped/Enveloping）に関しての.NET FrameworkとJava6によるプログラミング例と相互運用性の確認を報告しています。単に署名だけでは無くC14N正規化やWindows証明書ストアの利用方法等の基本も解説しています。

ただ問題点として、名前空間名なしEnvelopingのXML署名について、Sun Java6の実装が他と異なっており検証に失敗することが判明しています。全く同じプログラムを使ってIBM Java6の場合には問題はありません。これに関しても少し詳しく解説をしています。Sun Java6を使ってXML署名をしている方はぜひご覧頂きたい内容になっています。この問題はSunのJavaコミュニティにも報告しなければと考えています。さてどうすれば良いのか調べる必要がありますね。

以上が簡単な報告になります。XMLコンソーシアムも今年が最後なので、最後のXMLコンソーシアムWeekになるはずです。セキュリティ部会及びWeb実証部会の皆様お世話になりました。次の新しい団体はどうなるのかな？またご報告したいと思います。

昨日はECOMの会合でいつものように東京タワーの下まで行ってきました。ところでECOMは今年で解散になります。ECOMの電子署名普及WGが中心になって新団体「電子記録応用基盤フォーラム」が４月に発足します。会員募集が始まっていますので、ご興味がありましたらぜひ入会募集のご案内をご覧ください。

基本的には電子署名普及WGの活動を中心となりますので、最近だとPDF長期署名のPAdESの最新情報の入手だったり提案だったりと言った活動や、その他電子認証だったりと幅広い活動が可能です。弊社も電子署名普及WGから継続する予定です。弊社もまだまだ新参者ですしぜひ新しい方に入って頂けると嬉しいです。なお電子署名を利用するユーザの立場の方もノウハウやアドバイスも得られますのでご検討下さい。

更に４月からは電子記録マネジメントコンソーシアム（ERMC）の活動も開始されます。これはARMA/ECOM/JIIMA/JIPDEC/TBFと言った各種業界団体の集まりになります。電子文書を活用するのに必要となる電子署名のような基盤技術から運用やビジネスまで相互補完して活動することで日本としての電子文書マネージメントの基礎を作り上げようと言う目的で活動されます。ERMCに関しては団体単位の加盟になりますので直接入会することは出来ません。所属団体を通じての活動になる予定です。

XMLコンソーシアムも今年度で部会活動は終了となりますし、今年の新年度は色々な環境がリセットされることになりそうです。

さて昨日の続きです。おさらいをするとPKCS#7(CMS)を利用するPDF署名は素直に拡張するならPKCS#7の署名データをCAdESの長期署名データに変更すれば良いと思えます。しかしCAdESを全面採用できない事情が存在します。それはPDF署名が署名対象範囲を指定するのに使っているバイトレンジ指定の仕組みです。

PDF署名において署名データはPDFの中に埋め込まれます。しかし署名データは署名対象にはもちろん出来ません。つまり署名データの前と後ろの部分が署名対象になります。署名対象範囲はバイトレンジ（署名辞書内のByteRangeキー)で指定される４つの数字で示します。

　ByteRange [ 開始位置１　長さ１　開始位置２　長さ２ ]

開始位置と長さの２つの数値のペアになっています。これで署名データの上と下を指定できますね。めでたしめでたし… なのですが１つ問題があります。それは、

　「署名データのサイズは署名時（正確には署名前）に決定する必要があり後から変更やリサイズは出来ない」

と言うことです。バイトレンジの部分も署名対象の一部です。従って後から署名対象範囲の変更は出来ません。また開始位置とはファイル先頭からの指定です。従って前後２つの部分に挟まれた署名データ部分のサイズは署名後は変更できません。通常PDF署名ではある程度ゆとりを見て署名データ部のサイズを確保しておきます。署名データとせいぜいタイムスタンプくらいなら数キロバイト単位で確保しておけば充分です。

次に長期署名の仕組みを見てみましょう。JIS化されている仕様は大きく分けて以下の２種類です。

　１） ES-T： [ 署名 ＋ 署名タイムスタンプ ]
　２） ES-A： [ ES-T ＋ 証明書群 ＋ 検証情報 ＋ 保管タイムスタンプ ]

ES-Tの方は既存のPDF署名のPKCS#7でも細部は異なりますがほぼ同様に実現されています。問題はES-Aの方です。検証情報とはCRL（失効リスト）やOCSPレスポンスとなります。CRLの利用が一般的ですが、CRLの仕組みは失効したIDを全てリストアップしているので大量に証明書を発行されている認証局だと100キロバイト単位のサイズになることがあります。また検証情報は通常署名後に取得することになります。

またES-Aは有効期限が切れる前に繰り返し適用も可能になっています。つまり長期署名とは最新の情報を追加して行くことで長期間の有効性を担保していると言えます。動的な仕組みであり成長して行く署名データとも言えます。

バイトレンジの話に戻してみましょう。バイトレンジは通常はせいぜい数十キロバイト程度しか確保されていません。これを将来に渡ってES-Aを追加して行くつもりでメガバイト単位で最初から確保することは現実的でしょうか？ 答えはやはり「ノー」でしょう。どんなに小さなPDFファイルも最初から数メガバイトのサイズになるのは利用者から見て受け入れられませんし、そもそもどれだけ確保しても絶対に安全なサイズも分かりません。PDF署名は静的な安定した仕組みであり拡張性があまり無いと言えます。

以上から出てくる答えは、PDF署名の長期署名化に関して、ES-Tまでは現行の仕組みで対応が可能だが、ES-Aでは別途証明書や検証情報や保管タイムスタンプを保管する新しい場所をPDFファイル内に確保する必要がある。と言うことです。

証明書や検証情報をどこに保管するかで議論や検討があったようです。しかし最終的にはPDFのオブジェクト構造としてPDFの増分更新の仕組みで追加する仕様が支持されました。それが現在検討が進んでいるPAdESの仕様です。PAdESに関しては更に以下の仕様に分けられます（これ以外にもPAdES仕様は存在しますが今回はこの３つに絞ります）。

　PAdES Basic ： PKCS#7を使ったISO32000-1までのPDF署名
　PAdES Enhanced ： CAdES-Tを使ったPDF署名
　PAdES LTV (Long Term) ： PDFオブジェクトとしてES-Aを実現

PAdES Basicは従来からのPDF署名の仕様です。PKCS#7形式で署名＋タイムスタンプが利用可能です。PAdES EnhancedはPKCS#7部をCAdES-Tで置き換えた仕様です。CAdES-T形式で署名＋タイムスタンプが利用可能です。

最後のPAdES LTVは、PAdES Basic または PAdES Enhanced のPDF署名済みファイルを長期署名対応する為の仕様となり、証明書や検証情報を新しく設定されたPDFストリームオブジェクトとして増分更新を行い、PDF署名とほぼ同じ仕組みのこれも新しく設定されたドキュメントタイムスタンプを保管タイムスタンプとして利用する形式です。

ES-Aを実現しているのがPAdES-LTVですが、PAdES-Aとしなかったのはやはり既にPDF/Aと言う仕様が存在していた為でしょう。なおPAdES-LTVにより長期署名化することはPAdES-Basicつまり既存のPDF署名済みファイルに対しても有効と言うことになります。

また保管タイムスタンプでは無く、ドキュメントタイムスタンプと呼ぶことにも意味があります。ドキュメントタイムスタンプは署名無しでも利用が可能です。ドキュメントタイムスタンプだけ付与されたPDFファイルは「誰が」に関しては保障されませんが、「何時（いつ）」に関しては保障が可能ですので、特許対策の知財保護での利用等が考えられます。つまりドキュメントタイムスタンプは保管タイムスタンプ以外にも使い道があると言うことです。

CAdES/XAdESとは別の第3の長期署名フォーマットと言うことで何故増やす必要があるかと最初は思いましたが、既存のPDF署名からの連続性や拡張を考えると、PAdESは良く考えられた仕様だと思います。

さてお昼休みも終わりに近づいたし結構書いたと思うので今日はこのくらいにしたいと思います。なおPDF署名に関してはアンテナハウスにて色々な情報があります。PDF署名の仕組みに関して詳しく知りたい方は以下のリンクを辿ってみると良いでしょう。

　アンテナハウス「PDFと電子署名について」
　アンテナハウス「PDF電子署名入門」

また昨日話が出ましたPDF/Aに関する情報もあります。

　アンテナハウス「PDF/Aとはなにか」
　アンテナハウス「PDF/Aの概要」（PDFへのリンク）

どちらも大変勉強になります。

最近のPDFの状況を簡単にまとめてみましょう。現在ISO等で検討されているPDFの仕様としては、ISO32000-2と呼ばれるPDF2.0の仕様がまずあります。それとは別にPDF/A-2と呼ばれるPDF1.7（ISO32000-1）をベースとした仕様もあります。

PDF/AはPDFの長期保管の為の仕様です。既にAcrobat9.0ProではPDF/A-1の仕様に従っているかどうかをチェックするプリフライト機能とPDF/A-1bへの変換機能も付いています。PDF/Aはカプセル化して将来それだけで必要な情報は全て揃うようにPDFの仕様のうち使って良いものを指定したプロファイルとなります。例えばフォントに関しては全て埋め込みが必要ですし、カラースペースもデバイス独立か埋め込みが必要となります。更にPDF/A-1aと言う仕様がPDF/A-1のフル仕様対応版となりますが、タグ情報により文書の順番等も指定する必要があります。この辺りはちょうどPDF/A関連の仕事をしているので勉強しているところです。

PDF長期署名の仕様であるPAdESはISO3200-2にもPDF/A-2にも採用される方向だと理解しています。基本的には従来のPDF電子署名の拡張により長期署名を実現しています。

さてPDF署名では署名データとしてPKCS#7形式を利用しています。PKCS#7はバイナリ署名データCMS形式の元となった形式です。また既にJIS化されたCAdESはCMSを長期署名化した仕様となっています。ちょっと考えるとPKCS#7の部分をCAdESに置き換えるだけで長期署名化が出来そうに思えますが、PDF特有の問題がありそれが出来ないのでPAdESと言う仕様が生まれてきたと言うことになります。小出しにすることになりますが何故「PDF電子署名＋CAdES」でPDF長期署名が出来ないかはまた次回。

なおUさんのPAdES連載も既に第２回が出ています。こちらも是非ご覧になることをお勧めします。自堕落な技術者の日記 「連載:PAdES(PDF長期署名)について(第2回) PDF署名とは」。

PDF電子署名を長期署名化するPAdESと言う仕様の検討がETSIを中心に進められています。既に英語と日本語のWikipediaには記載されています。日本語版はETSI にも行かれているUさんが編集されてました。で私もPAdESの事をこのブログに書こうと思いつつ…ずるずる伸ばしていたらUさんのブログでPAdESに関する説明が開始されていました。

しまった！どう考えてもPKIの仕様の話でUさんに勝てるとは思えない（笑） これはもうあちらのブログを楽しみにするしか無いか… とは言え時間があったら私なりのPAdESの話を書くかも。こちらは入門編的な内容になるだろうし、勝ち負けの問題でも無いだろうし… と自分をなぐさめてみる。

なお弊社ではPDF電子署名に関してはアンテナハウスのPDF電子署名モジュールの販売代理店でもあります。PDF電子署名に関しては多少はノウハウもあります。一括してバッチ的にPDF署名を付与するようなツールを受託開発した経験も複数ありますので、ご興味がありましたらお問い合わせ下さい。カスタマイズを含めてご相談にのります。ちなみに最近は署名ではありませんがPDF/Aに関係する仕事もしていたりします。

何とかPAdESに対応したPDF署名ツールが提供できるようになると良いなぁとは思っていますがさてどうなりますか。その前に（入門的な）記事をちゃんと書かなきゃなぁ。とりあえずPAdESに（特にPKI的な）興味がある方はUさんのブログ「自堕落な技術者の日記」は必読ですよ。

Windows環境で証明書ストアを利用するAPIはWin32の時代ではCryptoAPI(CAPI)が使われてきました。.NET Frameworkの時代になって、CryptoAPIに対してCOMインターフェイスを提供するAPIがCAPICOMでした。CAPICOMにより.NET FrameworkからCryptoAPIの利用が可能になります。証明書の選択ダイアログを表示して選択したり、証明書情報をGUIで表示したり、証明書を検証したりする事ができます。しかしCAPICOMのDLLファイルは標準では提供されていません。更に色々なアプリケーションがCAPICOMをインストールする事が多く混乱の元になっていました。

実は弊社の長期署名ライブラリLe-XAdESはCAPICOMを使っています。それは昔Le-XAdESを開発した当時参考にしたのが.NET Framework 1.0用のサンプルだった為でした。しかし.NET Framework 2.0からX509Certificateが新しくX509Certificate2として機能が拡張されCAPICOMと同等の処理が可能になっていました。調べた結果、現在Le-XAdESの利用においてもX509Certificate2を使えばCAPICOMを使わなくても良いと言う事が分かりましたので、現在修正してバージョンアップ作業中です。

と言う事で今後.NET Framework 2.0以降にて証明書ストアを利用するならX509Certificate2クラスとX509Storeクラスを使いましょう。証明書の認証パスの検証もX509Chainクラスにて可能です。GUIを使った証明書の選択や表示はX509Certificate2UIクラスを利用します。

これで今後はCAPICOMと決別できそうです。ただCryptoAPI(CAPI)はICカード等のドライバの関係でまだまだ使わなければならなかったりしますが…

ETSIよりXAdESの新しいバージョンV1.4.1がリリースされています。以下のページからダウンロードできます。

http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=28064

ダウンロードには事前に登録が必要になりますのでご注意ください。

とりあえずダウンロードをして眺めています。アーカイブタイムスタンプxadesv141:ArchiveTimeStampが変更されたようです。ds:Objectの扱いが異なっているのかな？詳細はこれからです。またタイムスタンプ用の検証情報格納場所として新たにxadesb141:TimeStampValidationDataとしてCertifiecateValuesとRevocationValuesを指定できるようになりました。ん？URI属性が指定可能？これはどのタイムスタンプに対する検証情報なのか指定できると言うこと？やはりじっくり読まないと駄目そうです。

ちなみにJISプロファイルではタイムスタンプの検証情報はタイムスタンプトークン自体に後から埋め込む仕様になっていました。これはこれで良いのですがASN.1/BERを読んで解釈するだけではなく追加や生成するのはXMLプログラマにとってハードルが高いと言う点からTimeStampValidationDataが追加されたと思われます。ただどちらにせよ本格的にPKIをやろうと考えるとどうしてもASN.1/BERを自由に使えるようになる必要はあるんですけどね。

弊社もAsn1Xmlライブラリを自作して対応しています。ASN.1/BERを独自XMLにして自在にパースや追加/生成してまたASN.1/BERに戻すと言ったことができます。フリーツールとしてLeAsn1XmlToolを配布中ですのでよろしければご利用ください。

まずは速報と言うことで今日はここまで。

今週は「RSA CONFERENCE JAPAN 2009」が幕張で行われている。昨年までと違い今年は単独開催じゃ無くて「INTERROP Tokyo 2009」なんかと併設になってます。

だいたい毎年参加をしていたんですが今年はセッションの内容にあまり興味が持てずにコストを考えてパスすることに。いや仕事が忙しいと言う側面もあるのですが。場所も幕張はちょっと不便かなあ。でも昔はMacWorldなんかは喜んで幕張まで行っていました。

来年はできれば行きたいですがやはり内容と場所次第かも。なお今月は無料で濃いPKIの話題が聞けるJNSAの「PKI Day 2009」には行く予定。

DDTF（電子署名・電子認証シンポジウム　タスクフォース）と言うPKI業界では有名な弁護士の牧野先生が主催されている団体で、昨日「電子署名電子認証シンポジウム　第９回」が行われたので参加して来ました。

私の場合は技術的な側面からPKIの関わっている（それも新参者ですし隅っこの方に関わっている）訳ですが、今回のシンポジウムは当然ながら法的な面も含めてPKIの普及に関係する情報がメインです。会場に入って見回すとPKI業界の認証局からベンダーまでそうそうたる顔ぶれが並んでいます。私は会員でも無いので一番端っこでおとなしく見学です。J社のMさんにだけはご挨拶をしましたが(^^;

主な内容は電子認証局会議と言うやはり牧野先生が中心になって特定認証局が集まった団体が作成した「電子署名活用ガイド」の内容説明が中心です。この「電子署名活用ガイド」は経営者の方にも見て貰えるようにと作成されており、法的な話やシステム例やもちろん技術的な話も簡単にまとめられていて、大変有意義な冊子になっています。ちなみにPDFファイルとしてダウンロードも出来ますのでPKIや電子署名に興味がある方はダウンロードしましょう！特に法的な側面の情報は他では見たことありませんし、システム例もメリット・デメリットがまとめられていて参考になります。SIerの方なら必携ではないでしょうか。ちなみにECOMの長期署名相互運用性テストに合格した長期署名ソフトの一覧も巻末にあり、弊社のLe-XAdESも最後に名前が載ってました。良かった(^o^;;

最後には模擬裁判「やってて良かった電子署名」もありました。弁護士の先生が担当されているので大変参考になりましたし、内容も面白かったです。半日でしたが大変充実した内容でした。しかし業界関係者以外の参加はやや少なかったように感じました。SIerの皆さん等もこういうシンポジウムに参加されると新しいアイデアや市場が見つかるのではないかと思いますがどうでしょう？

４月は色々とシンポジウムや昨年度の発表会等色々イベントが多いです。先週の水曜日には国立情報学研究所で開催された「研究・教育のためのデータ連携ワークショップ(第1回)」にも参加して来ました。こちらは異なる分野間でデータやコンテンツをどう連携して行くかを考えようと言う目的で、第１回と言うこともあり、異分野間での考え方の違いや言葉の違い等の話が中心でこちらも興味深い内容でした。第２回も１１月頃に開きたいと主催の曽根原先生がおっしゃってましたので、興味のある方は参加しましょう！

これからの予定としては昨年も参加した日本ネットワークセキュリティ協会の「PKI Day 2009」が６月２４日（水）に開かれる予定です。こちらもPKIの濃い話題がたっぷり聞けます。今年もマイクロソフトによるサーバ製品のPKI機能についての話も聞けるようです。他ではあまりMS製品のPKI関連の話題は聞けないように思いますので、こちらもお勧めです。

その前には「RSAカンファレンスJAPAN2009」も６月８日～１２日まであります。今年は単独開催では無く、「Interop Tokyo 2009」との併催になるそうです。そのせいか例年は２日間だったのが今年はクラストラックは３日間だったりします。え～そんなに参加する時間が無いよう…値段も事前申し込みの１０％オフでも３日間だと６万７５００円です。さて今年はどうしようかな。でもSHA-3の話題なんかもあるようだし最新情報は確かに入手できるんだよなあ…悩みます(^^;

そうそうXMLコンソーシアムの活動発表の場である「XMLコンソーシアムWeek」が連休明けの５月１２日から開催されます。私も少し発表する予定です。XML署名に関して.NETとJava6の標準機能でどこまで出来るかをまとめる予定です。これの資料作成が私のゴールデンウィーク中の宿題になりそうです。こちらも無料ですのでお暇がありましたらぜひご参加を！そうそうXMLコンソーシアムではXMLを利用したセキュリティ製品調査を行っています。締め切りは実は過ぎているのですがまだ間に合います！XML関連の暗号やPKI等の製品をお持ちでしたらぜひご協力ください！よろしくお願いしますm(_ _)m

2008-05-26に「.NET Framework のRSA署名用ハッシュアルゴリズム」として、WindowsのXP環境で .NET Framework において、RSA署名を使うクラスRSACryptoServiceProviderの検証メソッドVerifyDataがRSA-SHA2の署名に対応していないと書きました。今日別件もあり.NETのXML署名関連を調査していて、確認の為にRSA-SHA2の署名と検証を試したところ問題なく動作していました！以前は例外になった箇所がきちんと動作しています。以下はC#で試したコードです。

　RSACryptoServiceProvider key
　　　　= new RSACryptoServiceProvider(2048);
　Byte[] target = Encoding.UTF8.GetBytes("TEST DATA");
　Byte[] sign = key.SignData(target, "SHA512");
　bool verify = key.VerifyData(target, "SHA512", sign);
　if (verify)
　　Console.WriteLine("RSA-SHA2 Verify: OK : valid.");
　else
　　Console.WriteLine("RSA-SHA2 Verify: NG : faild !!!!!");

う～む何時OKになったんでしょう？少なくとも昨年11月の時点では例外になる事を確認していたのですが… まあいずれにせよRSA-SHA2対応してくれたのはありがたいですね。もう少し調査をして何か分かればまた書きましょう。ちなみに過去の記事も更新しました。

なおXML署名のクラスであるSignedXmlではまだRSA-SHA2署名には対応していないようです。

[2009-05-03 追記]
XMLコンソーシアムWeek向けに調査をしていて、以前ある方からご指摘頂いた現象を確認。実はSignDataメソッドをPKCS#12形式の証明書＋秘密鍵から取得した鍵を使うと例外になると言うものだ。しかも例外は「無効なアルゴリズムが指定されました。」と言うもの。どこかでSHA-2に対応できていないに違いない(^^; 参考までにXP環境で例外になるソースを張っておきます。

　X509Certificate2 cert =
　　　new X509Certificate2("testcert.p12", pkcs12Pswd);;
　RSACryptoServiceProvider key =
　　　(RSACryptoServiceProvider)cert.PrivateKey;
　Byte[] target = Encoding.UTF8.GetBytes("TEST DATA");
　// Exception !!
　Byte[] sign = key.SignData(target, "SHA512");
　bool verify = key.VerifyData(target, "SHA512", sign);
　if (verify)
　　Console.WriteLine("RSA-SHA2 Verify: OK : valid.");
　else
　　Console.WriteLine("RSA-SHA2 Verify: NG : faild !!!!!");

Windowsくらい複雑なシステムになるとアルゴリズムの追加も大変ですね。

昨年弊社が研究のお手伝いをしたNII（国立情報学研究所）の学術ネットワーク研究開発センターで作成された研究資料をご担当の先生のご許可を得て公開します。

　「OpenXML長期署名システム設計書 （概要）」
　「OpenXML長期署名システム設計書 （詳細）」

内容としてはMicrosoft社のMS-Office2007で採用されているOpenXML（ISO 29500 OOXML）のXML署名を、長期署名XAdESに置き換えた場合の調査と、同時にOpenOffice.orgで採用されているODF（ISO 26300 OpenDocument Format）との比較や、XML署名と長期署名XAdESの比較も記載されています。実証用のOpenXML長期署名ツールには弊社のLe-XAdESライブラリが使われています。

調査の結論としては現在のOpenXMLのドキュメントを単純に長期署名化は出来ないことがわかっています。しかしそれがOpenXMLの仕様上許されない為なのかと言う点は微妙とも言えます。そもそもの問題はOpenXMLのXML署名はかなり独自の拡張がされている点にあります。

実はライバル関係であるODFのドキュメントはかなり素直なXML署名の仕様になっているので長期署名化も基本的に問題がありません。弊社でも日本認証サービス様の証明書更新サービスにて、ODF長期署名ツールの開発を行い運用されています。こちらも弊社のLe-XAdESライブラリが使われています。

なお今回公開するドキュメントは昨年既に某団体の会員専用ページにて公開されたものと同じ資料です。OpenXML関係では今年は他にも幾つかご報告が出来る予定ですが先行して公開します。何かの参考になれば幸いです。

ちょっと理由があってCtyptAPI（Win32API）によるRSA署名をする必要がありました。あんまり日本語の情報が無いようなので簡単にまとめておきましょう。まずCtyptAPIによるRSA署名の簡単な手順をまとめます。

　１＞CryptAcquireCertificatePrivateKey() で証明書から秘密鍵取得
　２＞CryptCreateHash() でハッシュ関数の初期化
　３＞CryptHashData() で署名対象のハッシュ計算
　４＞CryptSignHash() を空読みして署名値サイズの取得
　５＞CryptSignHash() 署名の実行
　６＞バイトを反転して署名値を取得
　７＞後始末（CryptDestroyHash()等）

基本的にはこれだけなのですが注意が必要なのは６＞のバイト反転でしょうか。.NETのRSACryptoServiceProvider.SignData メソッドで署名した署名値と、CryptSignHash() で署名した署名値とは、バイト反転させないと同じになりません。これを忘れると当然検証に失敗してしまいますのでご注意を。

もう１つ注意した方が良いのはRSACryptoServiceProvider.SignData メソッドの署名値はハッシュOIDを含んでいる一般的な形式です。CryptSignHash() の４番目の引数 dwFlags は必ずゼロにして何も指定しないようにします。CRYPT_NOHASHOID 等を指定するとハッシュOIDが含まれないので RSACryptoServiceProvider.SignData メソッドと互換性が取れなくなります。

このブログはNucleusを使っていますが、スパムコメントの対策やスパムメッセージの対策としてパスワード（PASSWD）として langedge と入れてもらうようにしていました。で本日の某団体のセキュリティ部会でリーダの方から、

「ラング・エッジさんのこのメールフォームってSSLじゃ無いのにパスワードを入力させているけど大丈夫なの？」

と指摘を受けました。ああ確かに PASSWD と入力フォームを表示していたので一見するとメールアドレスとパスワードの両方を平文サイトで入力させているように見えますね。でもこれって決まった文字列を打つので本当はパスワードじゃ無いんです。と説明して一応納得して頂きました(^^; 気をつかって部会では無く個別にお話を頂いてありがとうございましたm(_ _)m

でも確かに PASSWD と言う表記は相応しくないので スパム対策 に変更しました。なる程ねえこういうのは外部の目で見ないと気がつきにくいかもしれません。ちょっと反省でした。