自堕落な技術者の日記

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)

先日のブログ「Windowsルート証明書の更新プログラム(2014.09)と戯言など」で、

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね？と某木村大先生からご指摘いただきました。

実際に試してみたので、ちょっと書いてみたいと思います。

ルート証明書アップデーターからSSTの取り出し

Windows 7以降のオフライン環境で、信頼するルート認証機関のリストをアップデートするのにアップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exeがあるというので、早速ダウンロードしてみます。wgetでヘッダ見てみると最終更新は"Wed, 12 Nov 2014 17:33:07 GMT"になっているので、最新のアップデートには対応してそうかな？とも思ったんですが、後に最新のルート更新には対応してなかったことがわかりますorz

これはCAB形式自己解凍アーカイブみたいになっているので、exe2cab(Vectorのは64bitでは動作せず)を使って中身のcabファイルを取り出します。

cabファイルの中はこんな感じ。

ADVPACK.DLL
authroots.sst - ルートのスモールセット？
delroots.sst - 削除するルート
roots.sst - 最小限の2つのルート
rootsupd.inf -
updroots.exe - ルートを更新するプログラム
updroots.sst - 追加される多くのルート

cabファイルのタイムスタンプ見てみたら、2013年4月になっているので、どうも直近の2014年9月の更新に対応したアップデートファイルでは無さそうな雰囲気です。

SSTファイルからのルート証明書の取り出し

*.sstファイルはMicrosoft Serialized Certificate Filesというフォーマットらしく、前にも力技で証明書取り出すスクリプトを書いた記憶があるんですがorz、ちょっと調べてみたらPowerShellのExport-CertificateやImport-Certificateで操作できそうな雰囲気。サンプルにはSSTに証明書を追加する例なんかも紹介されていました。ところが、どうもSSTから証明書を取り出す方法がよくわからずに結局断念。

もうちょっと調べてみるとSSTの中の個々の証明書エントリはSerializedCertificateEntryという構造になっているらしく、SSTのヘッダ情報のあとはこの並びになっているので、Perlでちゃちゃっと抜き出すスクリプトを書きました。

id - 4byte 0x00000020
encodingType - 4byte 0x00000001 (= ASN.1 encoding)
length - 4byte 続く証明書データの長さ
certificate - 可変長 証明書生データ

取り出せた証明書の数はこんな感じ、2014年9月のルートの更新では411だそうですから、かなり少なめ。古い情報っぽくてちょっと萎え気味。

SSTファイル	ルート証明書数
authroots.sst	77
roots.sst	6
updroots.sst	275
計	358

で、ぽちぽちルート証明書を開いてみる

とまぁ、ルート証明書の取り出しはできたので、これをそれぞれ開いてみると 「インターネットオプション＞コンテンツ＞証明書＞信頼されたルート認証機関」に 未表示のものだったら、表示されるようになります。

Windows 8.1 Proの最新パッチ済の環境で、358のうち、有効期限切れになっているものや、すでにMicrosoftが登録削除しているものもあるようで、最終的には271個のルート認証機関がちゃんと表示されるようになりました。これの作業前は確か27だったので、大躍進という感じではあります。

(TURKTRUSTが表示されていることに他意はありません（＾＾；

おわりに

いや〜〜、隠し球っぽくて気持ち悪かったのが、表示されて随分すっきりしますね〜〜。ただ、

やっと271は表示されたが411まではまだ遠い

私はビックリマンチョコ世代ではないですが、仮面ライダースナックとか集めましたね〜〜。ソシャゲーのコンプガチャみたいんなもんなんですかね〜〜。最後までちゃんと表示させたくなりますよね〜〜〜。 411まではまだ道のりは遠い感じですねぇ。やっぱり、Certificate Transparencyのデータに手をつけないといかんかなぁ、、、と思っているところです。

今日は、この辺で、、、

関連記事

• Windows信頼するルート認証機関コンプへの道(第一回) (2015.05.10)
• Windowsルート証明書の更新プログラム(2014.09)と戯言など (2015.05.03)
• Windowsルート証明書の更新プログラム(2010.08)
• Windowsルート証明書の更新プログラム(2010.05)
• Windowsルート証明書の更新プログラム(2009.11)
• Windowsルート証明書の更新プログラム(2009.09)の続き
• Windowsルート証明書の更新プログラム(2009.09)
• Windowsルート証明書の更新プログラム(2009.02)
• Windows95の信頼するルート認証機関(2008.11.28)

2015年5月7日に「RFC 7525 TLSとDTLSの安全な利用に関する推奨事項(Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS))」が公開されました。

昨年あたり、SSL/TLSで使われる暗号アルゴリズム、プロトコルや実装にいろいろな問題が見つかり、製品をそのままデフォルトで使っているとロクなことが無いわけですが、どんなことに注意しながら実装や設定をしなければならないかをベストカレントプラクティス(現時点での最良の慣行)としてまとめたRFCだそうです。

