公開鍵インフラストラクチャ

公開鍵インフラストラクチャ( PKI ) は、デジタル証明書の作成、管理、配布、使用、保存、取り消し、および公開鍵暗号化の管理に必要な一連の役割、ポリシー、ハードウェア、ソフトウェア、および手順です。

PKI の目的は、電子商取引、インターネット バンキング、機密メールなどのさまざまなネットワーク アクティビティで、情報の安全な電子転送を容易にすることです。単純なパスワードでは認証方法として不十分で、通信に関与する当事者の身元を確認し、転送される情報を検証するために、より厳密な証明が必要なアクティビティでは、PKI が必要です。

暗号化において、PKI は公開鍵をエンティティ (個人や組織など) のそれぞれの ID に結び付ける 仕組みです。 ^{[1] [2]この結び付きは、}証明機関(CA)による証明書の登録と発行のプロセスを通じて確立されます。結び付けの保証レベルに応じて、これは自動プロセスによって実行される場合もあれば、人間の監督の下で実行される場合もあります。ネットワーク経由で実行される場合、 CMPなどの安全な証明書登録または証明書管理プロトコルを使用する必要があります。

有効で正しい登録を保証するために CA によって委任される PKI の役割は、登録機関(RA) と呼ばれます。RA は、デジタル証明書の要求を受け入れ、要求を行ったエンティティを認証する責任があります。^[3]インターネットエンジニアリング タスク フォースの RFC 3647 では、RA を「証明書申請者の識別と認証、証明書申請の承認または拒否、特定の状況下での証明書の失効または一時停止の開始、加入者の証明書の失効または一時停止の要求の処理、加入者の証明書の更新またはキー再生成の要求の承認または拒否など、1 つ以上の機能を担当するエンティティ」と定義しています。ただし、RA は証明書に署名したり発行したりしません (つまり、RA は CA に代わって特定のタスクを委任されます)。^[4] Microsoft は下位 CA を RA と呼んでいる可能性がありますが、 ^[5]これは X.509 PKI 標準では正しくありません。 RA は CA のような署名権限を持たず、証明書の審査とプロビジョニングのみを管理します。したがって、Microsoft PKI の場合、RA 機能は Microsoft 証明書サービス Web サイトまたはActive Directory証明書サービスによって提供されます。Active Directory 証明書サービスは、Microsoft Enterprise CA と証明書テンプレートによる証明書ポリシーを適用し、証明書の登録 (手動または自動登録) を管理します。Microsoft スタンドアロン CA の場合、CA を制御するすべての手順は、Active Directory ではなく、CA をホストするシステムと CA 自体に関連付けられた管理およびアクセス手順に基づいているため、RA の機能は存在しません。Microsoft 以外の商用 PKI ソリューションのほとんどは、スタンドアロン RA コンポーネントを提供しています。

エンティティは、そのエンティティに関する情報に基づいて、各 CA ドメイン内で一意に識別できる必要があります。サードパーティの検証機関(VA) は、CA に代わってこのエンティティ情報を提供できます。

X.509標準は、公開鍵証明書の最も一般的に使用される形式を定義します。^[6]

PKI は「信頼サービス」を提供します。簡単に言えば、人やコンピュータなどのエンティティのアクションや出力を信頼することです。信頼サービスの目標は、機密性、整合性、信頼性 (CIA) の 1 つ以上の機能を尊重します。

機密性:いかなるエンティティも悪意を持って、または無意識にクリア テキストのペイロードを閲覧できないことを保証します。データは秘密にするために暗号化されるため、たとえ読み取られたとしても意味不明な文字として表示されます。機密性目的で PKI を使用する最も一般的な方法は、おそらくトランスポート層セキュリティ ( TLS ) のコンテキストです。TLS は、転送中、つまり送信中のデータのセキュリティを支える機能です。機密性のための TLS の典型的な例は、インターネット ブラウザーを使用して、パスワードを入力してインターネット ベースの Web サイトでホストされているサービスにログオンする場合です。

整合性:エンティティが送信データを少しでも変更 (改ざん) した場合、整合性が損なわれているため、変更が行われたことが明らかであることを保証します。整合性が損なわれるのを防ぐこと (改ざん防止) はそれほど重要ではないことがよくありますが、整合性が損なわれた場合に、そのことが明確に証明されること (改ざん防止) は非常に重要です。

