自堕落な技術者の日記 : デジタルタイムスタンプ

最近、セキュリティに関係したトピックをサボっていてすみません。書きたいと思っているネタは幾つかあるんですが、ナカナカ時間が取れなくて、、、セキュリティ関係のやつはTwitterで紹介して済ませることも多かったので、興味ある方は、よかったら私のTwitterやFriendFeedなんかのつぶやきも見てやってください。

今回は、久しぶりにAdobe CDS(Certified Document Services)について署名、タイムスタンプ、PKI的にニッチな話を書いてみたいと思います。

ここに書いていることは、自分が所属する組織の立場によるものではなく、ウェブなどで公開されている情報から個人的に調べて思ったことを書いただけです。問題があればコメント欄にお願いします。なるべく誠意を持って対処するつもりではいます（＾＾；

Adobe CDSとは何か

PDFにはデジタル署名をつけたり、これを検証したりする機能を持っているが、これを進化（？）させたのがAdobe CDS(Certified Document Services)である。

PDF文書をAcrobat Readerで開いたとき、署名が無い場合には単に文書だけが表示されるが、署名がある場合には署名情報バーが文書の上に表示される。署名検証はプラグイン不要で自動的に行われ、署名結果が正しければバーは水色となり、合わせて以下の情報が表示される：
・署名検証結果
・署名者は誰か
・どの認証局が発行する証明書によるものか

CDSを使うメリットをまとめてみると、こんなとこ、、、

PDF文書ではデジタル署名やデジタルタイムスタンプを付与できるが、CDSの場合は署名やタイムスタンプを検証するために何ら追加のプラグインを必要としない。(従来の署名やタイムスタンプではAcrobat Readerに検証プラグインのインストールが必要なケースがあった。)

プラットフォームに依存せず、WindowsでもLinuxでも同じように検証結果が表示される。(Windowsの証明書ストアなどに依存しない。追加プラグインが無いのでAcrobat Readerさえあれば、プラットフォームも気にする必要がない。)

ルート証明書のインストールをする必要がない。変な認証局が入ってくる心配は(今のところ多分あまり)ない。

Adobe CDSに準じたPDF文書を検証するのにAcrobat Readerの検証設定を何ら変更する必要がなく、デフォルトで正しい検証結果が得られる。

ちなみに、Ubuntu上のAcrobat Readerを使って同じように表示すると、何もアドオンを入れたりルートを追加をしなくても、このように表示される。

Adobe CDSのPKIってどんなの？

Adobe CDSのルートCAは、Windowsのルート証明書ストアや、他のルートストアとは一切関係なく、専用のAdobe Trust Services Root CAのみを信頼点としている。このルートCAは他のデフォルトの信頼リストに含まれていることはない。そのルートの下位には、幾つかの商用証明書発行サービスのサブCAがあって、
・個人
・組織に属する個人
・組織
に対してAdobe CDS署名用の証明書を発行している。

現在対応している証明書発行サービスは5つあり、対応しているサービスはこのAdobe社のページで公開されている。

Adobe CDSの署名者用証明書には、署名用証明書を見たり、証明書発行サービスの説明を見てみると以下のような特徴があるようだ。

・秘密鍵はUSBトークンかHSMに格納される事が要件になっているよう
・拡張鍵使用法にはAcrobat認証文書(1.2.840.113583.1.1.5)を指定
・失効検証にOCSP利用可能
・証明書ポリシはAdobe CDS用ポリシ(1.2.840.113583.1.2.1)を指定
・デジタルタイムスタンプが利用可能でタイムスタンプサービスのURLが記載される

CDSに共通の証明書ポリシ(CP)は以下で公開されている。
・Adobe Systems Incorporated CDS Certificate Policy October 2005 Revision #14 (PDF)

下位CAやエンドエンティティ証明書は、発行会社の異なる証明書であっても、全て同じ証明書ポリシ拡張のOID、Adobe CDS証明書ポリシが設定されている。

CDS用証明書が一般の証明書とは違う大きな特徴として、どの認証サービスから発行される署名者用のエンドエンティティ証明書にも、これまで見たことがないプライベート拡張が含まれている。

・1.2.840.113583.1.1.9.1
・1.2.840.113583.1.1.9.2

Adobeで公開されている証明書ポリシ(CP)にも説明が無く、これらのASN.1シンタックスについても公開されている文書が無いようだが、それぞれ、どうやら