最近、SSL/TLSの設定ネタでお話しする機会を頂いたりしておりますが [1] [2] 、RFC 7525をざっと見たところ、概ね違ったことは言ってないようにおもいます。今日は、RFC 7525について、ちょっと見てみたところを書いていきたいと思います。

RFC 7525の目的

RFC 7525の目的は、仕様から以下の2つなのかなと思います。

• 最低限満たすべき推奨事項を示す。
• TLS 1.3が普及するまでのつなぎで対応しておくべき事を示す。

RFC 7525のポイント

各節から拾ってきたRFC 7525のポイントをまとめると以下のようになります。

• 3.1.1節 TLSプロトコル
  • POODLE等の対策として、SSLv2、SSLv3の利用禁止(MUST NOT)
  • CBCモード対策としてTLS 1.0の利用抑制(SHOULD NOT)
  • TLS 1.2の実装必須(MUST)
  • TLS 1.2、TLS 1.1、TLS 1.0の順で優先(MUST)
• 3.1.2節 DTLSプロトコル
  • DTLS 1.0の利用抑制(SHOULD NOT)
  • DTLS 1.2の実装必須(MUST)
  • DTLS 1.2、DTLS 1.0の順で優先(MUST)
• プロトコルその他
  • 3.1.3節 TLS 1.x からSSLv2、SSLv3のフォールバック禁止(MUST NOT)
  • 3.2節 HSTS(HTTP Strict Transport Security)ヘッダのサポート必須(MUST)
  • 3.3節 CRIME攻撃等の回避のためTLS圧縮を利用抑止(SHOULD)
  • 3.4節 セッション再開でセッションチケットの通信における認証と暗号化は必須(MUST)
  • 3.5節 TLS再ネゴシエーションが必要な場合、renegotiation_info拡張のサポート必須(MUST)
  • 3.6節 Server Name Indication(SNI)のサポート必須(MUST)
  • 4.5節 Truncated HMAC TLS拡張の利用禁止(MUST NOT)
  • 6.5節 証明書失効検証では、OCSP、status_request・status_request_v2 TLS拡張、OCSP stapling拡張を利用すべき(SHOULD)
• 4節 暗号スイートの推奨
  • NULL暗号スイートでの接続禁止(MUST NOT)
  • RC4暗号スイートでの接続禁止(MUST NOT)
  • EXPORT等、112ビット未満の暗号スイートでの接続禁止(MUST NOT)
  • 128ビット未満の暗号スイートでの接続抑止(SHOULD NOT)
  • TLS_RSA_WITH_*の接続抑制(SHOULD NOT)
  • DHE、ECDHEなどPFSをサポートする暗号スイートの優先接続のサポート(MUST)
  • TLS_{DHE,ECDHE}_RSA_WITH_AES_{128,256}_GCM_SHA{256,384}を推奨(RECOMMENDED)
• 4.3節 公開鍵長
  • DHE鍵交換の場合、DH鍵長は2048bit以上を推奨(RECOMMENDED)
  • ECDH鍵の場合、192bit未満の曲線は利用抑止(SHOULD NOT)
• 4.3節 証明書
  • RSA場合、鍵長2048bit以上の証明書を推奨(RECOMMENDED)
  • 証明書の署名はSHA-256の利用を推奨(RECOMMENDED)

RFC 7525を見て気になった点

気になった点や感想的なものをまとめてみます。

• 最小限の推奨事項といいながら、MUST、SHOULDに従ったとするとかなり厳格な要件で、これに対応できるのは最新のウェブブラウザ、ウェブサーバーのみであり、ちょっと前の組み込み機器、SSLアクセラレーターなどは、これらの要件を満たすことは不可能かなと思います。
• やはり、最新のソフトウェアのみで対応すればよい環境と、後方互換性を必要とする環境とで区別して推奨事項を述べるのがよいのではと思います。
• RSA鍵交換を抑制(SHOULD)する一方で、SEED、IDEA、Camelliaなど言及されないアルゴリズムも多く、これらの扱う際に混乱します。
• PFSやRC4を強調しすぎで、CBCモードは軽視されている。
• 鍵長の話はもう少しシンプルに纏められたのではと思う。文章が整理されておらずわかりにい。
• アプリケーションプロトコル(HTTP, SMTP, IMAP, IRC, XMPP等)の言及はあまり役立たない。
• 証明書要件はRECOMMENDEDと、かなり緩め。

RFC 7525の良かった点

一方、このRFC 7525の良かった点はこんなとこかなと、、、

• 何を根拠(Rationale)としてそのような設定を要求するのかが明らかになっており良い。
• 実装(implementation)と展開(deployment)を分けて書いてあるのはよい。
• Opportunistic Securityについて、単なるフォールバックよりも危険が懸念されることを明確にし、RFC 7525の対象外としたのは良い。
• 証明書失効の課題が整理されたのは良い。
• 特に、プロプライエタリな失効検証がスケールしない点を指摘したのは良い。

