TLS Certificate란?(대칭 키, 비대칭 키, CA, PKI)

 

이번 포스팅은 사용자-은행 시나리오를 통해 TLS Certificate가 무엇인지

그리고 추가적으로 알아야 할 보안적인 요소에 대해서 다룬다. 

 

우선 TLS certificate에 대해 간단히 알아보자면 

Certificate에서 예상할 수 있듯이 두 그룹간 거래에 신뢰성을 보장하기 위해 사용되는 것이다.  

 

그렇다면 이제부터 안전하게 뱅킹 서비스를 이용하려는 사용자에 대한 시나리오를 생각해보자. 

 

 

 

< 사용자-은행 시나리오 >

 

한 사용자가 뱅킹 시스템에 접속해서 은행 서버로 필요한 정보(아이디, 패스워드 등)를 보내려한다. 

 

만약 한 사용자가 어떠한 보안 조치도 되어있지 않은 crediential을 보낸다면

해커는 중간에 데이터를 스니핑할 수 있다.  

 

그래서 사용자는 데이터 보안을 위해 데이터를 암호화해서 서버로 보내야 한다. 

 

해커가 중간에서 데이터를 탈취해도 데이터가 암호화되어 있기 때문에 이 데이터가 어떤 데이터인지 알 수 없다.  

 

하지만 은행 서버 입장에서도 마찬가지다. 

 

은행 서버는 사용자가 어떤 데이터를 보냈는지 알기 위해서 사용자가 암호화할때 사용했던 키를 가지고 있어야 한다. 

 

이때 동일한 키를 갖는다고 해서 이를 대칭키(symmetric key)방식이라고 한다. 

 

하지만 은행서버와 사용자가 동일한 키를 갖기 위해서는 꼭 한 번은 이 키를 교환하는 과정이 필요한데 

키를 교환하는 과정에서 해커가 이를 탈취할 수 있다는 위험성이 있다. 

 

 

 

질문 ☞ 어떻게 하면 해커의  스니핑으로부터 안전하게 대칭키를 교환할 수 있을까? 

 

그래서 이에 대한 대안으로 나온 방식이  비대칭키(asymmetric key)방식이다.

 

비대칭 키방식은 프라이빗 키(private key)와 퍼블릭 키(public key)를 사용한다. 

 

프라이빗 키는 말 그대로 오직 나만 가지고 있어야 하는 키다. 

 

반대로 퍼블릭 키는 퍼블릭하기 때문에 모든 사람이 가져도 되는 키다.  

 

 

 

※ 참고 - 퍼블릭 키과 프라이빗 키의 형식 

 

 

 

퍼블릭 키를 가진 사람은 데이터를 퍼블릭 키로 암호화하여 프라이빗 키를 가진 사용자에게 전송하고

프라이빗 키를 가진 사용자는 프라이빗 키를 이용하여 이를 해독하고 오리지널 데이터를 얻을 수 있다. 

 

사용자가 은행서버와 대칭키를 안전하게 교환하기 위해서 이 비대칭키 방식을 사용하면 된다. 

 

은행 서버에서 다음과 같이 비대칭키를 생성하고  

 

 

 

사용자는 https를 이용하여 처음 은행 서버에 접속할 때 은행 서버의 퍼블릭 키를 얻는다. 

(클라이언트가 Https로 접근하게 되면 서버의 퍼블릭 키를 얻는다)

 

은행 서버의 퍼블릭 키를 얻은 사용자는 대칭키를 퍼블릭 키로 암호화하여 이를 은행 서버로 보낸다.

 

은행 서버는 은행서버의 프라이빗 키를 이용해서 사용자가 보낸 대칭키를 알 수 있다.

 

중간에서 스니핑을 하던 해커는 은행서버의 퍼블릭 키, 퍼블릭 키로 암호화된 대칭키만 알 수 있지 대칭키 자체는 알 수 없다. 

 

즉 해커로부터 안전하게 사용자와 은행서버간 데이터를 주고 받을 수 있게 된 것이다.  

 

하지만 중간에 정보를 탈취할 수 없게 된 해커는 다른 방법을 생각해낸다.

 

바로 은행 서버와 똑같이 생긴 사이트를 만드는 것이다. 

 

