PKI(Public Key Infrastructure)란
PKI는 비대칭 암호화 기술을 이용한 공개키 기반의 인증 체계임.
- 활용 사례 : HTTPS, SSH, 인터넷 뱅킹 등
- 대표적인 인증서 표준 포멧 : X.509 → 쿠버네티스에서는 X.509를 이용하여 사용자의 신원을 인증하는 목적으로 사용할 수 있음.
(참고로 이는 쿠버네티스의 많은 인증 방법들 중 하나임 - HTTP Authentication, OpenID Connect, Webhook, Proxy Auth, ..)
Public-Private 키
- X.509의 근간이 되는 암호화 기술
- Public 키와 Private 키가 존재
- Public 키는 누구나 가질 수 있으며, Private 키는 오직 Public, Private 키페어 소유자만 가지고 있음
- Public key는 Private key로만 복호화가 가능
PKI 인프라 구조(순서)
![](https://velog.velcdn.com/images/whattsup_kim/post/d2102f06-da24-4354-915d-0adb920be437/image.png)
인증서 내용(구조)
: 사용자 정보 + Public key + 공개 기관(Certificate Authority)의 서명
![](https://velog.velcdn.com/images/whattsup_kim/post/319fd21d-cc51-49bf-a161-e8806547dd22/image.png)
- 인증서에는 해당 인증서를 발급해준 발급 기관 (Issuer) 정보를 포함하고 있다.
- 발급 기관 정보를 이용하여 지금 보고 있는 인증서가 아무에게서나 발급된 인증서가 아니라 공인된 인증 기관에서 발급된 인증서라는 것을 확인할 수 있다. 이것을 Certificate Authority(인증 기관)이라 부르고 짧게 CA라고도 한다.
- 이 CA 또한 인증서로 이루어져 있어 해당 Public 키로 인증기관의 유효성을 동일한 메커니즘으로 검사할 수 있다. CA도 마찬가지로 CA의 인증서를 발급한 인증 기관(CA의 CA)이 존재하며 이러한 연결고리를 Certificate Chain (인증 체인)이라고 부른다.
- 인증 체인의 가장 끝에는 Root CA라고 하는 인증기관이 있다. 즉, Root CA를 이용하여 다른 CA를 검증하고 해당 CA가 최종 Certificate을 인증하는 것이다.
- 이 Root CA는 따로 인증 기관이 존재하지 않으며 스스로가 스스로를 인증한다.
PKI 동작 예시
다음 블로그의 글의 예시를 참고하였습니다.
예시 1) 상대방에게 메세지를 암호화하여 전달
- W의 암호화 열쇠 : [
W_Public Key
/ W_Private Key
]
- S의 암호화 열쇠 : [
S_Public Key
/ S_Private Key
]
- 이때, W가 S에게 “hello S”라는 메세지를 모내고 싶은 경우 다음과 같이 진행된다.
- W는 S의 공개된 열쇠인
S_Public Key
를 이용하여 "hello S" 라는 메세지를 암호화 한다. 암호화 했더니 "asj29dfns3aju1—" 라는 메세지로 변환되었다.
- 암호화 된 메세지를 S에게 전송한다.
- S는 자신만이 알고 있는 사적 열쇠인
S_Private Key
를 이용하여 메세지를 해독하여 "hello S" 라는 내용을 받는다.
- 이렇듯 상대방의 공개 열쇠를 이용하여 메세지를 암호화 한 후 전송하면, 그 상대방만이 메세지를 해독할 수 있다.
- 2번 과정에서 다른 이가 메세지를 가로채도 "asj29dfns3aju1—" 라는 메세지를 해독하는 것은 (거의) 불가능하다.
예시 2) 나 자신을 증명(신원 확인) - 디지털 서명(digital signature)
- 위 예시에서 반대로 W가 보낸 메세지를 S가 확인하고 싶은 상황이라고 가정해보자.
- S는 이 메세지가 정말 W가 보낸 것인지 확인 할 방법이 없다.
- 이럴 경우, W는
W_Private Key
를 통해 메세지르 암호화하여, S에게 보낼 수 있다.
- S는 이전에 W에게 전달받은
W_Public Key
으로 해당 메세지가 정말 W가 보낸 것이 맞는지 검증할 수 있다.
SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)
보안서버란
인터넷 상에서 사용자 PC와 웹 서버 사이에 송수신되는 정보를 암호화하여 전송하는 서버를 의미
- 웹 브라우저와 웹 서버 간 전송되는 데이터의 암/복호화를 통해 보안 채널을 형성하여 안전한 전자 거래를 보장함
보안 서버 구축 필요성
- 정보 유출 방지(sniffing : 서버로 전송되는 고객의 정보 해킹)
- 위조 사이트 방지(phishing : 기업을 사칭하여 고객의 정보를 뺴가는 등의 사기수법)
SSL(Secure Socket Layer)와 TLS(Transport Layer Security)
SSL이란 웹 표준 암호화 방식으로, 웹 서버와 웹 브라우저 사이에 몯느 정보를 암호화 해주는 방식을 의미
- SSL 통신은 http가 아닌 https 통신채널을 사용하며, 모든 웹 서버와 웹 브라우저가 SSL을 지원함
- SSL은 서버 인증(Server Authentication), 클라이언트 인증(Client Authenitication), 데이터 암호화(Data Encryption) 기능을 제공함
TLS 1.0은 SSL 3.0을 계승한다.
- TLS은 SSL 3.0을 기반으로 한 업그레드된 프로토콜임
SSL/TLS의 주요 기능은 다음과 같다.
- 신원 확인
- SSL 서버 인증서는 회사에 대한 방문조사 후 발급되기 때문에 고개들은 서버 인증서를 확인하여 회사의 웹 사이트가 실제로 존재하고, 회사의 소유임을 확인할 수 있다.
- 메시지 비밀 보장
- SSL로 웹 서버와 고객 간 교환된 정보를 하나의 Session 키로 암호화한다.
- 이 Session 키를 안전하게 고객에게 전달하기 위해 회사의 공캐키로 암호화하여 보냄
- 이때, 각 Session에 한 고객에게 하나의 키가 사용되므로, 권한이 없는 제3자는 정보를 가로채도 볼 수 없음
- 메시지의 무결성
- 사용자의 브라우저로부터 Web Server까지 전달되는 동안 누군가에 의해 데이터가 변경되지 않도록 보장한다.
대칭(Symmetric Encryption) 키 vs 비대칭(Asymmetric Encryption) 키
대칭키 : 암호화-복호화에 동일한 키를 사용하는 것
비대칭 키 : 암호화할 때와 복호화할 때의 키가 서로 다른 것
- 안전한 키 교환을 할 수 있지만, 속도가 느림
→ 다음과 같이 상호보완한 방법도 있음 : 용량이 큰 정보는 대칭키로 암호화하고, 암호화에 사용된 대칭키는 공개키로 암호화하여 대상에게 전달하는 방식
SSL 동작방법
본 섹션은 다음 블로그(1), 블로그(2)를 참고하였습니다.
![](https://velog.velcdn.com/images/whattsup_kim/post/e9e54bab-164f-4c19-8f1b-5b43b9171154/image.png)
- 인터넷 사이트는 자신의 정보와 공개 키를 인증기관에 제출한다.
- 인증기관은 검증을 거친후 사이트 정보와 공개 키를 인증기관의 개인 키로 암호화한다(=사이트 인증서).
- 인증기관은 인터넷 사이트에게 암호화한 인증서를 제공한다.
- 인증기관은 웹 브라우저에게 자신의 공캐 키를 제공한다.
- 사용자가 웹 브라우저로 사이트에 접속을 요청한다(Handshake: Client Hello). 사용자는 이때 서버에 다음과 같은 정보들을 보낸다.
- 클라이언트 측에서 생성한 랜덤한 데이터
- 클라이언트가 지원하는 암호화 방식들 : 클라이언트가 전달한 암호화 방식 중에서 사이트 쪽에서도 사용할 수 있는 암호화 방식을 선택하기 위한 작업
- 세션 아이디 : 이전에 HandShake를 했다면, 비용과 시간을 절약하기 위해 기존의 세션을 재활용하게 되는데, 이 때 사용할 연결에 대한 식별자를 사이트 측으로 전송한다.
- 사이트는 이에 대한 대답으로 다음과 같은 정보들을 보낸다(Handshake: Server Hello).
- 사이트 측에서 생성한 랜덤한 데이터
- 사이트가 선택한 웹 브라우저의 암호화 방식 : 이를 통해 암호화 방식 선택을 완료한다.
- 인증서(이 인증서에는 인증기관의 개인 키로 암호화한 사이트의 정보와 사이트의 공개키가 들어있다.)
- 웹 브라우저는 인증기관의 공개 키로 사이트 인증서를 해독하여 검증한다.
- 웹 브라우저에 내장된 CA 리스트를 확인(CA 리스트에 없다면 경고 메세지를 출력)
- 웹 브라우저 측에서 생성한 랜덤 데이터와 사이트 측에서 생성한 랜덤 데이터를 조합하여
pre master secret
라는 대칭키를 생성
- 웹 브라우저는 위에서 얻은 사이트 공개 키로 대칭키를 암호화해서 사이트로 보낸다.
- 사이트는 자신의 개인 키로 암호문을 해독하여 대칭 키를 얻는다.
- 이제 대칭 키로 암호문을 주고받을 수 있다.
- (9)까지의 과정을 통해 웹 브라우저와 사이트 모두 동일한 pre master secret을 가졌다. 이를 일련의 과정을 거쳐서 master secret 값으로 만든 뒤 이를 통해 Session key를 생성한다.
- 이 Session key 값을 이용하여 사이트와 웹 브라우저는 데이터를 대칭 키 방식으로 암호화 한 후에 주고받는다.
- 이후 데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알린 후, 통신에 사용한 Session key를 폐기한다.
Reference