おわりに

RFC 7525はベストカレントプラクティスと言いながら、少しトガった要求事項になっていて、最新の環境だけでしか動かない感じです。InternetWeekでお話をした時から、状況もいろいろ変わっていて、現時点での暗号スイート設定のおすすめは、近々書きたいと思っています。あと、メジャーなサーバーでの設定ファイルを作るウェブツールなども作ってしまいたいと思ってるんですが、なかなか先に進まない。

来週の情報セキュリティExpoでは、IPAさんのブースで私も委員として作成に携わらせて頂いた「SSL/TLS暗号設定ガイドライン」の説明もあったりするそうです。このガイドは主にサーバー管理者向けに幾つかのケースに分けてセキュリティ要件を定めて設定例を示したもので、RFC 7525 よりは、より具体的にどうすればよいかがわかるようになっています。最後の委員会が終わったあとも、リクエストがあったので追加原稿はいろいろ出させて頂いたんですが、どうも最終的に、特に暗号スイートの設定について、思った通りのものにはならなかったですね。いろんな意味で後悔しています。

今日はこの辺で

苦節7年(といっても本当は自分の貢献なんか大したこと無いんですがorz)、自分も携わらせて頂いたタイムスタンプに関する日本発のISO/IEC国際標準が、ようやく制定されました。

ISO/IEC 18014-4 Information technology - Security techniques - Time-stamping services - Part 4: Traceability of time sources

マジ、うれしいっす。ちょっと泣きそう。ISO/IEC国際標準を制定するためのプロセスはここに解説があるんですが、本当に長い道のりです。

デジタルタイムスタンプとは

国際標準時って昔はイギリスのグリニッジ天文台の時間を使ってたんだけど、今は幾つかの国の原子時計の時間を比べながら、地球の回転(正しくは公転周期)なんかも考慮しながら協定世界時(UTC)という標準時間を作っています。

パソコンの時間って、NTPとかで自動的に合わせている人も多いけど、無理やり設定することもできますよね。例えば、同じような発明を2人がほぼ同時した時に、パソコンで時間戻して、ワードで発明資料を保存して、「オレの方が先に発明してた〜〜！！ファイルの更新日時見ろ〜〜っ！！」とかね。パソコンの時間って全くあてにならないから、データの存在時刻もあてにならないわけです。

医療、裁判、株取引、銀行業務、特許など、いろんな業務の電子化が進んでいるんですけど、デジタルデータはコピーや変更が簡単という性質があって、そのデータが本物かどうか、本当にその時間にあったかどうかが大切になるんですが、時間を証明するのって難しいんですよね。

これを解決するのがデジタルタイムスタンプという技術です。あるデータがある時刻に存在していて、それ以降変更されていない事を示すために、データを区別するための拇印のような情報であるデータのハッシュ値をタイムスタンプサービスに送ると、そのデータの存在証明、つまりデジタルタイムスタンプを作って送ってくれるというものです。日本でもこのようなデータの存在時刻を証明する時刻認証事業者、日本標準時からの誤差を保証しながら時刻を配信する時刻配信事業者が生まれサービスが開始されました。

各国国際標準時とのトレーサビリティーの必要性

こうした中、デジタルタイムスタンプのフォーマットについては、ISO国際標準があるので問題ないのですが、発行されるタイムスタンプが、各国の国際標準時と比較してどれくらいの精度で発行されているのかを保証する仕組みがありませんでした。タイムスタンプ局は、自分の持つ時計を元に、タイムスタンプを発行することができますが、これが無いと、各国の国際標準時と連携しているのか、どれくらいの誤差範囲で提供されるか保証や監査ができないものは、お互いの国で信用ができないからです。

そのようなわけで、各国の標準時を起源として、時刻の精度のトレーサビリティが保証および監査できないと、その国のタイムスタンプは信頼できないという話になるため、まず日本でJIS規格を制定し、うまくいけば、これをISO国際標準にしましょうという話になりました。

私の個人的な時刻トレーサビリティーの興味と今回の策定の関わり

私はその頃、タイムスタンプ付きの署名フォーマットである長期署名に興味があり、PKI方式タイムスタンプを採用する事業者が、タイムスタンプトークンに含んでいる、時刻監査証もしくは時刻監査記録と呼んでいる、時刻のトレーサビリティーを示すX.509v2属性証明書に着目していました。当時懸念に思っていたのは以下の事柄でした。

• この時刻監査証(TAC: Time Audit Certificate)という属性証明書とその証明内容は利用者が検証する必要があるのか、無いのかが明らかになっていなかった。そもそもデータ・フォーマットや検証に必要な情報は公開されていなかった。
• この時刻監査証はASN.1として誤ったエンコーディングをされていた。
• 時刻監査証に誤りがあった時に、利用者はそのタイムスタンプトークンを無効とすべきか否かが規定されていない。

