PKIのユーザー証明書とCA証明書を安全に更新する方法

Question

私は現在、x.509-client-certificatesが公開サーバーによって発行される自分のPKIを開発しています。現時点では、CA公開鍵はバイナリとともに配布されており、クライアントもCA証明書も更新するルーチンはありません。これらのルーチンを実装するとき、私は何を考慮すべきですか？私の考えは：

クライアント証明書を更新する場合：

新しいキーペアを古いキーペアで確認するだけでは不十分のようです。たとえば、古いキーペアが侵害された場合などです。
クライアントが代わりに将来のオーセンティケーターのセットを保存し、最初の登録時にそれらをサーバーに渡すことができます。これらの認証システムは、証明書の更新にのみ使用する必要があります。それとももっと良い方法がありますか？

CA証明書を更新する場合：

別のCAを使用してCA証明書を検証することもできますが、システム外のエンティティを信頼したくありません。
クライアントのユーザーにCA-cert-fingerprintを表示することもできますが、ユーザーとの対話なしでプロセスを自動化したいと思います。

誰でも私にこの問題についてのsomポインタを提供できますか？この主題についての最高の本は何ですか？私は「応用暗号のハンドブック」をすでに試しましたが、証明書の更新について何も有用なものを見つけることができませんでした。

Thomas Pornin · Accepted Answer

更新について考える「正しい」方法は、自分自身に問いかけることです理由更新したい。

私が理解しているように、クライアントにインストールされている一部のアプリケーションにハードコーディングされているルートCAがあります。さらに、クライアント自体が証明書を所有しており、そのルートCAによって（直接または中間CAを介して間接的に）おそらく発行されます。これは、相互認証の設定を示唆しています。クライアントとサーバーの両方で証明書を使用するSSL。覚えておくべき重要な点は、証明書を所有している場合（つまり、対応する秘密鍵を知っている場合）、その証明書を検証する必要がないことです。あなたの証明書はあなたではなく、他の人々の利益のためのものです。特に、クライアントは、独自の証明書を使用するためにルートCAを信頼したり、知る必要さえありません。証明書を検証するには、ルートCAを信頼する必要がありますクライアントに送信（たとえば、クライアントが接続するSSLサーバーによって提示される証明書）。

したがって、「ルートCA更新」と「クライアント証明書更新」の概念は、実際には互いに無関係です。両方の種類の更新を別々に考える方が簡単です。

root CA updateの場合、次の設定があります。アプリケーションがデプロイされ、アプリケーションにハードコーディングされたルートCA名と公開鍵が含まれています。これは、X.509用語ではトラストアンカーと呼ばれます。アプリケーションはそのTAを使用して、着信証明書（SSLサーバー証明書など）を検証します。

何らかの理由で、TA名またはキー、あるいはその両方を変更したい。そのための通常のメカニズムは、アプリケーションの更新です。デプロイされた特定のアプリケーションにバグがないと信じるのは非常に初心であり、セキュリティ関連のアクションに関与している場合、バグは脆弱性に変わる可能性があります。したがって、アプリケーションバイナリを新しいバージョンで安全に置き換えることができる更新メカニズムが必要です。一部のソフトウェア配布プラットフォーム（Android用のGoogle Play、またはLinux配布用のパッケージなど）は、このようなメカニズムを提供します。

定義により、アプリケーションバイナリはtrusted（機密データを操作するのはそのコードであるため）なので、更新メカニズムは悪意のある変更から保護する必要があります。したがって、新しいTAをアプリケーションに組み込み、それを更新としてプッシュすることが、「ルートCAを更新する」ことができる主要な（そして実際にはonly）メソッドです。

外部プラットフォームが安全な更新メカニズムを提供しない場合は、独自のビルドメカニズムを構築する必要があります。これは、新しいcdromを各ユーザーに送信するのと同じくらい粗雑なことかもしれません...しかし、自動化したい場合は、signatureまたは少なくとも認証が必要です。たとえば、アプリケーションは特定のHTTPSサーバー（サーバー証明書の検証が必要）に接続して更新をダウンロードできます。これは、特定の更新サーバーからのものであるため、正しく評価されています。

理由新しいルートCAをプッシュする必要がある理由は、特にタイミングに関して重要です。主なケースは2つあります。ルートCAキーが危険にさらされたために迅速に対応する必要があるか、または時間があります（たとえば、使用したものが少し短すぎるために長いCAキーに変更したい）。暗号解読の進歩）：

時間がある場合は、sign新しいアプリケーションバイナリ（新しいルートCAを含む）を古いCAと一緒に使用できます。これにより、スムーズな移行が可能になります。
notに時間がかかる場合（ルートキーの侵害など）、深刻な問題に直面しています。あなたができる最善のことは、それを「重大な脆弱性」として扱い、ユーザーが手動で何らかの配布サーバー（100ドルで購入する「メインストリームSSL証明書」で保護されている）に接続してダウンロードできるように、それについて大騒ぎすることです。新しいアプリケーション。