信頼性:すべてのエンティティが接続先を確実に把握していること、または保護されたサービスに接続するときにその正当性を証明できることを保証します。前者はサーバー側認証と呼ばれ、通常はパスワードを使用して Web サーバーに認証するときに使用されます。後者はクライアント側認証と呼ばれ、スマート カード (デジタル証明書と秘密キーをホスト) を使用して認証するときに使用されることがあります。

公開鍵暗号は、安全でない公共ネットワーク上でエンティティが安全に通信し、デジタル署名を介してエンティティの身元を確実に検証できるようにする暗号化技術です。^[7]

公開鍵基盤（PKI）は、特定の公開鍵が特定のエンティティに属していることを確認するために使用されるデジタル証明書の作成、保存、配布のためのシステムです。PKIは、公開鍵をエンティティにマッピングするデジタル証明書を作成し、これらの証明書を中央リポジトリに安全に保存し、必要に応じて失効させます。^{[8] [9] [10]}

PKIは次の要素から構成されます: ^{[9] [11] [12]}

• デジタル証明書を保存、発行、署名する証明機関( CA)。
• デジタル証明書を CA に保存することを要求するエンティティの ID を確認する登録機関( RA)。
• 中央ディレクトリ、つまり、キーが保存され、インデックス付けされる安全な場所。
• 保存された証明書へのアクセスや発行される証明書の配信などを管理する証明書管理システム。
• PKI の手順に関する要件を規定した証明書ポリシー。その目的は、部外者が PKI の信頼性を分析できるようにすることです。

CA の主な役割は、特定のユーザーにバインドされた公開鍵にデジタル署名して公開することです。これは CA 自身の秘密鍵を使用して行われるため、ユーザー鍵の信頼性は CA の鍵の有効性に対する信頼に依存します。CA がユーザーやシステムとは別の第三者である場合、登録機関 (RA) と呼ばれます。これは CA とは別の場合とそうでない場合があります。^[13]鍵とユーザーのバインディングは、バインディングの保証レベルに応じて、ソフトウェアまたは人間の監督の下で確立されます。

信頼できる第三者機関（TTP）という用語は、認証局（CA）の意味で使われることもあります。さらに、PKI自体もCA実装の同義語としてよく使われます。^[14]

証明書は有効期限が切れる前に失効される可能性があり、これは証明書がもはや有効ではないことを示します。失効がなければ、攻撃者は有効期限が切れるまで、侵害された証明書や誤って発行された証明書を悪用することができます。^[15]したがって、失効は公開鍵インフラストラクチャの重要な部分です。^{[16]失効は発行}証明機関によって実行され、暗号的に認証された失効ステートメントを作成します。^[17]

失効情報をクライアントに配布する場合、失効の発見の適時性（したがって、攻撃者が侵害された証明書を悪用する機会）は、失効ステータスの照会におけるリソースの使用およびプライバシーの懸念とトレードオフになります。^[18]失効情報が利用できない場合（事故または攻撃のいずれかが原因）、クライアントは、フェイルハードにして証明書が失効しているものとして扱う（したがって可用性が低下する）か、フェイルソフトにして証明書が失効していないものとして扱う（したがって、攻撃者が失効を回避できるようにする）かを決定する必要があります。^[19]

失効チェックのコストと、信頼性の低いリモートサービスによる可用性への影響を考慮して、Webブラウザは失効チェックを制限し、チェックを行う場合はフェイルソフトにします。^[20] 証明書失効リストは日常的に使用するには帯域幅のコストがかかりすぎ、オンライン証明書ステータスプロトコルは接続の遅延とプライバシーの問題を引き起こします。フェイルハードチェックを可能にする他のスキームも提案されていますが、まだうまく導入されていません。^[16]

この信頼関係のモデルでは、CA は信頼できる第三者であり、証明書の主体 (所有者) と証明書を信頼する当事者の両方から信頼されます。

^{2015 年の NetCraft レポート[21]}によると、アクティブなトランスポート層セキュリティ(TLS) 証明書を監視するための業界標準では、「世界的な [TLS] エコシステムは競争が激しいものの、少数の大手 CA が支配しており、3 つの認証局 ( Symantec、Sectigo、GoDaddy ) が、公開 Web サーバーで発行されたすべての [TLS] 証明書の 4 分の 3 を占めています。[当社の] 調査開始以来、トップの座は Symantec (Symantec に買収される前はVeriSign ) が保持しており、現在はすべての証明書の 3 分の 1 弱を占めています。異なる方法論の影響を示すために、最もアクセス数の多い 100 万のサイトのうち、Symantec は使用されている有効な信頼できる証明書の 44% を発行しており、これは同社の市場シェア全体を大幅に上回っています。」と述べています。

