[컴퓨터보안] Public Key Infrastructure (Part 2)

Public Key Certificate (PKC)

Digital Certificate

• 디지털 인증서는 종이 기반 여권의 디지털 버전이다.
• 인터넷 상에서 개인이나 조직을 고유하게 식별하고, 사용자를 그들의 공개 키와 연결한다.
• Public Key Certificate
  
  • 공개 키 인증서는 사용자와 그들의 공개 키 간의 연결을 나타낸다.
    • 운전 면허증이나 여권과 같이 대조하여 맞는지 확인하는 용도
  • 이 연결은 신뢰할 수 있는 기관인 CA에 의해 승인된다.
  • 인증서의 내용은 X.509 표준을 따른다. 
• Digital Certificate Contents
  • 인증서의 주요 내용은 사용자 이름, 유효성, 공개 키가 포함되며, CA에 의해 서명된다.

• 여권과 디지털 인증서의 유사성

• Digital Certificates에서 CA의 역할
  • CA는 digital certificate 를 발급하는 신뢰할 수 있는 기관이다.
    • Ex. VeriSign, Entrust, ...
  • 사용자가 공개 키 정보를 전달하면 다른 참가자들이 해당 인증서가 기관에 의해 생성되었음을 검증할 수 있다.
  • 사용자는 자신의 개인 키를 기억하고, CA의 공개 키를 통해 다른 사용자들의 공개 키를 검증할 수 있다.
  • CA는 항상 온라인 상태일 필요는 없으며, 사용자는 CA의 단일 공개 키 만을 보관한다.
  • 공개 키 Pa가 사용자 A에 대응하는지 사용자가 어떻게 확인할 수 있을까?
    • 모든 사용자는 CA의 공개 키 사본을 가지고 있다.
    • CA는 A의 디지털 인증서에 dCA(CA의 개인키)를 서명하고 A에게 전송한다.
    • B가 A의 인증서를 받으면, B는 pCA(CA의 공개키)를 이용하여 이를 확인할 수 있다.
    • 인증서는 CA와의 상호 작용 없이 A가 전송할 수 있다.
  • 정리하자면,
    • 사용자가 다른 사용자의 공개 키 정보를 검증하려면, 먼저 해당 사용자의 디지털 인증서를 확인한다.
    • 이 인증서가 CA에 의해 서명되었는지를 CA의 공개 키로 확인함으로써, 그 공개 키가 실제로 해당 사용자의 것이라는 것을 인증할 수 있다.

X.509 인증서 형식

 

 

Public Key Infrastructure (PKI)

PKI Components

• End User
• Registration authority (RA)
  • 은행이나 증권사 등
  • CA와 end users 사이의 중간 엔터티로서 CA의 업무 부담을 나눈다.
  • 새로운 사용자에 대한 등록 정보를 수락하고 검증한다.
  • end users를 대신해서 키를 생성할 수 있다.
  • 키 백업 및 복구에 대한 요청을 수락하고 승인한다.
  • 인증서의 폐지 요청을 수락하고 승인한다.
  • RA는 인증서를 생성하지 않으며, 인증서 생성은 CA의 역할이다.
  • CA는 격리된 엔터티가 되기 때문에 보안 공격에 덜 노출된다.
• CA
• Key recovery server
  • Q. End users 가 그들의 private key를 잃어버리면?
    • A1: CA는 해당 공개 키 인증서(PKC)를 폐지하고, 새로운 키 쌍과 새로운 PKC를 생성한다.
    • A2: 키 복구 서버를 사용하여 CA는 생성 시점에 개인 키를 백업할 수 있다. 
• X.500 directory
  • Q. 인증서를 어디에 저장하는거지?
    • A1: end user는 자신의 로컬 컴퓨터에 인증서를 저장할 수 있다.
    • A2: CA는 인증서 디렉토리 또는 중앙 저장소를 사용할 수 있다.
      • 인증서 관리 및 배포에 대한 단일 지점을 제공하기 때문에 나중에 인증서를 폐지할 때 유용하다.

 

Certification creation steps

• 인증서 생성 단계
  • 키 생성 (2가지)
    • 1. 유저가 자신의 키 쌍을 스스로 생성하는 방법
    • 2. RA가 유저를 위해 키 쌍을 대신 생성해주는 방법
  • 키 등록
    • 사용자가 키를 직접 생성할 경우에만 인증서 서명 요청(Certificate Signing Request, CSR)이 필요하다.
  • 검증
    • RA는 사용자의 자격(credential) 증명을 검증하고, 개인 키의 소유 증명을 확인한다.
      • 사용자가 진짜 private key를 가지고 있는지 확인
      • Q. 사용자가 개인 키를 소유한 적이 없다고 주장하면, 개인 키로 서명한 문서가 법적 문제를 야기하면 어떻게 해야할까?
        • Sol1: RA는 사용자에게 개인 키를 사용하여 CSR에 서명할 것을 요구한다.
        • Sol2: RA는 난수를 생성하여 사용자의 공개 키로 암호화한 후 사용자에게 도전한다.
  • 인증서 생성
    • CA는 사용자를 위해 X.509 표준 형식의 디지털 인증서를 생성한다.

