이쿠의 슬기로운 개발생활

함께 성장하기 위한 보안 개발자 EverNote 내용 공유

보안

PKI 리서치 - 공개키를 공개하는 방법 : PKI

이쿠우우 2022. 4. 2. 11:26
반응형

 

PKI 리서치

 

목표

SSH, Kubernetes 등을 리서치 하면서 항상 개념이 혼란스러웠던 주제가 바로 인증서였음.
그러다 보니 ca.crt, ca.key, server.crt 같은 인증서 관련 파일만 보면 시작하기도 전에 걱정이 먼저였음...
대칭키, 공개키 알고리즘 개념은 완벽히 알고있지만 인증서, 전자서명 개념만 들어가면 개념이 흔들렸음.
이를 해결하기 위해 날을 잡고 개념부터 심화까지 글과 그림을 그려가며 리서치를 진행함.
개념적인 부분 부터 하나하나 다시 복습하는 마음으로 필자가 궁금증이 생겼던 시점의 순서대로 정리해봄.

 


PKI 리서치 시리즈 이동

PKI 리서치 - 암호화 알고리즘 개념
PKI 리서치 - 비대칭키(공개키) 알고리즘을 이용한 전자서명
PKI 리서치 - 공개키를 공개하는 방법 : PKI
PKI 리서치 - 실생활에서의 PKI : HTTPS - SSL/TLS
PKI 리서치 - OpenSSL을 통해 직접 PKI 환경을 구축해보자


 
 
 

공개키를 공개하는 방법 : PKI

 
여기까지 알아보니 한가지 궁금한 점이 있음.
Public Key를 모두에게 공개한다고 하는데 Public Key를 어떻게 필요한 User에게 공개할 수 있을까?
네트워크 상에서 이런 인프라를 제공하는것을 바로 PKI라고 함.
PKI를 통해 Private Key,는 본인만 소유하고 Public Key는 모두에게 공개할 수 있음.
 
 

PKI란?

Public Key Infrastructure로 공개키 기반구조로 불려짐.
쉽게 말해서 Private key는 본인만 소유하고 Public key는 모두에게 공개할 수 있는 인프라를 제공함.
 
PKI는 이러한 인프라를 제공하는 역할 이외에 또 한가지 중요한 역할을 담당하는데
바로 Public key소유자의 신분을 보장해주는 것임.
Public key의 소유자 신분은 왜 보장되어야하는지 이해하기 위해
비대칭키 알고리즘의 취약점에 대해 한번 알아봄.
 
 
 

Public key 소유자의 신분은 왜 보장되어야 하는가? (공개키 알고리즘 취약점)

 
 

비대칭키 암호화 알고리즘의 취약점

 

[A사용자가 B사용자에게 암호문을 전달하는 과정에서 발생할 수 있는 취약점을 정리함.]
1. B사용자가 Private Key, Public Key를 생성.
2. 공격자도 마찬가지로 Private Key(X), Public Key(X)를 생성.
3. A사용자는 B사용자에게 암호문을 전송하기 위해 사전에 B가 생성한 Public Key를 보관하고 있음
    하지만 공격자가 해당 Public Key를 공격자의 Public Key(X)로 교체함.
4. A는 보관하고 있는 Public Key(X)가 B의 것이라고 알고있지만 이를 모르고 
    공격자의 Public Key(X)이용해서 공개키 알고리즘을 통해 평문을 암호화 함.
    (즉 A가 암호화에 사용한 Public key가 정상적인 B의 Public key 임을 확인할 수 있는 방법이 없음)
5. A는 암호문을 B에게 전송
6. 공격자는 해당 암호문을 중간에서 가로챔.
7. 공격자는 가로챈 암호문을 기존에 보관하고 있던 Private Key(X)로 
    동일한 공개키 알고리즘을 통해 복호화해서 평문을 확인함. (즉 평문이 유출됨.)
8. B의 Public Key는 말그대로 공개되어있음으로 공격자도 쉽게 확보할 수 있음.
9. 공격자는 보관하고 있는 B의 Public Key를 이용해서 공개키 알고리즘을 통해 평문을 암호화 함.
10. 공격자가 생성한 암호문을 B에게 전송
11. B는 받은 암호문을 기존에 보관하고 있던 Private Key로 
      동일한 공개키 알고리즘을 통해 복호화해서 평문을 확인함.
 

결론

위와 같이 비대칭키 기반의 암호화가 완벽한 알고리즘이고 구조이지만,
공개키의 주인이 누구인지! 
즉 유효성이 확인되지 않으면 무용지물이 됨...
이런 상황을 해결하기 위해 PKI는 Public key의 소유자 신분을 보장하는 프로세스를 제공함.
 
그렇다면 PKI는 어떻게 Public key의 소유자 신분을 보장하는지 알아봄.
 
 
 
 

