공개키 인프라

Public key infrastructure
공개키 인프라 다이어그램

공개 키 인프라(Public Key Infrastructure, PKI)는 디지털 인증서를 생성, 관리, 배포, 사용, 저장 및 취소하고 공개 키 암호화를 관리하는 데 필요한 역할, 정책, 하드웨어, 소프트웨어 및 절차의 집합입니다.PKI의 목적은 전자 상거래, 인터넷 뱅킹 및 기밀 이메일과 같은 다양한 네트워크 활동을 위한 정보의 안전한 전자 전송을 촉진하는 것입니다.간단한 비밀번호가 부적절한 인증 방법이며 통신에 관련된 당사자의 신원을 확인하고 전송되는 정보를 확인하기 위해 보다 엄격한 증명이 필요한 활동에 필요합니다.

암호학에서 PKI는 공개 키를 개체(사람 및 조직 등)의 각각의 ID와 묶는 배열입니다.[1]제본은 인증기관(CA)에서 인증서 등록 및 발급 과정을 거쳐 성립됩니다.바인딩의 보증 수준에 따라 이 작업은 자동화된 프로세스에 의해 수행되거나 사람의 관리 하에 수행될 수 있습니다.네트워크를 통해 작업을 수행하려면 보안 인증서 등록 또는 CMP와 같은 인증서 관리 프로토콜을 사용해야 합니다.

CA가 유효하고 올바른 등록을 보장하기 위해 위임할 수 있는 PKI 역할을 RA(registration authority)라고 합니다.기본적으로 RA는 디지털 인증서 요청을 수락하고 요청을 수행하는 주체를 인증할 책임이 있습니다.[2]인터넷 엔지니어링 태스크 포스(Internet Engineering Task Force)의 RFC 3647은 RA를 "자격증 신청자의 식별 및 인증, 자격증 신청의 승인 또는 거부, 특정 상황에서 자격증 취소 또는 정지 개시, 처리,가입자가 인증서를 취소하거나 일시 중단할 것을 요청하고, 가입자가 인증서를 갱신하거나 키를 다시 지정할 것을 승인하거나 거부하는 것을 말합니다.그러나 RA는 인증서에 서명하거나 발급하지 않습니다(즉, RA는 CA를 대신하여 특정 작업을 위임받음)."[3]Microsoft에서 하위 CA를 RA라고 불렀을 수 있지만 X.509 PKI 표준에 따르면 이는 올바르지 않습니다.[4]RA는 CA의 서명 권한이 없으며 인증서의 조사 및 프로비저닝만 관리합니다.따라서 Microsoft PKI의 경우 RA 기능은 Microsoft Certificate Services 웹 사이트 또는 인증서 템플릿을 통해 Microsoft Enterprise CA 및 인증서 정책을 시행하고 인증서 등록(수동 또는 자동 등록)을 관리하는 Active Directory Certificate Services를 통해 제공됩니다.Microsoft Standalone CA의 경우 CA를 제어하는 모든 절차가 Active Directory가 아닌 CA 및 CA 자체를 호스팅하는 시스템과 관련된 관리 및 액세스 절차를 기반으로 하기 때문에 RA의 기능은 존재하지 않습니다.대부분의 비 마이크로소프트 상용 PKI 솔루션은 독립형 RA 구성 요소를 제공합니다.

개체는 해당 개체에 대한 정보를 기반으로 각 CA 도메인 내에서 고유하게 식별 가능해야 합니다.CA를 대신하여 제3자 유효성 검사 기관(VA)이 이 엔티티 정보를 제공할 수 있습니다.

X.509 표준은 공개 키 인증서에 가장 일반적으로 사용되는 형식을 정의합니다.[5]

성능

PKI는 "신뢰 서비스"를 제공합니다. 즉, 사람이나 컴퓨터를 막론하고 실체의 행위나 산출물을 신뢰하는 것입니다.신뢰 서비스 목표는 다음 기능 중 하나 이상을 존중합니다.기밀성, 무결성 및 진정성(CIA).

기밀성:어떤 엔티티도 악의적이거나 무의식적으로 명확한 텍스트로 페이로드를 볼 수 없음을 보장합니다.데이터를 암호화하여 비밀로 만들어 읽어도 횡설수설하는 것처럼 보입니다.아마도 기밀성 목적으로 PKI를 가장 일반적으로 사용하는 것은 TLS(Transport Layer Security)의 맥락일 것입니다.TLS는 전송 중인, 즉 전송 중인 데이터의 보안을 뒷받침하는 기능입니다.기밀성을 위한 TLS의 전형적인 예는 인터넷 브라우저를 사용하여 비밀번호를 입력하여 인터넷 기반 웹 사이트에서 호스팅되는 서비스에 로그온하는 경우입니다.

