Madison Digital Garden

Search

SearchSearch

7. PKC

Mar 25, 2024, 11 min read

서울대학교 컴퓨터공학과 권태경 교수님의 "Topics in Computer Networks" 강의를 필기한 내용입니다.

다소 잘못된 내용과 구어적 표현 이 포함되어 있을 수 있습니다.

PKC - Public Key Cryptography

-주는 것이 힘들기 때문 - N 명이 참여하는 네트워크에서 2쌍씩 배포하기에는 nC2 부하 - 또한 키가 유출되었을 때는 누구에게 책임이 있는지 등

  • 따라서 PKC 를 이용하면 공개키는 모두가 알고 있기 때문에 그것으로 암호화를 하고 server 만 가지고 있는 개인키로 복호화해서 사용

특징

  • ku, k+, kp: public key
  • kr, k-, ks: private key
  • cipher = f(ku, plain): ku 를 안다면 가능
    • f 가 암호화 의미
  • plain = f-1(kr, cipher): kr 를 안다면 가능, 모르면 불가능
    • f-1 은 역함수로 복호화 의미
  • kr 를 이용해 암호화하고, ku 를 이용해 복호화하는 것도 가능하다: 하지만 이 경우에는 (ku는 모두에게 공개되어 있기 때문) 모든 사람들이 볼 수 있기 때문에 암복호화의 기능이 아니라 데이터 변조 및 authenticate 를 위한 것이다 → 즉, 이것이 signature 인 것
  • 송신자는 msg 에 서명해서 signature (기호: sigma) 을 같이 보내고, 송신자는 이것을 ku 로 복호화해서 누가 보냈는지, 그리고 변조되지는 않았는지 검증한다
  • Key 생성 알고리즘
    • Diffie-Hellman 알고리즘
      • a = bq + r → a = b mod r ??
      • m = g^x mod p 에서 m, g, p 를 알아도 (이 수들이 정말 크다면) x 를 알아낼 수 없다.
      • Alice (송신자) 만 x 을 알고있고, m = g^x mod p 를 계산하여 m 을 보낸다
      • Bob (수신자) 만 y 를 알고있고, n = g^y mod p 를 계산하여 n 을 보낸다
      • 뭐라노 시바꺼 구글로 찾아봐야 할듯
  • Digest
    • msg 자체를 서명할 경우에는 msg 크기가 큰 경우에 자원이 많이 소모되기 때문에
    • Hash 를 돌려서 digest 를 만들어 이것을 서명하는 방법을 이용한다.
    • Hash 함수는 입력이 달라도 출력이 같은 경우가 발생할 수도 있는데, 이것을 collision 이라고 한다 → 근데 이건 극히 확률이 적다고 한다.

MAC (Message Authentication Code)

-ash 를 한 후, msg 와 붙인 후 Bob 에게 보낸다

TRANSMIT_MSG
= MSG + DIGEST
= MSG + HASH(SHARED_SECRET + MSG)
  • Bob 은 이것을 받아들고 msg 앞에 공유 시크릿을 붙인 뒤에 hash 를 하여 전송된 digest 과 비교하여 msg 가 변경되었는지 감지한다
COMP(MSG, HASH(SHARED_SECRET + MSG))
  • 근데 이 방법은 문제가 있다:
    • Alice 는 아무것도 보내지 않았는데, Bob 은 이 메세지를 받았다고 주작치는 것이 가능하다.
    • 반대로 Alice 가 보내놓고서 안보냈다고 주장할 수도 있다.
  • 이는 signature 을 이용하면 해결할 수 있다
    • 즉, kr 은 Alice 만 갖고 있기 때문에 msg 를 서명하여 그 sign 을 보내게 되면 Bob 은 ku 로 검증할 수 있지만, Bob 은 kr 을 모르기 때문에 거짓으로 이것을 만들어서 수신되었다고 주장할 수 없다.
    • 조금 더 구체적으로는 msg 를 hash 하여 서명하게 된다
TRANSMIT_MSG = MSG + SIGN(KR, HASH(MSG))
COMP(HASH(MSG), DECRYPT(KU, SIGN))

PKI (Public Key Infrastructure)

  • ku 는 모두가 알고있는 것이기 때문에 누가 이것을 발급했는지 client 입장에서 알 방법이 없다
  • 이 때문에 인증서 (certificate) 이라는 것이 등장했다
  • CA (Certificate Authority) 는 cert 를 발급해며 어떤 ku 가 누구에게 속해있는 지 인증 (certify) 해주는 역할을 한다
  • CA 또한 자신만의 ku, kr 이 있고
  • CA 가 kr 을 이용해 (공개키 + 소유자) 를 서명하게 되고 이 서명까지 합쳐서 인증서 (certificate) 라고 한다
  • 정리하자면, CA 가 Alice 가 공개키 ku 를 소유하고 있음을 인증하는 인증서는 다음처럼 세 정보로 구성된다
    • 공개키 (ku)
    • 소유자 (Alice)
    • 이것에 대한 서명 (sign)
  • 물론 CA 에 대한 정보도 들어간다