Public key 소유자의 신분을 보장하는 방법 (CA와 인증서)

 
Private Key는 본인만 잘 가지고 있으면 되지만 
Public Key는 모두에게 공개가 되고 
위에서 설명한 공개키의 취약점을 해결하기 위해 
해당  Public Key가 정말 나의 소유라는 것이 증명이 되어야함.
 
"비대칭키 서명 알고리즘 1,2,3"에서 설명했던 전자 서명을 이용함.
그렇다면 나의 Public Key는 누가 서명을 해줄것인지가 의문임.
내가 나를 서명해봤자 의미가 없고 누군가가 나의  Public Key가 정말 나의 소유라는 것을 증명해줘야함.
누가  Public Key를 서명해주고 어떠한 값을 전자서명 하는지에 대해 알아봄.
 
 
위에서 설명한 "비대칭키 암호화 알고리즘의 취약점"에서 
사용자B가 생성한 Public Key의 주인이 사용자B임을 증명하지 않아서 공격자에게 평문이 유출됨.
그래서 해당 의 주인이 사용자B임을 증명하기 위해 인증된 기관으로 부터 "인증서"를 받음
 

인증서 발급 과정

1. B사용자가 Private Key, Public Key를 생성.
2. B는 신뢰할 수 있는 기관 CA에게 Public Key를 전달.
3. 신뢰할 수 있는 기관 CA는 B의 Public Key를 Hash 함수를 돌려 Hash 값을 생성함. 
4. C는 보관하고 있는 Private Key를 이용해서 공개키 알고리즘을 통해 Hash값을 암호화 함.
    (Private Key로 암호화 했기 때문에 암호문이 아니라 전자서명임.)
5. 최종적으로 인증서를 생성함 인증서 내용은 아래와 같은 내용이 포함되어있음.
  • 발행자 : 신뢰할 수 있는 기관 CA
  • 공개키의 주인 : 사용자 B
  • 공개키 : B의 Public Key 원본 값을 넣어줌
  • 서명 : 4단계에서 생성했던 전자서명값을 넣어줌.
6. 생성한 인증서를 사용자 B에게 전달.
 
즉 A,B 사용자 이외의 제 3자가 B의 Public Key가 B의 것임을 증명해줌.

 

인증서를 통해 공개키 소유자를 확인하는 과정

 

1. B사용자는 Private Key와 CA로 부터 받은 인증서를 가지고 있음.
2. B는 인증서를 A에게 전달
3. A는 B의 인증서를 저장
4. A는 B의 Public Key 를 확인하기 위해 인증서 내용을 확인함 
   인증서 내용은 아래와 같은 내용이 포함되어있음.
  • 발행자 : 신뢰할 수 있는 기관 CA
  • 공개키의 주인 : 사용자 B
  • 공개키 : B의 Public Key 원본 값을 넣어줌
  • 서명 : 전자서명
5. 인증서의 공개키 항목으로 부터 B의 Public Key 확인. 
6. B의 Public Key 확인했지만 해당 키가 정말 B의 Public Key 가 맞는지 보장이 안됨
    이를 확인하기 위해 전자서명 값을 확인
7. CA의 Public Key 로 전자서명을 복호화해서 Hash값을 확인함
8. 그리고 5번 항목에서 확인했던 B의 Public Key 를 Hash 해서 Hash 값을 확인
9. 7번과 8번 과정에 생성한 2개의 Hash값을 비교함
   일치한다면 해당 Public Key 는 B의 소유가 증명됨
   일치하지 않는다면 해당 Public Key 는 B의 소유가 아님
10. Hash 값이 일치했다면 A는 보관하고 있는 B의 Public Key를 이용해서 
      공개키 알고리즘을 통해 평문을 암호화 함.
11. 암호문을 B에게 전송
12. B는 받은 암호문을 기존에 보관하고 있던 Private Key로 
      동일한 공개키 알고리즘을 통해 복호화해서 평문을 확인함.
 
이와 같이 A와 B 사용자 모두 신뢰할 수 있는 인증 기관을 "CA(Certificate Authority)"라고 함.
근데 한 가지 의문점이 생김.
위 과정에서 전자서명을 복호화 할 때 CA의 Public Key를 사용하는데
CA의 Public Key는 또 어떤 기관이 해당 Public Key가 정말 CA의 Public Key 라고 증명해주는가?

 

 

 

CA의 Public Key는 누가 소유자 신분을 보장하는가? (ROOT CA, Chain Of Trust)

 
 

CA의 Public key를 획득하는 방법(ROOT CA)

 
상위 그림을 보면 7번 과정에서 CA의 Public Key 를 사용하는데
실제로는 바로 공개키가 전달되는 것이 아니라 
CA의 Public Key 또한 마찬가지로 다른 누군가가 인증을 해줘서 인증서 형태로 존재함.
 