これは依然として非常に悪い状況であり、遭遇したくないでしょう。ルートCAキーを安全に保つための古典的な方法は、キーを保持することですoffline：ルートCAをネットワークに接続しないでください。つまり、ユーザーの証明書を発行するには、PKIにオンラインの中間CAが必要です。手動で（つまり、USBフラッシュドライブを使用して）ルートCAからCRLを定期的な手順で（たとえば、毎週）取得します。

または、ルートCAとは別に、オフラインマシンに無関係な「更新パッケージの署名キー」を保持して、新しいバージョンを構築して配布する必要があるときに使用することもできます。アプリケーションのバイナリには、対応する公開鍵のコピーが含まれます。これは、ルートCAの鍵と証明書とは何の関係もありません。これは、アプリケーション更新パッケージを検証するためにのみ使用される「追加のルート」のようなものです。常にオフラインになっているため、そのマシンはリモートの攻撃者から安全である必要があります。したがって、パッケージの署名キーが侵害されないという前提で作業することができます。

他のすべての条件は同じであるため、ルートCAキーを更新しないことが最善です。私たちが知る限り、2048ビットのRSA鍵はかなりの数十年の間有効であるはずであり、まだ発見されていないが壊滅的な攻撃によってのみ破壊される可能性があります。現在のところ、そのような攻撃が将来発見されるか、または存在する場合でも、その兆候はありません。そして、より長いCAキーが適切に機能することを示すものもありません（これは、unknownの推測に関する問題です。これはspeculativeであり、有用な情報をほとんど提供しません）。

クライアント証明書の更新の場合、問題は完全に異なります。クライアント証明書は、クライアント自体が信頼するものではありません。

クライアント証明書にはクライアントIDと公開鍵が含まれているため、最初の「更新」方法は、古い証明書を取得して有効期限を変更し、再度署名することにより、CAに証明書を自発的に更新させることです。したがって、クライアントのキーと名前は変更されません。「更新の問題」は、新しい証明書を知る必要がある人にプッシュするという問題にまで減りました。通常（ただし、必ずというわけではありません）。クライアント自体が独自の証明書を知っていると、クライアントが一部のネットワークプロトコルの一部として証明書を送信できるため、最適です（例： SSL/TLS 、クライアントが認証に証明書を使用する場合、サーバーはクライアントが証明書を送信することによりその証明書を学習します。

証明書には公開データのみが含まれ、署名されているため、インターネット上で安全に移動できます。クライアントが新しい証明書が存在するかどうかをサーバーに尋ね、それを取得するための通常のプレーンなHTTPリクエストをセットアップするだけです。そのメカニズムの場合、証明書が正しいものであることを確認するために、クライアントには発行CA公開鍵またはそれより上位のCAのコピーが含まれている可能性があります-クライアントはそうではありませんtrustルートCAただし、悪意のある攻撃者が転送中に更新された証明書を破損することによる不本意な混乱を回避する必要があります。これは DoS攻撃になります。変更されたクライアント証明書はどのサーバーでも受け入れられませんが、クライアントアプリケーションが、証明書の使用時ではなく、後で証明書のダウンロード時に不正行為に気付いた場合に最適です。

理由クライアント証明書を更新する理由は、ここでも重要です。

X.509証明書で有効期限の日付を強制する公式の理由は、失効リスト（CRL）が無制限に大きくならないようにするためです。それほど公式ではない理由は、1年間の証明書が毎年の更新を保証し、それが年間のアクセス料金に変わる可能性があることです。これらの理由でクライアント証明書を更新する場合は、前述のようにCA側で更新できます。
クライアントキーを変更する必要がある場合は、異常な例外的な状況に対処しています。クライアントキーの侵害。その場合、クライアントは、すべてのサーバー、特にCAに対してそのアイデンティティを示すためのメインメソッドを失ったばかりです。

その時点で、最初に証明書を発行した方法を考慮する必要があります。証明書はIDを公開キーにバインドするため、その時点では、クライアントのIDを確認する方法がありました。したがって、秘密鍵の侵害後の一般的な回復方法では、同じ初期認証方法が再び使用されます。その時点で、ユーザーは通常積極的に協力しています-結局のところ、侵害は通常ユーザー自身によって発見されています。

可能な緊急復旧方法の詳細は、状況によって大きく異なります。 PKIが使用するIDの概念が「同じユーザー」である場合（誰でも登録でき、正式な物理的なIDはありませんが、ユーザーは以前と同じユーザーであることを証明できるはずです）、実用的な方法は、、最初の証明書と一緒に、ユーザーが紙に書き留めた「回復コード」と、秘密鍵の排他制御を失ったときに再度入力します。秘密鍵は攻撃者に知られているか、ユーザーの電話が故障し、キーを使用できなくなった、またはその両方が発生した（一般的なケース：ユーザーの電話またはラップトップが盗まれた）。回復コードは、ユーザーがCAに対して、更新する証明書を以前に所有していたユーザーと同じユーザーであることをCAに示すことができる方法です。