무결성:기업이 전송된 데이터를 최소한의 방법으로 변경(변조)한 경우, 기업의 무결성이 손상되어 발생한 것이 분명하다는 보장.종종 무결성이 손상되는 것을 방지하는 것이 가장 중요한 것은 아니지만, 무결성이 손상된 경우에는 손상된 것에 대한 명백한 증거가 있다는 것이 가장 중요합니다.

진정성:모든 개체가 자신이 무엇과 연결하고 있는지 확실하게 알고 있거나 보호 서비스에 연결할 때 정당성을 입증할 수 있다는 보장.전자를 서버측 인증이라고 합니다. 일반적으로 암호를 사용하여 웹 서버에 인증할 때 사용됩니다.후자는 클라이언트 측 인증이라고 합니다. 스마트 카드(디지털 인증서 및 개인 키 호스팅)를 사용하여 인증할 때 사용되는 경우도 있습니다.

설계.

공개 키 암호화는 안전하지 않은 공개 네트워크에서 엔티티가 안전하게 통신하고 디지털 서명을 통해 엔티티의 신원을 안정적으로 확인할 수 있도록 하는 암호화 기술입니다.[6]

공개 키 인프라(Public Key Infrastructure, PKI)는 특정 공개 키가 특정 개체에 속하는지 확인하는 데 사용되는 디지털 인증서의 생성, 저장 및 배포를 위한 시스템입니다.PKI는 공개 키를 엔티티에 매핑하는 디지털 인증서를 생성하고 이러한 인증서를 중앙 저장소에 안전하게 저장한 후 필요한 경우 해지합니다.[7][8][9]

PKI는 다음과 같이 구성됩니다.[8][10][11]

  • 디지털 인증서를 보관·발급·서명하는 인증기관(CA)
  • 디지털 인증서를 CA에 저장할 것을 요청하는 기관의 신원을 확인하는 등록 기관(RA);
  • 중앙 디렉토리, 즉 키가 저장되고 색인화되는 안전한 위치.
  • 보관된 인증서의 열람 또는 발급받을 인증서의 교부 등을 관리하는 인증서 관리 시스템
  • 절차에 관한 PKI의 요구사항을 기재한 인증서 정책.외부 인사가 PKI의 신뢰도를 분석할 수 있도록 하는 것이 목적입니다.

인증방법

일반적으로 이러한 신뢰를 얻기 위한 방법은 인증 기관(CA), 신뢰의 웹(WoT), 그리고 단순 공개 키 인프라(SPKI)의 세 가지가 있습니다.[citation needed]

인증기관

CA의 주요 역할은 주어진 사용자에게 바인딩된 공개 키에 디지털 서명하고 게시하는 것입니다.이 작업은 CA의 자체 개인 키를 사용하여 수행되므로 사용자 키에 대한 신뢰는 CA의 키의 유효성에 대한 신뢰에 의존합니다.CA가 사용자 및 시스템과 별개인 제3자인 경우, CA는 RA(Registration Authority)라고 불리며 CA와 별개이거나 분리되지 않을 수 있습니다.[12]키-투-유저 바인딩은 바인딩이 가지고 있는 보장 수준에 따라 소프트웨어에 의해 또는 인간의 감독 하에 설정됩니다.

TTP(Trusted Third Party)라는 용어는 CA(Certificate Authority)에도 사용될 수 있습니다.또한 PKI는 그 자체로 CA 구현의 동의어로 사용되는 경우가 많습니다.[13]

인증서 해지

주요 기사:인증서 해지

인증서가 만료되기 전에 인증서가 취소될 수 있으며, 이는 인증서가 더 이상 유효하지 않음을 나타냅니다.취소하지 않으면 공격자는 만료될 때까지 손상되거나 잘못 발급된 인증서를 이용할 수 있습니다.[14]따라서 취소는 공개 키 인프라의 중요한 부분입니다.[15]취소는 암호로 인증된 취소문을 생성하는 발급 인증 기관에 의해 수행됩니다.[16]