X.509

-ame, DN): 소유자에 대한 정보 - CN: 도메인, 서버 이름 - 이외에 O, OU, LO, S, C 등 - Valid-From, Valid-To: 유효 날짜 (시작, 끝) - Signature Algorithm: 서명을 생성한 알고리즘 - Issuer: 인증서 발급 기관

CA Hierarchy

  • CA 가 인증서를 발급해 주기 때문에, 이 CA 에 대한 보증이 필요하다
  • 이를 위해 신뢰할 수 있는 인증 기관들은 잘 알려져 있고
  • 이 인증기관들은 신뢰를 잃지 않기 위해 잘 보호하는데 이를 위한 것이 계층형 CA 이다 (아마?)
  • Root CA 와 Intermediate CA 는 Offline 으로 유지해 외부에서 접근할 수 없게 하고
  • 말단의 Issuing CA 가 online 으로 사용자들의 인증서 생성 요청을 받아들인다
  • 각 Root CA 및 Intermediate CA 는 모두 K+, K- 를 가지고 있다
  • Intermediate CA 와 Issuing CA 는 모두 상위 CA 로부터 서명된 인증서를 갖고 있다
  • Root CA 의 경우에는 스스로 서명 (self-sign) 되어 있다

Self-sign certificates

  • Root CA 나 테스팅/개발 서버용으로 사용한다
  • 근데 revocation 문제가 있다고 한다 → 다음시간에 설명

여기부터는 강의 8 초반부

Cert Lifecycle

  • 인증서에는 대상 (subject) 와 그 대상의 공개키, 그리고 이것들을 ca 가 서명한 서명이 들어간다
  • lifecycle
    • expiration: 인증서에 있는 기간이 만료되면 서명과 공개키, 개인키 모두 사용 못한다.
    • revocation: CA 가 발급해준 인증서를 폐기시킬 수도 있다 ??? (9”8)
      • CA 가 인증서가 잘못되었다고 판단해서 폐기하기도 한다
      • 브라우저는 인증서 검증 과정에서 CA 에게 본 인증서가 revoked 되었는지 물어보게 되는데
      • 방법은 두가지가 있다고 한다: CRL, OCSP
  • CRL: Certificate Revocation Lists
    • 인증서 소유자는 CA 에게 이 인증서를 revoke 해달라고 요청할 수 있는데
    • 그럼 CA 는 이 정보들을 모아다가 CRL 을 만들어서 공개한다
    • 클라이언트는 서버에 접속할 때 받은 인증서를 검증할 때 이 CRL 을 다운받아 revoke 되지 않았는지 확인한다
    • CRL 이 자주 업데이트되지 않으면 인증서가 revoke 되었다는 것을 나중에 알기 때문에 주기를 짧게 해야 된다
  • OCSP
    • CA 혹은 CA 가 위임한 어떤 단체가 OCSP 서버를 운영한다
    • 이것도 마찬가지로 client 가 인증서를 받아들고 OCSP 서버에게 이 인증서가 revoke 되었는지 물어보는 형태로 진행된다
    • 이렇게 하면 revocation 정보를 실시간으로 반영할 수 있어 CRL 의 문제를 해결할 수 있다
    • 문제는 OCSP 서버가 client 가 어디 방문했는지 추적할 수 있기 때문에 privacy 문제가 있고
      • 이것은 Stapling 이라는 것으로 해결한다: client 가 OCSP 에 물어보는 것이 아니고 웹서비스 server 가 OCSP 에 물어보는 것
    • 두번째 문제는 OCSP 서버에 접근하지 못할 경우 client delay 가 걸리게 된다는 것이다
      • 이것은 soft-fail 방식으로 타협한다: 응답이 안오면 문제가 없는 것으로 판단한다는 것

Cert Level

  • PKI 문제점
    • Spoofing: CA 를 해킹하는 식으로 문제를 일으켜 가짜 인증서를 발급받는 것
  • 인증서 정보
    • DV: 도메인 소유주가 해당 도메인으로 접속했을 때 특정 정보를 반환하도록 하여 CA 로 하여금 도메인을 갖고 있음을 인증하는 방식
    • OV: 31”
    • EV: 제일 까다롭지만 신뢰성이 강한 인증서로 이 인증서를 받으면 브라우저 주소창이 녹색이 되는 등의 효과가 있다고 하더라
  • 그럼에도 불구하고 CA 가 안일해지면 얼마든지 가짜 인증서를 받는 것이 가능하다

Graph View

Backlinks