自堕落な技術者の日記

PDF署名の利用拡大につながると、密かに期待していた、とても先進的な サービスだったAdobe CDSが、いよいよサービスを終了し、AATL (Adobe Approved Trust List)に移行すると知りました。まぁ、移行とは言えず、いろいろなものを捨て去っているわけですが、、、かつて自分も人柱としてAdobe CDS対応の証明書とトークンを購入し、使ってみたりもし、幾つかブログで書かせてもらい、良いサービスだったのですがとても残念です。悲しすぎるので追悼記事のようなもの書いてみたいと思います。

Adobe CDSとは何か

Adobe Acrobat には誰が署名をしたか、それが改ざんされていないかを示すためのPDF署名機能があり、Adobe Acrobat ReaderにはPDF署名の検証機能がついています。PDF署名の運用を厳格化し、Adobe Acrobat Readerのデフォルトであっても、ちゃんと本人確認をした証明書とハードウェアデバイスをつかって署名したPDF署名が検証できるようにするサービスがAdobe CDSでした。Adobe CDSには

• HSMを使った組織によるサーバー向けPDF署名
• USBトークンを使った個人によるPDF署名

の2種類に対応していました。ただのPDF署名とはどう違うのか、比較表にまとめてみました。

一般的なPDF署名	Adobe CDS PDF署名
証明書発行の際、本人確認をしようがしまいが構わない	証明書発行の本人確認はかなり厳格。例えば、パスポートのコピー、メールアドレスの送付と電話による(英語での)本人の意思確認など
秘密鍵の管理はなんでもよい	秘密鍵は必ずサーバー型ならHSM、個人型ならUSBトークンに格納され、エクスポート不可。(スマートカード対応の認証ベンダーはなかったはず。)
証明書はデジタル署名が可能ならなんでも良い。例えば、SSLサーバー証明書と秘密鍵でもよい	Adobe CDS署名専用の証明書であり、拡張領域に専用の拡張がある。証明書ポリシもCDS対応のものでないとAdobe CDSに登録できるCAとはならない。
PAdESタイムスタンプつきPDF署名である必要はなく、普通のPDF署名でもよい	署名するとPAdES署名タイムスタンプ付きのPDF署名となる
タイムスタンプをつけようとする場合、日本では一般に別途、タイムスタンプ事業者との利用契約が必要	Adobe CDS対応の認証局では、証明書を購入すればタイムスタンプサービスが合わせて提供される。Adobe CDSでは、認証サービスごとに、どのタイムスタンプサービスを使用するかが、証明書拡張に記載されており、固定である。認証サービス自体がタイムスタンプサービスを提供しているケースが多い。
信頼するルート証明書のリストはAdobe独自のものだった。この度これが、Adobe Approved Trust List(AATL)というルート証明書プログラムとして定義され、現時点で58のルート証明書が登録されている。WindowsやMac OS Xなどのルート証明書の数は400程度とこれよりかなり多いが、OSの持つルート証明書はAcrobat Readerのデフォルトでは信頼しておらず、これを信頼するようにするには設定変更の必要がある。	Adobe CDSのルート認証局はAdobeのルート一つであり、中間認証局としてAdobe CDS対応の認証ベンダー6つ程度があり、そこからユーザ用の証明書が発行される。Adobe CDS用の専用の運用ポリシ(CP/CPS)で運用されている。どのようなOSのAcrobat ReaderでもOSのトラストリストに関係なく同じ検証結果となる

Adobe CDSサービスのポイントは以下のようになると思います。

• 確かに本人が署名したと見なせる印鑑で言えば実印レベルのPDF署名ができる
• (最近いろんな認証局が問題起こしていますが)運用のしっかりしていない認証局が紛れ込む可能性が比較的低い(けど、この中にも問題起こしたところありましたよね)
• Adobe CDS専用の証明書で署名する
• 電子署名では、証明書が有効だった時刻に署名されたことを示すために、タイムスタンプが必須とされるが、Adobe CDSではデフォルトで署名タイムスタンプつきPDF署名となる
• USBトークンなどのハードウェアデバイスを持っているはずの本人署名できず、他人がなりすまして署名をされる可能性は極めて低い