즉 CA의 Public Key 도 인증서 형태로 있음.
CA는 어떻게 인증서를 생성하는지 절차를 알아봄
 
[해당 image는 ROOT CA의 SSC인증서 생성 과정임]

 

 

ROOT CA는 자신이 생성한 Private Key와  Public Key를 가지고 있음.

1. ROOT CA는  Public Key를 Hash 함
2. 생성한 Hash값을 자신의 Private Key로 암호화해서 전자 서명을 생성함
3.  Public Key 가 ROOT CA가 생성한 것임을 증명하기 위해 인증서를 생성함
   인증서 내용은 아래와 같은 내용이 포함되어있음.
  • 발행자 : 본인 (ROOT CA) = 이 의미가 ROOT CA 임을 나타냄
  • 공개키의 주인 : 본인 (ROOT CA)
  • 공개키 : CA의 Public Key 원본 값을 넣어줌
  • 서명 : 위에서 생성한 전자 서명
  • (인증서 생성 완료)
4. 사용자 A는 ROOT CA의 인증서에 포함되어있는 Public Key 를 사용하기 위해 해당
Public Key가 진짜 ROOT CA가 생성한 것 인지 확인이 필요함.
5. 확인을 위해 ROOT CA가 생성한 인증서에 포함 되어있는 전자서명을 인증서에 있는 Public Key키로 복호화함.
6. 인증서에 포함되어있는 Public Key를 Hash함
7. 전자서명을 복호화해서 얻은 Hash값과 인증서에 있는 Public Key를 Hash값을 비교함
2개의 Hash 값이 일치한다면 해당 Public Key는 ROOT CA의 Public Key가 맞음이 증명됨.
확실한 확인을 위해 얻은 Public Key로 전자서명을 복호화 해봄
 
 

의문점..

근런데 의문점이 또 있음...
CA가 가지고 있는 인증서의 전자서명 항목을 복호화 할 때 
본인의 Public Key로 복호화 함.
정상적인 case라면 인증서에 있는 Public Key가 인증된 Public Key임을 확인하기 위해
다른 기관Private Key로 전자서명을 만들고
그 기관의 공개키로 전자서명을 복호화 해서 확인해봐야하는데
위와같은 과정으로 하면 정상적인 인증이 되지 않음.
 
(CA가 인증서를 발행하고 자신의 Public Key를 자신의 Private Key로 서명함)
 
즉 제 3자가 인증하는 것이 아니라 본인이 본인을 인증함.
이런게 CA가 공개키 전자서명을 생성할 때
본인의 Private key로 스스로가 서명한 경우
해당 CA를  ROOT CA라고함.
그리고 위와 같이 만들어진 인증서
즉 스스로 서명한 ROOT CA 인증서를 SSC(Self Signed Certificate)라고 함.
 
 

결론 (ROOT CA)

그래서 CA의 Public Key가 인증됐음을 보장해주는 또 다른
CA2 기관이 필요함.
그럼 CA2의 Public Key를는 누가 인증해주나?
역시 또 다른 기관인 CA3가 보장해줘야함
결국 끝이 없이 서로가 서로를 인증해야함.
이는 결국 "Chain of Trust" 문제가 제기됨
이를 해결하기 위해 모든 CA를 최종적으로 인증해주는 
ROOT CA가 존재함.
ROOT CA는 무조건 신뢰한다는 전재하에 이러한 PKI 구조가 유지됨.
 
위 그림에서 설명한 본인이 본인을 서명한다는 구조는
ROOT CA 인증서에 해당함.
ROOT CA 인증서 이외의 인증서는 제 3자가 인증해줘야함.

 

 
 

PKI 결론

 
PKI는 공개키를 공개할 수 있는 장소를 마련해주고
원하는 공개키를 가져올 수 있도록 해줌.
공개키 관리도 해줌(재생성, 폐기)
그리고 공개키 소유자의 신분을 보장해줌.
결국 이런 인프라 자체가 PKI를 의미함.
 
PKI는 정형화된 구조가 아니라 
여러 형태의 구조로 존재할 수 있음.
 
위에서 사용한 인증서의 포맷도 여러가지가 있음
x.500 ~ x530등 다양하게 있지만
대표적으로 X.509 인증서 포맷을 사용함
 
PKI를 사용하는 환경은 예를 들어
특정 업체에서 사용할 수 있는 구조도 있고
kubernetes의 인증구조와 같이 특정 제품에서 사용할 수 있는 구조도 있음
대표적으로 웹에서 사용할 수 있는 구조가 있음.

 


제 글을 복사할 시 출처를 명시해주세요.
글에 오타, 오류가 있다면 댓글로 알려주세요! 바로 수정하겠습니다!


 

참고
학부생 때 기록했던 자료 및 내 머리...

 

반응형