CA는 사용자 또는 등록 기관(RA)에 인증서를 발급하고, 인증서 디렉토리에 저장하며, 필요한 경우 사용자의 개인 키를 백업하는 과정으로 인증서를 생성한다.

 

 

Questions about Certificate

1. How CA Signs a Certificate?

• CA는 인증서의 마지막 필드를 제외한 모든 필드에 대한 message digest 를 생성하고, 이 MD에 CA의 개인 키로 서명하면 signature S가 나오고, 이 S는 인증서의 마지막 필드에 저장된다.
• 인증서를 검증하기 위해 CA의 공개 키를 사용해서 de-sign 해야한다.
• 만약 인증서를 de-sign 할 수 있다면, 그 인증서가 유효하다고 안전하게 추정할 수 있다. 

 

2. How do you verify a certificate?

• 인증서의 Message Digest 가 일치하는지 확인하여 인증서의 유효성을 검증한다.

 

 

3. How do we get CA's public key of some certificate?

• CA의 공개 키는 CA 자체의 인증서를 통해 얻을 수 있다.
  • 이 인증서는 해당 공개 키가 CA에 속함을 증명한다.
• CA의 인증서에는 누가 서명하나?
  • CA Hieracrchy
    • 다른 상위 레벨의 CA가 하위 레벨의 CA 인증서에 서명하여 보증할 수 있다.
  • 자체 서명된 인증서(Self-Signed Certificate)
    • 루트 CA는 자체적으로 자신의 인증서에 서명할 수 있다.
    • 이는 최상위 CA에서 주로 사용되며, 이 인증서는 일반적으로 소프트웨어(예: 웹 브라우저)에 내장되어 있다.
  • 상호 인증(Cross-Certification)
    • 서로 다른 CA들이 서로의 인증서에 서명하여 신뢰를 확립할 수 있다. 이는 서로 다른 CA 시스템 간의 신뢰를 구축할 때 사용다.

 

 

Certificate Revocation (인증서 해지)

• 개인 키 손상, CA의 오류, 직업 변경 등의 이유로 인증서 폐지할 경우, 먼저 확인해야할 사항이 있다.
  • 소유자 확인: 인증서가 실제 소유자에게 속하는지 확인
  • 유효성 확인: 인증서가 여전히 유효한지, 또는 폐지되었는지 확인
    • 인증서의 유효성 검사
      • Online Checks: 실시간으로 인증서의 상태를 확인하는 방법
        • OCSP(Online Certificate Status Protocol): 인증서 상태 정보를 CA 제공 서버에 요청하는 프로토콜
          • OCSP는 CRL을 대체하거나 보완하는 방법으로 사용될 수 있다.
          • OCSP 프로토콜을 사용하여 CA 또는 신뢰할 수 있는 서버에 인증서 상태를 요청하고, 서버는 X.500 디렉토리를 조회한 후 '유효함(good)', '폐지됨(revoked)', '알 수 없음(unknown)' 등의 응답을 보다.
          • OCSP는 인증서의 즉각적인 상태 정보를 제공한다.
          • 응답은 CA, 신뢰할 수 있는 응답자, 또는 CA에 의해 인증된 권한 있는 응답자에 의해 서명된다.
      • Offline Checks: 인증서 폐지 목록(CRL)을 사용하여 인증서의 유효성을 검사하는 방법
        • RA는 폐지된 인증서 목록, 즉 CRL을 발행하고 정기적으로(예: 매일) 업데이트한다.
        • CRL은 유효 기간이 만료된 인증서를 포함하지 않는다.
        • 사용자는 인증서의 만료일과 서명뿐만 아니라 최신 CRL도 확인해야 한다.
        • 만료일의 필요성: 만료일은 CRL의 크기를 관리 가능한 수준으로 유지하고 폐지 메커니즘을 보다 효율적으로 만든다. 많은 시스템은 폐지를 확인하지 않고 만료일만 확인한다.
        • 단점
          • CRL은 크기가 매우 커질 수 있으며, 따라서 전송 시간이 길어질 수 있다(Delta CRL 사용 가능).
          • 인증서가 손상된 경우와 CRL의 다음 업데이트 사이에 취약한 시간 창이 발생할 수 있으며, 이 기간 동안 실시간 상태를 확인할 수 없다.
          • CRL을 신뢰할 수 있고 효율적으로 배포하는 방법이 필요하다.