Junos OS の PKI コンポーネント

PKI の管理と実装

Junos OS の証明書ベースの認証に必要な基本的な PKI 要素は次のとおりです。

• CA 証明と認証局の設定

• デバイスの ID(IKE ID のタイプと値など)を含むローカル証明書

• 秘密鍵と公開鍵

• 認定資格検証のための CRL

Junos OS は、以下の 3 種類の PKI オブジェクトをサポートしています。

IKE

IKE セッションの 2 人の参加者間で送信されるメッセージにデジタル署名する手順は、デジタル証明書の検証と似ていますが、以下の点が異なります。

• 送信者は、CA 証明書からダイジェストを作成する代わりに、IP パケット ペイロード内のデータからダイジェストを作成します。

• CA の公開鍵と秘密鍵のペアを使用する代わりに、参加者は送信者の公開鍵と秘密鍵のペアを使用します。

HTTPS経由のPKI

PKI の HTTPS サポートにより、証明書管理操作のセキュリティが強化されます。PKI の HTTPS は、SCEP 登録と CRL 失効のための安全な通信チャネルを確立し、機密情報を保護します。

PKIプロセスは、設定されたURLに基づいてHTTPまたはHTTPSを動的に選択し、柔軟性と安全な伝送を提供します。

• CA プロファイルで HTTP URL を使用する場合、PKID プロセスは HTTP 通信チャネルを使用します。
• CA プロファイルで HTTPS URL を使用する場合、PKID プロセスは HTTPS 通信チャネルを使用します。

信頼されたcaグループ

CA は、証明書の発行と失効を担当する信頼されたサードパーティです。信頼できる CA グループは、特定のトポロジーの 1 つのグループ内の複数の CA(CA プロファイル)のグループです。これらの証明書は、2 つのエンドポイント間の接続を確立するために使用されます。IKE または IPsec を確立するには、両方のエンドポイントが同じ CA を信頼する必要があります。いずれかのエンドポイントが、それぞれの信頼できる CA(CA プロファイル)または信頼できる CA グループを使用して証明書を検証できない場合、接続は確立されません。

たとえば、エンドポイント A とエンドポイント B の 2 つのエンドポイントがあり、セキュリティで保護された接続を確立しようとしているとします。エンドポイント B がエンドポイント A に証明書を提示すると、エンドポイント A は証明書が有効かどうかを確認します。エンドポイント A の CA は、エンドポイント B が承認を受けるために使用している署名付き証明書を検証します。 trusted-ca または trusted-ca-group が設定されている場合、デバイスは、この trusted-ca-group で追加された CA プロファイルまたは trusted-ca で設定された CA プロファイルのみを使用して、エンドポイント B からの証明書を検証します。証明書が有効であることが確認された場合、接続は許可され、そうでない場合は接続が拒否されます。

利点：

• 着信接続要求では、それぞれのエンドポイントの特定の信頼できる CA によって発行された証明書のみが検証されます。そうでない場合、認証は接続を拒否します。

暗号化キーの処理

暗号化キーの処理では、キーを変更せずに、永続的なキーをデバイス メモリに格納します。内部メモリは敵対者からアクセスできません。暗号化キーのキー処理メカニズムを有効にして、セキュリティを提供できます。

暗号化キーの処理を有効にすると、次のようになります。

• 暗号化キーの処理では、すぐに使用しないときにキーが暗号化されます。

• あるメモリ位置から別のメモリ位置にキーをコピーするときにエラー検出を実行します。

• キーが使用されなくなったときに、キーのメモリ位置をランダムなビットパターンで上書きします。

暗号管理者は、暗号自己診断テスト機能を有効または無効にすることができます。ただし、セキュリティー管理者は、定期的な自己診断の構成や暗号自己診断テストのサブセットの選択など、暗号自己診断機能の動作を変更することができます。

現在、次の永続キーは IKE と PKI の管理下にあります。

• IKE PSK(IKE事前共有鍵)

• PKI 秘密キー

• 手動 VPN キー

証明書の署名と検証

デジタル証明書は、CA と呼ばれる信頼できるサードパーティーを通じて ID を確認するための電子的な手段です。 または、自己署名証明書を使用して ID を証明することもできます。

使用する CA サーバーは、独立した CA または独自の組織によって所有および運用され、その場合は独自の CA になります。独立 CA を使用する場合は、その CA および CRL サーバーのアドレス (証明書と CRL を取得するため)、および個人証明書要求をサブミットする際に必要な情報について、その CA に連絡する必要があります。自分自身の CA の場合は、この情報を自分で決定します。

証明書を発行する CA は、ハッシュ アルゴリズムを使用してダイジェストを生成し、そのダイジェストを秘密キーで暗号化して証明書に "署名" します。その結果、デジタル署名が作成されます。その後、CA は、デジタル署名された証明書を要求したユーザーがダウンロードできるようにします。

証明書の受信者は、同じハッシュアルゴリズムを証明書ファイルに適用して別のダイジェストを生成し、CAの公開キーを使用してデジタル署名を復号化します。復号化されたダイジェストと新しく生成されたダイジェストを比較することで、受信者は CA の署名の整合性、ひいては付随する証明書の整合性を確認できます。 図 1 は、このプロセス全体を示しています。

デジタル署名を検証でき、証明書のシリアル番号が CRL に記載されていない場合、証明書は有効と見なされます。

DSA 署名が使用される場合、SHA-1 ハッシュ アルゴリズムを使用してダイジェストが生成されます。Rivest-Shamir-Adleman(RSA)署名が使用される場合、SHA-1はダイジェストの生成に使用されるデフォルトのハッシュアルゴリズムです。SHA-256 ハッシュ アルゴリズムは、request security pki generate-certificate-request または request security pki local-certificate generate-self-signed コマンドの digest オプションで指定できます。ECDSA 署名を使用する場合、ECDSA-256 署名には SHA-256 が使用され、ECDSA-384 署名には SHA-384 が使用されます。

Junos OS リリース 18.1R3 以降、自動および手動で生成された自己署名 PKI 証明書の検証に使用されるデフォルトのハッシュ アルゴリズムは SHA-256 です。Junos OS リリース 18.1R3 より前は、SHA-1 がデフォルトのハッシュ アルゴリズムとして使用されています。

証明書の検証

証明書の信頼性を検証するには、ローカル証明書を発行している CA から CA ドメインのルート証明機関までの認定 CA のパスを追跡できる必要があります。PKI は、公開鍵暗号の実装を成功させるために必要な信頼の階層構造を指します。

図 2 は、複数の階層レベルを持つ単一ドメイン CA の構造を示しています。

証明書が組織内でのみ使用される場合、その組織は、会社の CA が従業員の証明書を発行および検証する独自の CA ドメインを持つことができます。その組織が、後でその従業員が自分の証明書を別の CA ドメインの証明書 (たとえば、独自の CA ドメインを持つ別の組織の従業員) と交換することを希望する場合、2 つの CA は、互いの機関を信頼することに同意することによって、相互認証を開発できます。この場合、PKI 構造は、垂直方向には拡張されませんが、水平方向には拡張されます。 図 3 を参照してください。