認定基準を定め監督管理する団体、タイムスタンプ関係の事業者の専門家方、電子署名の専門家、国際標準の専門家の方と議論させて頂き、 2009年、日本データ通信協会で「タイムスタンプ局に対するUTCトレーサビリティ保証のTA技術要件に関する検討 中間報告書」にまとめて頂きました。私は4.3節「TACの課題と結論」を執筆させて頂いております。

当時の私の疑問に対する識者コンセンサスは、

• デジタルタイムスタンプの利用者は時刻監査証を検証する必要はない。
• 時刻監査証のASN.1エンコーディングはASN.1に準ずるようサービスを修正する。
• 時刻監査証に誤りがあった際に、利用者はそのタイムスタンプトークンを無効とする必要はない。

ということで納得しました。

ただ結局、タイムスタンプ事業者のTP/TPSタイムスタンプポリシ/運用規定では、時刻監査証のASN.1シンタックスが公開されず、時刻監査証は検証不要であることが明記する所、しない所があったりといった状況です。(ちょっと残念)

JIS X 5094:2011という時刻トレーサビリティに関するJIS規格の制定

その後、その中間報告書をベースに、日本国内で日本標準時からのタイムスタンプのタイムスタンプの トレーサビリティーを保証するためのJIS規格が2011年に制定されました。(これは、これで結構大変だった。)

JIS X 5094:2011 UTCトレーサビリティ保証のためのタイムアセスメント機関(TAA)の技術要件

中間報告書をベースにこれがJIS規格になり、日本データ通信協会で認定を受けている、時刻配信事業者や時刻認証事業者が当たり前のように行っていたことが、JIS規格として後ろ盾を持つことができるようになりました。

日本標準時とのトレーサビリティーの標準化で面倒だったのが、タイムスタンプサービスの標準がISOにはあるのにJISには無かったことです。このことで、タイムスタンプサービスを参照せずに、JIS化する必要があり、用語など手間がかかりました。

そして、今回のJISからISO/IEC規格へ

そして、世界各国のタイムスタンプが互いに信頼できるようにするために、言い換えると、世界各国の標準時とのトレーサビリティを持つ時刻配信が信頼できるようにするために、標準時からのトレーサビリティを持つ時刻配信のJIS標準をISOに持って行くことになり、ISOのドラフト版を作成しました。

関係者いろいろな伝をあたって頂き、暗号セキュリティ関係のISO/IEC SC27でお世話になることになり、SC27会議で正式に受理されました。

丁度、ISO/IEC 18014シリーズのタイムスタンプサービスのISO/IEC標準を見直す時期に来ていたそうで、これ幸いと、持っていったら追加でPart 4として標準化良いのでは？という事でワーキンググループが立ち上がりました。

その後、表現や細かい文言の修正など関係者の協力のおかげで、数多く対応してきましたが、私に関係するところとしては、当時nCipher製品でサポートされていた、PKI方式で電子署名された時刻監査証について参考情報として掲載したのですが、米国ではXML形式の電子署名されないデータを監査証として使っていました。先行するサービスの監査情報に適用できないのはまずいということで、これも比較できるよう掲載し、各項目の対応関係の補足説明を追加させていただきました。

後は、本当に長い時間のかかる、表現や文言の調整で、単に英語表現の問題だけではなくて、ISO/IECにふさわしい英語表現というのがあるようで、本当にWGの英国の方には細かく見ていただけました。

もうすぐ、承認されるかも、されるかもと、言っては、国際会議で流れ、また手直しをし、2014年10月のSC27メキシコ総会でPublishしてよいとの承認を頂いたそうです。それで、みな1月頃にはでるんじゃないの？と心待ちにしていたんですが、結局は4月になっちゃいました。

今後のISO/IEC規格からJISへ

JIS規格からISO/IEC規格にする際に、何点か国際間の整合を取れるような改正をしています。ISO/IEC規格は、翻訳さえすればそのままJIS規格にすることができるルールになっているそうです。ただ、関係省庁にお伺いをたてたところ、このUターンのJIS化は、今年は実施せずに、来年がJIS X 5094:2011が制定後、ちょうど5年になり見直しの年になるので、来年にやりましょうという話になったそうです。

盛大に祝杯をあげねばっ！！！

参考リンク

• ISO/IEC 18014-4 CD1次投票、CD2次投票、FCD1次投票、FCD2次投票の結果
• 入札「ISO/IEC 18014-4標準化制定作業及びJIS X 5094の見直し作業 」
• ISO/IEC JTC1/SC27/WG2 2011年10月ナイロビ会議報告
• ISO/IEC JTC1/SC27/WG2 2012年5月ストックホルム会議報告
• ISO/IEC JTC1/SC27/WG2 2012年10月ローマ会議報告
• ISO/IEC JTC1/SC27/WG2 2013年4月ニース会議報告
• ISO/IEC JTC1/SC27/WG2 2014年4月香港会議報告
• ISO/iEC 18014シリーズの標準ドラフト、NBコメント等番号一覧

