どの暗号が「見えない」CAを防止および検出しますか？ （例：X509v4）
この質問では、私は「見えないCA」と呼んでいます。
- ルートCAによって署名され、2番目または3番目の層として存在します
- 有効であり、有効期限が切れていないか、取り消されていません
- 現在支配的でアクティブな公開鍵とは異なる公開鍵を持っている
このシナリオは、実際には次の場合に発生する可能性があります。
- 通常のsubCA（root0-1）が更新されます*
- 悪意のある、またはウイルスに感染したrootCAオペレーターが、側面に追加のCA（root0-2）に署名します
- 次に、オペレーターは、正当で予想されるルートCAに署名/更新します（root0-1はroot0-3になります）。
私の目標は、特定のPKI階層を消費者として、または発行された証明書を信頼する誰かとして洞察を得ることであり、キーカウントを備えたトップダウンのサードパーティ監査やHSMに依存しないことです。
サブCAが発行された回数と、発行されたCAがアクティブであるか、取り消されていないかを示す暗号化の約束が必要です。
同様ですが異なる概念はパスの長さです。特定のパス値に対するアクティブなCAの数に焦点を当てています。
限定された表示資格情報
キーを使用できる回数を制限し（ECashなど）、「秘密」を公開する暗号化技術について聞いたことがあります。この場合、おそらく「秘密」はブール値"complies with stated agreements"または"does not comply with stated agreements"。ただし、このアプローチには欠陥があります。たとえば、クライアントは、このようなイベントを検出するために送信されるすべてのsubCAを監視する必要があります。
質問
クライアントがPKIの整合性のこの側面を検証するための、より賢明なアプローチ（理論上）はありますか？ （または「当局」の信頼ネットワーク）
現在、X.509では、特定のキーの使用回数を追跡するようなことはありません。これは、「X.509はコンテキストフリー」の意味の一部です。検証とは、類似したパスまたは異なるものが表示されたかどうかに関係なく、目の前にある証明書パスが有効かどうかに関するものです5。数分前、「同じ」という概念について「同じ」サーバーと話しているとき。
X.509のもう1つの重要な点は、不正なCAは範囲外ですです。これは逆説的なように見えますが、CAが敵対的な制御下に置かれると、CAは「失われ」、侵害された証明書に対応する証明書を取り消すことによって、ツリーブランチ全体を切断することしかできません。 CAキー（「侵害」とは「秘密キーが敵対的な目的で使用された」ことを意味し、必ずしも「秘密キーのコピーが盗まれた」とは限りません）。侵害されたルートCAの場合、自己発行されているルートCAは取り消すことができないため、考えられる唯一の修正は、すべてのクライアントのトラストストアから削除することです。
（MicrosoftがデフォルトのトラストストアからルートCAを削除するWindowsパッチをプッシュすると、これはある種の失効と見なされる可能性があります。この場合、ルートCAは実際には「ルート」ではなく、「真のルート」はMicrosoftです。これはすべてX.509の外部で発生します。）
説明したシナリオでは、攻撃者が実際に不正な証明書を使用していない間は、攻撃者がルート秘密鍵を使用して行ったことを検出できません。これは、強力な数学的方法で避けられません。攻撃者がルートCAの完全な状態にアクセスできる場合、攻撃者は「クローンを作成」して自分のマシンで秘密鍵を使用できます。したがって、ルートCAの状態は影響を受けません。あなたが求めているのは、攻撃者が完全な状態を見ることができたとしても、攻撃者が自由に変更できない「使用カウンター」を維持する暗号化の魔法です。コンピュータがそれらである限り、これは実行可能ではありません。不正な署名を確実に検出するために、発行された署名の数を追跡するには、他の何かが必要になります。ルート秘密鍵を改ざん防止デバイス（HSM）に保存します。これにより、カウンターが維持され、たとえば、発行されたすべての証明書のシリアル番号の一部として使用されます（したがって、クライアント側の監査が可能になります）。これは実際には、攻撃者が捕捉できない「ルートCAコア」を1つにすることによってモデルを変更することです。
概念的には、「署名カウンター」を含む形式で、すべての署名がプッシュされる分散データベースシステム（ビットコインで使用されているものと同様）を想定できます。これは、次のことを前提としています。
- 署名アルゴリズムは、h（m）ではなくh（c || m）で機能するように変更されています。 /（cはカウンター、m署名されたデータ、h暗号化ハッシュ関数）。
- すべての署名値は、署名者とカウンター値によってインデックス付けされてグローバルデータベースに保存されます（したがって、重複が検出されます）。
- 検証者（クライアント）は、データベースで署名を見つけられない限り、署名を受け入れません。
- ベリファイアは、特定のカウンタ動作を強制します。これにより、CAが予想よりも多くの署名を行ったことを確認できます。
- 分散データベースは、攻撃者が変更することはできません。
これはいずれもX.509でサポートされておらず、現在も近い将来もサポートされていません。シグニチャ値のグローバルデータベースはありません。X.509はオフラインコンテキストで使用できると想定されているため、データベースはありません。また、X.509では、検証者はステートレスです。検証履歴を追跡しないため、これは望ましい機能であると考えられています。
電子キャッシュプロトコルでの二重支払いを検出するための暗号化アルゴリズムは、実際には「データベース」の概念の短縮版です。銀行が実際に両方のトランザクションを確認したときに、銀行レベルで発生します。したがって、E-cashプロトコルは、二重支払いの場合に消費者の身元が明らかになるように作成されます。この相関フェーズ中。