第33回 デジタル情報の検証とトラストチェーン
デジタル情報の確からしさをどうやって確認するか？ タイムスタンプを例にひも解きます。
デジタル情報の検証とトラストチェーン
デジタル情報の検証とトラストチェーン
デジタル情報の確からしさって、皆さん、どうやって確認しますか？
今回は、タイムスタンプを例に、検証について書いてみたいと思います。
タイムスタンプの効能は、
- 存在証明
- 非改ざん証明
です。
タイムビジネス信頼・安心認定制度の審査基準では、
タイムスタンプ検証の際は、
（a） タイムスタンプ付与対象文書のハッシュ値確認、
（b） タイムスタンプトークンに付与されたデジタル署名の検証、
（c） TSA公開鍵証明書失効確認を含む証明書パス検証、
という一連の手順を実行することにより検証を行う。
検証は、タイムスタンプ保有者がTSAに依存することなく実行可能でなければならない。
とあります。
これら三つの検証をすることで、
- いつの時点でスタンプが付与されたのか
- その後、対象情報に変化がなかったこと
- スタンプ付与時点で不正はなかったこと
が確認でき、タイムスタンプとしての効能を発揮できるようになります。
ここで、（a） と（b） は、デジタルならではの検証で、白黒はっきりさせることができます。
（c） については、公開鍵暗号基盤（PKI）特有のトラストチェーンによる検証をすることになります。
今回は、この「検証＝不正無なきことの確認」について
提供側がどのような工夫をしてサービス提供しているかをひも解きたいと思います。
認定事業者のタイムスタンプだから安心！をご確認ください。
タイムスタンプの構造
まず、タイムスタンプの構造を見てみましょう。
この構造を一つ一つ確認することが検証作業になります。
図-1がタイムスタンプの構造です。
利用者は、対象データのhash値（hashedMessage）を、タイムスタンプ局に送付して、
タイムスタンプを要求します。（Time Stamp Request）
タイムスタンプ局は、時刻配信局から配信されている正しい時刻（genTime）を付与して
タイムスタンプを利用者に戻します。（Time Stamp Response）
このとき、タイムスタンプトークン（TST）の生成に公開鍵暗号基盤（PKI）が利用されています。
タイムスタンプ局の秘密鍵によって、対象データのhash値や正しい時刻などの署名対象情報（TSTInfo）と、
秘密鍵の対である公開鍵を含む公開鍵証明書（certificates）がデジタル署名されたトークンが生成されます。
さぁ検証です。
TSTから、公開鍵証明書に含まれている公開鍵を抜き出して
［1］暗号化されている署名値（signature）を復号して、signedAttrsから演算されるhash値との比較をすることでsignedAttrsの完全性を確認します。
signedAttrsから
［2］SigningCertificateを取り出し、公開鍵証明書から演算されるhash値との比較で、デジタル署名に利用されている秘密鍵の対である公開鍵との一致を確認します。
［3］messageDigestを取り出し、TSTInfoから演算されるhash値と比較することで、対象データと時刻を含む、署名対象データ（TSTInfo）に変化がないことを確認します。
ここまでで、対象データのhash値が、genTime付与時点に存在していたことを検証できます。……［4］
次に対象データからhash値を演算し、そのhash値とTSTInfo内のhash値（hashedMessage）
の比較をすることでTSTに含まれているhash値が対象データと一致することが検証できます。……［5］
これらを実施することで、対象データがその時刻に存在していたことを、数学的に確実に検証ができ、
認定審査基準の（a）および（b）についてクリアできます。
デジタルの暗号技術は、独立した記録情報から数学的に○、×の判断ができますが、できることはここまでです。
この検証では、単に、どこの馬の骨か分からない誰かによって、適当に生成されたgenTimeを付与してデジタル署名された情報と、対象データが一致するということが確認できたということに過ぎません。タイムスタンプ対象文書を改ざんして、適当な時間に、さも存在したかのように、どこかの馬の骨が生成することはできてしまいます。
「不正なきこと」を確認するためには、もう少し複雑な仕組みが必要なのです。
認定審査基準の（c）が重要なのですね。
検証のスキーム
ここからが、トラストの領域になります。
タイムスタンプで、対象データに正確な時刻が付与される仕組みとその確からしさは、「タイムビジネス信頼・安心認定制度」で担保されています。
事業者の運用状態と利用している技術や設備の正当性を第三者である適合性評価機関である日本データ通信協会が規定にのっとって監査することで担保しているのです。
認定制度は、事業者の認定であって、実際にタイムスタンプを発行する「そのとき」ではなく
さらには、そのサービスによって自らの正当性を主張する「将来」における検証ではありません。
「そのとき」以降「将来」にわたって確かにきちんとサービスを提供するだろうということを
「そのとき以前」の監査によって認定しているのですね。
このあたりの時系列をよ～く理解しないといけません。
すなわち、事前にそのサービスの不正なきことを信用して、将来の主張したいときに「頼る」。
まさに、トラスト＝信用して信頼するのです。
認定制度を信頼し、認定されていることを確認することで
その事業者の確からしさと正確な時刻が付与されていることを検証することになるのです。
【参考：トラストについて】
トラスト＝信用して信頼すること
さぁ、では対象のタイムスタンプから何をもって信頼しましょうか？
発行者が認定制度で認定されている事業者であることを確認できればよいのですね。
認定事業者であることは、日本データ通信協会のWebにて確認ができます。
そして、対象のタイムスタンプの発行者が認定事業者であることは、タイムスタンプに含まれている公開鍵証明書から確認できます。
［2］で署名者の秘密鍵はこの公開鍵証明書に含まれる公開鍵とペアであることが確認されていますから
この公開鍵証明書の中身を確認することで、誰が秘密鍵の所有者、すなわち発行者であることが分かります。
証明書には、公開鍵の所有者情報がsubjectに記載されています。
cn：所有者
ou：組織名称
o：事業者名称
図-2にWindows証明書ビューアでの当社タイムスタンプのsubjectを記載します。
トラストのチェーン
ところで、公開鍵証明書は正しいものでしょうか？
PKIでは、公開鍵証明書は、公開宣言している認証局のポリシー（CP/CPS）に基づいて秘密鍵の管理者（事業者）の鍵の運用方法と実在の確認をして発行されます。
その認証局もその上位の認証局のポリシーに基づいて運用される仕組みです。
証明書は、認証局の秘密鍵によってデジタル署名されており、その対となる公開鍵は上位の認証局の秘密鍵によってデジタル署名される、というチェーンを形成しています。
これら認証局の有効性や発行される公開鍵証明書の失効状況などは、リアルタイムで変化が起こります。
このため、認証局運用事業者はそれらが確認できる情報をインターネット上に公開することで、確からしさを担保しています。
検証時には、最新の情報をインターネットを介して入手することが必要です。
この検証が、認定審査基準の「（c）TSA公開鍵証明書失効確認を含む証明書パス検証」になるのですね。
一方で、一般的な認証局は
タイムビジネス信頼・安心認定制度のような専門的な監査はできません。
従って、タイムビジネス審査基準の中でTSA公開鍵証明書として定義し、TSAは信頼できるCA（認証局）により公開鍵証明書の発行を受けた秘密鍵を用いてタイムスタンプトークンにデジタル署名を施すことと規定しています。
公開鍵証明書を発行している認証局が信頼できることが確認できなくてはいけません。
弊社の場合、公開している運用規程（TP/TPS）にて公開鍵証明書の認証を行う事業者を規定しています。
セイコーソリューションズ株式会社 タイムスタンプサービスリポジトリ
そう、実にややこしい。
なので、そこのところは誰かに依存してしまおう！
というのが、トラストの発想です。
きちんと運用していることを、誰かに確認してもらってそれを利用しましょう。
それが、信頼できる第三者機関：TTP（Trusted Third Party）という発想です。
認証局も、適合性評価機関も、TTPでなくてはいけませんね。
いわゆるお墨付きです。
どこまでやれば信頼できるか？
デジタルなので数学的に白黒を明確にできますので、
アナログの社会に比して、正しく情報が付与できていれば、検証作業は相当削減できます。
最後は、数学的に検証しきれないところ、正しく対象の秘密鍵が運用されたか？です。
もちろん、タイムスタンプ発行事業者も、認証事業者も、適合性評価機関も民間です。
赤字採算での事業継続はできません。
また、それらの運用基準も一定に担保されたものではなく、自らポリシーを公開し宣言することでサービスを提供しています。
正しく発行していること自体がサービスの品質になり
それが、ブランド化することでビジネスが継続して回るのですね。
数学的に完全性を確認したうえで、トラストチェーンで正当性を確認する。
実にうまくできた仕組みですが、利用者はサービスを利用する「今」の判断で「将来」を委ねることになります。
一例としてのAcrobat Readerによる検証
タイムスタンプが付与されているPDFを、簡単に検証することがAdobe社のAcrobat Readerで可能です。
では、Adobe社のAcrobat Readerでは、どのような検証をしているのでしょうか？
タイムスタンプが付与されているPDFをAdobe社のAcrobat Readerで開くと
自動でこの検証プログラムが走り、左上に署名アイコンと共に青色背景でその結果が表示されます。
特に異常がなければ
が表示されます。
本当か？
誰も、その中身までは、確認しませんよね。
そう。これがトラストってやつです。
ところが、そこで、何らかの異常が表示されて初めて、何々何……となるのですね。
ここからが大変。
異常が出ると、何がどう異常なの？ これは本当にダメなのか？ 今までは大丈夫だったけど？……
不安になるわけです。
そう、Adobe社のアプリケーションに依存しているのですね。
でも、決してAdobe社や自らの設定を疑ったりはしない……トラストなのです。
もちろん、タイムスタンプが不正であったり、対象情報が改ざんされていたりすると
数学的な検証は、きちんとされて、ダメなものはダメと適格に表示されます。
しかし、公開鍵証明書については少々あいまいな検証結果となります。
……有効期限切れの場合やAcrobat Readerの証明書ストアに証明書が登録されていない場合はこれ。
……署名後に署名対象情報ではない箇所に何らかの追加をした場合。
……署名後に何らかの変更を加え新たに署名をした場合。
ここで、トラストのチェーンが重要になります。
Acrobat Readerは、公開鍵証明書から、その証明書を発行している認証局をたどり、正当な認証局であることや当該証明書が失効されていないことを確認します。
もし、ここで証明書に登録されていない場合や、正当な認証局であっても証明書登録情報がupdateされていない場合、登録された認証局から発行されてはいるものの有効期限切れであったりした場合は「少なくとも1つの署名に問題があります。」となるわけです。
「少なくとも1つの署名に問題があります。」なんて表示が出てしまうと、一般の利用者は、「こりゃいかん」となってしまいますよね。
望まれる信頼基盤の構築
ここまで、タイムスタンプの検証ということで記載してきましたが
デジタル社会においてデジタル証明書を利用し信頼性を確認する場合は、数学的に完全性を確認したうえで、トラストチェーンで正当性を確認する、この検証スキームは全て同じです。
一定の信頼基準をクリアしていることを適合性評価機関が監査し、その結果として事業者の利用する秘密鍵と対の公開鍵証明書を発行する認証局の証明書をトラストに公開する仕組みを用意し、自動で検証してくれることで、利用者が安心して利用できる信頼基盤の構築が望まれます。
日々刻々と進化するデジタル社会で、複雑な検証を利用者自らが行うことは、既に困難な状況になっています。
専門的に管理運用される機関・仕組みがあれば、誰もが便利なデジタル社会を安心して楽しく活用できますね。
信頼基盤は、利用者にとっては、トラステッドされたトラストアンカーでなくてはいけません。
- 一定の信頼基準にのっとったサービスであることが第三者機関によって監査される。
- 一定の信頼基準は、提供されるサービスによって項目は異なる技術、運用、設備の基準であり、社会環境によって変化することを前提とし、常に最良状態になるべく設計される。
- サービス提供事業者は、民間であり、状況によって廃業・廃局・休止もありうるが、そのような事態になったとしても利用者に影響を与えないこと、すなわち、サービスを提供している「そのとき」は確かに一定基準を超えた正当なサービスであったことを将来の検証時に確認ができる。
- 業界や国といった枠を超えて、誰もがいつでもどこでも利用できる。
このような枠組みは、既にEUではDigital Single Market推進のために構築されeIDASという域内直接法にて定められTrustedlistという形で運用されています。
急速に発展するデジタル社会において、流通するデジタル情報を信頼して利用するための業界や国の枠を超越する安心・安全の基盤構築は、急がなくてはなりません。