[보안] PKI(Public Key Infrastructure) 시스템을 활용한 TLS 통신(HTTPS, 공동인증서)

💙베하💙 누구든 탑승할 수 있는 유임승차 팀입니다!!💨😉

TLS 란?

네트워크를 공부하다 보면 "네트워크 7계층" 혹은 "TCP/IP 4계층" 이라는 용어를 접해 보셨을 것입니다.

서로 통신을 할 때 사용되는 여러 프로토콜 단계들을 각각의 계층으로 나누어 구분할 때 네트워크 7계층(혹은 OSI 7계층) 으로 구분짓기도 하고 TCP/IP 4계층으로 구분짓기도 합니다.

<OSI 7계층 과 매칭되는 TCP/IP 4계층>

 

TLS 는 TCP 통신인 Transport Layer 상위 계층에서 동작하는 통신이라고 합니다.

 

 

<TLS 계층의 프로토콜 구조>

 

TLS(Transport Layer Security) 는 SSL(Secure Socket Layer) 에서 발전한 형태라고 생각하시면 되는데, 웹 브라우저를 만들었던 Netscape 에서 WWW를 이용한 안전한 통신을 보장하기 위해 개발된 SSL 프로토콜이 널리 사용되면서 이를 표준화 하기 위해 SSL 3.1 -> TLS 1.0 으로 명칭이 변경되었습니다.

 

일반적으로 SSL 이나 TLS 를 혼용해서 부르기도 하지만, 현재는 SSL 는 보안 취약점이 발견되어 TLS 를 사용한다고 합니다.

 

그리고 TLS 프로토콜을 사용한 통신 위에 HTTP 프로토콜을 얹어 통신하는 방식을 HTTPS 라고 합니다. HTTPS 에 대해서는 뒤에서 다시 한 번 설명하겠습니다.

 

 

PKI 시스템

PKI(Public Key Infrastructure) 를 이해하기 위해서는 대칭키와 비대칭키의 개념부터 이해할 필요가 있습니다.

<대칭키를 사용한 암호화 방식>

- 대칭키 : 암호화를 하거나 복호화를 할 때 같은 키를 사용함. DES, AES 같은 알고리즘을 사용함

<비대칭키를 사용한 암호화 방식>

- 비대칭키 : 공개키 암호화 방식이라고도 하며, 암호화를 할 때와 복호화를 할 때 서로 다른 키를 사용함. RSA 알고리즘을 주로 사용

 

PKI 는 이름에서도 Public Key 가 들어가 있듯, 공개키 방식(비대칭키 방식)을 활용해 보안을 강화한 구조입니다.

 

PKI 를 이해하기 위해 하나의 시나리오를 따라가 봅시다.

 

시나리오1) 사용자가 은행 사이트에 접근하기 위해 계정정보를 입력함

<암호화 없이 평문(Plain Text) 을 전달 >

온라인뱅킹을 하기 위해 은행 사이트에 접속할 때, 암호화 과정이 없다면 사용자가 입력한 계정정보(id / pw) 는 서버에 그대로 전달됩니다. 그리고 해커는 스니핑(네트워크 상의 패킷 교환을 엿보는 행위)으로 이 노출된 계정정보를 그대로 탈취할 수 있습니다. 이런 문제를 막기 위해선 암호화가 반드시 필요합니다.

 

시나리오2) 사용자의 계정정보를 암호화한 뒤, 암호화에 사용한 키와 같이 전달함

<계정정보를 대칭키로 암호화함>

<서버에서 암호화된 사용자의 계정정보를 풀기 위해 대칭키도 같이 전달>

사용자는 계정정보가 노출될 수 있으니, 대칭키를 사용해 자신의 계정정보를 암호화합니다. 이 때, 서버에서 사용자의 암호화된 계정정보를 복호화하려면 사용자의 키가 필요하니 대칭키를 암호화된 계정정보와 같이 전달합니다.

물론, 해커는 이 과정에서 스니핑으로 암호화된 계정정보와 키를 탈취할 수 있습니다. 이런 문제를 해결하기 위해서는 비대칭키를 사용해야 합니다.

 

시나리오3) 사용자의 비대칭키를 사용해 계정정보를 넘김

<각각의 사용자마다 공개키를 서버에 등록>

비대칭키를 사용한다면 일반적으로 공개키로 암호화를 한 뒤, 개인키로 복호화를 합니다.(개인키로 암호화를 한 뒤 공개키로 복호화할 수도 있지만, 그런 경우엔 공개된 키로 모든 사람이 내가 암호화 한 데이터를 다 열어볼 수 있습니다.)

 

따라서 공개키로 암호화를 하면 암호화된 데이터를 해커가 스니핑으로 가져가더라도 개인키가 없으면 열어볼 수 없으니 안전합니다.

 