・1.2.840.113583.1.1.9.1 (TSA局に関する情報)
・1.2.840.113583.1.1.9.2 (アーカイブバージョン情報もしくはOCSP検証に関する属性)

の情報を持たせているようだ。タイムスタンプに関する証明書拡張は次のようなASN.1構造になっている。

SEQUENCE {
　OBJECT IDENTIFIER '1 2 840 113583 1 1 9 1'
　OCTET STRING, encapsulates {
　　　SEQUENCE {
　　　　INTEGER タイムスタンプサービスの属性
　　　　[6]
　　　　　'認証サービスの持つタイムスタンプサービスのURL'
　　　　}
　　　}
　}

タイムスタンプ属性に関しては、フラグを意味するものらしく、値が1のとき、Acrobat Readerで見ると「認証=必須」という意味を持っているらしい。

もう一つのプライベート拡張についてはウェブなどで検索してみるとOCSP検証を行うかどうかのフラグのようなものらしいが正確な情報は何ら得られていない。Acrobat Readerで参照すると「アーカイブバージョン情報」に相当するように思われるが、この値が何を意味するかについては何も情報がない。

SEQUENCE {
　OBJECT IDENTIFIER '1 2 840 113583 1 1 9 2'
　OCTET STRING, encapsulates {
　　　SEQUENCE {
　　　　INTEGER 1
　　　　}
　　　}
　}

CRLの発行周期はどうか

全てのエンドエンティティ証明書、サブCA証明書はOCSPで検証できるようになっているが、PDF長期署名(PAdES)などのことを考えるとCRLの発行周期は気になるところである。調べたところ以下であった。

・RootCA - 1年
・SubCA(A社) - 7日
・SubCA(B社) - 7日
・SubCA(C社) - 7日
・SubCA(D社) - 7日
・SubCA(E社) - 1日

多くのサブCAが7日周期を採用していた。システム設計上、長期署名検証の猶予期間(Grace Period)に配慮する必要がある場合にはCRL発行周期に留意しなければならない。

ちなみにAdobe CDSのCPを見るとCRLについて
・X.509 V2 CRLでなければならない
・AuthorityKeyIdentifierとCRLNumberの拡張を持たなければならない
とあるが、これに準拠しないサブCAもあるようだ。

Adobe CDSのタイムスタンプ

Adobe CDS用の証明書発行サービスでは、OCSPサーバーの他にRFC 3161に基づくタイムスタンプサービスを運営することを求めらているようだ。

タイムスタンプサーバー用のタイムスタンプ局(TSA)証明書は各認証サービスのサブCAから発行されている。

各認証サービスが発行する署名者証明書のプロファイルは認証サービスの公開するCPS(認証実施規定)で規定されているようだが、同じサブCAが発行するTSA証明書やOCSPレスポンダ証明書については、どの認証サービスも記述していないようだ。

タイムスタンププロトコルについては、4社がRFC 3161方式を採用しているが、1社だけOASIS DSS(Digital Signature Service)を採用しているように見える。(その1社の発行するトークンもRFC 3161型のトークンである。)

公開されているPDF署名文書からタイムスタンプトークンのプロファイルを比較してみた。まとめると以下のような特徴があった。

タイムスタンプ局ポリシーOID: (実際はどのようなタイムスタンプポリシーで運用しているかは疑わしいものもあるが)きちんとタイムスタンプサービスの自前のポリシーOIDを付与しているものもあれば、Adobe CDSの証明書ポリシOIDを記載している所や、とてもそのサービスが維持権限を持っているとは思われないポリシーOIDを(恐らく勝手に)使用している所もあった。ちなみに、Adobe CDSの証明書ポリシにはタイムスタンプトークンやTSTInfoのプロファイルの記述は無い。従ってCDS証明書ポリシーOIDをTSAポリシーOIDとして記載することは適切でないように思う。
messageImprint(PDFのタイムスタンプ対象部分のハッシュ値): 全てSHA1アルゴリズムを使用している。
genTime: マイクロ秒単位から秒単位までと幅がある。
accuracy(時刻精度): フィールドが無いもの、500ミリ秒、1秒のものがある。中には60秒というものもある。
ordering(順序保証): 有るもの、無いもの様々である。60秒でordering=trueであったり、マイクロ秒単位のgenTimeで1秒のaccuracyでordering=falseであるケースなど結構扱いに困るケースがあると思う。
nonce: 全てのサービスで本フィールドがある。
tsa(TSAの名称(GeneralName)): サービスにより有ったりなかったり。
時刻監査証(TAC): 1つのサービスだけ、時刻監査証(TAC)を含んだトークンを発行するサービスがあった。TACとは、時刻配信局(TA)から見たTSAの装置との時差予測を時刻監査証は上位との時刻のずれの予測をX.509属性証明書の形式でTAより発行するものである。TACに関する課題は、ここ何年か幾つかの場所でコメントさせて頂く機会があったが、これを盛り込んで日本データ通信協会(デ協)でまとめたものが近日公開される予定だそうなので、また別の機会に紹介させて頂こうと思う。この課題およびコンセンサス抜きにはTACを使用することはあまり適切でないように思う。デ協で議論されたのと同じ問題が含まれるTACには見受けられた。(今回の調査で、また別の属性値の問題も見つけてしまった(T_T))

