Loading article…
暗号学において、認証局（ CA ）とは、デジタル証明書を保存、署名、発行する機関です。デジタル証明書は、証明書に指定された主体による公開鍵の所有権を証明します。これにより、他の者（依拠当事者）は、証明された公開鍵に対応する秘密鍵に関する署名または表明に依拠することができます。CAは、証明書の主体（所有者）と証明書に依拠する当事者の両方から信頼される、信頼できる第三者として機能します。[ 1 ]これらの証明書の形式は、X.509またはEMV規格で規定されています。
認証局の特に一般的な用途の1つは、ワールドワイドウェブの安全なブラウジングプロトコルであるHTTPSで使用される証明書に署名することです。もう1つの一般的な用途は、電子署名文書に使用するために各国政府が発行する身分証明書です。[ 2 ]
信頼できる証明書は、インターネット経由でサーバーへの安全な接続を確立するために使用できます。証明書は、ターゲット サーバーへの経路上にいる悪意のある第三者が、あたかもターゲットであるかのように振る舞うのを回避するために不可欠です。このようなシナリオは、一般的に中間者攻撃と呼ばれます。クライアントは、安全な接続を開始する前の認証の一部として、CA 証明書を使用してサーバー証明書の CA 署名を認証します。[ 3 ] 通常、クライアント ソフトウェア (たとえば、ブラウザー) には、信頼できる CA 証明書のセットが含まれています。これは、多くのユーザーがクライアント ソフトウェアを信頼する必要があるため、理にかなっています。悪意のあるクライアントや侵害されたクライアントは、セキュリティ チェックをスキップして、ユーザーを騙してそうではないと信じ込ませることができます。
CA のクライアントは、サーバーがユーザーに発行する証明書を要求するサーバー管理者です。商用 CA は証明書の発行に料金を請求し、顧客は、認証済みサーバーへの安全な接続がすぐに効率的に機能するように、CA の証明書がほとんどの Web ブラウザーに含まれていることを期待しています。特定の認証局を信頼する Web ブラウザー、その他のデバイス、およびアプリケーションの数は、ユビキティと呼ばれます。非営利団体であるMozilla は、製品とともにいくつかの商用 CA 証明書を発行しています。 [ 4 ] Mozilla は独自のポリシーを開発しましたが、CA/ブラウザー フォーラムは、CA の信頼に関する同様のガイドラインを開発しました。単一の CA 証明書は、複数の CA またはその再販業者間で共有される場合があります。ルートCA 証明書は、検証要件が異なる複数の中間CA 証明書を発行するためのベースとなる場合があります。
商用認証局（CA）に加えて、Let's Encryptなどの非営利団体も、無料で公的に信頼されるデジタル証明書を発行しています。また、 IBM Cloud、Amazon Web Services、Cloudflare、Google Cloud Platformなどの大手クラウドコンピューティング企業やウェブホスティング企業も、公的に信頼される認証局として、自社のインフラストラクチャ上でホストされているサービスに証明書を発行しています。
大規模な組織や政府機関は、それぞれ独自のPKI（公開鍵基盤）を保有している場合があり、それぞれに独自の認証局（CA）が含まれています。自己署名証明書を使用するサイトは、それ自体がCAとして機能します。
EMV決済カードを発行する商業銀行はEMV認証局[ 5 ]によって管理されており、決済スキームはPOS端末で開始された決済取引をカード発行銀行にルーティングし、カード所有者の銀行口座から支払い受取人の銀行口座に資金を送金します。各決済カードは、カードデータとともにカード発行証明書をPOSに提示します。発行証明書はEMV CA証明書によって署名されています。POSは、EMV CAの公開鍵をストレージから取得し、決済スキームに支払い要求を送信する前に、発行証明書と決済カードの真正性を検証します。
ブラウザやその他のクライアントでは、通常、ユーザーが自由に CA 証明書を追加または削除できます。サーバー証明書は通常比較的短い期間しか有効ではありませんが、CA 証明書はさらに延長されるため、[ 6 ]繰り返しアクセスするサーバーの場合、サーバーの証明書が更新されるたびにセキュリティ免除を確認するよりも、発行された CA をインポートして信頼する方がエラーが発生しにくくなります。
信頼性の高い証明書は、メッセージの暗号化や署名に使用されることは少ない。認証局（CA）はエンドユーザー証明書も発行しており、これはS/MIMEで使用できる。しかし、暗号化には受信者の公開鍵が必要であり、暗号化されたメッセージの作成者と受信者は互いに知り合いであるため、信頼できる第三者の有用性は、公開メーリングリストに送信されるメッセージの署名検証に限られる。
世界的に見ると、認証局事業は細分化されており、各国または地域ごとのプロバイダーがそれぞれの国内市場を支配している。これは、法的拘束力のある電子署名など、デジタル証明書の多くの用途が、認証局に対する現地の法律、規制、および認定制度と密接に関連しているためである。
しかし、世界的に信頼されているTLS/SSLサーバー証明書の市場は、少数の多国籍企業によってほぼ独占されています。この市場は、技術的な要件のために参入障壁が非常に高くなっています。 [ 7 ]法的に義務付けられているわけではありませんが、新規プロバイダーは、Webブラウザやオペレーティングシステムに信頼できるルートとして組み込まれるために、年次セキュリティ監査（北米の認証局の場合はWebTrust [ 8 ] 、ヨーロッパの場合はETSI [ 9 ]など）を受けることを選択する場合があります。
2020年8月24日現在 Mozilla Firefoxウェブ ブラウザでは 52 の組織を代表する 147 個のルート証明書が信頼されており、 [ 10 ] macOSでは 60 の組織を代表する 168 個のルート証明書が信頼されており、[ 11 ] Microsoft Windowsでは 101 の組織を代表する 255 個のルート証明書が信頼されています。[ 12 ] Android 4.2 (Jelly Bean) の時点では、Android には現在 100 を超える CA が含まれており、リリースごとに更新されています。[ 13 ]
2014年11月18日、電子フロンティア財団、Mozilla、Cisco、Akamaiなどの企業や非営利団体のグループが、無料のドメイン検証済みX.509証明書と証明書のインストールおよびメンテナンスを可能にするソフトウェアを提供する非営利の認証局であるLet's Encryptを発表しました。 [ 14 ] Let's Encryptは、新たに設立されたInternet Security Research Groupによって運営されています。Internet Security Research Groupは、連邦政府から免税対象として認められているカリフォルニア州の非営利団体です。[ 15 ]
Netcraftによると、2015年5月時点で、アクティブなTLS証明書を監視する業界標準として、「グローバルな[TLS]エコシステムは競争が激しいものの、少数の主要CAが支配的であり、3つの認証局（Symantec、Comodo、GoDaddy）が、公開Webサーバーで発行されたすべての[TLS]証明書の4分の3を占めている。調査開始以来、Symantec（またはSymantecに買収される前のVeriSign）がトップの座を維持しており、現在ではすべての証明書の3分の1弱を占めている。異なる方法論の影響を示す例として、最もアクセス数の多い100万サイトのうち、Symantecは使用されている有効で信頼できる証明書の44%を発行しており、これは同社の全体的な市場シェアを大幅に上回っている。」[ 16 ]
2024年7月現在 Alexaの上位1000万サイトとTrancoの上位100万サイトにおける認証局の使用状況に関する統計を収集している調査会社W3Techsは、絶対使用率で上位5位の認証局を以下のようにリストアップしている。[ 17 ]
HTTPSサーバー用の証明書の大部分を発行する商用認証局（CA）は、通常、「ドメイン検証」と呼ばれる手法を用いて証明書の受領者を認証します。ドメイン検証に使用される手法はCAによって異なりますが、一般的に、ドメイン検証の目的は、証明書申請者が特定のドメイン名を所有していることを証明することであり、申請者の身元に関する情報を証明することではありません。
多くの認証局は、ドメイン検証証明書よりも厳格な代替手段として、拡張検証（EV）証明書も提供しています。拡張検証は、ドメイン名の所有権だけでなく、証明書に含める追加のID情報も検証することを目的としています。一部のブラウザでは、この追加のID情報をURLバーの緑色のボックスに表示します。ドメイン検証の弱点に対する解決策としてのEVの制限の1つは、攻撃者が被害者ドメインのドメイン検証証明書を取得し、攻撃中にそれを展開する可能性があることです。その場合、被害者のユーザーが認識できる違いは、会社名が表示された緑色のバーがないことです。ユーザーがこの欠落を攻撃が進行中であることを示すものとして認識できるかどうかは疑問です。 2009年にInternet Explorer 7を使用して行われたテストでは、IE7のEV警告がないことにユーザーは気づかなかったことが示されましたが、Microsoftの新しいブラウザであるEdge Legacyでは、EV証明書とドメイン検証証明書の間にかなり大きな違いが見られ、ドメイン検証証明書には中空の灰色の鍵が表示されます。
ドメイン検証には、構造的なセキュリティ上の制約がいくつか存在する。特に、認証局（CA）が送信するドメイン検証プローブを攻撃者が傍受できるような攻撃に対して常に脆弱である。こうした攻撃には、DNS、TCP、BGPプロトコル（TLS/SSLのような暗号化による保護がない）に対する攻撃や、ルーターの侵害などが含まれる。このような攻撃は、CA近傍のネットワーク、あるいは被害ドメイン自体近傍のネットワークのいずれにおいても発生する可能性がある。
ドメイン検証の最も一般的な手法の 1 つは、認証トークンまたはリンクを含むメールを、ドメインの管理責任者である可能性が高いメールアドレスに送信することです。これは、ドメインのWHOISエントリに記載されている技術担当者のメールアドレス、またはドメインのadmin@、administrator@、webmaster@、hostmaster @、postmaster @などの管理者メールアドレスである可能性があります。 [ 18 ] [ 19 ] 一部の認証局は、ドメインのroot@、info@、またはsupport@を使用した確認を受け入れる場合があります。 [ 20 ] ドメイン検証の背後にある理論は、これらの管理者アドレスに送信されたメールを読むことができるのは、ドメインの正当な所有者だけであるということです。
ドメイン検証の実装は、セキュリティ脆弱性の原因となることがある。ある事例では、セキュリティ研究者が、認証局がdomain.comに対してssladmin@domain.comのようなメールアドレスを使用することに同意していたため、攻撃者がウェブメールサイトの証明書を取得できることを示したが、すべてのウェブメールシステムが「ssladmin」ユーザー名を予約して攻撃者が登録できないようにしていたわけではなかった。[ 21 ]
2011 年以前は、ドメイン検証に使用できる電子メール アドレスの標準リストがなかったため、どのアドレスを予約する必要があるかが電子メール管理者には明確ではありませんでした。2011年 11 月に採択されたCA/Browser Forumベースライン要件の最初のバージョンでは、そのようなアドレスのリストが指定されました。これにより、メール ホストは管理用にそれらのアドレスを予約できるようになりましたが、そのような予防措置はまだ普遍的ではありません。2015 年 1 月、フィンランド人男性がMicrosoft Liveのフィンランド版でユーザー名「hostmaster」を登録し、ドメイン名の所有者ではないにもかかわらず、live.fi のドメイン検証済み証明書を取得することができました。[ 22 ]
認証局 (CA) は、公開鍵と所有者の身元情報を含むデジタル証明書を発行します。対応する秘密鍵は公開されず、鍵ペアを生成したエンドユーザーによって秘密に保持されます。証明書はまた、証明書に含まれる公開鍵が証明書に記載されている人物、組織、サーバー、またはその他のエンティティに属していることを CA が確認または検証するものです。このようなスキームにおける CA の義務は、申請者の資格情報を検証し、ユーザーと信頼する当事者が発行された証明書の情報を信頼できるようにすることです。CA は、そのためにさまざまな標準とテストを使用します。本質的に、認証局は「はい、この人物は本人であり、私たち CA がそれを証明する」と述べる責任があります。[ 23 ]
ユーザーが認証局を信頼し、認証局の署名を検証できる場合、特定の公開鍵が証明書に記載されている人物に実際に属していると想定することもできます。[ 24 ]
公開鍵暗号は、 2者間で通信されるデータを暗号化するために使用できます。これは通常、ユーザーがHTTP Secureプロトコルを実装しているサイトにログインするときに発生します。この例では、ユーザーがオンラインバンキングを行うために銀行のホームページwww.bank.exampleにログインするとします。ユーザーがwww.bank.exampleホームページを開くと、Webブラウザに表示されるすべてのデータとともに公開鍵を受け取ります。公開鍵はクライアントからサーバーへのデータの暗号化に使用できますが、安全な手順は、一時的な共有対称暗号鍵を決定するプロトコルで使用することです。このような鍵交換プロトコル内のメッセージは、銀行の公開鍵で暗号化され、銀行サーバーのみがそれを読み取るための秘密鍵を持つようにすることができます。[ 25 ]
その後の通信は、新しい（使い捨ての）共通鍵を使用して行われます。ユーザーが銀行のページに情報を入力して送信（銀行に情報を送り返す）すると、ユーザーがページに入力したデータはウェブブラウザによって暗号化されます。したがって、たとえ誰かがユーザーからwww.bank.exampleに送信された（暗号化された）データにアクセスできたとしても、その盗聴者はデータを読み取ったり解読したりすることはできません。
この仕組みは、ユーザーがウェブブラウザに表示されているのが銀行のウェブサイトであると確信できる場合にのみ安全です。ユーザーがwww.bank.exampleと入力したとしても、通信が傍受され、偽のウェブサイト（銀行のウェブサイトを装ったもの）がページ情報をユーザーのブラウザに送信した場合、偽のウェブページは偽の公開鍵をユーザーに送信できます（偽サイトは対応する秘密鍵を所有しています）。ユーザーはフォームに個人情報を入力してページを送信します。すると、偽のウェブページはユーザーのデータにアクセスできるようになります。
これは、認証局メカニズムが防止しようとしているものです。認証局（CA）は、公開鍵とその所有者を保存する組織であり、通信に関わるすべての当事者はこの組織を信頼し（そして自身の公開鍵を知っています）。ユーザーのウェブブラウザがwww.bank.exampleから公開鍵を受信すると、鍵のデジタル署名（いわゆるX.509証明書にいくつかの追加情報を含む）も受信します。ブラウザは既にCAの公開鍵を所有しているため、署名を検証し、証明書とその中の公開鍵を信頼することができます。www.bank.exampleは認証局が証明した公開鍵を使用しているため、偽のwww.bank.exampleは同じ公開鍵しか使用できません。偽のwww.bank.exampleは対応する秘密鍵を知らないため、その正当性を検証するために必要な署名を作成することができません。[ 26 ]
データが認証局（CA）に提示される際（おそらく電子ネットワーク経由）、証明書を要求する個人／企業／プログラムの資格情報も同様に提示される場合、データとエンティティの一致の正確性を保証することは困難です。そのため、商用CAは、政府機関、決済インフラ、サードパーティのデータベースとサービス、カスタムヒューリスティックなど、複数の認証技術を組み合わせて使用することがよくあります。一部の企業システムでは、Kerberosなどのローカル認証方式を使用して証明書を取得し、それを外部の依拠当事者が使用することができます。公証人は、署名を公証する当事者を個人的に知っている必要がある場合もあります。これは、多くのCAが満たしている基準よりも高い基準です。米国弁護士協会のオンライン取引管理に関する概要によると、デジタル署名に関して制定された米国の連邦法および州法の主な目的は、「矛盾する過度に負担の大きい地方規制を防止し、電子文書が紙文書に関連する従来の要件を満たすことを確立すること」です。さらに、米国の電子署名法と提案されているUETAコード[ 27 ]は、以下のことを保証するのに役立つ。
個人や企業の身元を正しく検証するためのセキュリティ対策が講じられているにもかかわらず、単一の認証局がなりすまし犯に偽の証明書を発行するリスクがあります。また、個人や企業が同じ名前または非常によく似た名前で登録される可能性があり、混乱を招く可能性があります。この危険性を最小限に抑えるため、証明書透明性イニシアチブは、すべての証明書を公開の偽造不可能なログで監査することを提案しており、これはフィッシングの防止に役立つ可能性があります。[ 28 ] [ 29 ]
大規模な展開では、アリスはボブの認証局（CA）を知らない可能性があり（おそらくそれぞれ異なるCAサーバーを使用している）、そのためボブの証明書には、アリスが認識できる別のCA 2によって署名されたボブのCAの公開鍵が含まれる場合があります。このプロセスは通常、CAとCA証明書の階層構造またはメッシュ構造につながります。
証明書は有効期限が切れる前に失効させることができ、これは証明書がもはや有効ではないことを示します。失効がなければ、攻撃者は有効期限が切れるまで、侵害された、または誤って発行された証明書を悪用することができます。[ 30 ]したがって、失効は公開鍵インフラストラクチャの重要な部分です。[ 31 ]失効は発行CAによって実行され、暗号的に認証された失効ステートメントが生成されます。[ 32 ]
クライアントに失効情報を配信する場合、失効の発見の適時性（したがって、攻撃者が侵害された証明書を悪用できる期間）は、失効ステータスの照会におけるリソース使用量とプライバシーの懸念とトレードオフの関係にあります。[ 33 ]失効情報が利用できない場合（事故または攻撃による）、クライアントは、証明書が失効しているかのように扱う（可用性が低下する）か、失効していないかのように扱う（攻撃者が失効を回避できるようにする）かを決定する必要があります。[ 34 ]
失効チェックのコストと、信頼性の低い可能性のあるリモートサービスによる可用性への影響のため、Web ブラウザは失効チェックの実行を制限し、実行する場合はフェイルソフトで処理します。[ 35 ]証明書失効リストは、日常的に使用するには帯域幅のコストが高すぎ、オンライン証明書ステータスプロトコルは接続遅延とプライバシーの問題を引き起こします。フェイルハードチェックを可能にするための他のスキームが提案されていますが、まだ正常に展開されていません。[ 31 ]
CA/Browser Forum は、CA が従うべきポリシーと技術要件のリストであるベースライン要件[ 41 ]を公開しています。これらは、Firefox [ 42 ]および Safari [ 43 ]の証明書ストアに含めるための要件です。
2025年4月14日、CA/Browser Forumは、SSL/TLS証明書の有効期間を2029年3月15日までに最大47日間に短縮する投票を可決した。[ 44 ]
認証局（CA）が侵害された場合、システム全体のセキュリティが失われ、侵害されたCAを信頼しているすべての組織が危険にさらされる可能性がある。
例えば、攻撃者のイブが、認証局（CA）からアリスを名乗る証明書の発行を受け取ったとします。つまり、その証明書はアリスを名乗っていることを公に表明し、アリスに関するその他の情報も含まれている可能性があります。アリスの勤務先名など、アリスに関する情報の一部は真実である可能性があり、証明書の信頼性を高めます。しかし、イブは証明書に関連付けられた非常に重要な秘密鍵を所有しています。イブは、その証明書を使ってボブにデジタル署名付きのメールを送信し、ボブにメールがアリスから送られてきたものだと信じ込ませることができます。ボブは、アリスしか読めないと思い込んで暗号化されたメールで返信するかもしれませんが、実際にはイブは秘密鍵を使ってそれを復号化できるのです。
このような認証局の不正操作の注目すべき事例は、2001 年に認証局VeriSign がMicrosoft を名乗る人物に 2 つの証明書を発行した際に発生しました。これらの証明書には「Microsoft Corporation」という名前が付けられていたため、実際には Microsoft から提供されていない Microsoft ソフトウェアのアップデートが Microsoft から提供されていると誰かを騙すために使用できました。この不正は 2001 年初頭に発覚しました。Microsoft と VeriSign は問題の影響を最小限に抑えるための措置を講じました。[ 45 ] [ 46 ]
2008年、Comodoの再販業者であるCertstarは、Mozillaを代表する権限を持たないEddy Niggにmozilla.comの証明書を販売した。[ 47 ]
2011年に、イランのハッカーによってComodoとDigiNotarから不正な証明書が取得された[48][ 49 ] 。不正なDigiNotar証明書がイランでの中間者攻撃に使用されたという証拠がある[ 50 ] 。
2012年に、Trustwaveが透過的なトラフィック管理（中間者攻撃）に使用される下位ルート証明書を発行していたことが明らかになり、これにより企業は下位証明書を使用してSSL内部ネットワークトラフィックを傍受することが事実上可能になった。[ 51 ]
2012年、Flameマルウェア（SkyWiperとしても知られる）には、欠陥のあるMD5ハッシュアルゴリズムを使用するMicrosoft Terminal Serverライセンス証明書によって発行された有効な証明書とMD5衝突を起こすモジュールが含まれていました。そのため、作者は証明書に記載されているハッシュを使用して衝突攻撃を実行することができました。 [ 52 ] [ 53 ]
2015年、中国の中央ドメインレジストリと提携しているMCS Holdingsという中国の認証局が、Googleドメインに対して不正な証明書を発行した。[ 54 ] [ 55 ]そのためGoogleはChromeからMCSとルート認証局の両方を削除し、証明書を失効させた。[ 56 ]
認証局の秘密鍵を盗んだ攻撃者は、認証局のシステムへの継続的なアクセスを必要とせずに、あたかも認証局であるかのように証明書を偽造することができます。そのため、鍵の盗難は認証局が防御すべき主要なリスクの1つです。公的に信頼されている認証局は、ほぼ常にハードウェアセキュリティモジュール（HSM）に鍵を保管しています。これにより、鍵を使用して証明書に署名できますが、物理的およびソフトウェア的な制御によって鍵の抽出を防ぐことができます。認証局は通常、長期ルート証明書の鍵をオフラインのHSMに保管するというさらなる予防措置を講じています。ただし、有効期限の短い中間証明書に署名する必要がある場合は例外です。オンラインのHSMに保管されている中間証明書は、エンドエンティティ証明書に署名したり、失効情報を最新の状態に保ったりする日常業務を行うことができます。
認証局は、署名鍵を生成する際に、鍵が改ざんされたり複製されたりしないように、鍵生成儀式を行うことがあります。
現在の X.509 スキームの実装方法における重大な弱点は、特定の当事者が信頼する CA であれば、任意のドメインに対して証明書を発行できることである。このような証明書は、正当で認可されているかどうかに関わらず、信頼する当事者によって有効として受け入れられる。[ 57 ] X.509 と信頼できる第三者を使用する最も一般的な技術が HTTPS プロトコルであることを考えると、これは深刻な欠点である。すべての主要な Web ブラウザは、数十に及ぶ信頼された CA のリストがあらかじめ設定された状態でエンド ユーザーに配布されているため、これらの事前承認された信頼された CA のいずれかが、任意のドメインに対して有効な証明書を発行できることを意味する。[ 58 ] これに対する業界の反応は控えめである。[ 59 ]ブラウザの事前設定された信頼された CA リストの内容は、ブラウザ アプリケーションを配布またはインストールさせる当事者によって独立して決定されるため、CA 自体ができることは何もない。
この課題こそが、DNSベースの名前付きエンティティ認証（DANE）プロトコルの開発を推進する原動力となっている。ドメインネームシステムセキュリティ拡張（DNSSEC）と併用して採用されれば、DANEはドメインのPKIにおける信頼できる第三者の役割を大幅に削減、あるいは完全に排除するだろう。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)