취소 정보를 클라이언트에 배포하는 경우, 취소 검색의 적시성(따라서 공격자가 손상된 인증서를 악용할 수 있는 창)이 취소 상태 및 개인 정보 보호 문제를 쿼리하는 데 있어 리소스 사용과 상충됩니다.[17]취소 정보를 사용할 수 없는 경우(사고 또는 공격으로 인해), 클라이언트는 인증서를 취소된 것처럼 페일 하드하고 처리할 것인지(따라서 가용성이 저하됨), 페일 소프트하고 취소되지 않은 것으로 처리할 것인지(그리고 공격자가 취소를 회피할 수 있도록 허용할 것인지)를 결정해야 합니다.[18]

취소 검사 비용과 잠재적으로 신뢰할 수 없는 원격 서비스로 인한 가용성 영향 때문에 웹 브라우저는 수행할 취소 검사를 제한하고 수행하는 위치에서 오류가 발생합니다.[19]인증서 해지 목록은 일상적으로 사용하기에는 대역폭 비용이 너무 많이 들고 온라인 인증서 상태 프로토콜은 연결 지연 시간 및 개인 정보 보호 문제를 나타냅니다.다른 계획이 제안되었지만 페일 하드 검사를 사용할 수 있도록 아직 성공적으로 배포되지 않았습니다.[15]

발행자시장점유율

이러한 신뢰 관계 모델에서 CA는 인증서의 주체(소유자)와 인증서에 의존하는 당사자 모두에게 신뢰받는 신뢰할 수 있는 제3자입니다.

2015년 NetCraft 보고서에 따르면,[20] 액티브 TLS(Active Transport Layer Security) 인증서 모니터링을 위한 업계 표준은 "글로벌 [TLS] 생태계는 경쟁력이 있지만, 3개의 인증 기관(Symantec, Sectigo,GoDaddy)는 일반 웹 서버에서 발급된 [TLS] 인증서의 3/4을 차지합니다.Symantec(또는 VeriSign은 Symantec에서 구입하기 전부터)이 1위를 차지하고 있으며, 현재는 전체 인증서의 3분의 1 미만을 차지하고 있습니다.다양한 방법론의 효과를 설명하기 위해 시만텍은 사용 중인 유효하고 신뢰할 수 있는 인증서의 44%를 발행했는데, 이는 전체 시장 점유율보다 훨씬 높은 수치입니다."

인증서 발급 관리에 큰 문제가 생기자 2017년부터 모든 주요 업체들은 시만텍이 인증서를 발급한 것을 점차 불신하게 되었습니다.[21][22][23]

임시 인증서 및 Single Sign-On

이 방법에는 단일 인증 시스템 내에서 오프라인 인증 기관 역할을 하는 서버가 포함됩니다.단일 인증 서버는 클라이언트 시스템에 디지털 인증서를 발급하지만 저장하지는 않습니다.사용자는 임시 인증서로 프로그램 등을 실행할 수 있습니다.X.509 기반 인증서를 사용하여 이 솔루션의 다양성을 확인하는 것이 일반적입니다.[24]

2020년 9월부터 TLS 인증서 유효기간이 13개월로 단축되었습니다.

신뢰망

주요 기사:신뢰망

공개 키 정보의 공개 인증 문제에 대한 대안적인 접근 방식은 자체 서명된 인증서와 해당 인증서의 타사 증명을 사용하는 웹 오브 트러스트(Web-of-trust) 체계입니다."신뢰의 웹"이라는 단수의 용어는 단일 신뢰의 웹 또는 공통 신뢰점의 존재를 의미하는 것이 아니라, 잠재적으로 서로 단절된 수많은 "신뢰의 웹" 중 하나를 의미합니다.이 접근 방식의 구현 예로는 PGP(Pretty Good Privacy)와 GnuPG(PGP의 표준 규격인 OpenPGP의 구현)가 있습니다.PGP 및 구현을 통해 공개 키 정보의 자체 공개를 위해 전자우편 디지털 서명을 사용할 수 있기 때문에 자신만의 신뢰 네트워크를 구현하는 것이 비교적 용이합니다.