証明書の発行管理方法に関する大きな問題を受けて、2017年から2021年にかけて、すべての主要プレーヤーが徐々にシマンテックが発行した証明書を信用しなくなりました。^{[22] [23] [24] [25]}

このアプローチでは、シングルサインオンシステム内でオフライン証明機関として機能するサーバーを使用します。シングルサインオンサーバーはクライアントシステムにデジタル証明書を発行しますが、それを保存することはありません。ユーザーは一時的な証明書を使用してプログラムなどを実行できます。このソリューションの種類は、 X.509ベースの証明書でよく見られます。^[26]

2020 年 9 月から、TLS 証明書の有効期間は 13 か月に短縮されます。

公開鍵情報の公開認証の問題に対する代替アプローチは、自己署名証明書とそれらの証明書の第三者による証明を使用する信頼のウェブ スキームです。単数形の「信頼のウェブ」という用語は、単一の信頼のウェブ、または共通の信頼ポイントの存在を意味するのではなく、複数の潜在的に相互に関連しない「信頼のウェブ」の 1 つを意味します。このアプローチの実装の例には、PGP (Pretty Good Privacy) とGnuPG (PGP の標準化された仕様であるOpenPGPの実装) があります。PGP と実装では、公開鍵情報の自己公開に電子メールのデジタル署名を使用できるため、独自の信頼のウェブを実装するのは比較的簡単です。

PGPなどの信頼のウェブの利点の 1 つは、信頼できる紹介者として証明書を保証する意思のあるドメイン内のすべての関係者 (企業内の内部 CA など) から完全に信頼されている PKI CA と相互運用できることです。「信頼のウェブ」が完全に信頼されている場合、信頼のウェブの性質上、1 つの証明書を信頼することは、そのウェブ内のすべての証明書を信頼することを意味します。PKI の価値は、証明書の発行を制御する標準と実践によってのみ決まります。PGP または個人的に確立された信頼のウェブを含めると、その企業またはドメインの PKI 実装の信頼性が大幅に低下する可能性があります。^[27]

信頼のウェブの概念は、1992 年に PGP の作成者であるPhil ZimmermannによってPGP バージョン 2.0 のマニュアルで初めて提唱されました。

時間が経つにつれて、信頼できる紹介者として指定したい他の人からの鍵が蓄積されます。他のすべての人はそれぞれ自分の信頼できる紹介者を選択します。そして、すべての人は徐々に他の人からの証明署名のコレクションを蓄積し、自分の鍵とともに配布します。その署名を受け取る人は誰でも、少なくとも 1 つまたは 2 つの署名を信頼するでしょう。これにより、すべての公開鍵に対する分散型のフォールト トレラントな信頼のネットワークが出現します。

公開鍵情報の公開認証を扱わないもう 1 つの代替案は、X.509とPGPの信頼の網の複雑さを克服するための 3 つの独立した取り組みから生まれた、シンプルな公開鍵インフラストラクチャ (SPKI) です。SPKIでは、信頼されるのは人物ではなく鍵であるため、ユーザーと人物を関連付けません。検証者が発行者でもあるため、SPKI では信頼の概念を使用しません。これは SPKI 用語で「承認ループ」と呼ばれ、承認は設計に不可欠です。^[28]このタイプの PKI は、証明書の承認、証明書情報などを第三者に依存しない PKI の統合を行うのに特に役立ちます。この良い例は、オフィス内の エアギャップネットワークです。

分散型識別子（DID）は、階層型PKIの標準である、識別子の集中型レジストリや鍵管理の集中型認証局への依存を排除​​します。DIDレジストリが分散型台帳である場合、各エンティティは独自のルート機関として機能することができます。このアーキテクチャは、分散型PKI（DPKI）と呼ばれます。^{[29] [30]}

PKIの開発は1970年代初頭にイギリスの諜報機関GCHQで行われ、ジェームズ・エリス、クリフォード・コックスらが暗号化アルゴリズムと鍵配布に関する重要な発見をしました。^[31] GCHQでの開発は極秘であったため、この研究の結果は秘密にされ、1990年代半ばまで公に認められませんでした。