사용자 입장에서는 해커가 만든 은행 서버와 실제 은행 서버는 똑같아 보이기 때문에 

해커의 서버로 접속해 개인정보를 입력할 수도 있는 것이다. 

 

 

해커 또한 마찬가지로 비대칭키를 생성하여 대칭키 교환방식을 통해 사용자로부터 대칭키를 얻어낼 수 있는 것이다. 

 

즉, 사용자로부터 대칭 키를 얻어낸 해커는 대칭키와 다른 추가적인 정보를 이용하여

사용자인척 연기할 수 있는 것이다.  

 

그래서 실제 은행서버는 처음 우리가 Https로 접속했을 때 퍼블릭 키 달랑 하나만 보내지 않는다. 

 

인증서(certificate)안에 퍼블릭 키를 담아서 보낸다.

 

 

인증서에는 이 인증서를 누가 발행했고, 주체는 누구이며 퍼블릭 키는 무엇인지 등에 대한 정보가 담겨 있다. 

 

은행 서버로부터 인증서와 퍼블릭 키를 받은 사용자는 인증서를 통해

"내가 진짜 은행 서버에 접속했다"는 것을 알 수 있는 것이다. 

 

 

 

질문 ☞ 그렇다면 해커 또한 인증서를 만들어서 진짜 은행 서버처럼 보이게 할 수 있지 않을까?

 

답은 그렇지 않다. 

 

인증서를 발급받을 때는 자신의 사인이 들어가게 되는데, 은행 서버의 사인과 해커의 사인은 다르기 때문이다.   

 

클라이언트의 브라우저는 접속한 서버로 부터 받은 인증서가 "안전한 인증서가 아님"을 다음과 같이 알려준다.

 

 

 

 

그렇다면 여기서 또 연달아 물을 수 있다.

 

질문 ☞ 정식 인증서를 만들면 되지 않을까? 

 

하지만 정식 인증서는 CA(Certificate Authorities)에서 발급을 인정해준 경우만 가능하므로

정식 증서 발급은 쉬운 일이 아니다.

 

CA

 

정식 인증서 발급은 다음과 같은 과정으로 이루어지는데 

 

1. Certificate Signing Request(CSR) : 인증서 발급을 요청

2. validate information : 유효한 정보인지 판단

3. sign and send certificate : 인증서 발급 

 

해커는  validate information 단계에서 통과하지 못하고, 정식 인증서를 발급할 수 없다. 

 

이렇게 사용자는 브라우저를 통해 "사용자가 접속한 은행 서버가 진짜 은행서버다"라는 것을 알 수 있게 된다.

 

 

 

질문 ☞ 그런데 브라우저는 이 인증서가 정식 인증서인지 어떻게 판단할까?

 

CA를 모방하는 기관에서 발급해준 인증서일 수도 있지 않은가?

 

CA는 자신들의 프라이빗 키를 이용해서 인증서를 발급한다.

 

그리고 우리의 브라우저는 모든 CA들의 퍼블릭 키를 처음부터 제공받는다. 

 

브라우저는 CA의 퍼블릭 키를 이용해서 이 증서가 CA가 발급한 인증서인지 확인할 수 있는 것이다. 

 

이렇게 사용자는 Https와 인증서를 이용하여 내가 접속한 은행 서버가 진짜 은행서버인지를 판단하고  

아이디와 패스워드를 마음 놓고 입력할 수 있는 것이다. 

 

 

 

질문 ☞ 하지만 만약 해커가 이미 사용자의 아이디와 패스워드를 알고 있다면 은행서버가 이를 대처할 수 있을까?

 

이에 대한 대안으로 우리는 TLS를 이용한다. 

 

은행서버는 사용자가 은행서버가 원하는 사용자가 맞는지 판단하기 위해 

접속 초기에 Trust building 작업을 한다. 

 

은행서버 또한 사용자에게 정식 인증서를 요청하는 것이다. 

 

하지만 실제로 은행 서버를 이용하면서 인증서를 발급하지는 않고, 

사용자는 인증서를 발급할 필요 또한 없다.

 

이러한 모든 구조들을 합쳐서 PKI(public key infrasturcture) 구조에 의해

처리가 되기 때문에 사용자는 안전하게 뱅킹 서비스를 이용할 수 있는 것이다.