Loading article…
公開鍵基盤（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サイト、またはMicrosoft Enterprise CAと証明書ポリシーを証明書テンプレートを通じて適用し、証明書の登録（手動または自動登録）を管理するActive Directory証明書サービスによって提供されます。MicrosoftスタンドアロンCAの場合、CAを制御するすべての手順はActive Directoryではなく、CAをホストするシステムとCA自体に関連付けられた管理およびアクセス手順に基づいているため、RA機能は存在しません。Microsoft以外のほとんどの商用PKIソリューションは、スタンドアロンRAコンポーネントを提供しています。
各認証局（CA）ドメイン内では、エンティティは当該エンティティに関する情報に基づいて一意に識別可能でなければなりません。第三者検証機関（VA）は、CAに代わってこのエンティティ情報を提供することができます。
PKIは「信頼サービス」を提供します。簡単に言えば、人やコンピュータといったエンティティの行動や出力を信頼することです。信頼サービスの目的は、機密性、完全性、真正性（CIA）という1つ以上の機能を満たすことです。
機密性:いかなる主体も、悪意を持って、または意図せずペイロードを平文で閲覧できないことを保証します。データは暗号化されて秘密にされるため、たとえ読み取られたとしても、意味不明な文字列として表示されます。機密性目的での PKI の最も一般的な使用例は、トランスポート層セキュリティ ( TLS ) のコンテキストです。TLS は、転送中、つまり送信中のデータのセキュリティを支える機能です。機密性のための TLS の典型的な例は、Web ブラウザを使用して、インターネットベースの Web サイトでホストされているサービスにパスワードを入力してログインする場合です。
完全性：送信されたデータが何らかの形で変更（改ざん）された場合、その完全性が損なわれるため、改ざんが行われたことが明白になるという保証。多くの場合、完全性が損なわれることを防ぐこと（改ざん防止）は最重要事項ではないが、完全性が損なわれた場合に、その事実が明確に証明されること（改ざん検出）は最重要事項である。
真正性：エンティティが、i) 接続先を確実に認識していること、および/または ii) 保護されたサービスに接続する際に、自身の正当性を証明できることを保証すること。前者はサーバー証明書認証と呼ばれ、通常はWebサーバーへのログオン時に使用されます。後者はクライアント証明書認証と呼ばれ、例えばデジタル証明書と秘密鍵を格納するスマートカードを使用してログオンする場合などに使用されます。
公開鍵暗号は、安全でない公共ネットワーク上でエンティティが安全に通信し、デジタル署名によってエンティティの身元を確実に検証できるようにする暗号技術です。[ 7 ]
公開鍵基盤 (PKI) は、特定の公開鍵が特定のエンティティに属していることを検証するために使用されるデジタル証明書の作成、保存、配布を行うシステムです。PKI は、公開鍵をエンティティにマッピングするデジタル証明書を作成し、これらの証明書を中央リポジトリに安全に保存し、必要に応じて失効させます。[ 8 ] [ 9 ] [ 10 ]
CAの主な役割は、特定のユーザーに紐づけられた公開鍵にデジタル署名を行い、公開することです。これはCA自身の秘密鍵を使用して行われるため、ユーザー鍵の信頼性は、CAの鍵の正当性に対する信頼に依存します。CAがユーザーやシステムとは別の第三者である場合、それは登録機関（RA）と呼ばれ、CAとは別個の場合もあれば、そうでない場合もあります。[ 13 ]鍵とユーザーの紐付けは、紐付けの保証レベルに応じて、ソフトウェアまたは人間の監視下で確立されます。
信頼できる第三者機関(TTP)という用語は、認証局(CA)にも使用されることがあります。さらに、PKI 自体が CA 実装の同義語としてよく使用されます。[ 14 ]
証明書は有効期限が切れる前に失効させることができ、これは証明書がもはや有効ではないことを示します。失効がなければ、攻撃者は有効期限が切れるまで、侵害された、または誤って発行された証明書を悪用することができます。[ 15 ]したがって、失効は公開鍵インフラストラクチャの重要な部分です。[ 16 ]失効は発行認証局によって実行され、認証局は暗号的に認証された失効ステートメントを作成します。[ 17 ]
クライアントに失効情報を配信する場合、失効の発見の適時性（したがって、攻撃者が侵害された証明書を悪用できる期間）は、失効ステータスの照会におけるリソース使用量とプライバシーの懸念とトレードオフの関係にあります。[ 18 ]失効情報が利用できない場合（事故または攻撃による）、クライアントは、証明書が失効しているかのように扱う（可用性が低下する）か、失効していないかのように扱う（攻撃者が失効を回避できるようにする）かを決定する必要があります。[ 19 ]
失効チェックのコストと、信頼性の低い可能性のあるリモートサービスによる可用性への影響のため、Web ブラウザは失効チェックの実行を制限し、実行する場合はフェイルソフトで処理します。[ 20 ]証明書失効リストは、日常的に使用するには帯域幅のコストが高すぎ、オンライン証明書ステータスプロトコルは接続遅延とプライバシーの問題を引き起こします。フェイルハードチェックを可能にするための他のスキームが提案されていますが、まだ正常に展開されていません。[ 16 ]
この信頼関係のモデルでは、認証局（CA）は信頼できる第三者であり、証明書の主体（所有者）と証明書に依拠する当事者の両方から信頼されている。
NetCraftの2015年のレポート[ 21 ]によると、アクティブなトランスポート層セキュリティ（TLS）証明書を監視する業界標準では、「グローバルな[TLS]エコシステムは競争が激しいものの、少数の主要認証局（CA）が支配的であり、3つの認証局（Symantec、Sectigo、GoDaddy）が、公開Webサーバーで発行されたすべての[TLS]証明書の4分の3を占めている。調査開始以来、Symantec（またはSymantecに買収される前のVeriSign）がトップの座を維持しており、現在ではすべての証明書の3分の1弱を占めている。異なる方法論の影響を示す例として、最もトラフィックの多い100万サイトのうち、Symantecは使用されている有効で信頼できる証明書の44%を発行しており、これは同社の全体的な市場シェアを大幅に上回っている」と述べている。
証明書の発行管理方法に大きな問題があったため、2017年から2021年にかけて、すべての主要プレーヤーが徐々にSymantec発行の証明書を信用しなくなりました。[ 22 ] [ 23 ] [ 24 ] [ 25 ]
このアプローチでは、シングルサインオンシステム内でオフライン認証局として機能するサーバーを使用します。シングルサインオンサーバーはクライアントシステムにデジタル証明書を発行しますが、決して保存しません。ユーザーは一時的な証明書を使用してプログラムなどを実行できます。このソリューションは、 X.509ベースの証明書でよく見られます。[ 26 ]
2020年9月より、TLS証明書の有効期間が13ヶ月に短縮されました。
公開鍵情報の公開認証の問題に対する代替アプローチとして、自己署名証明書とそれらの証明書に対する第三者による証明を用いる信頼のウェブ方式があります。「信頼のウェブ」という単数形は、単一の信頼のウェブ、つまり共通の信頼点が存在することを意味するのではなく、むしろ互いに分離可能な複数の「信頼のウェブ」が存在することを意味します。このアプローチの実装例としては、PGP（Pretty Good Privacy）とGnuPG （PGPの標準仕様であるOpenPGPの実装）が挙げられます。PGPとその実装では、公開鍵情報の自己公開に電子メールのデジタル署名を使用できることから、独自の信頼のウェブを実装することは比較的容易です。
PGPなどの信頼のウェブの利点の 1 つは、ドメイン内のすべての関係者から完全に信頼されている PKI CA (企業内の内部 CA など) と相互運用できることです。信頼のウェブは、信頼できる紹介者として証明書を保証する意思があります。信頼のウェブが完全に信頼されている場合、信頼のウェブの性質上、1 つの証明書を信頼することは、そのウェブ内のすべての証明書を信頼することになります。PKI の価値は、証明書の発行を管理する標準と慣行によって決まります。PGP や個人的に確立された信頼のウェブを含めると、その企業またはドメインの PKI 実装の信頼性が著しく低下する可能性があります。[ 27 ]
信頼のウェブという概念は、PGPの開発者であるフィル・ジマーマンが1992年にPGPバージョン2.0のマニュアルの中で初めて提唱したものである。
時間が経つにつれて、あなたは信頼できる紹介者として指定したい他の人々から鍵を蓄積していくでしょう。他のすべての人はそれぞれ、信頼できる紹介者を選びます。そして、誰もが徐々に他の人々からの認証署名のコレクションを自分の鍵とともに蓄積し、配布していきます。受け取った人は、少なくとも1つか2つの署名を信頼するだろうという期待のもとに。こうして、すべての公開鍵のための分散型で耐障害性の高い信頼のネットワークが出現するでしょう。
公開鍵情報の公開認証を扱わない別の代替案として、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年にディフィー、ヘルマン、リベスト、シャミア、アドレマンらが安全な鍵交換アルゴリズムと非対称鍵アルゴリズムを公開したことで、安全な通信は完全に変革されました。高速デジタル電子通信（インターネットとその前身）のさらなる発展に伴い、ユーザー同士が安全に通信できる方法の必要性が明らかになり、その結果として、ユーザーが実際に誰とやり取りしているのかを確実に知る方法の必要性も生じました。
新しい暗号プリミティブを効果的に使用できるさまざまな暗号プロトコルが考案され、分析されました。ワールドワイドウェブの発明と急速な普及により、認証と安全な通信の必要性がさらに高まりました。商業的な理由だけでも十分でした（たとえば、電子商取引、ウェブブラウザからの独自のデータベースへのオンラインアクセスなど）。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（公開鍵基盤）は、複数のベンダーから提供されており、多くの用途があります。その用途の一つとして、公開鍵とユーザーIDとの関連付けの提供が挙げられます。これらは以下のような目的で使用されます。
SSL/TLSで Web サイトを保護し、コード署名でソフトウェアを保護するための証明書の購入は、中小企業にとって費用のかかる事業であると主張する人もいます。[ 41 ]しかし、 Let's Encrypt などの無料の代替手段の出現により、この状況は変わりました。HTTPプロトコルの最新バージョンであるHTTP/2は、理論上は安全でない接続を許可しますが、実際には、主要なブラウザ企業は、このプロトコルを PKI で保護されたTLS接続でのみサポートすることを明確にしています。[ 42 ] Chrome、Firefox、Opera、Edgeなどの Web ブラウザの HTTP/2 実装は、 TLS プロトコルのALPN拡張機能を使用することで、TLS 上でのみ HTTP/2 をサポートします。これは、HTTP/2 の速度上の利点を得るには、Web サイト所有者は企業が管理する SSL/TLS 証明書を購入せざるを得ないことを意味します。
現在、ほとんどのウェブブラウザには、いわゆるルート証明書によって認証された公開鍵によって認証局によって発行および署名された中間証明書がプリインストールされています。これは、ブラウザが多数の異なる証明書プロバイダーを保持する必要があり、鍵の漏洩のリスクが高まることを意味します。[ 43 ]
キーが侵害されたことが判明した場合、証明書を失効させることで修正できますが、そのような侵害は容易に検出できず、重大なセキュリティ侵害となる可能性があります。ブラウザは、侵害されたルート認証局によって発行された中間証明書を失効させるセキュリティパッチを発行する必要があります。[ 44 ]