自堕落な技術者の日記

つい先日、MさんのTLで中国のタイムスタンプサービスのURLがあって、面白そうだからいろいろ調べてみました。UniTrust Time Stamp Authority(http://www.tsa.cn/)というのだそうです。

タイムスタンプサービスとは

例えば何か発明した時に、自分の発明の方が先だったとかテキストメモで書いたりしたとしても、パソコンの時間は自由に変更できますし、テキストメモの内容だって自由に変更できちゃいますから証明するの難しいですよね。そんな時、タイムスタンプサービスが発行してくれるデジタルタイムスタンプ使うと「ある時点にそのデータが存在してて、それ以降変更されてないこと」を証明することができます。

デジタル署名も証明書が有効だった「時」に署名された事がわからないと困るので、特にデータを保管する際には「デジタル署名にはデジタルタイムスタンプをつけましょう」というのが定石になっています。

日本ではタイムスタンプサービスをタイムビジネス協議会が普及促進をしていて、米国、欧州、アジアの幾つかの国でもこのようなサービスが始まっています。

で、tsa.cnはどうなの？

中国語は全く読めないんですが、

• 画像やデータをスマホからアップしてタイムスタンプをつけたりするAndroidアプリも充実
• Windows用デスクトップアプリも提供
• タイムスタンプつき文書をオンラインで検証できるページもある
• 値段は1タイムスタンプ10元(160円)?

となかなかサービスは充実しているようです。

タイムスタンプの取得方法ですが、http://timestamp.tsa.cn/tsa がRFC 3161 over HTTPで取得するためのURLになっているようでBasic認証で取得するみたいです。 Basic認証なのにHTTPSじゃなくていいのかな？tsa.cnではHTTPSのページは一切無いように見えます。

マニュアルなどのドキュメントは署名タイムスタンプつきPDF署名(PAdES-Tフォーマット)になっているようで 署名やタイムスタンプや証明書などを取り出して見てみました。

興味深いところはこんなとこです。

• タイムスタンプトークンについて
  • タイムスタンプ局のポリシが公開されていないようだ
  • トークンのTSA Policyは1.3.6.1.4.1.8291.1.1になっており米国Digistamp社の OIDになっている。OEMかもしれないし、単にOIDをパクってきただけなのかもしれない。
  • genTimeはミリ秒まで対応している
  • ordering=True
  • トークンへの署名アルゴリズムはSHA1withRSA
  • トークンのCMS SignedDataにはSigningTime属性が入っている。tSTInfoに時刻が含まれるのでSigningTimeは含めない方がよい
• TSA証明書について
  • ルートは"O=China Time-Stamp Authority, CN=China TSA Root"、2048bit RSA、SHA1withRSA
  • TSA証明書は"O=China Time-Stamp Authority, CN=China TSA"、2048bit RSA、SHA1withRSA
  • TSA署名書にはCRLDP拡張が無い
• PDF署名に使った署名者用証明書について
  • これは面白いところが満載
  • シリアル番号が負の値になっている。(RFC 5280的にNG)
  • 自己署名証明書
  • DNはCN=UniTrust, O=beijing unitrust, OU=, E=unitrust@unitrust.com.cn, C=<无
  • CNがUTF8の中国語になっている。本来なら"CN=cn" (RFC 5280的にNG)
  • OUの値が長さ0 (RFC 5280的にNG)
  • 不明の拡張がある1.2.840.113583.1.1.10。これ自体はAdobe社のOID
  • 普通はこのような証明書は発行できないので、独自のエンコーダーを使った CAアプリがあるのではと想像する。

アカウントを取っていろいろ調べて見ようともしているんですが、 アカウントの取り方がわかりそうになく断念してしまいました。今日はこの辺で。

最近、セキュリティに関係したトピックをサボっていてすみません。書きたいと思っているネタは幾つかあるんですが、ナカナカ時間が取れなくて、、、セキュリティ関係のやつは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というフレームワークについて調べた事、思った事を述べさせて頂いた。

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

11月25日、26日にスペイン・ビルバオ(Bilbao)で行われた欧州電子通信規格協会(ETSI)電子署名基盤技術委員会(TC ESI)の資料を見ていたら、これまでESIで議論していたRFC 3161の問題点に対する改訂のドラフトについてPinkasさんが3161の主エディタとしてIETF 73回ミネアポリス会議で発表したことを報告していたみたいです。

スライド資料「RFC 3161 bis Time Stamp Protocol, Denis Pinkas, Nov 2008」

変更の主要ポイントは以下、、、

・現行のESSCertIDはSHA1だけなので汎用のESSCertIDv2を使えるようにする
・Time Stamping Service(TSS)という用語を新たに定義しTime Stamping Authority(TSA)と区別させる
　(複数TSUとTSSの関係)
・ASN.1 モジュールの更新
・米Suretyの特許(#7,047,404)に関する記述
　(ETSI ES 201 733 が先に2000年に公開されている)
・ISOのタイムスタンプ(ISO 18014)の参照の追加

ESSCertIDv2については、SHA2などのために元々CAdESでETSI定義のOtherCertIDを使おうとしていたのを、ESSCertIDv2を使うように変更するようECOMからESIに提言しました。これを受けRFC 3161についてもハッシュ危殆化の問題からESSCertIDv2を使えるようにすべきだとESI副議長がコメントしていたことに対する修正となります。Surety特許問題もECOMからＫさんがESIにインプットしてくれたものです。

RFC 2634のESSCertIDだとSHA1しか使えなかったのが

ESSCertID ::=  SEQUENCE {

     certHash                 Hash,

     issuerSerial             IssuerSerial OPTIONAL }

Hash ::= OCTET STRING -- SHA1 hash of entire certificate

RFC2634 5.4.1節より

RFC 5035では任意のハッシュアルゴリズムが使えデフォルトではSHA-256となります。

ESSCertIDv2 ::=  SEQUENCE {

    hashAlgorithm           AlgorithmIdentifier

           DEFAULT {algorithm id-sha256},

    certHash                 Hash,

    issuerSerial             IssuerSerial OPTIONAL }

Hash ::= OCTET STRING

RFC5035 5.4.1.1節より

日本の時刻認証局も様々な箇所でハッシュ危殆化対応のために既にSHA2へ移行していますが、ESSCertIDだけは仕様に縛られるため移行できず片手落ちみたいなところがあったかと思うのですが、RFC 3161 bisが出てくればこの部分も含め完全な移行が完了できるのではと期待しています。

今週あるデ協のTA-WGでも報告できるように資料作っておこう、、、、、

ちなみに、スペインのビルバオですがＭさんによれば、元々鉄鋼の町だったものを新しい工場団地を誘致しているような所で基本的には観光するようなところでは無いとの事でした。ピッツバーグやデトロイトに行くようなもんなんですかね、、、、、

＜追記＞
TSP over HTTPの際のMIME Typeについて不整合があったはずなので、これもインプットしておかないといけません。