メキシコの会議報告が見つからないなぁ。しかし、会議報告の置き場所がバラバラだったり、一覧になってないのは何でなんですかねぇ。

標準ドラフト、NBコメント等一覧

年月日	番号	文書名
2011.05.31	N 10047	Call for contributions to the proposed new project
2011.06.16	N 9659	Text for ISO/IEC 1st WD
2011.09.05	N 10225	Summary of NB comments on document SC 27 N9659
2011.09.20	N 10388	UK NB comments on document SC 27 N9659
2011.10.03	N 10328	Draft disposition of NB comments on document SC 27 N9659
2011.12.12	N 10425	Text for ISO/IEC 2nd WD
2011.12.12	N 10426	Disposition of NB comments received on SC 27 N9659 - 1st WD
2012.04.13	N 10851	Summary of NB comments on document SC 27 N10425 2nd WD
2012.04.27	N 11060	Draft disposition of NB comments on document SC 27 N10425 - 2nd WD
2012.06.06	N 11173	ISO/IEC 1st CD
2012.06.06	N 11174	Disposition of NB comments received on document SC 27 N10425
2012.09.12	N 11485	Summary of voting on document SC 27 N11173
2012.10.05	N 11613	Draft disposition of comments received on document SC 27 N11173 1st CD
2012.12.14	N 11808	ISO/IEC 2nd CD
2012.12.14	N 11809	Dispositions of NB comments received on document SC 27 N11173 1st CD
2013.03.26	N 12185	Summary of voting on document SC 27 N11808 2nd CD
2013.04.08	N 12341	Draft disposition of comments received on SC 27 N11808 2nd CD
2013.06.10	N 12567	Text for ISO/IEC DIS
2013.06.10	N 12568	Disposition of comments received in SC 27 N12185 on document SC 27 N11808 2nd CD
2013.07.02		ISO/IEC DIS

DIS以降も改変があった記憶があるんですが、それはN番号つかないのかな？

つい先日、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アプリがあるのではと想像する。

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

昨日あたりからpure JavaScriptの暗号ライブラリjsrsasignと、JSON Web Token (JWT)やJSON Web Signatures (JWS)を生成、検証できるライブラリjsjwsを合体させて、最近流行りらしいサーバーサイドJavaScriptであるNode.js用のパッケージ https://npmjs.org/package/jsrsasign として公開しています。

Node.jsでは、基本的にOpenSSLベースの標準モジュールCryptoがあって、あまりjsrsasignの出番は少ないとも思うんですが、コマンドラインインタープリタで例えばASN.1作ったり、読んだり、 JWS ができたりして結構楽しめます。そういう意味では惜しげもなくほとんどすべてのクラス、名前空間、メソッドにNode.jsからアクセスできるようにしています。

Node.jsは適当に検索してインストールしてもらうとして、jsrsasignのnpmをインストールするにはこんな感じ。

% npm install jsrsasign

で、Node.jsインタプリタを起動します。

% node

下準備としてファイル入出力とjsrsasignをロードしておきます。

> var r = require('jsrsasign');
> var fs = require('fs');

そんで、試しに暗号化されたPKCS#5 RSA秘密鍵ファイルを読み込んでみましょう。

