인증국

Certificate authority

암호학에서 인증국 또는 인증국(CA)은 디지털 증명서를 저장, 서명 및 발급하는 주체입니다.디지털 증명서는 증명서의 명명된 주체별로 공개 키의 소유권을 증명합니다.이것에 의해, 다른 사람(기존 당사자)은, 서명이나, 증명된 공개 키에 대응하는 개인 키에 관한 어설션에 의존할 수 있습니다.CA는 신뢰할 수 있는 서드파티로서 기능합니다.증명서의 서브젝트(소유자)와 증명서에 의존하는 당사자의 양쪽 모두에 의해 신뢰됩니다.이러한 인증서의 형식은 X.509 또는 EMV 표준으로 지정되어 있습니다.

인증국에 있어서 특히 일반적인 용도는 HTTPS에서 사용되는 증명서에 서명하는 것입니다.HTTPS는 World Wide Web의 시큐어 브라우징 프로토콜입니다.또 다른 일반적인 용도는 전자서명 [1]서류에 사용하기 위해 국가 정부가 신분증을 발급하는 것이다.

개요

신뢰할 수 있는 인증서를 사용하여 인터넷을 통해 서버에 안전하게 연결할 수 있습니다.증명서는 타깃서버에의 루트에 있는 악의적인 파티를 회피하기 위해서 필수적입니다.이 파티는 타깃서버인 것처럼 동작합니다.이러한 시나리오를 보통 중간자 공격이라고 합니다.클라이언트는 CA 증명서를 사용하여 서버 증명서의 CA 시그니처를 인증합니다.이는 안전한 [2]접속을 시작하기 전에 인가의 일부입니다.보통 클라이언트소프트웨어(브라우저 등)에는 신뢰할 수 있는 CA 증명서 세트가 포함됩니다.이는 많은 사용자가 클라이언트 소프트웨어를 신뢰해야 하기 때문에 타당합니다.악의적인 클라이언트 또는 손상된 클라이언트는 보안 검사를 건너뛰고 사용자를 속여 그렇지 않다고 믿게 할 수 있습니다.

CA 클라이언트는 서버가 사용자에게 부여하는 증명서를 요구하는 서버 슈퍼바이저입니다.상용 CA는 증명서를 발급하기 위해 비용을 청구하며, 고객은 CA의 증명서가 대부분의 웹 브라우저에 포함되어 있을 것으로 예상하므로 인증 서버에 대한 안전한 연결이 즉시 효율적으로 작동합니다.특정 인증 기관을 신뢰하는 인터넷 브라우저, 기타 장치 및 응용 프로그램의 양을 유비쿼티라고 합니다.비영리 사업자인 Mozilla는 자사 제품과 [3]함께 여러 상용 CA 인증서를 발급합니다.Mozilla가 자체 정책을 개발한 반면 CA/Browser Forum은 CA 신뢰에 대한 유사한 지침을 개발했습니다.1개의 CA 증명서를 여러 CA 또는 재판매업자와 공유할 수 있습니다.루트 CA 증명서는 다양한 검증 요건을 가진 여러 중간 CA 증명서를 발급하기 위한 기반이 될 수 있습니다.

상업용 CA 외에 Let's Encrypt와 같이 일부 비영리 단체는 공개적으로 신뢰할 수 있는 디지털 인증서를 무료로 발급합니다.일부 대형 클라우드 컴퓨팅 및 웹 호스팅 회사도 공개적으로 신뢰할 수 있는 CA이며, Amazon Web Services, CloudflareGoogle Cloud Platform과 같은 인프라에서 호스팅되는 서비스에 인증서를 발급합니다.

대규모 조직이나 정부기관에는 각각 독자적인 CA를 포함한 독자적인 PKI(공개키 인프라스트럭처)가 있는 경우가 있습니다.자체 서명된 인증서를 사용하는 사이트는 자체 CA로 작동합니다.

EMV 결제 카드를 발행하는 시중은행은 POS(Point of Sale Terminals)에서 시작된 결제 거래를 카드 발급 은행으로 라우팅하여 카드 소유자의 은행 계좌에서 결제 수취인의 은행 계좌로 자금을 이체하는 결제 체계인 EMV 인증 [4]기관에 의해 관리됩니다.각 결제 카드는 카드 데이터와 함께 카드 발급자 증명서를 POS에 제시합니다.발급자 증명서는 EMV CA 증명서에 의해 서명됩니다.POS는 EMV CA의 공개키를 스토리지에서 취득하여 지불요구를 지불스킴에 송신하기 전에 발행자 증명서와 지불카드의 신뢰성을 검증합니다.

