ディレクトリ
コンセプト
特殊な暗号化アルゴリズムを使用して証明透明ログは、国民の監視証明書とログに貢献します。特定の暗号化アルゴリズムと呼ばメルクハッシュツリー（マークルハッシュツリー）単純なバイナリツリーのノードとリーフのハッシュ（図1）を含みます。葉はすでに単一の証明書ログハッシュに添付されています。子葉ノードは、ハッシュまたは子ノードのペアをペアになっています。すべてのルートノードとリーフ、すなわち、ルートハッシュは呼ばメルクハッシュツリー（ハッシュマークル木を）。場合は、ログサーバメルクツリーハッシュ（およびその他の情報）の署名と呼ばれる署名ツリーヘッド（STH：署名ツリーヘッド）。
定期的に、おそらく1時間に1回、新たに取得したログサーバ証明書は、ログに追加します。メルクは新たに証明書、ハッシュ及び以前にハッシュツリーの新しいハッシュツリーメルク（図2）に結合ハッシュツリーメルク古いによって取得された別個のハッシュツリーを作成します。新メルク木ハッシュ署名が新しい署名ツリーヘッドを作成します。ログに提出されたすべての証明書が成長しているメルクツリーを形成する前に、繰り返し、続けました。
適合性の監査証明と認証
このような構成モードでは、メルクハッシュツリーのログは、迅速かつ効率的に二つのことを証明することができ：
- すべての証明書は、一貫してログに取り付けられています。
- ログに取り付けた特定の証明書
の監査の一貫性を証明するためにメルクとメルク証明：ログが証拠を提供することにより、2つの暗号化をサポートしています。
適合性のメルク認証
二つのバージョンのいずれかのログを確認する証明メルクの一貫性は同じです。つまり、新バージョンでは、エントリの最後のバージョンの後に、すべての新しいエントリに追いついて、他の言葉で、すべての古いバージョンが含まれています。それが判明した場合、ログには期限切れの証明書は、および証明書が変更されていないことをログに挿入されていない、とログがあまりにも分岐していないことを意味し、同じです。
原則メルクの一貫性の証拠を示すために、あなたは図2に証明したいと3ログが同じであると仮定します。最初のステップは、古い木のハッシュメルクメルクは、ハッシュツリーの新しい部分集合であることを証明する必要があります。そして、新しいメルクメルク古い木のハッシュは、ハッシュツリーのノードに加えて、すべての新しい追加の中間証明書のハッシュであることを証明します。一貫性は、両方のセットのために必要な計算されたハッシュ少なくとも中間ノードを証明しました。
この場合、中間ノードハッシュの整合性によって証明される：k、l、及びm（図4参照します）。使用kしてm作成メルク古い木のハッシュを、ひいては古い木の存在が変更されていないことを証明。次に、使用lしてk作成nしてnし、m新しいログメルクツリーハッシュを作成します。マッチングと計算されたハッシュツリーメルクログ場合は、ログが一貫しています。
定期的に監視し、ログの正常かどうかを確認するために、一貫性の証明の使用を監査しています。モニターおよびログは、通常、自己無撞着計算証明すること、およびログの整合性を検証することができる証明書のリストと同じであるからです。任意の一貫性は、2つのツリーに署名した証明取得するには、単純なクエリのログサーバを設計します。
メルクの監査証明
メルクの監査証明書は、特定の証明書ログがあることを確認します。すべてのクライアントTLS証明書がログに表示することを拒否しないために証明書が必要になるので、これは証拠、透明モデルの重要な課題です。
原理の証明を示すためのメルク監査、確認したいとしd3た証明書（d葉）は、すでにログの図3に取り付けられています。メルク監査は、葉と根の間のすべてのノードをハッシュするために必要な計算ノードの欠如であることが判明しました。計算されたハッシュと監査のルートパスメルク電流をログは、ハッシュツリーに一致する場合、ツリーの葉に存在する（または言い換えると、ログ内の証明書が存在します）。
この例では、含むメルク監査証明書ハッシュノード：c,i,n（図5参照）。それがd知られている、それが可能なc計算しますj。そして、iとj計算しm、その後、n、およびmハッシュツリーは、メルクのログを計算します。あなたは証明書がいることを確認したい場合は同様に、d4ログに追加された、ログはあなたに送るf, l, m適合ノードのハッシュの認証を。（既知のハッシュを残しe、それは葉のハッシュとすることができる）f計算されたハッシュノードk、ハッシュと、ノードl計算されたハッシュ・ノードn、そのノードのハッシュmとnログ算出メルクツリーハギリシャ。
誰でもメルクハッシュツリーのログを要求することができ、証明書は、ログの存在を確認することができます。証明書TLSクライアントを検証するために、ログに送信された監査要求の一般的にこれらのタイプ。監査はメルクとメルクは、ハッシュツリーのルートハッシュ一致を計算していなかったことを証明した場合、それは証明書がログに存在しないことを意味します。
実証済みの使用
暗号化されたデータの監査のニーズを提供するための実証済み。通知は、少しは、監査ログ情報について知られているが、限られた知識にもかかわらず、特定の証明書がログに添付されているため、それは一貫して、監査ログを確認することができるかどうかを証明します。
証拠がなければ、監査はすべてのログにアクセスしたり、その職務の行使に戻ります。データ、監査ログのより効率的な交換を証明してみましょう、とのデータ交換の量もはるかに少ないです。例えば、わずか24節ハッシュ一貫性が証明必要なログの千万証明書を包みます。ログは2000万証明書、25にそのノードのハッシュの数の一貫性の証明に増加した場合。
モニターはまた、わずかに異なる方法であるが、有用であることが判明します。モニターは、典型的には、各証明書は、ログをチェックするように、ログのコピーを保存するために監視し、特定の証明書に注意を払います。モニタが特定のログの整合性を監視するためにチェックした場合、自分の身元を証明するために計算され、その後、ログの一貫性を検証することができます。モニター特定の証明書は必ずしも必要ログに存在する場合も同様に、それはまた、計算された監査証明書、証明書であり、その後、証明を検証します。