1976 年にDiffie、Hellman、Rivest、Shamir、Adlemanによって安全な鍵交換アルゴリズムと非対称鍵アルゴリズムの両方が公開されたことで、安全な通信は完全に変わりました。高速デジタル電子通信 (インターネットとその前身) がさらに発展するにつれて、ユーザーが互いに安全に通信できる方法の必要性が明らかになり、その結果、ユーザーが実際にやり取りしている相手を確かめられる方法の必要性も明らかになりました。

さまざまな暗号化プロトコルが発明され、分析され、その中で新しい暗号化プリミティブが効果的に使用されました。ワールドワイドウェブの発明と急速な普及により、認証と安全な通信の必要性がさらに高まりました。商業上の理由（電子商取引、ウェブブラウザからの独自データベースへのオンラインアクセスなど）だけでも十分でした。NetscapeのTaher Elgamalと他の人たちによってSSLプロトコル（Web URLの「https 」）が開発されました。これには、キーの確立、サーバー認証（v3より前は一方向のみ）などが含まれていました。^[32]このようにして、安全な通信を望むWebユーザー/サイトのためにPKI構造が作成されました。

ベンダーや起業家は大きな市場の可能性を見出し、会社を設立し（または既存の会社で新しいプロジェクトを立ち上げ）、法的承認と責任からの保護を求めて運動を始めました。アメリカ法曹協会の技術プロジェクトでは、PKI運用の予測可能な法的側面のいくつかに関する広範な分析を公開し（ABAデジタル署名ガイドラインを参照）、その後まもなく、米国のいくつかの州（ 1995年にユタ州が最初）と世界中の他の管轄区域で法律を制定し、規制を採用し始めました。消費者団体はプライバシー、アクセス、責任の考慮事項について疑問を呈しましたが、これらは管轄区域によっては他の管轄区域よりも多く考慮されていました。^[33]

制定された法律や規制は異なり、PKI スキームを商業運用に成功させるには技術的および運用上の問題があり、進歩は先駆者たちが想像していたよりもはるかに遅いものでした。

21 世紀の最初の数年間、基盤となる暗号技術を正しく導入するのは明らかに容易ではありませんでした。操作手順 (手動または自動) を正しく設計するのは容易ではありませんでした (設計したとしても、技術に必要な完璧な実行は困難でした)。既存の標準では不十分でした。

PKI ベンダーは市場を見つけましたが、それは 1990 年代半ばに想定された市場とはまったく異なり、予想よりもゆっくりと、また予想とは若干異なる形で成長しました。^[34] PKI は期待されていた問題のいくつかを解決できず、いくつかの主要ベンダーは廃業するか、他社に買収されました。PKI は政府による実装で最も成功を収めています。現在までの最大の PKI 実装は、共通アクセス カードプログラム用の国防情報システム局(DISA) PKI インフラストラクチャです。

さまざまなタイプの PKI や、複数のベンダーの PKI には、次のような目的で使用される公開鍵やユーザー ID へのバインディングの提供など、さまざまな用途があります。

• 電子メールメッセージの暗号化および/または送信者認証（例：OpenPGPまたはS/MIMEを使用）。
• 文書の暗号化および/または認証（たとえば、文書がXMLとしてエンコードされている場合のXML 署名またはXML 暗号化標準）。
• アプリケーションに対するユーザーの認証(例:スマート カードログオン、 SSL/TLSによるクライアント認証)。Enigformおよびmod_openpgpプロジェクトでは、デジタル署名されたHTTP認証が実験的に使用されています。
• インターネット キー交換(IKE) やSSL/TLSなどの安全な通信プロトコルのブートストラップ。これらの両方において、安全なチャネル (「セキュリティ アソシエーション」)の初期セットアップでは非対称キー(つまり公開キー) 方式が使用されますが、実際の通信ではより高速な対称キー(つまり秘密キー) 方式が使用されます。
• モバイル署名は、モバイルデバイスを使用して作成され、場所に依存しない通信環境での署名または認証サービスに依存する電子署名です。^[35]
• モノのインターネットでは、相互に信頼されたデバイス間の安全な通信が必要です。公開鍵インフラストラクチャにより、デバイスは X.509 証明書を取得および更新できます。この証明書は、デバイス間の信頼を確立し、TLS を使用して通信を暗号化するために使用されます。