> var pem = fs.fileReadSync('z1.prv.p5e.pem', 'ascii');
> var prvKey = r.KEYUTIL.getKey(pem, 'passwd');
試しにプリントする
> prvKey
{ n:
   { '0', 18414937 ...
ふむふむ大丈夫そうだ。

ほいで、JWS署名なんかしてみちゃいましょう。

> r.jws.JWS.sign(null, '{"alg":"RS256"}', '{"fruit":"orange"}', prvKey);
'eyJhbGciOiJSUzI1NiJ9.eyJmcnVpdCI6Im9yYW5nZSJ9.uuYgjlhRGbQyxw-Zx0sqgrbc5WNIUh7ow
M1m_lLM_JpRJuL8XdgANr7hkp09yFSxK7EzqZYrC_iMQjz72d7-wg'

読めないでしょうけど(汗)、JWSはちゃんとできてるっぽいですね。ってなわけで、コマンドラインでJWS作ったり、署名したり、ハッシュ計算したり、ASN.1作ったりいろいろできるので遊んでみてください。

今日はこんなとこで

JNSA電子署名ワーキンググループのスキルアップタスクフォースの勉強会で 拙作のJavaScript暗号ライブラリjsrsasignとJOSE JWS JWTライブラリ jsjwsのお話をさせて頂く機会を頂きました。スライドを公開しました。 これらのライブラリで日本語版の資料は作ったことがなかったので、 よかったら参考にしてください。

前回の記事では、署名生成と署名検証とか、RSAとECDSAとかどっちが速いのかOpenSSLやJava JCEを使って速度の比較をしました。一度作った署名を何回か検証に使うというケースもあるので、検証にかかる時間はとても重要だと思います。今日は、前回の比較をさらに掘り下げてみたいと思います。

・署名検証の速度は(今我々が普通に使う鍵長では)RSAの方が断然速い
・しかしながらECCは鍵長が長くても遅くならないという特徴があるのでいつか逆転するはず

鍵長が長いとRSA不利、ECDSA有利になってくるのでいつか速度の逆転が起きるのだろうと思います。では、それが鍵長としていつなのかを調べたいと思います。

NISTの暗号強度の比較表を再度引用します。

共通鍵暗号 相当	RSA	ECDSA
80	1024	160-223
112	2048	224-255
128	3072	256-383
192	7680	384-511
256	15360	512-

まずは、同じ暗号強度のECC、RSAの鍵長に対して秒間署名検証回数をプロットしてみましょう。

ご覧の通り共通鍵暗号で200bit相当、RSAなら9000bit、ECCなら200bit程度の所で署名検証の のスピードが逆転しているように見えます。我々が現在利用することの多い2048〜4096bit程度の RSAの鍵ならまだまだ十分高速であることは言えるのではないかと思います。

上記のグラフが指数関数的なので今度は秒間署名回数の対数を取ってプロットしてみましょう。

グラフから、暗号強度に対してはほぼリニアに秒間署名速度の対数が推移し、 共通鍵暗号相当の暗号強度の軸であるx座標が212.5423729(bit)の時に、 RSAとECCの署名検証の速度が逆転しています。

それでは、共通鍵暗号の強度で213bitということはRSAやECCではどの程度の鍵長に 相当するのでしょうか。 共通鍵暗号暗号強度と同等のECC、RSAの鍵長は最初のNISTの表から これも指数関数的なのでRSAの鍵長と、ECCの鍵長の対数を使ってプロットしてみます。

すると、ご覧のように取った対数に対してほぼリニアに推移することがわかります。 共通鍵暗号の暗号強度で213bitとする点はRSAだとy軸が3.965、ECCだと2.612となり、 これらは指数に戻して

RSAとECDSAと同じ暗号強度で署名検証速度が逆転するのは
・RSAだと9234bit のとき
・ECCだと409bitのとき

ということのようです。この値に近づいてるようならECDSAへの移行を考えた方が よいということなんでしょうね。

今晩はこの辺で

あ、そうそう。これ書いている途中でizuさんのとてもためになる関連記事を発見してしまいました。杜撰な研究者の日記「RSA暗号の強度 (2009.11.19)」。

2013年9月4日に開催されたOpenID Tech Night Vol.10 に参加してて、

大きなプロバイダではRSA署名の検証は結構大変です。 RSAは署名よりも検証の方が計算コストがかかるので...

みたいな話をされ、「んん？逆じゃないの。RSA署名の検証は署名生成よりも圧倒的に計算コスト低いよね。」とか 思ってたわけで「がが〜〜ん」と。 「まぁ、ちょっと調べてみるべぇ。」と手持ちのノートPCで調べてみました。

検証内容

以下のことを検証してみたいと思います。

• 署名の生成と検証ではどちらが速いのか。RSAとECC(ECDSA)では違いがあるのか。
• 同程度の暗号強度のRSA署名とECDSA署名ではどれくらい速度差があるのか。
• RSA署名では鍵長が変わったとき、どれくらい速度差があるのか。
• ECDSA署名では楕円曲線や鍵長が変わったとき、どれくらい速度差があるのか。
• Ruby+OpenSSLとJava JCEではどれくらい速度差があるのか。

なんか、楕円「マンセー」みたいな人もおられますが、 「楕円は鍵長が短いから圧倒的に速い」みたいな事を言い出す人もいて 「ホンマかいな？」と調べてみたかったわけです。 楕円って期待するほどそんなに速くないですよね？ むしろ遅いですよね。

検証方法・検証環境

言語の偏りがあるのも良くないのでOpenSSLベースのものとJava JCEベースのものと調べます。 いちいちOpenSSLをCで書くのも面倒なので。Rubyを使いました。 処理時間の測定方法については、Ruby+OpenSSL、Java JCEで次のような観点で測定しています。

共通

• 鍵や証明書のロードの時間は処理時間に含めない。
• 測定条件統一のためハッシュ計算の時間は処理時間に含める。
• 同一のマシンで測定する。
• 再利用しない同一の鍵で2000回の署名生成、署名検証の時間を計測。
• 公開鍵暗号のパフォーマンスを知りたいだけなので署名対象は"aaa"の短い文字列。
• SHA1withRSAもしくはSHA1withECDSAで比較する。

Ruby+OpenSSL

• Ruby標準の'benchmark'モジュールを用い、リハーサルも行う。benchmarkのrealの時間を用いる。

Java JCE

• イテレーションループの前後でのSystem.currentTimeMillis()の値の差を処理時間とする。

細かい検証環境情報は以下の通りとなります。

検証環境
マシン	Lenovo X201s
CPU	Intel Core i7 L620 2.00GHz
メモリ	8GB
OS	Microsoft Windows 7 Professional 32bit SP1
Java
バージョン	Oracle Java 1.7.0 build 1.7.0-b147
RSA署名JCEプロバイダ	SunRsaSign 1.7 Provider
ECDSA署名JCEプロバイダ	SunEC 1.7 Provider
Ruby (+ OpenSSL)
バージョン	cygwin C Ruby 1.9.3p194
OpenSSL	OpenSSL 1.0.1c

Ruby + OpenSSLで署名

Ruby + OpenSSLでRSAやECDSA署名するには、OpenSSLコマンドで普通に PKCS#5の秘密鍵と公開鍵を準備してこんな感じで署名生成、署名検証すればヨロシ。

# ECDSAの署名生成
prvKey = OpenSSL::PKey::EC.new(File.read(PKCS#5秘密鍵PEM))
hashed = OpenSSL::Digest::SHA1.digest(署名対象メッセージ)
sigVal = prvKey.dsa_sign_asn1(hashed)

# ECDSAの署名検証
pubKey = OpenSSL::PKey::EC.new(File.read(PKCS#5公開鍵PEM))
hashed = OpenSSL::Digest::SHA1.digest(data)
isValid = pubKey.dsa_verify_asn1(hashed, sigVal)

# RSAの署名生成
prvKey = OpenSSL::PKey::RSA.new(File.read(PKCS#5秘密鍵PEM))
sigVal = prvKey.sign("sha1", data)   

# RSAの署名検証
pubKey = OpenSSL::PKey::RSA.new(File.read(PKCS#5公開鍵PEM))
isValid = pubKey.verify("sha1", sigVal, data)   

ECDSAの時はハッシュを自分で計算するのと、 ECDSAの署名値をASN.1構造で表現することに気をつければ問題ないかと思います。

Java JCEで署名

最近、キーストア使って楽してたので普通に鍵ファイルを読みたい場合には、 PKCS#8 DERじゃないといけないんだよなとか探してみると 自分の記事 「OpenSSLで鍵生成した秘密鍵をJavaで使う」が見つかって助かりました。 秘密鍵ファイルはPKCS#8にしといて、公開鍵もPKCS#8にしようとしたら 「読めな〜〜〜い！！」鍵はパラメータの数値(BigInteger)を指定するか 証明書じゃないといけないそうだ。仕方ないから無理やり自己署名証明書を作りました。

ECDSAの署名生成はこんな感じ。

KeySpec keySpec = new PKCS8EncodedKeySpec(PKCS#8秘密鍵DERのデータbyte配列);
KeyFactory kf = KeyFactory.getInstance("EC");
PrivateKey prvKey = kf.generatePrivate(keySpec);
Signature sig = Signature.getInstance("SHA1withECDSA");
sig.initSign(prvKey);
sig.update(署名対象データaaa);
sigVal = sig.sign();

RSAの署名生成はこんな感じ。

KeySpec keySpec = new PKCS8EncodedKeySpec(PKCS#8秘密鍵DERのデータbyte配列);
KeyFactory kf = KeyFactory.getInstance("RSA");
PrivateKey prvKey = kf.generatePrivate(keySpec);
Signature sig = Signature.getInstance("SHA1withRSA");
sig.initSign(prvKey);
sig.update(署名対象データaaa);
sigVal = sig.sign();

RSAやECDSAの署名検証はこんな感じ。

CertificateFactory cf = CertificateFactory.getInstance("X.509");
X509Certificate cer = (X509Certificate)cf.generateCertificate(new FileInputStream(公開鍵証明書));
pubKey = cer.getPublicKey();
Signature sig = Signature.getInstance("SHA1withECDSA"); // RSAならSHA1withRSA
sig.initVerify(pubKey);
sig.update(署名対象データ);
isValid = sig.verify(sigVal);

最初、BouncyCastle使えばいいかとも思ったんですが、 Java SE 7から楕円用のプロバイダSunECが標準提供されるようになったので、 Java SE 7の標準バンドルされたプロバイダを使うことにしました。 サポートしている楕円曲線はどうだっけと思ったら 前に自分で調べてあったのでそれを参考にしました。 ( 祝 Java SE 7 リリース記念「JCEはどうなってんの？」)

RSAとECCの暗号強度対応

一般に、

• ECC 160bit は RSA 1024bitに相当する、とか
• ECC 256bit は RSA 3072bitに相当する、とか

言われていますが、調べて見ると、 NIST SP800-57 Recommendation for Key Management - Part1: Generalの 5.6.1節 Comparable Algorithm Strengthで対象暗号、RSA、DSA、ECC(ECDSA)の鍵長と 暗号強度の対応の表があり、 RFC 5656 Elliptic Curve Algorithm Integration in the Secure Shell Transport Layerでも引用してます。(こっちの方が見やすい)

表を引用しておきましよう。

共通鍵暗号	DSA	RSA	ECDSA
80	L=1024,N=160	1024	160-223
112	L=2048,N=256	2048	224-255
128	L=3072,N=256	3072	256-383
192	L=7680,N=384	7680	384-511
256	L=15360,N=512	15360	512-

(結果1)RSAの署名生成と署名検証はどっちが速いか

まずはRSA鍵での署名と検証がどれくらい違うのか見てみましょう。

署名と生成では、署名の方が圧倒的に時間がかかることがわかります。 また、鍵長が長くなるほど指数関数的に時間がかかることがわかります。 署名生成に関しては特にJava JCEの遅さが顕著です。

(結果2)ECDSAの署名生成と署名検証はどっちが速いか

グラフからECDSAではRSAとは逆に署名検証より署名生成の方が わずかながら速いですが、あまり変わらないということがわかります。 また、同じ鍵長のsecp160r1, secp160r2, secp160k1とでは ほとんど処理速度には違いはなく、鍵長が長くなると処理時間は増えますが、 RSAが非常に鍵長の影響を受けるのに対し、ECDSAでは あまり鍵長が長くなっても処理時間が長くはならない事がわかります。

(結果3)同じ暗号強度ではRSAとECDSAとどちらが速いか

ECC 160bit とRSA 1024bitはほぼ同等の暗号強度です。 ECDSAと比較して、RSAは署名生成はとても遅いが、署名検証は とても速いことがわかります。

鍵長が長いケース、ECC 256bit と同等なRSA 3072bit を比較してみると、 順序関係は変わりませんが、鍵長が長くなった分、 非常にRSA署名の生成時間が長くなっています。 これに対し、ECDSAではRSAほどは鍵長が長くなった影響を受けていません。

まとめ

簡単にまとめると時間がかかる順に

• RSA署名の生成には非常に時間がかかる
• ECDSAの署名検証は署名生成よりほんの少し長く時間がかかる
• ECDSAの署名生成は普通に時間がかかる
• RSA署名の検証は非常に短時間であるECDSAの署名生成は普通に時間がかかる
• RSAでは鍵長が長くなるほどその傾向が顕著になる。
• ECDSAはRSAほどは鍵長が長くなる影響を受けない。

といった感じでしょうか。認識してたとおりで良かったなぁと思いました。今日はこの辺で。

前回はApple iOS 5のメーラーの新機能であるS/MIME署名暗号メールを 送受信してみるあたりを見てきましたが、今日はその中身を覗いてみましょう。 (結論からいうとフツーすぎてかなりがっかり)

まずメッセージヘッダの特徴的なところを

iOS5から送られたS/MIME署名メールについて メッセージ本体のヘッダで特徴的なところを抜き出すとこんな感じ。

Content-Type: multipart/signed;
　　　　micalg=sha1;
　　　　boundary=Apple-Mail-XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX;
　　　　protocol="application/pkcs7-signature"
X-Mailer: iPhone Mail (XXXXX)
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)

S/MIME署名メールはクリアテキスト形式になっており 署名データのMIMEヘッダはこんな感じ。

Content-Disposition: attachment;
　　　　filename=smime.p7s
Content-Type: application/pkcs7-signature;
　　　　name=smime.p7s
Content-Transfer-Encoding: base64

まぁ、至って普通です。

署名データの中身は

PKCS#7 SignedData形式である署名データを覗いてみて 特徴をまとめてみました。

フィールド	値
version(SignedData)	1
digestAlgorithms	SHA1
certificates	EE証明書のみ

SignedDataの中のSignerInfoの特徴はこんな感じ。

フィールド	値
version(SignerInfo)	1(=IssuerSerial)
digestAlgorithm	SHA1

SignerInfoの中の署名属性(signedAttributes)の一覧は以下の通り。

フィールド	値
contentType	data
signingTime	UTCTime
messageDigest	署名対象のSHA1ハッシュ値
microsoftRecipientInfo(1.3.6.1.4.1.311.16.4)	受信者のIssuerSeiralセット
encrypKeyPref(1.2.840.113549.1.9.16.2.11)	送信者の暗号用証明書のIssuerSerial
signatureAlgorithm	rsaEncryption(1.2.840.113549.1.1.1)

暗号データの中身

次にPKCS#7 EnvelopedData形式である暗号データを覗いてみました。 特に特徴的なところはなくてTriple DES EDEモード(des-EDE3-CBC 1.2.840.113549.3.7) が使われているというだけでしょうか。

まとめ

というわけで、iOS5のメールのS/MIME機能は使われている フォーマットや暗号アルゴリズムは至って普通で とても相互運用性が高いものになっていると言っていいんでしょうかね。 うーん、つまらん。