PGP와 같은 신뢰 웹의 이점 중 하나는 인증서를 보증하려는 도메인(예: 회사의 내부 CA)의 모든 당사자가 신뢰할 수 있는 도입자로서 완전히 신뢰하는 PKI CA와 상호 운용할 수 있다는 것입니다.신뢰 웹의 특성상 "신뢰 웹"을 완전히 신뢰하는 경우, 하나의 인증서를 신뢰하는 것은 해당 웹의 모든 인증서에 신뢰를 부여하는 것입니다.PKI는 인증서 발급을 통제하는 표준 및 관행만큼 가치가 있을 뿐이며 PGP 또는 개인적으로 도입된 신뢰 네트워크를 포함할 경우 해당 기업 또는 도메인의 PKI 구현에 대한 신뢰도가 크게 저하될 수 있습니다.[25]

웹 오브 트러스트 개념은 1992년 PGP 제작자 필 짐머만(Phil Zimmermann)이 PGP 버전 2.0 매뉴얼에서 처음 제시했습니다.

시간이 지남에 따라 신뢰할 수 있는 소개자로 지정할 수 있는 다른 사용자의 키가 누적됩니다.다른 모든 사람들은 각자 신뢰할 수 있는 소개자를 선택할 것입니다.그리고 모든 사람들이 자신의 키를 가지고 다른 사람들의 인증 서명 모음을 점차 축적하고 배포하게 될 것입니다. 이 서명을 받는 사람은 누구나 최소한 한 두 개의 서명을 신뢰할 것이라는 기대감을 가지고 말입니다.이로 인해 모든 공용 키에 대한 분산된 내결함성 신뢰성 웹이 등장하게 됩니다.

간단한 공개 키 인프라스트럭처

공개 키 정보의 공개 인증을 다루지 않는 또 다른 대안은 X.509와 PGP의 신뢰 네트워크의 복잡성을 극복하기 위한 세 가지 독립적인 노력으로 성장한 단순 공개 키 인프라(SPKI)입니다.SPKI는 사용자가 아닌 신뢰할 수 있는 것이 핵심이기 때문에 사용자와 사용자를 연결하지 않습니다.SPKI는 검증자가 발급자이기 때문에 신뢰의 개념을 사용하지 않습니다.이를 SPKI 용어에서 "인가 루프"라고 하며, 인가가 설계에 필수적입니다.[26]이러한 유형의 PKI는 인증서 승인, 인증서 정보 등을 제3자에게 의존하지 않는 PKI를 통합하는 데 특히 유용합니다. 이러한 예로는 사무실에 에어갭(air-gap)된 네트워크가 있습니다.

분산형 PKI

DID(Decentralized Identifier)는 계층적 PKI의 표준인 키 관리를 위한 중앙 집중식 인증 기관뿐만 아니라 식별자를 위한 중앙 집중식 레지스트리에 대한 의존도를 제거합니다.DID 레지스트리가 분산원장인 경우, 각 개체는 고유한 루트 권한 역할을 수행할 수 있습니다.이 아키텍처를 분산형 PKI(DPKI)라고 합니다.[27][28]

역사

PKI의 발전은 1970년대 초 영국의 정보 기관인 GCHQ에서 이루어졌는데, James Ellis, Clifford Cocks 등이 암호화 알고리즘과 키 분배와 관련된 중요한 발견을 했습니다.[29]GCHQ의 개발은 고도로 분류되어 있기 때문에, 이 연구의 결과는 1990년대 중반까지 비밀에 부쳐져 공개적으로 인정되지 않았습니다.

1976년 Diffie, Hellman, Rivest, Shamir 및 Adleman에 의한 보안 키 교환 및 비대칭 키 알고리즘의 공개는 보안 통신을 완전히 변화시켰습니다.초고속 디지털 전자 통신(인터넷과 그 이전의 인터넷)이 더욱 발전함에 따라, 사용자들이 서로 안전하게 의사소통할 수 있는 방법, 그리고 그 결과 사용자들이 실제로 누구와 상호작용하고 있는지 확신할 수 있는 방법에 대한 필요성이 명백해졌습니다.

새로운 암호화 프리미티브가 효과적으로 사용될 수 있는 다양한 암호화 프로토콜이 발명되고 분석되었습니다.월드 와이드 웹의 발명과 그것의 급속한 확산으로, 인증과 안전한 통신의 필요성은 더욱 절실해졌습니다.상업적인 이유만으로 충분했습니다(예: 전자 상거래, 웹 브라우저에서 독점 데이터베이스에 대한 온라인 액세스).Netscape의 Taher Elgamal 등은 SSL 프로토콜('https' in Web URL)을 개발했습니다. 여기에는 키 설정, 서버 인증(v3 이전, 단방향 전용) 등이 포함되었습니다.따라서 안전한 통신을 원하는 웹 사용자/사이트를 위해 PKI 구조를 만들었습니다.