• OpenSSL は、最もシンプルな形式の CA であり、PKI 用のツールです。これは C で開発されたツールキットで、すべての主要なLinuxディストリビューションに含まれており、独自の (シンプルな) CA の構築と PKI 対応アプリケーションの両方に使用できます。( Apache ライセンス)
• EJBCA は、 Javaで開発されたフル機能のエンタープライズ グレードの CA 実装です。社内使用とサービスの両方で CA を設定するために使用できます。( LGPL ライセンス)
• XiPKI、^[36] CAおよびOCSPレスポンダー。SHA -3をサポートし、 Javaで実装されています。（Apacheライセンス）
• XCA ^[37]はグラフィカルインターフェースとデータベースです。XCAは基盤となるPKI操作にOpenSSLを使用します。
• DogTag は、 Fedora プロジェクトの一環として開発および保守されているフル機能の CA です。
• CFSSL ^{[38] [39]} CloudFlareがTLS証明書の署名、検証、バンドルのために開発したオープンソースツールキット。（ BSD 2条項ライセンス）
• Vault ^[40] HashiCorpが開発した秘密情報（TLS証明書を含む）を安全に管理するためのツール。（Mozilla Public License 2.0ライセンス）
• Boulder は、Goで書かれたACMEベースの CA です。Boulder は、 Let's Encrypt を実行するソフトウェアです。

SSL/TLSでウェブサイトを保護し、コード署名でソフトウェアを保護するための証明書を購入することは、中小企業にとってはコストのかかる事業であると主張する人もいます。^{[41]しかし、} Let's Encrypt などの無料の代替手段の出現により、この状況は変わりました。 HTTPプロトコルの最新バージョンであるHTTP/2は、理論上は保護されていない接続を許可します。実際には、主要なブラウザ企業は、PKIで保護されたTLS接続でのみこのプロトコルをサポートすることを明らかにしています。 ^[42] Chrome、Firefox、Opera、EdgeなどのHTTP/2のウェブブラウザ実装は、TLSプロトコルのALPN拡張を使用することで、TLS経由でのみHTTP/2をサポートしています。つまり、HTTP/2の速度上の利点を得るには、ウェブサイトの所有者は企業が管理するSSL/TLS証明書を購入する必要があります。

現在、ほとんどのウェブブラウザには、いわゆるルート証明書によって認証された公開鍵によって証明機関が発行・署名した中間証明書がプリインストールされています。つまり、ブラウザは多数の異なる証明書プロバイダーを持ち運ぶ必要があり、鍵が侵害されるリスクが高まります。^[43]

キーが侵害されたことが判明した場合、証明書を取り消すことで修正できますが、このような侵害は簡単には検出できず、大きなセキュリティ侵害となる可能性があります。ブラウザは、侵害されたルート証明機関によって発行された中間証明書を取り消すためにセキュリティパッチを発行する必要があります。^[44]

• 暗号化の敏捷性（暗号敏捷性）
• 証明書管理プロトコル(CMP)
• CMS 経由の証明書管理(CMC)
• シンプル証明書登録プロトコル(SCEP)
• セキュアトランスポート経由の登録(EST)
• 自動証明書管理環境(ACME)
• リソース公開鍵基盤(RPKI)

• チョン、テジュン; ロク、ジェイ; チャンドラセカラン、バラクリシュナン; チョフネス、デイビッド; レビン、デイブ; マッグス、ブルース M.; ミスラブ、アラン; ルーラ、ジョン; サリバン、ニック; ウィルソン、クリスト (2018)。「Web は OCSP 必須ステープルに対応していますか?」( PDF)。インターネット測定カンファレンス 2018 の議事録。pp. 105–118。doi : 10.1145/3278532.3278543。ISBN 9781450356190.S2CID 53223350  。
• Larisch, James; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Wilson, Christo (2017)。「CRLite: すべての TLS 失効をすべてのブラウザーにプッシュするためのスケーラブルなシステム」。2017 IEEEセキュリティおよびプライバシーシンポジウム (SP) 。pp . 539–556。doi : 10.1109/ sp.2017.17。ISBN 978-1-5090-5533-3. S2CID  3926509。
• Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (2022 年 11 月). トランスポート層セキュリティ (TLS) とデータグラム トランスポート層セキュリティ ( DTLS ) の安全な使用に関する推奨事項。doi : 10.17487/RFC9325 . RFC 9325。
• スミス、トレバー、ディキンソン、ルーク、シーモンズ、ケント( 2020)。「Let's Revoke: スケーラブルなグローバル証明書失効」。2020年ネットワークおよび分散システム セキュリティ シンポジウム議事録。doi : 10.14722 / ndss.2020.24084。ISBN 978-1-891562-61-7. S2CID  211268930。

• SSL 認証局の市場シェア動向 (W3Techs)