Loading article…
暗号学において、証明機関または認証局( CA ) は、デジタル証明書を保存、署名、発行する機関です。デジタル証明書は、証明書の指定された主体による公開鍵の所有権を証明します。これにより、他者 (信頼当事者) は、証明された公開鍵に対応する秘密鍵に関する署名またはアサーションに依存できるようになります。CA は、証明書の主体 (所有者) と証明書に依存する当事者の両方から信頼される、信頼できる第三者として機能します。[1]これらの証明書の形式は、X.509またはEMV標準によって指定されます。
認証局の特に一般的な用途の1つは、ワールドワイドウェブの安全なブラウジングプロトコルであるHTTPSで使用される証明書に署名することです。もう1つの一般的な用途は、文書に電子署名するために各国政府が身分証明書を発行することです。[2]
概要
信頼できる証明書を使用すると、インターネット経由でサーバーへの安全な接続を作成できます。証明書は、ターゲットサーバーへのルート上に偶然いて、あたかもそれがターゲットであるかのように動作する悪意のある当事者を回避するために不可欠です。このようなシナリオは、一般に中間者攻撃と呼ばれます。クライアントは、安全な接続を開始する前の承認の一部として、CA証明書を使用してサーバー証明書のCA署名を認証します。[3] 通常、クライアントソフトウェア（ブラウザなど）には、信頼できるCA証明書のセットが含まれています。多くのユーザーがクライアントソフトウェアを信頼する必要があるため、これは理にかなっています。悪意のあるクライアントまたは侵害されたクライアントは、セキュリティチェックをスキップして、ユーザーをだましてそうではないと信じ込ませることができます。
CA のクライアントは、サーバがユーザに付与する証明書を要求するサーバ管理者です。商用 CA は証明書の発行に料金を請求し、その顧客は認証サーバへの安全な接続がすぐに効率的に機能するように、ほとんどの Web ブラウザに CA の証明書が含まれていることを期待しています。特定の証明機関を信頼するインターネット ブラウザ、その他のデバイス、アプリケーションの数は、ユビキタスと呼ばれます。非営利企業であるMozillaは、自社製品とともにいくつかの商用 CA 証明書を発行しています。 [4] Mozilla は独自のポリシーを開発しましたが、CA/ブラウザ フォーラムはCA の信頼に関する同様のガイドラインを開発しました。単一の CA 証明書を複数の CA またはその再販業者間で共有できます。ルートCA 証明書は、さまざまな検証要件を持つ 複数の中間CA 証明書を発行するためのベースになる場合があります。
商用 CA に加えて、Let's Encryptなどの一部の非営利団体も公的に信頼されたデジタル証明書を無料で発行しています。一部の大規模なクラウド コンピューティングおよび Web ホスティング企業も公的に信頼された CA であり、IBM Cloud、Amazon Web Services、Cloudflare、Google Cloud Platformなどのインフラストラクチャでホストされているサービスに証明書を発行しています。
大規模な組織や政府機関は独自の PKI (公開鍵インフラストラクチャ) を持ち、それぞれに独自の CA が含まれている場合があります。自己署名証明書を使用するサイトは、独自の CA として機能します。
EMV決済カードを発行する商業銀行は、EMV認証局[5]によって管理されています。EMV認証局は、 POS（Point of Sale Terminal ）で開始された決済取引をカード発行銀行にルーティングし、カード所有者の銀行口座から支払い受取人の銀行口座に資金を送金する決済スキームです。各決済カードは、カードデータとともにカード発行者証明書も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、シスコ、アカマイを含む企業や非営利団体のグループが、無料のドメイン検証済みX.509証明書と、証明書のインストールとメンテナンスを可能にするソフトウェアを提供する非営利の認証局であるLet's Encryptを発表しました。 [14] Let's Encryptは、連邦税免除が認められているカリフォルニア州の非営利団体で、新たに設立されたInternet Security Research Groupによって運営されています。[15]
2015 年 5 月のNetcraftによると、アクティブな TLS 証明書を監視する業界標準は、「世界的な [TLS] エコシステムは競争が激しいものの、少数の大手 CA が支配しています。3 つの認証局 (Symantec、Comodo、GoDaddy) が、公開 Web サーバーで発行されたすべての [TLS] 証明書の 4 分の 3 を占めています。[当社の] 調査開始以来、トップの座は Symantec (Symantec に買収される前の VeriSign) が保持しており、現在はすべての証明書の 3 分の 1 弱を占めています。異なる方法論の影響を示すために、最も混雑している 100 万のサイトのうち、Symantec は使用されている有効な信頼できる証明書の 44% を発行しており、これは同社の市場シェア全体を大幅に上回っています。」[16]
2020年、独立調査会社Netcraftによると、「DigiCertは世界最大の高保証認証局であり、Extended Validation証明書市場の60％、世界中の組織検証証明書の96％を占めています。」[17]
2024年7月現在、Alexa[アップデート]上位1000万サイトとTranco上位100万サイトの認証局の使用状況に関する統計を収集している調査会社W3Techsは、絶対的な使用シェアで上位6位の認証局を以下のようにリストアップしている。[18]
検証基準
HTTPS サーバーの証明書の大半を発行する商用 CA は、通常、「ドメイン検証」と呼ばれる手法を使用して証明書の受信者を認証します。ドメイン検証に使用される手法は CA によって異なりますが、一般的にドメイン検証手法は、証明書の申請者が特定のドメイン名を管理していることを証明するためのものであり、申請者の身元に関する情報を証明するものではありません。
多くの証明機関は、ドメイン検証証明書のより厳格な代替手段として、拡張検証(EV) 証明書も提供しています。拡張検証は、ドメイン名の管理だけでなく、証明書に含まれる追加の ID 情報も検証することを目的としています。一部のブラウザでは、この追加の ID 情報が URL バーの緑色のボックスに表示されます。ドメイン検証の弱点に対するソリューションとしての EV の 1 つの制限は、攻撃者が依然として被害者ドメインのドメイン検証証明書を入手し、攻撃中にそれを展開できることです。その場合、被害者のユーザーが目にする違いは、会社名が表示された緑色のバーがないことです。ユーザーがこの不在を攻撃が進行中であることの兆候として認識するかどうかについては疑問があります。2009年にInternet Explorer 7 を使用して行ったテストでは、IE7 の EV 警告がないことはユーザーには気づかれませんでした。ただし、Microsoft の現在のブラウザであるEdgeでは、EV 証明書とドメイン検証証明書の間に大きな違いが見られ、ドメイン検証証明書には中空の灰色の鍵が表示されます。
検証の弱点
ドメイン検証には、特定の構造的セキュリティ制限があります。特に、CA が送信するドメイン検証プローブを攻撃者が観察できる攻撃に対して常に脆弱です。これには、DNS、TCP、または BGP プロトコル (TLS/SSL の暗号化保護がない) に対する攻撃や、ルーターの侵害が含まれます。このような攻撃は、CA の近くのネットワーク上、または被害ドメイン自体の近くで発生する可能性があります。
最も一般的なドメイン検証技術の1つは、認証トークンまたはリンクを含む電子メールを、ドメインの管理責任者である可能性が高い電子メールアドレスに送信することです。これは、ドメインのWHOISエントリに記載されている技術担当者の電子メールアドレス、またはドメインのadmin@、administrator@、webmaster@、hostmaster@、postmaster@などの管理メールアドレス である可能性があります。[19] [20]一部の証明機関は、ドメイン内のroot@、[引用が必要] info@、またはsupport@を使用した確認を受け入れる場合があります。[21] ドメイン検証の理論は、ドメインの正当な所有者だけがこれらの管理アドレスに送信されたメールを読むことができるというものです。
ドメイン検証の実装は、セキュリティ上の脆弱性の原因となることがあります。ある例では、セキュリティ研究者は、CA がdomain.com の代わりにssladmin@domain.comのような電子メール アドレスを使用することをいとわなかったため、攻撃者が Web メール サイトの証明書を取得できることを示しました。ただし、すべての Web メール システムが、攻撃者が登録するのを防ぐために「ssladmin」というユーザー名を予約していたわけではありません。[22]
2011 年以前は、ドメイン検証に使用できる電子メール アドレスの標準リストがなかったため、電子メール管理者はどのアドレスを予約する必要があるかが明確ではありませんでした。2011年 11 月に採用されたCA/ブラウザー フォーラムベースライン要件の最初のバージョンでは、そのようなアドレスのリストが指定されました。これにより、メール ホストは管理用にそれらのアドレスを予約できましたが、このような予防措置はまだ普遍的ではありません。2015 年 1 月、フィンランドの男性がMicrosoft Liveのフィンランド語版でユーザー名「hostmaster」を登録し、ドメイン名の所有者ではないにもかかわらず、live.fi のドメイン検証済み証明書を取得できました。[23]
証明書の発行
CA は、公開鍵と所有者の ID を含むデジタル証明書を発行します。対応する秘密鍵は公開されず、鍵ペアを生成したエンド ユーザーによって秘密に保持されます。証明書は、証明書に含まれる公開鍵が証明書に記載されている人物、組織、サーバー、またはその他のエンティティに属していることを CA が確認または検証したものでもあります。このようなスキームにおける CA の義務は、申請者の資格情報を検証し、ユーザーと証明書の利用者が発行された証明書の情報を信頼できるようにすることです。CA は、さまざまな標準とテストを使用してこれを実行します。本質的に、証明機関は「はい、この人物は本人であり、私たち CA はそれを保証します」と述べる責任があります。[24]
ユーザーがCAを信頼し、CAの署名を検証できる場合、特定の公開鍵が証明書に記載されている人物のものであると想定することもできます。[25]
例
公開鍵暗号は、 2者間でやりとりされるデータを暗号化するために使用できます。これは通常、ユーザーがHTTP Secureプロトコルを実装しているサイトにログオンするときに発生します。この例では、ユーザーがオンラインバンキングを行うために銀行のホームページwww.bank.exampleにログオンするとします。ユーザーがwww.bank.exampleホームページを開くと、Webブラウザに表示されるすべてのデータとともに公開鍵を受け取ります。公開鍵は、クライアントからサーバーへのデータを暗号化するために使用できますが、安全な手順は、一時的な共有対称暗号化キーを決定するプロトコルで使用することです。このようなキー交換プロトコルのメッセージは、銀行の公開鍵で暗号化でき、銀行サーバーだけが秘密鍵を持ってメッセージを読み取ることができます。[26]
残りの通信は新しい (使い捨て) 対称キーを使用して続行されるため、ユーザーが銀行のページに何らかの情報を入力し、ページを送信する (情報を銀行に送り返す) と、ユーザーがページに入力したデータは Web ブラウザーによって暗号化されます。したがって、ユーザーから www.bank.example に送信された (暗号化された) データに誰かがアクセスできたとしても、そのような盗聴者はそれを読み取ったり解読したりすることはできません。
このメカニズムは、ユーザーが Web ブラウザに表示されているのが銀行であることを確信できる場合にのみ安全です。ユーザーが www.bank.example と入力したが、通信が乗っ取られ、偽の Web サイト (銀行の Web サイトを装う) がページ情報をユーザーのブラウザに送り返すと、偽の Web ページは偽の公開鍵 (偽のサイトは対応する秘密鍵を所有) をユーザーに送信できます。ユーザーはフォームに個人情報を入力し、ページを送信します。すると、偽の Web ページはユーザーのデータにアクセスできるようになります。
証明機関のメカニズムは、これを防ぐことを目的としています。証明機関 (CA) は、公開鍵とその所有者を保管する組織であり、通信に参加するすべての当事者はこの組織を信頼します (そして、その公開鍵を知っています)。ユーザーの Web ブラウザーが www.bank.example から公開鍵を受信すると、その鍵のデジタル署名も受信します (いわゆるX.509証明書内の追加情報も受信します)。ブラウザーはすでに CA の公開鍵を所有しているため、署名を検証し、証明書とその中の公開鍵を信頼できます。www.bank.example は証明機関が認証した公開鍵を使用しているため、偽の www.bank.example は同じ公開鍵しか使用できません。偽の www.bank.example は対応する秘密鍵を知らないため、その真正性を検証するために必要な署名を作成できません。[27]
安全
データが CA に提示されるとき (おそらく電子ネットワーク経由)、および証明書を要求する人物/会社/プログラムの資格情報も同様に提示されるとき、データとエンティティの一致の正確さを保証することは困難です。このため、商用 CA は、政府機関、支払いインフラストラクチャ、サードパーティのデータベースとサービス、カスタム ヒューリスティックの活用を含む認証手法の組み合わせを使用することがよくあります。一部のエンタープライズ システムでは、Kerberosなどのローカル形式の認証を使用して証明書を取得し、それを外部の信頼当事者が使用できます。公証人は、署名を公証する当事者を個人的に知っている必要がある場合があります。これは、多くの CA が達成している基準よりも高い基準です。米国法曹協会のオンライン トランザクション管理の概要によると、デジタル署名に関して制定された米国連邦法と州法の主なポイントは、「矛盾した、過度に負担の大きいローカル規制を防ぎ、電子文書が紙の文書に関連する従来の要件を満たすことを確立すること」です。さらに、米国の電子署名法と提案されたUETAコード[28]は、次のことを保証するのに役立ちます。
- 当該取引に関連する署名、契約書、その他の記録は、電子形式であるという理由のみで法的効力、有効性、執行可能性を否定されないものとする。
- 当該取引に関連する契約は、その締結に電子署名または電子記録が使用されたという理由のみで、法的効力、有効性または執行可能性を否定されることはない。
個人や企業の身元を正しく確認するためのセキュリティ対策が講じられているにもかかわらず、単一のCAが偽の証明書を偽造者に発行するリスクがあります。また、同じ名前または非常によく似た名前の個人や企業を登録することも可能であり、混乱を招く可能性があります。この危険を最小限に抑えるために、証明書の透明性イニシアチブは、すべての証明書を公開の偽造不可能なログで監査することを提案しており、これはフィッシングの防止に役立ちます。[29] [30]
大規模な展開では、アリスはボブの証明機関をよく知らない可能性があります (おそらくそれぞれ異なる CA サーバーを持っているため)。そのため、ボブの証明書には、アリスが認識できると思われる別の CA 2によって署名されたボブの CA の公開キーも含まれている可能性があります。このプロセスにより、通常、CA と CA 証明書の階層またはメッシュが作成されます。
証明書の失効
証明書は有効期限が切れる前に失効される可能性があり、これは証明書がもはや有効ではないことを示します。失効がなければ、攻撃者は有効期限が切れるまで、侵害された証明書や誤って発行された証明書を悪用することができます。[31]したがって、失効は公開鍵インフラストラクチャの重要な部分です。[32]失効は発行CAによって実行され、暗号的に認証された失効ステートメントを作成します。[33]
失効情報をクライアントに配布する場合、失効の発見の適時性（したがって、攻撃者が侵害された証明書を悪用する機会）は、失効ステータスの照会におけるリソースの使用およびプライバシーの懸念とトレードオフになります。[34]失効情報が利用できない場合（事故または攻撃のいずれかにより）、クライアントは、フェイルハードにして証明書を失効したものとして扱う（したがって可用性が低下する）か、フェイルソフトにして証明書を失効していないものとして扱う（したがって、攻撃者が失効を回避できるようにする）かを決定する必要があります。[35]
失効チェックのコストと、信頼性の低いリモートサービスによる可用性への影響を考慮して、Webブラウザは失効チェックを制限し、チェックを行う場合はフェイルソフトにします。[36] 証明書失効リストは、日常的に使用するには帯域幅のコストがかかりすぎ、オンライン証明書ステータスプロトコルは接続の遅延とプライバシーの問題を引き起こします。フェイルハードチェックを可能にする他のスキームも提案されていますが、まだうまく導入されていません。[32]
業界団体
- 認証局セキュリティ協議会（CASC） – 2013年2月、CASCは業界の問題に対処し、インターネットセキュリティについて一般の人々を啓蒙することを目的とした業界擁護団体として設立されました。創設メンバーは7つの最大の認証局です。[37] [38]
- 共通コンピューティングセキュリティ標準フォーラム（CCSF） – 2009年にCCSFはエンドユーザーを保護する業界標準を推進するために設立されました。ComodoグループのCEOであるMelih AbdulhayoğluがCCSFの創設者と考えられています。[39]
- CA/ブラウザフォーラム– 2005年に、インターネットセキュリティの業界標準と基本要件を促進するために、認証局とウェブブラウザベンダーの新しいコンソーシアムが結成されました。コモドグループのCEOであるメリフ・アブドゥルハヨルが最初の会議を主催し、CA/ブラウザフォーラムの創設者と見なされています。[40] [41]
ベースライン要件
CA/ブラウザフォーラムは、CAが従うべきポリシーと技術要件のリストであるベースライン要件[42]を公開しています。これは、Firefox [43]とSafari [44]の証明書ストアに含めるための要件です。
CA の妥協
CA が破壊されると、システム全体のセキュリティが失われ、侵害された CA を信頼するすべてのエンティティが破壊される可能性があります。
たとえば、攻撃者の Eve が CA から Alice を代理する証明書を発行してもらうことに成功したとします。つまり、証明書には Alice を代理する旨が公に記され、Alice に関するその他の情報も含まれる可能性があります。Alice に関する情報の一部、たとえば雇用主名などは真実である可能性があり、証明書の信頼性が高まります。ただし、Eve は証明書に関連付けられた非常に重要な秘密鍵を持っています。その後、Eve は証明書を使用してデジタル署名された電子メールを Bob に送信し、Bob にその電子メールが Alice からのものであると信じ込ませることができます。Bob は、その電子メールは Alice だけが読めるものと思い込んで、暗号化された電子メールで返信する可能性もありますが、実際には Eve は秘密鍵を使用してその電子メールを復号化できます。
このような CA 転覆の顕著な事例は 2001 年に発生しました。このとき、証明機関VeriSign はMicrosoft を代表していると主張する人物に 2 つの証明書を発行しました。証明書には「Microsoft Corporation」という名前が付けられているため、実際にはそうではないのに、Microsoft ソフトウェアの更新が Microsoft から提供されたと誰かを騙して信じ込ませるのに使用できました。この不正行為は 2001 年初頭に発覚しました。Microsoft と VeriSign は、問題の影響を抑えるための措置を講じました。[45] [46]
2008年、コモドの再販業者であるCertstarは、Mozillaを代表する権限を持たないEddy Niggにmozilla.comの証明書を販売しました。[47]
2011年にコモドとデジノタールから偽造証明書が入手されたが、[48] [49]イランのハッカーによるものとされている。この偽造デジノタール証明書がイランでの中間者攻撃に使用されたという証拠がある。[50]
2012年に、Trustwaveが透過的なトラフィック管理（中間者攻撃）に使用される従属ルート証明書を発行したことが明らかになりました。これにより、企業は従属証明書を使用してSSL内部ネットワークトラフィックを盗聴できるようになりました。[51]
2012年、Flameマルウェア（別名SkyWiper）には、壊れたMD5ハッシュアルゴリズムを使用したMicrosoftターミナルサーバーライセンス証明書によって発行された有効な証明書とMD5衝突を起こすモジュールが含まれていました。そのため、作成者は証明書に記載されているハッシュを使用して衝突攻撃を行うことができました。 [52] [53]
2015年、中国の中央ドメインレジストリに所属するMCSホールディングスという中国の認証局が、Googleドメインに対して無許可の証明書を発行した。[54] [55]そのため、GoogleはChromeからMCSとルート認証局の両方を削除し、証明書を失効させた。[56]
キーストレージ
証明機関の秘密鍵を盗んだ攻撃者は、CA のシステムに継続的にアクセスすることなく、自分が CA であるかのように証明書を偽造することができます。したがって、鍵の盗難は証明機関が防御する主なリスクの 1 つです。公的に信頼されている CA は、ほとんどの場合、鍵をハードウェア セキュリティ モジュール(HSM) に保存します。これにより、証明書に鍵で署名できますが、通常は物理的制御とソフトウェア制御の両方でその鍵の抽出を防止します。CA は通常、より短期間の中間証明書に署名する必要がある場合を除き、長期的なルート証明書の鍵をオフラインの HSM に保管するというさらなる予防策を講じます。オンライン HSM に保存された中間証明書は、エンド エンティティ証明書に署名し、失効情報を最新の状態に維持するという日常的な作業を行うことができます。
CA は、キーが改ざんされたりコピーされたりしないようにするために、署名キーを生成するときに キーセレモニーを使用することがあります。
信頼できる第三者スキームの実装上の弱点
現在の X.509 方式の実装方法における重大な弱点は、特定の当事者によって信頼されたどの CA も、選択したどのドメインに対しても証明書を発行できることです。このような証明書は、正当で認可されているかどうかに関わらず、信頼する当事者によって有効なものとして受け入れられます。[57] X.509 と信頼できる第三者を採用する最も一般的なテクノロジが HTTPS プロトコルであることを考えると、これは重大な欠点です。すべての主要な Web ブラウザは、数十に及ぶ信頼できる CA のリストが事前設定された状態でエンド ユーザーに配布されるため、これらの事前承認された信頼できる CA のいずれかが、どのようなドメインに対しても有効な証明書を発行できることになります。[58] これに対する業界の反応は沈黙しています。[59]ブラウザの事前設定された信頼できる CA リストの内容は、ブラウザ アプリケーションを配布またはインストールさせる当事者によって独立して決定されるため、CA 自体にできることは実際に何もありません。
この問題は、 DNS ベースの名前付きエンティティの認証(DANE) プロトコルの開発の原動力となっています。ドメイン ネーム システム セキュリティ拡張(DNSSEC)と組み合わせて採用された場合、DANE はドメインの PKI における信頼できる第三者の役割を大幅に削減するか、完全に排除します。
参照
参考文献
- ^ Chien, Hung-Yu (2021-08-19). 「Forward Secrecyを備えた動的公開鍵証明書」.エレクトロニクス. 10 (16): 2009. doi : 10.3390/electronics10162009 . ISSN 2079-9292.
- ^ 「証明機関 (CA) とは何ですか?」
- ^ Villanueva, John Carl. 「デジタル証明書の仕組み - 概要」www.jscape.com . 2021年9月5日閲覧。
- ^ 「Mozilla に含まれる CA 証明書リスト — Mozilla」。Mozilla.org。2013 年 8 月 4 日時点のオリジナルよりアーカイブ。2014 年 6 月 11 日閲覧。
- ^ 「EMV CA」。EMV Certificate Authority Worldwide。2010年10月2日。2019年2月17日閲覧。
- ^ Zakir Durumeric、James Kasten、Michael Bailey、J. Alex Halderman (2013 年 9 月 12 日)。「HTTPS 証明書エコシステムの分析」(PDF)。インターネット測定カンファレンス。SIGCOMM。2013年 12 月 22 日時点のオリジナルからアーカイブ(PDF) 。2013 年12月20 日に取得。
- ^ 「SSL証明書とは何ですか？」。2015年11月3日時点のオリジナルよりアーカイブ。2022年3月19日閲覧。
- ^ "webtrust". webtrust. 2013年8月18日時点のオリジナルよりアーカイブ。2013年3月2日閲覧。
- ^ Kirk Hall (2013 年 4 月)。「認証局に適用される標準および業界規制」(PDF)。トレンドマイクロ。2016年 3 月 4 日のオリジナルからアーカイブ(PDF) 。2014 年 6 月 11 日閲覧。
- ^ 「CA:IncludedCAs - MozillaWiki」。wiki.mozilla.org。2017年3月25日時点のオリジナルよりアーカイブ。2017年3月18日閲覧。
- ^ 「macOS High Sierra で利用可能な信頼されたルート証明書のリスト」。Appleサポート。2020 年 8 月 24 日閲覧。
- ^ 「Microsoft 付属 CA 証明書リスト」ccadb-public.secure.force.com . 2020 年 8 月 24 日閲覧。
- ^ 「HTTPS と SSL によるセキュリティ」。developer.android.com。2017年 7 月 8 日時点のオリジナルよりアーカイブ。2017 年 6 月 9 日閲覧。
- ^ 「Let's Encrypt: あらゆる場所で SSL/TLS を提供」(プレスリリース)。Let's Encrypt。2014 年 11 月 18 日時点のオリジナルよりアーカイブ。2014年 11 月 20 日閲覧。
- ^ 「About」。Let's Encrypt。2015年6月10日時点のオリジナルよりアーカイブ。2015年6月7日閲覧。
- ^ 「SSL証明書のカウント - Netcraft」。news.netcraft.com。2015年5月13日。2015年5月16日時点のオリジナルよりアーカイブ。
- ^ 「DigiCert - 世界最大の高保証認証局 | Netcraft」。trends.netcraft.com。
- ^ 「ウェブサイトのSSL認証局の使用統計、2024年8月 - W3Techs」w3techs.com。
- ^ 「公的に信頼される証明書の発行と管理に関する基本要件、v.1.2.3」(PDF)。2015 年 3 月 23 日のオリジナルからアーカイブ(PDF) 。2015年 3 月 20 日に取得。
- ^ 「CA/禁止または問題のある慣行 - MozillaWiki」。wiki.mozilla.org。2017年7月21日時点のオリジナルよりアーカイブ。2017年7月6日閲覧。
- ^ 「SSL FAQ - よくある質問 - Rapid SSL」。www.rapidssl.com。2015年2月6日時点のオリジナルよりアーカイブ。
- ^ Zusman, Mike (2009). 刑事告訴は行われない: PKI のハッキング(PDF)。DEF CON 17. ラスベガス。2013 年 4 月 15 日時点のオリジナルよりアーカイブ(PDF) 。
- ^ 「フィンランド人男性がシンプルなメールアカウントを作成し、Microsoft のセキュリティ証明書を受け取った」tivi.fi。2015年 8 月 8 日時点のオリジナルよりアーカイブ。
- ^ 「認証局の責任」。2015年2月12日時点のオリジナルよりアーカイブ。2015年2月12日閲覧。
- ^ 「ネットワークワールド」 2000年1月17日。
- ^ 応用暗号とネットワークセキュリティ：第2回国際会議、ACNS 2004、中国黄山、2004年6月8日〜11日。議事録。Springer。2004年6月。ISBN 9783540222170。
- ^ 証明書ライフサイクル管理のショートカットガイド。Realtimepublishers.com。2006年。ISBN 9781931491594。
- ^ 「電子署名と記録」(PDF) 。 2016年3月4日時点のオリジナルよりアーカイブ(PDF) 。 2014年8月28日閲覧。
- ^ 「証明書の透明性」。2013年11月1日時点のオリジナルよりアーカイブ。2013年11月3日閲覧。
- ^ B. Laurie、A . Langley、E. Kasper (2013 年 6 月)。証明書の透明性。インターネットエンジニアリング タスク フォース。doi : 10.17487/ RFC6962。ISSN 2070-1721。RFC 6962 。 実験的。 |- | 6963 |現在のベストプラクティス | P. Saint-Andre (2013 年 5 月)。例のための Uniform Resource Name (URN) 名前空間。インターネットエンジニアリング タスク フォース。doi : 10.17487/ RFC6963。ISSN 2070-1721。RFC 6963 。 | RFC 1930 を更新します。 |- |6979 |情報 | T. Pornin (2013 年 8 月)。デジタル署名アルゴリズム (DSA) と楕円曲線デジタル署名アルゴリズム (ECDSA) の決定論的使用法。独立した投稿。doi : 10.17487 / RFC6979。ISSN 2070-1721。RFC 6979 。 | |- |6980 |提案標準 | F. Gont (2013 年 8 月)。 IPv6 近隣探索による IPv6 フラグメンテーションのセキュリティへの影響。インターネット エンジニアリング タスク フォース。doi : 10.17487/RFC6980。ISSN 2070-1721。RFC 6980。 |RFC 3971 および 4861 を更新します。| - |6996 |現在のベスト プラクティス | J. Mitchell (2013 年 7 月)。プライベート使用のための自律システム (AS) 予約。インターネット エンジニアリング タスク フォース。doi : 10.17487/ RFC6996。ISSN 2070-1721。BCP 6。RFC 6996。 | RFC 1930 を更新します。 |} ← 前へ|次へ →
- ^ スミス、ディキンソン、シーモンズ 2020年、1ページ。
- ^ ab シェファー、サンタンドレ、フォッサティ 2022、7.5。証明書の失効。
- ^ Chung et al. 2018、p.3。
- ^ スミス、ディキンソン、シーモンズ 2020年、10頁。
- ^ ラリッシュら。 2017、p. 542.
- ^ スミス、ディキンソン、シーモンズ 2020年、1-2頁。
- ^ 「デジタル証明書の問題に対処するためにマルチベンダー電力協議会が結成」Network World 2013年2月14日。2013年7月28日時点のオリジナルよりアーカイブ。
- ^ 「主要な認証局が SSL セキュリティの名の下に団結」Dark Reading 2013 年 2 月 14 日。2013 年 4 月 10 日時点のオリジナルよりアーカイブ。
- ^ 「CA/Browser Forum Founder」。2014年8月23日時点のオリジナルよりアーカイブ。2014年8月23日閲覧。
- ^ 「CA/Browser Forum」。2013年5月12日時点のオリジナルよりアーカイブ。2013年4月23日閲覧。
- ^ Wilson, Wilson. 「CA/ブラウザフォーラムの履歴」(PDF)。DigiCert。2013年 5 月 12 日のオリジナルからアーカイブ(PDF) 。2013 年 4 月 23 日閲覧。
- ^ 「ベースライン要件」。CAB フォーラム。2013 年 9 月 4 日。2014 年 1 月 7 日時点のオリジナルよりアーカイブ。2017年4 月 14 日閲覧。
- ^ 「Mozilla Root Store Policy」。Mozilla。2017年4月15日時点のオリジナルよりアーカイブ。2017年4月14日閲覧。
- ^ 「Apple Root Certificate Program」。Apple。2017年3月20日時点のオリジナルよりアーカイブ。2017年4月14日閲覧。
- ^ "CA-2001-04". Cert.org. 2001年12月31日. 2013年11月2日時点のオリジナルよりアーカイブ。 2014年6月11日閲覧。
- ^ Microsoft, Inc. (2007-02-21). 「Microsoft セキュリティ速報 MS01-017: VeriSign 発行の誤ったデジタル証明書がなりすましの危険をもたらす」。2011 年 10 月 26 日時点のオリジナルよりアーカイブ。2011年 11 月 9 日閲覧。
- ^ Seltzer, Larry. 「SSL 証明書ベンダーが Mozilla.com CSSL 証明書をある人物に販売」eWeek . 2021 年12 月 5 日閲覧。
- ^ Bright, Peter (2011年3月28日). 「イランの独立系ハッカーがComodoハックの責任を主張」 Ars Technica. 2011年8月29日時点のオリジナルよりアーカイブ。2011年9月1日閲覧。
- ^ Bright, Peter (2011-08-30). 「別の不正な証明書が、証明機関に関する同じ古い疑問を提起」 Ars Technica. 2011-09-12 にオリジナルからアーカイブ。2011-09-01に取得。
- ^ Leyden, John (2011-09-06). 「『オペレーション・ブラック・チューリップ』の内部：DigiNotarハックの分析」The Register。2017-07-03時点のオリジナルよりアーカイブ。
- ^ 「Trustwave が中間者証明書を発行」The H Security 2012-02-07。2012-03-13 にオリジナルからアーカイブ。2012-03-14に取得。
- ^ 「Flame マルウェア衝突攻撃の説明 | MSRC ブログ | Microsoft セキュリティ レスポンス センター」。msrc.microsoft.com。2023年 10 月 13 日閲覧。
- ^ Goodin, Dan (2012-06-07). 「暗号技術のブレークスルーは、Flameが世界クラスの科学者によって設計されたことを示している」Ars Technica . 2023年10月13日閲覧。
- ^ Fisher, Dennis (2015-03-23). 「中国のレジストラにリンクされたCAが不正なGoogle証明書を発行」ThreatPost . 2023年9月27日閲覧。
- ^ Langley, Adam (2015-03-23). 「デジタル証明書のセキュリティの維持」。Googleセキュリティ ブログ。2023年 9 月 27 日閲覧。
- ^ Lowenthal, Tom (2015-03-31). 「中国のCNNICが偽の証明書を発行、暗号資産の信頼を深刻に侵害」ジャーナリスト保護委員会。2023年10月13日閲覧。
- ^ Osborne, Charlie. 「Symantec、不正なGoogle証明書を発行したとしてスタッフを解雇 - ZDNet」ZDNet。2016年10月2日時点のオリジナルよりアーカイブ。
- ^ 「不正な Google デジタル証明書が発見される」。linkedin.com。2014年 8 月 12 日。
- ^ 「インドの CA NIC による無許可の証明書発行を受けて、政府 CA は依然として「信頼できる第三者」とみなされるのか?」casecurity.org 2014 年 7 月 24 日。2016 年 10 月 3 日時点のオリジナルよりアーカイブ。
引用文献
- チョン、テジュン; ロク、ジェイ; チャンドラセカラン、バラクリシュナン; チョフネス、デイビッド; レビン、デイブ; マッグス、ブルース 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。
外部リンク
- HTTPS は現在どの程度安全ですか? 攻撃の頻度はどのくらいですか?、電子フロンティア財団(2011 年 10 月 25 日)