공급업체와 기업가들은 큰 시장의 가능성을 보고 기업(또는 기존 기업의 새로운 프로젝트)을 시작했으며 법적 인정과 책임으로부터의 보호를 촉구하기 시작했습니다.American Bar Association 기술 프로젝트는 PKI 운영의 몇 가지 예측 가능한 법적 측면에 대한 광범위한 분석을 발표했습니다(ABA 디지털 서명 지침 참조). 얼마 지나지 않아 여러 미국 주(Utah는 1995년 최초) 및 전 세계의 다른 관할권에서 법을 제정하고 규정을 채택하기 시작했습니다.소비자 단체들은 프라이버시, 접근 및 책임 고려 사항에 대해 의문을 제기했는데, 이는 다른 지역보다 일부 지역에서 더 많이 고려되었습니다.

제정된 법률과 규정이 달랐고, PKI 계획을 성공적인 상업 운영으로 전환하는 데 기술적 및 운영상의 문제가 있었고, 개척자들이 상상했던 것보다 훨씬 더 진전이 늦었습니다.

21세기의 처음 몇 년 동안, 기본적인 암호화 엔지니어링은 분명히 정확하게 구현하기가 쉽지 않았습니다.작동 절차(수동 또는 자동)는 정확하게 설계하기가 쉽지 않았습니다(설계된 경우에도, 엔지니어링에서 필요로 하는 완벽한 실행을 위해).존재하는 기준이 불충분했습니다.

PKI 공급업체들은 시장을 찾았지만, 1990년대 중반에 계획된 시장은 아니며, 예상했던 것보다 더 천천히 그리고 약간 다른 방식으로 성장했습니다.[30]PKI는 예상했던 문제 중 일부를 해결하지 못했고, 몇몇 주요 공급업체는 폐업하거나 다른 공급업체에 인수되었습니다.PKI는 정부 구현에서 가장 큰 성공을 거두었습니다. 현재까지 가장 큰 PKI 구현은 공통 액세스 카드 프로그램을 위한 DISA(Defense Information Systems Agency) PKI 인프라스트럭처입니다.

사용하다

여러 공급업체의 PKI는 다음 용도로 사용되는 공용 키와 사용자 ID에 대한 바인딩을 제공하는 등 여러 용도로 사용됩니다.

  • 이메일 메시지의 암호화 및/또는 발신자 인증(예: OpenPGP 또는 S/MIME 사용)
  • 문서의 암호화 및/또는 인증(예: 문서가 XML로 인코딩된 경우 XML 서명 또는 XML 암호화 표준)
  • 응용 프로그램(예: 스마트 카드 로그온, SSL/TLS를 사용한 클라이언트 인증)에 대한 사용자 인증Enigform 및 mod_openpgp 프로젝트에서 디지털 서명된 HTTP 인증에 대한 실험적인 용도가 있습니다.
  • IKE(Internet Key Exchange) 및 SSL/TLS와 같은 부트스트래핑 보안 통신 프로토콜이 두 가지 모두에서, 보안 채널("보안 협회")의 초기 설정은 비대칭 키, 즉 공개 키 방식을 사용하는 반면, 실제 통신은 더 빠른 대칭 키, 즉 비밀 키 방식을 사용합니다.
  • 모바일 서명이란 모바일 기기를 이용하여 작성하는 전자서명으로서 위치 독립적인 전기통신 환경에서 서명 또는 인증 서비스에 의존하는 것을 말합니다.[31]
  • 사물인터넷은 상호 신뢰할 수 있는 기기들 간의 안전한 통신을 필요로 합니다.공용 키 인프라를 사용하면 장치 간 신뢰를 설정하고 TLS를 사용하여 통신을 암호화하는 데 사용되는 X.509 인증서를 얻고 갱신할 수 있습니다.