브라우저 및 기타 클라이언트에서는 사용자가 CA 증명서를 자유롭게 추가하거나 삭제할 수 있습니다.서버 증명서는 비교적 짧은 기간 동안 정기적으로 유지되지만 CA 증명서는 더욱 [5]확장됩니다.따라서 반복적으로 방문하는 서버의 경우 서버의 증명서가 갱신될 때마다 보안 면제를 확인하는 것이 아니라 발급된 CA를 가져오고 신뢰하는 것이 오류 발생 가능성이 낮습니다.

신뢰할 수 있는 인증서가 메시지 암호화 또는 서명에 사용되는 빈도는 낮습니다.CA는 S/MIME과 함께 사용할 수 있는 최종 사용자 증명서도 배포합니다.단, 암호화에는 수신자의 공개 키와 암호화된 메시지의 작성자와 수신자가 서로 알고 있는 것이 분명하기 때문에 신뢰할 수 있는 서드파티의 유용성은 퍼블릭 메일링 리스트에 송신되는 메시지의 서명 검증에 한정됩니다.

프로바이더

전 세계적으로 인증국 비즈니스는 국가 또는 지역 공급자가 자국 시장을 장악하면서 세분화되어 있습니다.이는 법적 구속력이 있는 디지털 서명 등 디지털 증명서의 많은 사용이 인증 기관의 현지 법률, 규제 및 인증 체계와 연계되어 있기 때문입니다.

다만, 글로벌하게 신뢰받는 TLS/SSL 서버 증명서의 시장은, 소수의 다국적 기업이 차지하고 있습니다.이 시장은 기술적 [6]요건으로 인해 진입에 상당한 장벽이 있습니다.법률적으로는 필요하지 않지만 새로운 프로바이더는 매년 보안 감사(북미의 인증국에 대한 WebTrust[7], 유럽의[8] ETSI 등)를 실시하여 웹 브라우저 또는 운영체제에 의해 신뢰할 수 있는 루트로 포함되도록 선택할 수 있습니다.

2020년 8월 24일 현재 Mozilla Firefox 웹 [9]브라우저에서 52개 조직을 나타내는 147개의 루트 증명서가 신뢰되고 있으며, 60개 조직을 나타내는 168개의 루트 증명서가 MacOS[10]의해 신뢰되고 있으며, [11]101개 조직을 나타내는 255개의 루트 증명서가 Microsoft Windows에 의해 신뢰되고 있습니다.Android 4.2(Jelly Bean) 현재 Android에는 100개 이상의 CA가 있으며,[12] 각 릴리스에 따라 업데이트되고 있습니다.

2014년 11월 18일, Electronic Frontier Foundation, Mozilla, Cisco 및 Akamai를 포함한 기업 및 비영리 단체 그룹은 무료 도메인 검증된 X.509 인증서와 [13]인증서 설치 및 유지 관리를 지원하는 소프트웨어를 제공하는 비영리 인증 기관인 Let's Encrypt를 발표했습니다.Let's Encrypt는 캘리포니아 비영리단체인 Internet Security Research Group에 의해 운영되며 연방정부에서 비과세 대상으로 [14]인정됩니다.

2015년 5월 Netcraft에 따르면 활성 TLS 인증서 모니터링 업계 표준은 다음과 같습니다.「글로벌 [TLS] 생태계는 경쟁력이 있지만, 공공용 Web 서버상에서 발행된 모든 [TLS] 인증서 중 4분의 3을 차지하는 3개의 인증 기관(Symantec, Comodo, GoDaddy))이 대부분을 차지하고 있습니다.1위는 [Symantec]조사가 시작된 이래 Symantec(또는 Symantec이 구입하기 전에는 VeriSign)이 차지하고 있으며, 현재는 전체 인증의 3분의 1도 되지 않습니다.다양한 방법론의 효과를 설명하기 위해 Symantec은 사용 중인 신뢰할 수 있는 유효 증명서의 44%를 발행했습니다.이는 전체 시장 [15]점유율을 크게 웃도는 수치입니다.

독립 조사 회사 Netcraft에 따르면, "DigiCert는 세계 최대의 고보증 인증 기관으로, 확장 검증 인증 시장의 60%, 조직 인증 인증의 96%를 [16]점유하고 있습니다.

2022년 7월 현재 Alexa Top 1000만 웹사이트와 Tranco Top 100만 웹사이트 중 인증국 이용 통계를 수집하는 조사업체 W3Techs는 절대적인 이용점유율 기준으로 6대 기관을 다음과 같이 열거하고 있습니다.[17]