Adobe CDSのナイスなところ

タイムスタンプ付きPDF署名をしようとした場合に、日本では一般に署名用のクライアント証明書と、タイムスタンプサービスの利用がそれぞれ必要になります。これって、それぞれお金がかかるし、煩わしいですよね。日本でタイムスタンプ付き署名が流行らない理由の一つなのではとも思ってたりもします。海外の署名用証明書発行サービスでは、タイムスタンプサービスとセットで提供するものが多いですし、Adobe CDSもセット提供で、とても使いやすいです。

コード署名用証明書なんかも、RFC 3161タイムスタンプとは違いますが、似たようなカウンタ署名によるタイムスタンプの仕組みがセットで提供されるので、デフォルトでコード署名にはタイムスタンプがつきます。

Adobe CDSの何がいけなかったのか

Adobe CDSを使っているかどうかで、PDF署名に対する信頼の度合いは全く異なると思うのですが、Acrobat Readerでは、普通のPDF署名とAdobe CDS PDF署名との違いはありません。違いもないのなら、高いお金を払ってまでAdobe CDSを使うメリットも薄いですよね。

また、認証局にとっても、独立した中間CAを運用しなければならない。特別な証明書プロファイルも必要で、認証局にとってもとても負担となるプログラムだったと思います。相当利用が伸びないとサービスを維持するのは難しいと思います。

Adobe CDSのようにUSBトークンを使ったり、マイナンバーカードのようにスマートカードを使ったり、ハードウェアデバイスを使用して、厳格な本人確認のもと発行された証明書に関しては、共通の専用の証明書拡張を持たせるようにし、普通の署名とは区別し、EV証明書の緑のアドレスバーのような表示上の区別をしないと、ハードウェアデバイスを使った署名がなかなか普及しないのかなとも思います。

最近では、クラウド上で秘密鍵の管理をし、リモートで署名を行うような運用形態も増えており、ハードデバイスを本人が管理して署名するというのは、だんだん時代にも合わなくなってきたのかもしれません。

おわりに

Adobe CDSは、維持費用も結構かかるので、結局持ち続けることはできませんでしたが、「実印レベルのちゃんとした」PDF署名であるAdobe CDSは、なくなって欲しくはなかったです。ホントさびしい。バイバイ Adobe CDS。

関連記事

• AcrobatのAdobe CDSについて書いてみる (2009.11.15)
• dumpasn1用のAdobe CDS関連の設定の追加 (2009.11.22)
• Adobe eSignaturesを試してみたんですが、、、 (2010.05.17)
• Adobe CDSについて書いてみた(その2) (2010.06.27)
• 連載:PAdES(PDF長期署名)について(第1回) (2009.11.21)
• 連載:PAdES(PDF長期署名)について(第2回) PDF署名とは (2009.11.27)
• 連載:PAdES(PDF長期署名)について(第3回) PAdES仕様の構成 (2009.12.11)
• 連載:PAdES(PDF長期署名)について(第4回) PAdES Basic (2010.01.17)
• 連載:PAdES(PDF長期署名)について(第5回) PAdES Basicと署名ポリシ (2010.01.18)

Adobe Acrobatで使うと便利な証明書とタイムスタンプサービスのセットである Adobe CDSに関する前回の記事を書いてから半年すこし立ちましたが、それまで5つあった証明書発行サービスがもう一つ増えて6つになっていました。 今日はちょっと補足情報を書いてみようと思います。

Adobe CDSサービスの価格比較

Adobe CDS対応の証明書発行サービスには、個人向けと企業(組織)向けがありまして、 発行サービスによって署名可能回数が無制限のものや回数制限を設けているものがあります。 以前、自腹で証明書買おうと思って、最初にあった国内1社を含む6社で価格を比較したメモを作っていました。 これに、新たに加わった1社を入れて表にまとめてみました。

結構価格差ありますよね。購入の際の参考にしてみてください。 個人的には署名回数に制限無いものの方が、心置きなくテストで使えるのでいいかなとも思うんですが、 たまにしか使わない個人の人ならTC TrustCenterの500署名2万円弱/年っていうのでも十分なのかもしれません。

署名回数制限の方法について想像してみる