오픈 소스 구현

  • OpenSSL은 가장 간단한 형태의 CA이자 PKI용 도구입니다.이것은 C에서 개발된 툴킷으로, 모든 주요 리눅스 배포판에 포함되어 있으며, 사용자 자신의 (단순) CA 구축과 PKI 지원 응용 프로그램 구축에 모두 사용할 수 있습니다. (Apache 라이센스가 부여됨)
  • EJBCA는 Java에서 개발된 완전한 기능의 엔터프라이즈급 CA 구현입니다.내부용 및 서비스용 CA를 설정하는 데 사용할 수 있습니다.(LGPL 라이선스)
  • XiPKI,[32] CA 및 OCSP 응답기.SHA-3 지원, Java로 구현(Apache 라이센스 있음)
  • XCA는 그래픽 인터페이스이며 데이터베이스입니다.XCA는 OpenSSL을 기본 PKI 작업에 사용합니다.
  • DogTag은 Fedora Project의 일환으로 개발 및 유지보수되는 풀 기능 CA입니다.
  • CloudFlare에서 TLS 인증서 서명, 검증 및 번들링을 위해 개발한 CFSSL[33][34] 오픈 소스 툴킷 (BSD 2-clause licensed)
  • Hashi Corp.(Mozilla Public License 2.0 라이선스)가 개발한 보안(TLS 인증서 포함)을 안전하게 관리하는 볼트[35] 도구
  • 바둑으로 작성된 ACME 기반 CA인 Boulder.볼더는 Let's Encrypt를 실행하는 소프트웨어입니다.

비평

참고 항목: X.509 § 시큐리티, 2011년 코모도 그룹 § 침해 사건, Diginotar § 부정 인증서 발급

SSL/TLS를 통한 웹사이트 보안과 코드 서명을 통한 소프트웨어 보안을 위해 인증서를 구입하는 것은 중소기업에게는 비용이 많이 드는 모험이라는 주장도 있습니다.[36]하지만 암호화를 합시다와 같은 자유로운 대안의 등장은 이를 바꾸어 놓았습니다.HTTP 프로토콜의 최신 버전인 HTTP/2는 이론적으로 안전하지 않은 연결을 허용합니다. 실제로 주요 브라우저 회사들은 PKI 보안 TLS 연결을 통해서만 이 프로토콜을 지원할 것임을 분명히 했습니다.[37]Chrome, Firefox, Opera 및 Edge를 포함한 HTTP/2의 웹 브라우저 구현은 TLS 프로토콜의 ALPN 확장을 사용하여 TLS를 통한 HTTP/2만 지원합니다.이는 HTTP/2의 속도의 이점을 얻기 위해 웹 사이트 소유자는 기업이 통제하는 SSL/TLS 인증서를 구입해야 한다는 것을 의미합니다.

현재 대부분의 웹 브라우저는 인증 기관에 의해, 소위 루트 인증서로 인증된 공개 키에 의해, 사전에 설치된 중간 인증서와 함께 발송됩니다.이는 브라우저가 다수의 다른 인증서 공급자를 보유해야 함을 의미하며, 이는 핵심적인 손상의 위험을 증가시킵니다.[38]

키가 손상된 것으로 알려지면 인증서를 취소하여 고칠 수 있지만, 이러한 손상은 쉽게 탐지할 수 없고 큰 보안 침해가 될 수 있습니다.브라우저는 손상된 루트 인증 기관에서 발급한 중개 인증서를 취소하기 위해 보안 패치를 발급해야 합니다.[39]

참고 항목