순위 발행자 사용. 시장 점유율
1 Iden Trust (IdenTrust(신뢰) 43.4 48.9%
2 DigiCert 16.6% 18.7%
3 제1절 (코모도 사이버 보안) 13.8% 15.5%
4 암호화합시다 7.2% 8.2%
5 고다디 5.4% 6.1%
6 글로벌 사인 2.4% 2.7%

검증 기준

HTTPS 서버의 증명서 대부분을 발행하는 상용 CA는 일반적으로 "도메인 검증"이라는 기술을 사용하여 증명서 수신자를 인증합니다.도메인 검증에 사용되는 기법은 CA마다 다르지만 일반적으로 도메인 검증 기법은 증명서 신청자가 신청자의 ID에 대한 정보가 아니라 특정 도메인 이름을 통제한다는 것을 증명하기 위한 것입니다.

또한 많은 인증 기관은 도메인 검증 증명서의 보다 엄격한 대체 수단으로 확장 검증(EV) 증명서를 제공합니다.확장 검증은 도메인 이름의 제어뿐만 아니라 증명서에 포함할 추가 ID 정보를 확인하는 것을 목적으로 합니다.일부 브라우저에서는 URL 표시줄의 녹색 상자에 이 추가 ID 정보가 표시됩니다.도메인 검증의 취약점에 대한 해결책으로서의 EV의 한 가지 제한사항은 공격자가 여전히 공격 대상 도메인의 도메인 검증 증명서를 취득하여 공격 중에 전개할 수 있다는 것입니다.이러한 경우, 공격 대상 유저가 인식할 수 있는 차이는, 회사명의 녹색 바가 없는 것입니다.사용자가 이 부재를 공격이 진행 중임을 나타내는 것으로 인식할 수 있을지에 대해서는 의문이 있습니다.2009년 Internet Explorer 7을 사용한 테스트에서는 IE7의 EV 경고 부재가 사용자에 의해 인식되지 않았지만 Microsoft의 현재 브라우저인 Edge는 EV와 도메인 간에 현저한 차이를 보이고 있습니다.도메인 검증 증명서에 빈 회색 잠금이 있는 검증된 증명서를 사용합니다.

검증의 약점

도메인 검증에는 특정 구조적 보안 제한이 있습니다.특히 CA가 송신하는 도메인 검증 프로브를 상대방이 감시할 수 있는 공격에 항상 취약합니다.여기에는 DNS, TCP 또는 BGP 프로토콜에 대한 공격(TLS/SSL의 암호화 보호가 없음)이나 라우터의 손상 등이 포함됩니다.이러한 공격은 CA 근처 네트워크 또는 공격 대상 도메인 자체에서 발생할 수 있습니다.

가장 일반적인 도메인 검증 기법 중 하나는 인증 토큰이 포함된 전자 메일을 전송하거나 도메인에 대한 관리 책임이 있을 수 있는 전자 메일 주소로 링크를 보내는 것입니다.도메인 WHOIS 엔트리에 기재되어 있는 기술 연락처 이메일 주소 또는 다음과 같은 관리 이메일 주소입니다. admin@,[18][19] administrator@, webmaster@, hostmaster@ 또는 postmaster@ 도메인.일부 인증 기관은 도메인에서 [20]root@,[citation needed] info@ 또는 support@사용하여 확인을 수락할 수 있습니다.도메인 검증의 이면에 있는 이론은 도메인의 합법적인 소유자만이 이러한 관리 주소로 전송된 전자 메일을 읽을 수 있다는 것입니다.

도메인 검증 구현이 보안 취약성의 원인이 되는 경우가 있습니다.일례로 보안연구원은 CA가 domain.com에 대해 ssladmin@domain.com과 같은 이메일 주소를 사용하려고 했지만 공격자가 이를 [21]등록하는 것을 막기 위해 모든 웹 메일 시스템이 "sladmin" 사용자 이름을 예약한 것은 아니기 때문에 공격자가 웹 메일 사이트의 인증서를 얻을 수 있음을 보여 주었습니다.

2011년 이전에는 도메인 검증에 사용할 수 있는 표준 이메일 주소 목록이 없었기 때문에 관리자에게 어떤 주소를 예약해야 하는지 이메일 관리자에게 알 수 없었습니다.2011년 11월에 채택된 CA/Browser Forum Baseline Requirements의 첫 번째 버전에는 이러한 주소의 목록이 명시되어 있습니다.이렇게 하면 메일 호스트는 이러한 주소를 관리용으로 예약할 수 있지만, 이러한 예방 조치는 여전히 보편적이지 않습니다.2015년 1월 핀란드 남성이 Microsoft Live 핀란드 버전에 사용자 이름 "hostmaster"를 등록하고 도메인 이름의 [22]소유자가 아님에도 불구하고 live.fi의 도메인 인증서를 취득할 수 있었습니다.

증명서 발급

공개증명서를 취득하는 순서

CA는 공개 키와 소유자의 ID를 포함하는 디지털 증명서를 발급합니다.일치하는 개인 키는 공개적으로 사용할 수 없지만 키 쌍을 생성한 최종 사용자에 의해 비밀로 유지됩니다.증명서는 증명서에 포함된 공개키가 증명서에 기재되어 있는 개인, 조직, 서버 또는 기타 엔티티의 것임을 CA가 확인 또는 검증하는 것이기도 합니다.이러한 제도에서 CA의 의무는 신청자의 자격 증명을 검증하여 사용자와 의존 당사자가 발급된 인증서의 정보를 신뢰할 수 있도록 하는 것입니다.CA는 이를 위해 다양한 표준과 테스트를 사용합니다.기본적으로 인증 기관은 "네, 이 사람은 그들이 말하는 사람입니다. 그리고 우리는 CA가 그것을 증명합니다."[23]라고 말할 책임이 있습니다.

사용자가 CA를 신뢰하고 CA의 시그니처를 확인할 수 있는 경우 특정 공개 키가 [24]증명서 내에서 식별된 사용자의 것이라고 가정할 수도 있습니다.

공개키 암호화를 사용하여 두 당사자 간에 통신되는 데이터를 암호화할 수 있습니다.이 문제는 일반적으로 사용자가 HTTP Secure 프로토콜을 구현하는 사이트에 로그온할 때 발생할 수 있습니다.이 예에서는 사용자가 은행 홈페이지 www.bank.example에 로그인하여 온라인 뱅킹을 한다고 가정합니다.사용자가 www.bank.example 홈페이지를 열면 웹 브라우저에 표시되는 모든 데이터와 함께 공용 키가 수신됩니다.공용 키는 클라이언트에서 서버로 데이터를 암호화하는 데 사용할 수 있지만 안전한 절차는 임시 공유 대칭 암호화 키를 결정하는 프로토콜로 사용하는 것입니다. 이러한 키 교환 프로토콜의 메시지는 은행 서버만 [25]읽을 수 있는 개인 키를 갖도록 은행의 공용 키로 암호화할 수 있습니다.

그 후 나머지 통신은 새로운 (폐기 가능한) 대칭 키를 사용하여 진행되므로 사용자가 은행 페이지에 정보를 입력하고 페이지를 제출하면(은행에 정보를 다시 전송), 사용자가 페이지에 입력한 데이터는 웹 브라우저에 의해 암호화됩니다.따라서 사용자로부터 www.bank. 예시로 전달된 (암호화된) 데이터에 누군가 접근할 수 있더라도 그러한 도청자는 이를 읽거나 해독할 수 없습니다.

이 메커니즘은 사용자가 웹 브라우저에 은행임을 확인할 수 있는 경우에만 안전합니다.사용자가 www.bank.example에 입력했지만 통신이 납치되어 가짜 웹 사이트(은행 웹 사이트인 것처럼 가장)가 페이지 정보를 사용자의 브라우저로 되돌려 보내면 가짜 웹 페이지는 사용자에게 가짜 공개 키를 전송할 수 있습니다(이 경우 가짜 웹 사이트는 일치하는 개인 키를 소유합니다).사용자는 양식에 개인 데이터를 입력하고 페이지를 제출합니다.가짜 웹 페이지는 사용자의 데이터에 액세스할 수 있습니다.

이것이 인증국 메커니즘이 방지하는 것입니다.Certificate Authority(CA; 인증국)는 공개키와 그 소유자를 저장하는 조직으로 통신의 모든 당사자가 이 조직을 신뢰하고 공개키를 알고 있습니다.사용자의 웹 브라우저가 www.bank.example에서 공용 키를 수신하면 키의 디지털 서명도 수신합니다(자세한 내용은 이른바 X.509 인증서).브라우저는 이미 CA의 공개키를 가지고 있기 때문에 시그니처를 검증하고 증명서 및 공개키를 신뢰할 수 있습니다.www.bank.example은 인증기관이 인증한 공개키를 사용하므로 가짜 www.bank.example은 동일한 공개키만 사용할 수 있습니다.fake www.bank.example은 대응하는 개인 키를 모르기 때문에 [26]그 신뢰성을 확인하기 위해 필요한 시그니처를 작성할 수 없습니다.

보안.

데이터가 CA에 제시될 때(아마도 전자 네트워크를 통해), 그리고 인증서를 요청하는 개인/회사/프로그램의 자격 증명이 제시될 때 데이터와 엔티티 간의 일치의 정확성을 보장하는 것은 어렵다.이것이 상용 CA가 종종 정부 기관, 결제 인프라, 서드 파티의 데이터베이스와 서비스 및 사용자 정의 휴리스틱을 활용하는 등 인증 기술을 조합하여 사용하는 이유입니다.엔터프라이즈시스템에 따라서는 Kerberos 등의 로컬 형식의 인증을 사용하여 증명서를 취득할 수 있습니다.이 증명서는 외부 의존 당사자가 사용할 수 있습니다.경우에 따라서는 공증인은 서명이 공증되는 당사자를 직접 알아야 합니다.이것은 많은 CA가 도달하는 것보다 높은 기준입니다.미국 변호사 협회의 온라인 거래 관리에 관한 개요에 따르면, 디지털 서명에 관해 제정된 미국 연방 및 주 법령의 주요 포인트는 "상충되고 과도한 부담을 주는 지역 규제를 방지하고 전자 서류가 종이 문서와 관련된 전통적인 요건을 충족하도록 하는 것"이었다.미국 E-Sign 법령 및 제안된 UETA 코드는[27] 다음 사항을 보장하는 데 도움이 됩니다.

  1. 이러한 거래와 관련된 서명, 계약 또는 기타 기록은 그것이 전자적 형식이라는 이유만으로 법적 효력, 유효성 또는 집행력을 거부할 수 없다.
  2. 이러한 거래와 관련된 계약은 그 작성에 전자서명 또는 전자기록이 사용되었다고 해서 법적 효력, 유효성 또는 집행성을 부인할 수 없다.

사람과 회사의 신원을 정확하게 확인하기 위해 취해진 보안 조치에도 불구하고, 단일 CA가 가짜 증명서를 사기꾼에게 발급할 위험이 있습니다.또, 개인이나 기업의 이름이 같거나 매우 유사한 등록도 가능하기 때문에, 혼란을 초래할 가능성이 있습니다.이 위험을 최소화하기 위해 인증서 투명 이니셔티브피싱 [28][29]방지에 도움이 될 수 있는 공개 로그의 모든 인증서를 감사할 것을 제안합니다.

대규모 전개에서는 Alice가 Bob의 인증국에 익숙하지 않을 수 있습니다(각 CA 서버가 다를 수 있습니다).따라서 Bob의 증명서에는 Alice가 인식할 수 있는 다른2 CA에 의해 서명된 CA의 공개 키도 포함되어 있을 수 있습니다.이 프로세스는 보통 CA와 CA 증명서의 계층 또는 메시로 이어집니다.

증명서의 실효

WebPKI의 당국은 이전에 발급된 증명서를 무효화할 수 있도록 취소 서비스를 제공합니다.CA/Browser 포럼의 Baseline Requirements에 따르면 CA는 증명서가 만료될 때까지 실효 상태를 유지해야 합니다.상태는 Online Certificate Status Protocol을 사용하여 전달해야 합니다.인터넷에서 대부분의 해지 상태는 인증서 [30]만료 후 즉시 사라집니다.

권한 취소 목록

Authority Revocation List(ARL; 인증국 취소 목록)는 취소된 엔드 엔티티 증명서를 포함하는 CRL과 달리 인증국에 발급된 증명서를 포함하는 Certificate Revocation List(CRL; 증명서 취소 목록)의 한 형식입니다.

업계 조직

  • CASC(인증국 시큐러티 평의회)– 2013년 2월, CASC는 업계의 문제에 대처하고, 인터넷 시큐러티에 대해 일반인에게 교육하는 것을 목적으로 하는 업계 옹호 단체로서 설립되었습니다.창립 멤버는 가장 큰7개의 [31][32]인증국입니다.
  • Common Computing Security Standards Forum (CCSF; 공통 컴퓨팅 보안 표준 포럼)– 최종 사용자를 보호하는 업계 표준을 촉진하기 위해 2009년에 CCSF가 설립되었습니다.CCSF[33]설립자로는 코모도 그룹의 CEO인 멜리 압둘하요슬루가 꼽힌다.
  • CA/Browser Forum – 2005년에 인터넷 보안에 대한 업계 표준과 기준 요건을 촉진하기 위해 인증 기관과 웹 브라우저 벤더의 새로운 컨소시엄이 구성되었습니다.Comodo Group의 CEO인 Melih Abdulhayo organizedlu는 첫 회의를 조직했으며 CA/Browser [34][35]Forum의 창립자로 알려져 있습니다.

기준 요건

CA/Browser Forum은 기본 요건, CA가 따라야 할 정책 [36]및 기술 요건 목록을 게시합니다.Firefox 및 [38]Safari의 인증서[37] 저장소에 포함하기 위한 요구 사항입니다.

CA의 타협

CA를 전복시킬 수 있는 경우 시스템 전체의 보안이 상실되어 침해된 CA를 신뢰하는 모든 엔티티가 전복될 가능성이 있습니다.

예를 들어, 공격자 Eve가 CA를 통해 Alice를 대표한다고 주장하는 증명서를 발급받았다고 가정합니다.즉, 증명서는 공개적으로 Alice를 나타내며 Alice에 대한 다른 정보를 포함할 수 있습니다.Alice에 대한 정보 중 일부(예: 고용주 이름)가 참일 수 있으므로 인증서의 신뢰성이 향상됩니다.단, 이브는 증명서와 관련된 매우 중요한 개인 키를 가지고 있습니다.그러면 이브는 인증서를 사용하여 밥에게 디지털 서명된 이메일을 보내 밥이 앨리스가 보낸 이메일이라고 믿게 할 수 있습니다.Bob은 Eve가 개인 키를 사용하여 암호를 해독할 수 있을 때 Alice만 읽을 수 있다고 믿고 암호화된 전자 메일로 응답할 수도 있습니다.

이와 같은 CA 서브버전 사례는 2001년 인증국 VeriSign이 Microsoft를 대표한다고 주장하는 사람에게 2개의 증명서를 발급했을 때 두드러졌습니다.이 증명서에는 「Microsoft Corporation」이라고 하는 이름이 붙어 있기 때문에, Microsoft 소프트웨어의 갱신이 실제로 Microsoft 로부터 행해지지 않은 것을 속이기 위해서 사용할 수 있습니다.그 사기는 2001년 초에 발견되었다.Microsoft와 VeriSign은 [39][40]이 문제의 영향을 제한하기 위한 조치를 취했습니다.

2008년, Comodo의 재판매업자 Certstar는 [41]Mozilla를 대표할 권한이 없는 Eddy Nigg에게 mozilla.com의 증명서를 판매했습니다.

2011년 이란 해커에 의해 Comodo와 DigiNotar로부터 사기 증명서가 취득되었습니다.[42][43]가짜 [44]디지노타 증명서가 이란에서 중간자 공격에 사용됐다는 증거가 있다.

2012년에는 Trustwave가 투과적인 트래픽 관리에 사용되는 하위 루트 증명서(man-in-the-middle)를 발행하여 기업이 하위 [45]증명서를 사용하여 SSL 내부 네트워크트래픽을 스니핑할 수 있도록 한 것이 판명되었습니다.

키 스토리지

인증국의 개인 키를 도용한 공격자는 CA 시스템에 대한 지속적인 액세스 없이 CA인 것처럼 인증서를 위조할 수 있습니다.따라서 키 도난은 인증당국이 방어하는 주요 위험 중 하나입니다.공개적으로 신뢰받는 CA는 거의 항상 키를 Hardware Security Module(HSM; 하드웨어 보안 모듈)에 저장합니다.이를 통해 키를 사용하여 증명서에 서명할 수 있지만 일반적으로 물리적 제어와 소프트웨어 제어를 모두 사용하여 키를 추출할 수 없습니다.일반적으로 CA는 수명이 짧은 중간 증명서에 서명할 필요가 있는 경우를 제외하고 오프라인으로 유지되는 HSM에 장기 루트 증명서 키를 보관하기 위한 추가 예방 조치를 취합니다.온라인 HSM에 저장된 중간 증명서는 엔드 엔티티 증명서에 서명하고 실효 정보를 최신 상태로 유지하는 일상적인 작업을 수행할 수 있습니다.

CA는 서명 키를 생성할 때 키의 조작이나 복사를 방지하기 위해 세리머니를 사용하는 경우가 있습니다.

신뢰할 수 있는 서드파티 제도 구현의 약점

현재의 X.509 스킴의 실장 방법의 중요한 약점은 특정 당사자가 신뢰하는 CA가 선택한 도메인에 대해 증명서를 발행할 수 있다는 것입니다.이러한 증명서는 적법한 증명서인지 [46]아닌지를 불문하고 신뢰할 수 있는 당사자에 의해 유효한 것으로 간주됩니다.이는 X.509와 신뢰할 수 있는 서드파티를 채용한 가장 일반적인 테크놀로지가 HTTPS 프로토콜이라는 점을 감안하면 심각한 결점입니다.모든 주요 웹 브라우저가 최종 사용자에게 배포되기 때문에 수십 개에 이르는 신뢰할 수 있는 CA 목록이 미리 설정되어 있기 때문에 이러한 사전 승인된 신뢰할 수 있는 CA 중 하나가 [47]어떤 도메인에 대해서도 유효한 증명서를 발급할 수 있습니다.이에 대한 업계의 반응은 [48]약해졌다.브라우저의 사전 설정된 신뢰할 수 있는 CA 목록의 내용은 브라우저 응용 프로그램을 배포하거나 설치하는 당사자에 의해 독립적으로 결정되므로 CA 자체가 수행할 수 있는 일은 없습니다.

이 문제는 DNS 기반 DNS(Authentication of Named Entity) 프로토콜 개발의 원동력이 됩니다.Domain Name System Security Extensions(DNSEC; 도메인네임 시스템보안 확장)와 함께 채택할 경우 도메인의 PKI에서 신뢰할 수 있는 서드파티의 역할을 제거하지 않으면 DANE은 대폭 감소합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "What is a certificate authority (CA)?".
  2. ^ Villanueva, John Carl. "How do Digital Certificates Work - An Overview". www.jscape.com. Retrieved 2021-09-05.
  3. ^ "Mozilla Included CA Certificate List — Mozilla". Mozilla.org. Archived from the original on 2013-08-04. Retrieved 2014-06-11.
  4. ^ "EMV CA". EMV Certificate Authority Worldwide. 2 October 2010. Retrieved February 17, 2019.
  5. ^ Zakir Durumeric; James Kasten; Michael Bailey; J. Alex Halderman (12 September 2013). "Analysis of the HTTPS Certificate Ecosystem" (PDF). The Internet Measurement Conference. SIGCOMM. Archived (PDF) from the original on 22 December 2013. Retrieved 20 December 2013.
  6. ^ "What is an SSL Certificate?". Archived from the original on 2015-11-03. Retrieved 2022-03-19.
  7. ^ "webtrust". webtrust. Archived from the original on 2013-08-18. Retrieved 2013-03-02.
  8. ^ Kirk Hall (April 2013). "Standards and Industry Regulations Applicable to Certification Authorities" (PDF). Trend Micro. Archived (PDF) from the original on 2016-03-04. Retrieved 2014-06-11.
  9. ^ "CA:IncludedCAs - MozillaWiki". wiki.mozilla.org. Archived from the original on 2017-03-25. Retrieved 2017-03-18.
  10. ^ "List of available trusted root certificates in macOS High Sierra". Apple Support. Retrieved 2020-08-24.
  11. ^ "Microsoft Included CA Certificate List". ccadb-public.secure.force.com. Retrieved 2020-08-24.
  12. ^ "Security with HTTPS and SSL". developer.android.com. Archived from the original on 2017-07-08. Retrieved 2017-06-09.
  13. ^ "Let's Encrypt: Delivering SSL/TLS Everywhere" (Press release). Let's Encrypt. Archived from the original on 2014-11-18. Retrieved 2014-11-20.
  14. ^ "About". Let's Encrypt. Archived from the original on 2015-06-10. Retrieved 2015-06-07.
  15. ^ "Counting SSL certificates - Netcraft". news.netcraft.com. Archived from the original on 2015-05-16.
  16. ^ "DigiCert - World's Largest High-Assurance Certificate Authority Netcraft". trends.netcraft.com.
  17. ^ "Usage statistics of SSL certificate authorities for websites, July 2002 - W3Techs". w3techs.com. {{cite web}}: archive-url=잘못된 형식: 타임스탬프(도움말)CS1 유지보수:url-status(링크)
  18. ^ "Archived copy" (PDF). Archived (PDF) from the original on 2015-03-23. Retrieved 2015-03-20.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  19. ^ "CA/Forbidden or Problematic Practices - MozillaWiki". wiki.mozilla.org. Archived from the original on 2017-07-21. Retrieved 2017-07-06.
  20. ^ "SSL FAQ - Frequently Asked Questions - Rapid SSL". www.rapidssl.com. Archived from the original on 2015-02-06.
  21. ^ Zusman, Mike (2009). Criminal charges are not pursued: Hacking PKI (PDF). DEF CON 17. Las Vegas. Archived (PDF) from the original on 2013-04-15.
  22. ^ "A Finnish man created this simple email account - and received Microsoft's security certificate". tivi.fi. Archived from the original on 2015-08-08.
  23. ^ "Responsibilities of Certificate Authority". Archived from the original on 2015-02-12. Retrieved 2015-02-12.
  24. ^ "Network World". 17 January 2000.
  25. ^ Applied Cryptography and Network Security: Second International Conference, ACNS 2004, Yellow Mountain, China, June 8-11, 2004. Proceedings. Springer. June 2004. ISBN 9783540222170.
  26. ^ The Shortcut Guide to Managing Certificate Lifecycles. Realtimepublishers.com. 2006. ISBN 9781931491594.
  27. ^ "Electronic Signatures and Records" (PDF). Archived (PDF) from the original on 2016-03-04. Retrieved 2014-08-28.
  28. ^ "Certificate transparency". Archived from the original on 2013-11-01. Retrieved 2013-11-03.
  29. ^ Laurie, Ben; Langley, Adam; Kasper, Emilia (June 2013). "Certificate transparency". Internet Engineering Task Force. Archived from the original on 2013-11-22. Retrieved 2013-11-03.
  30. ^ Korzhitskii, Nikita; Carlsson, Niklas (2021). Revocation Statuses on the Internet. In proceedings of 2021 Passive and Active Measurement Conference (PAM 2021). arXiv:2102.04288.{{cite book}}: CS1 maint :url-status (링크)
  31. ^ "Multivendor power council formed to address digital certificate issues". Network World. February 14, 2013. Archived from the original on July 28, 2013.
  32. ^ "Major Certificate Authorities Unite In The Name Of SSL Security". Dark Reading. February 14, 2013. Archived from the original on April 10, 2013.
  33. ^ "CA/Browser Forum Founder". Archived from the original on 2014-08-23. Retrieved 2014-08-23.
  34. ^ "CA/Browser Forum". Archived from the original on 2013-05-12. Retrieved 2013-04-23.
  35. ^ Wilson, Wilson. "CA/Browser Forum History" (PDF). DigiCert. Archived (PDF) from the original on 2013-05-12. Retrieved 2013-04-23.
  36. ^ "Baseline Requirements". CAB Forum. Archived from the original on 7 January 2014. Retrieved 14 April 2017.
  37. ^ "Mozilla Root Store Policy". Mozilla. Archived from the original on 15 April 2017. Retrieved 14 April 2017.
  38. ^ "Apple Root Certificate Program". Apple. Archived from the original on 20 March 2017. Retrieved 14 April 2017.
  39. ^ "CA-2001-04". Cert.org. Archived from the original on 2013-11-02. Retrieved 2014-06-11.
  40. ^ Microsoft, Inc. (2007-02-21). "Microsoft Security Bulletin MS01-017: Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard". Archived from the original on 2011-10-26. Retrieved 2011-11-09.
  41. ^ Seltzer, Larry. "SSL Certificate Vendor Sells Mozilla.com CSSL Certificate to Some Guy". eWeek. Retrieved 5 December 2021.
  42. ^ Bright, Peter (28 March 2011). "Independent Iranian hacker claims responsibility for Comodo hack". Ars Technica. Archived from the original on 29 August 2011. Retrieved 2011-09-01.
  43. ^ Bright, Peter (2011-08-30). "Another fraudulent certificate raises the same old questions about certificate authorities". Ars Technica. Archived from the original on 2011-09-12. Retrieved 2011-09-01.
  44. ^ Leyden, John (2011-09-06). "Inside 'Operation Black Tulip': DigiNotar hack analysed". The Register. Archived from the original on 2017-07-03.
  45. ^ "Trustwave issued a man-in-the-middle certificate". The H Security. 2012-02-07. Archived from the original on 2012-03-13. Retrieved 2012-03-14.
  46. ^ Osborne, Charlie. "Symantec sacks staff for issuing unauthorized Google certificates - ZDNet". zdnet.com. Archived from the original on 2016-10-02.
  47. ^ "Unauthorized Google Digital Certificates Discovered". linkedin.com. 12 August 2014.
  48. ^ "In the Wake of Unauthorized Certificate Issuance by the Indian CA NIC, can Government CAs Still be Considered "Trusted Third Parties"?". casecurity.org. 24 July 2014. Archived from the original on 3 October 2016.

외부 링크