証明書発行サービスによっては署名回数に上限を設けて価格設定している所があります。この署名回数の制限をどのように行うのか、上限を超えると本当にできなくなるのか、単なる紳士協定なのか、システムエラーなどで失敗した場合に回数のカウントはどうなるのかずっと疑問に思っていました。以下のようなこともあって署名回数のカウント方法がよくわからなかったのです。

• USBトークン自体には秘密鍵を使用する回数に制限を設けられているといった話を聞いたことがない。
• Adobe CDSで使用するタイムスタンプサービスはどこも認証無であるし、Adobe Acrobatで タイムスタンプサービスの認証設定の画面などは無い。

署名回数制限があるサービスの中で、タイムスタンプ署名の回数として制限をしているところがありました。Adobe CDS署名に使われた証明書にはスタンプサービスのURLが拡張領域に書かれていますがそれを見てみると

http://TSPのホスト/TSPアプリ/乱数のような長い値

となっていました。おそらくこのURL中の乱数のような長い値を以てユーザの認証をしているのかな、と思いました。

タイムスタンプURLによる認証の問題

タイムスタンプ要求の差異のURLへのアクセスにより認証していて、その回数がAdobe CDSの署名回数と同等だったとすると少し困った問題が起きると思います。

• タイムスタンプ付き署名されたPDF文書はコピーされて不特定多数に渡ったりするので、渡した先は必ずしも悪い事をしない人とは限りません。
• Adobe CDSのPDF署名文書から、この署名に利用したタイムスタンプサービスのURLは誰でも知る事ができます。署名者の証明書に記載されています。
• 記載されているタイムスタンプサービスは特にIDパスワードなどの認証も無いので、URLさえ知っていればアクセスすることができます。接続元IPなどを制限している風でもありません。
• すると、Adobe CDS署名されたPDF文書を受け取った誰か意地悪な人が何人かいたとして、署名に回数制限があるサービスだったとすると、そのURL誰かが何回もアクセスして、Adobe CDSの証明書を持っている人(サブスクライバ)の残り署名可能回数を0にしてしまう事ができるかもしれません。

どんな運用になってるのかは、開示されている情報も無いのでよくわかりませんが、実際のところどうなんでしょうね。自分のやつは回数制限の無いタイプにしたので、とりあえずこんな不安は無くて良かったなぁと思います。

ではでは、今朝はこんなところで。

関連記事

• 2009.11.15 AcrobatのAdobe CDSについて書いてみる
• 2009.11.22 dumpasn1用のAdobe CDS関連の設定の追加

前にAdobe CDSのPDF署名について書きましたが、証明書や署名データなどをdumpasn1というASN.1ダンプツールで表示させると不明の(説明されない)OID(オブジェクト識別子)のように表示されてしまいます。

オフィシャルなものでもありませんが、とりあえず dumpasn1.cfg ファイルに以下を追加してみました。

# Adobe

OID = 06 09 2A 86 48 86 F7 2F 01 01 08
Comment = Adobe AdobeRevocationInfoArchival CMS attribute for PDF
Description = adobeRevocationInfoArchival (1 2 840 113 583 1 1 8)

OID = 06 0A 2A 86 48 86 F7 2F 01 01 09 01
Comment = Adobe CDS timestamp information extension (unofficial name)
Description = adobeCDSTimeStampInfo (1 2 840 113583 1 1 9 1)

OID = 06 0A 2A 86 48 86 F7 2F 01 01 09 02
Comment = Adobe CDS certificate verification information extension (unofficial name)
Description = adobeCDSCertVerifyInfo (1 2 840 113583 1 1 9 2)

OID = 06 09 2A 86 48 86 F7 2F 01 02 01
Comment = Adobe CDS certificate policy
Description = adobeCDSCertificatePolicy (1 2 840 113583 1 2 1)

これを入れておけば、Adobe CDS証明書やPDF署名のPKCS#7署名データを見たときに役に立つかもしれません。

adobeCDSTimeStampInfo、adobeCDSCertVerifyInfoについては正しい名称がわからないし、公開されないままなので、とりあえずで付けています。また何か情報得られたら、こちらで紹介したいと思います。

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

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