사용자가 개인키와 공개키를 생성하여 서버에 공개키를 등록해 놓는다면, 서버는 사용자가 개인키로 암호화 한 데이터를 열어볼 수 있습니다.

 

하지만 이 경우 첫째로 공개키를 가져가 사용자가 암호화 한 데이터를 열어볼 수 있는 문제가 있고, 둘째로 각 사용자 마다 자신의 공개키를 서버에 등록해 줘야 하는 문제가 있습니다.

 

시나리오4) 서버의 비대칭키를 이용해 사용자의 대칭키를 넘기고 대칭키로 암호화된 계정정보를 넘김

<서버에서 비대칭키를 생성>

<서버의 공개키로 사용자의 대칭키를 암호화>

서버는 비대칭키를 생성한 뒤, 서버의 공개키를 사용자에게 전달하면, 사용자는 서버의 공개키로 사용자의 대칭키를 암호화합니다. 이렇게 암호화된 대칭키를 서버에 다시 전달하면 중간에 해커가 가로채더라도 서버의 개인키가 없으니 사용자의 대칭키를 탈취할 수 없고, 서버에게 전달된 사용자의 대칭키를 통해 사용자와 서버 간 암호화된 통신을 할 수 있게 됩니다.

 

하지만 여기서 해커는 또 다른 방법을 사용합니다.

<피싱사이트를 만들어 계정정보 탈취>

해커는 사용자가 온라인 뱅킹을 하기 위해 my-bank.com 에 접속하는 과정에서 해커가 만든 피싱사이트(정상적인 사이트와 완전히 동일한 사이트) 에 접속하도록 유도하고, 피싱사이트의 공개키를 사용자에게 넘겨 사용자의 대칭키를 탈취합니다.

 

그럼 이런 방법을 막기 위해선 어떻게 해야 할까요?

 

시나리오5) 공개키를 전달할 때 인증서를 만들어 전달

<인증서 예시>

단순히 서버에서 사용자에게 공개키만 전달하면 누가 보냈는지 알 수 없으니 인증서를 만들고, 인증서 안에 공개키를 담아 같이 전달하는 방법을 사용합니다.

 

인증서는 위의 그림과 같이 여러가지 정보를 담고 있는데, 인증서의 발행자, 이름, DNS 이름, 공개키, 서버의 위치 등을 포함하고 있습니다. 이 인증서 안에는 사용자가 접속하려는 서버의 DNS 이름이 있고, 이 이름과 사용자가 입력한 url 이 일치하는지를 브라우저에서 확인한 뒤 진짜 서버라고 인식하여 서버의 공개키를 받아 사용자의 대칭키를 전달 후 SSH(Secure Shell) 통신을 하게 됩니다.

 

하지만 이렇게 복잡한 방식에서도 안심할 수 없습니다. 해커는 서버의 진짜 인증서와 동일한 가짜 인증서를 만들어 자신의 인증서가 진짜라고 우기며 사용자에게 자신의 공개키를 전달할 수 있습니다.

 

인증서를 만들 땐 인증서가 유효함을 증명하는 sign 이 필요한데, 예를들자면 아래의 이미지와 같습니다.

(실제 인증서는 데이터로 이뤄졌기 때문에 아래와 같은 이미지는 존재하지 않습니다.)

<sign 된 인증서 이미지 예시>

이 때 만들어진 인증서(certificate) 에 스스로 sign 한 인증서를 self-signed certificate 라고 합니다. 바로 이런 self-signed certificate 를 이용해 해커가 자신의 인증서가 진짜라고 우기는 경우, 시나리오4) 와 동일하게 해커에게 사용자의 대칭키를 전달하게 될 수 있습니다.

 

참고로 self-signed certificate 를 사용하는 서버의 url 에 접속하는 경우, 브라우저에 미리 등록된 공인된 CA기관의 sign이 없기 때문에 아래와 같은 화면을 보게 됩니다.

<self-signed certificate 를 사용하는 서버와 HTTPS 통신을 시도할 때>

 

시나리오6) CA(Certificate Authority) 가 서버가 만든 인증서에 싸인을 해 줌

그렇다면 어떻게 공신력 있는 인증서를 만들어 사용자에게 전달할 수 있을까요? 바로 아래와 같은 공신력 있는 CA기관들이 당신이 만든 인증서에 싸인을 해 줄 경우 정상적인 인증서라고 인증받게 됩니다.

<CA 기관들에게 인증서 싸인을 요청>

HTTPS 통신을 위한 웹 서비스를 제공하는 서버들은 공신력 있는 CA기관들(Symantec, DigiCert, Comodo, GlobalSign 등)에게 자신들이 만든 인증서의 sign 을 요청하는데 이 과정을 CSR이라고 합니다.

 