署名者の認証については、どの認証サービスもセキュアな署名デバイスを必須とするなど厳密になっているが、タイムスタンプについてはあまりのサービスのバラつきに愕然としてしまった。

どのCDS用認証サービスのページからも正しくタイムスタンプポリシーの記述を辿れるようなサービスは見当たらなかった(1社は日本のタイムスタンプ局なので知っている人は辿ることができるかもしれない)。Adobe CDSで使われている多くのタイムスタンプサービスはどのような時刻源、もしくは時刻配信局(TA)に基づいてタイムスタンプを発行しているか知ることはできないし、どのような運用をしているのか、例えば運用するTSAと協定世界時(UTC)との時刻差からどれだけ離れたら正しくタイムスタンプサービスを停止するかなど一切知ることはできない。(検索すれば間接的に情報を入手できるところもある。)

タイムスタンプポリシーについては以下の規格がある。
・ETSI TS 102 023, V1.2.1 (2003-01), Policy Requirements for time-stamping authorities
・RFC 3628 Policy Requirements for Time-Stamping Authorities (TSAs) (Informational)
これらに基づいたタイムスタンプポリシーもしくはRFC 3628の付録にあるModel TSA Disclosure Statement Structureに準じて書かれたタイムスタンプ局開示規定が無ければ利用者はこのタイムスタンプトークンを信じてよいのかどうか判断が付かない。

IETF PKIX WGやETSI TC ESIでは、RFC 3161の改訂の議論が一時期盛り上がりそうになったが、結局本体は改訂されないことが決定した。現行のタイムスタンプトークンのフォーマットで大変残念に思うのは、タイムスタンプポリシーを記述したドキュメントやホームページへのURLを記載する正式な場所が無いことである。タイムスタンプポリシーのOIDからタイムスタンプポリシーのドキュメントが(運が良ければ)見つかることがあるかもしれないが、今回のAdobe CDSのように怪しいポリシーOIDが記載されている場合には、ほぼ不可能である。

ISOのタイムスタンプの標準によりタイムスタンプトークンの拡張領域も使うことはできそうにないので、例えば、タイムスタンプ局の名前を表すtSTInfoのtsaフィールドのGeneralNameの値にタイムスタンプポリシを示すURLの記載を必須とするような要件を追加するべきだと思っている。

詰まる所、Adobe CDSのタイムスタンプサービスの多くは、どれもにわかには信じがたいというのが率直な印象である。

もう一点だけ、TSA証明書のほとんどは鍵使用法拡張の値はDigiatal SignatureとNon-Repudiationのビットの両方が立っているが、1社だけNon-Repudiationのビットのみしか立っていないものがあった。以前にもこのブログで述べたようにJava JCEで実装された検証器の場合、障害となるかもしれない[参照1][参照2]。

署名回数の制限の謎

5つある証明書発行サービスを比較してみると、年に500回まで等、署名の回数に制限を設けているサービスが多い。これは、どうのような仕組みで実現されているのかとても興味が有るところだ。例えば

・利用者との紳士協定である。とか、
・配布するUSBトークンで署名回数の制限を設けている。とか、
・タイムスタンプトークンの発行回数で制限を設けている。とか、

回数制限がある場合に極端に安いとかいうこともあまり無いようなので、個人的には回数制限の無いタイプの方が使い勝手が良いような気もしているが、どうだろうか。

以上、今回は長々とAdobe AcrobatのAdobe CDSというフレームワークについて調べた事、思った事を述べさせて頂いた。

今回もニッチな話ですみませんｍ（＿　＿）ｍ