참고문헌

  1. ^ Chien, Hung-Yu (2021-08-19). "Dynamic Public Key Certificates with Forward Secrecy". Electronics. 10 (16): 2009. doi:10.3390/electronics10162009. ISSN 2079-9292.
  2. ^ Fruhlinger, Josh (29 May 2020). "What is PKI? And how it secures just about everything online". CSOOnline. Retrieved 26 August 2021.
  3. ^ "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework". IETF. Retrieved 26 August 2020.
  4. ^ "Public Key Infrastructure". MSDN. Retrieved 26 March 2015.
  5. ^ "Using Client-Certificate based authentication with NGINX on Ubuntu - SSLTrust". SSLTrust. Retrieved 13 June 2019.
  6. ^ Adams, Carlisle; Lloyd, Steve (2003). Understanding PKI: concepts, standards, and deployment considerations. Addison-Wesley Professional. pp. 11–15. ISBN 978-0-672-32391-1.
  7. ^ Trček, Denis (2006). Managing information systems security and privacy. Birkhauser. p. 69. ISBN 978-3-540-28103-0.
  8. ^ a b Vacca, Jhn R. (2004). Public key infrastructure: building trusted applications and Web services. CRC Press. p. 8. ISBN 978-0-8493-0822-2.
  9. ^ Viega, John; et al. (2002). Network Security with OpenSSL. O'Reilly Media. pp. 61–62. ISBN 978-0-596-00270-1.
  10. ^ McKinley, Barton (January 17, 2001). "The ABCs of PKI: Decrypting the complex task of setting up a public key infrastructure". Network World. Archived from the original on May 29, 2012.
  11. ^ Al-Janabi, Sufyan T. Faraj; et al. (2012). "Combining Mediated and Identity-Based Cryptography for Securing Email". In Ariwa, Ezendu; et al. (eds.). Digital Enterprise and Information Systems: International Conference, Deis, [...] Proceedings. Springer. pp. 2–3. ISBN 9783642226021.
  12. ^ 마이크 마이어스 컴프TIA Security+ Certification Passport", T. J. Samuelle, 페이지 137.
  13. ^ Henry, William (4 March 2016). "Trusted Third Party Service".
  14. ^ 스미스, 디킨슨 & 시먼스 2020, 페이지 1.
  15. ^ a b Shefer, Saint-Andre & Fossati 2022, 7.5. 인증서 취소
  16. ^ Chung et al. 2018, p. 3.
  17. ^ 스미스, 디킨슨 & 시먼스 2020, 페이지 10.
  18. ^ Larisch et al. 2017, p. 542.
  19. ^ 스미스, 디킨슨 & 시먼스 2020, 페이지 1-2.
  20. ^ "Counting SSL certificates". 13 May 2015.
  21. ^ "CA:Symantec Issues". Mozilla Wiki. Retrieved 10 January 2020.
  22. ^ "Chrome's Plan to Distrust Symantec Certificates". Google security blog. Retrieved 10 January 2020.
  23. ^ "JDK-8215012 : Release Note: Distrust TLS Server Certificates Anchored by Symantec Root CAs". Java Bug Database. Retrieved 10 January 2020.
  24. ^ SAP 엔터프라이즈용 Single Sign-On 기술:SAP의 의견은 무엇입니까?
  25. ^ Ed Gerck, 인증 시스템 개요: x.509, CA, PGP 및 SKIP, The Black Hat Briefing '99, http://www.securitytechnet.com/resource/rsc-center/presentation/black/vegas99/certover.pdf 및 http://mcwg.org/mcg-mirror/cert.htm Wayback Machine에서 2008-09-05 보관
  26. ^ Gonzalez, Eloi. "Simple Public Key Infrastructure" (PDF).
  27. ^ "Decentralized Identifiers (DIDs)". World Wide Web Consortium. 9 December 2019. Archived from the original on 14 May 2020. Retrieved 16 June 2020.
  28. ^ "Decentralized Public Key Infrastructure" (PDF). weboftrust.info. 23 December 2015. Retrieved 23 June 2020.
  29. ^ Ellis, James H. (January 1970). "The Possibility of Secure Non-Secret Digital Encryption" (PDF). Archived from the original (PDF) on 2014-10-30.
  30. ^ Stephen Wilson, 2005년 12월, "오늘날 PKI의 중요성" Wayback Machine, China Communications에서 2010-11-22 아카이브, 2010-12-13 검색
  31. ^ Mark Gasson, Martin Meints, Kevin Warwick (2005), D3.2: PKI와 생체 인식에 관한 연구, FIDIS 자료 (3)2, 2005년 7월
  32. ^ "xipki/xipki · GitHub". Github.com. Retrieved 2016-10-17.
  33. ^ Sullivan, Nick (10 July 2014). "Introducing CFSSL - Cloudflare's PKI toolkit". CloudFlare's Blog. CloudFlare. Retrieved 18 April 2018.
  34. ^ "cloudflare/cfssl · GitHub". Github.com. Retrieved 18 April 2018.
  35. ^ "hashicorp/vault · GitHub". Github.com. Retrieved 18 April 2018.
  36. ^ "Should We Abandon Digital Certificates, Or Learn to Use Them Effectively?". Forbes.
  37. ^ "HTTP/2 Frequently Asked Questions". HTTP/2 wiki – via Github.
  38. ^ "Root Certificate vs Intermediate Certificates". About SSL. Retrieved 2022-05-02.
  39. ^ "Fraudulent Digital Certificates could allow spoofing". Microsoft Security Advisory. Microsoft. March 23, 2011. Retrieved 2011-03-24.

인용작품

외부 링크