CA기관은 CSR을 요청받아 건내받은 인증서가 이미 등록된 인증서인지, 형식이 맞는지 등을 검증한 뒤 sign 을 하여 sign 된 인증서를 요청한 서버에 전달하게 됩니다.

 

따라서 만약 해커가 만든 피싱사이트의 인증서를 CSR로 CA의 sign 을 요청한다면, 이 검증과정에서 실패하기 때문에 CA의 sign 을 받은 인증서는 안전하다고 할 수 있습니다.

<각 브라우저에 등록된 CA들의 public key>

또한, WWW에 접근하기 위해 사용되는 모든 브라우저들에는 CA들이 미리 등록되어 있는데, 단순히 등록된 것 뿐만 아니라 CA들의 공개키가 등록되어 있습니다.

 

서버의 인증서를 CSR 요청하면 CA가 sign 을 한 뒤, 서버에 인증서를 전달할 때 CA의 개인키로 인증서를 암호화하여 전달하게 되는데, 서버는 이 CA의 개인키로 암호화된 인증서를 사용자에게 바로 전달합니다.

 

이 때 사용자는 브라우저에 등록된 CA의 공개키로 암호화된 인증서를 복호화 할 수 있고, 그렇기 때문에 만약 해커가 자신의 인증서를 자신이 CA기관인것처럼 속이고 암호화된 인증서를 사용자에게 전달했다 하더라도 사용자의 브라우저에 해커가 만든 CA의 공개키가 등록되어 있지 않기 때문에 정상적인 CA기관에서 sign 받은 인증서인지 알아볼 수 있습니다.

 

만약 사내 내부망에서만 사용할 목적의 인증서가 필요하다면 private CA 를 만들어 운영할 수 있고, 이 경우에는 이 인증서를 필요로 하는 사용자의 브라우저에 private CA 및 private CA 의 공개키를 직접 등록해 줘야 합니다.

 

하지만 만약 어떤 이유로든 사용자의 계정정보가 해커에게 탈취된 경우라면 어떻게 할 수 있을까요?

 

시나리오7) 사용자의 인증서를 CA에 등록 후 서버에 전달

사용자가 만약에라도 직접적인 탈취로 계정정보를 빼앗긴 경우를 방지하기 위해 사용자가 자신의 인증서를 만들어 CA에게 CSR을 요청하고 sign 받은 인증서를 서버에 전달하여 서버와 통신하는 방법이 있습니다.

 

하지만 이런 방식은 일반적으로 잘 일어나지 않는 경우이기에 대체로 웹 서버에 구현되지 않는다고 합니다.

 

요약) PKI

<서버의 공개키가 포함된 인증서를 CSR요청>

1. 서버에서 자신이 만든 인증서(공개키 포함)를 CA기관에 CSR 요청

<CA의 private key 로 서버의 인증서 암호화 후 전달>

2. CA는 요청받은 인증서의 검증 및 sign 을 한 뒤 자신의 개인키로 암호화하여 서버 -> 사용자에게 까지 전달함

<사용자의 대칭키 전달하는 과정>

3. 사용자는 자신의 브라우저에 등록된 CA의 공개키로 서버의 인증서(공개키)를 획득하고, 자신의 대칭키를 서버의 공개키로 암호화하여 서버에게 전달함

4. 사용자와 서버는 같은 대칭키를 소유하고 있으므로 SSH 통신을 할 수 있음

 

PKI 시스템의 활용 1 - HTTPS

PKI 가장 대표적으로 사용되는 것이 HTTPS 통신입니다.

기존 HTTP 통신이 암호화 되지 않은 패킷들이 웹 상에서 통신되었다면, HTTPS 는 아래와 같이 자물쇠 모양이 표시된 사이트를 이용할 때의 모든 패킷들이 위의 PKI 방식을 활용하여 통신하게 됩니다.

<https 통신을 하는 사이트>

 

PKI 시스템의 활용 2 - 공동인증서

2020년 5월 전자서명법이 개정되면서 덕지덕지 ActiveX를 설치해야만 사용할 수 있었던 공인인증서 방식이 명칭을 바꿔 공동인증서가 되었습니다.

 

이 명칭이 변경된 이유는 사용자에게 어떤 인증서를 사용할 것인지에 대한 선택권을 부여하고, 전자서명 시장의 자율경쟁을 촉진하여 신기술 기반의 다양한 전자서명 활성을 유도하기 위함이라고 합니다. 그에 맞춰 "공인"이라는 용어에서 다양한 인증서가 있다는 뜻으로 "공동"이라는 용어를 사용하게 되었습니다.

 

이 공동인증서(구 공인인증서) 가 대표적인 PKI 를 활용한 시스템이고, 현재는 금융인증서와 같이 사용되고 있습니다.

자세한 내용은 아래 영상을 참고해 주세요!

https://www.youtube.com/watch?v=Znvxw6J-Vpc