[CS] SSL/TLS 인증서는 어떻게 등장했을까?

🔊 해당 포스팅은 인프런 강의 널널한개발자님의 외워서 끝내는 SSL과 최소한의 암호기술 내용을 공부하면서 배운 내용을 저만의 방식으로 재정리하고자 하는 목적 하에 작성되는 포스팅입니다. 아래 포스팅에서 사용되는 모든 자료는 제가 직접 재구성했음을 알립니다.

 

SSL/TLS 인증서는 어떻게 등장했을까?

---

이번 포스팅에서는 컴퓨터 공학에서 주로 사용되는 기초적인 암호기술과 관련해서 소개하려고 한다. 현재 웹 통신에서 가장 자주 사용되는 SSL/TLS 인증서가 등장하기 이전의 전통적인 암호기술은 어떤 방식을 채택했는지, 그리고 어떤 문제점이 있어 지금의 SSL/TLS 인증서까지 오게 되었는지 시간의 흐름 순으로 살펴보도록 하자. 그에 앞서서 기초적인 암호기술 관련된 몇 가지 개념들에 대해서 배워보도록 하자.

1. Checksum과 Hash

체크섬(Checksum)과 해시(Hash)에 대한 개념에 대해 알아보자. 먼저 체크섬은 한국어로 해석하면 '검사합'이다. 이름에서도 유추할 수 있다시피 체크섬은 데이터 원본을 어딘가에 복사했을 때 복사본과 원본 간의 데이터 차이가 없는지 확인하기 위해 사용된다. 체크섬은 데이터를 일정한 단위로 쪼갠 뒤, 쪼갠 단위를 계속 합(sum)을 하는 것이다. 그래서 원본의 체크섬과 복사본의 체크섬을 비교해서 동일하다면 원본 데이터가 복사본 데이터는 일치함을 의미한다. 

 

하지만 체크섬에서 주의할 점은 체크섬이 데이터 무결성을 보장하지는 못한다는 것이다. 여기서 데이터의 무결성이라 함은 데이터를 위조나 변조할 수 없는 특성을 의미한다. 체크섬은 왜 무결성을 보장하지 못할까? 방금 체크섬이라는 것은 데이터를 일정한 단위로 쪼갠 뒤, 쪼갠 단위들을 계속 합해나가는 것이라고 했다. 그러면 만약에 이 쪼개진 단위의 일부를 누군가가 변조해놓는다면 어떻게 될까? 아래 그림처럼 말이다.

 

중간에 해커가 데이터 일부를 변조한다면?

 

원본 데이터가 존재하는데, 중간에 해커가 일부 단위의 데이터에 대해 변조를 수행했다. 하지만 체크섬은 이러한 변조를 수행했다고 해서 체크섬의 값이 변조 이전과 달라지지는 않는다. 따라서 복사본의 체크섬이 원본의 체크섬과 동일하다고 하더라도 그 데이터 내부의 일부는 여전히 변조된 상태일 수 있는 것이다.

 

이러한 체크섬의 문제를 해결하기 위해 해시가 등장한다. 우선 해시란 무엇일까? 우리가 한 번이라도 들어보았을 법한 '해시함수'의 해시가 그것이다. 만약 어떤 박스에 무엇을 넣었을 때, 결과를 내뱉는다라고 한다면 '박스가' 바로 해시라고 할 수 있다.

 

 

그런데 해시는 단방향의 특성을 갖는다. 즉, 위 그림에서 해시는 출력을 보고 입력을 역추론할 수는 없다는 것이다. 그리고 해시는 입력 값의 크기가 달라져도 결과값의 길이는 일정하다. 예를 들어, 위 그림에서 입력에 x를 넣던, xy를 넣던, 1234567890을 넣던 출력은 고정된 길이의 임의의 값으로 출력된다는 특징을 갖는다. 그래서 해시는 이런 특성으로 인해 데이터 무결성 확보를 위해 대부분 사용된다.

 

대표적인 해시 알고리즘의 종류로는 MD-5, SHA-1, SHA-128, SHA-256, SHA-384, SHA-512 등이 있다. 여기서 우리는 MD-5 알고리즘의 특징에 대해서 살펴보도록 하자. MD-5는 다른 알고리즘과 달리 상대적으로 복호화하기 쉬운 난이도의 알고리즘에 속한다. 그래서 MD-5 알고리즘을 패스워드 단방향 암호화에 사용을 하지 않도록 강력히 권고하고 있다. 왜냐하면 MD-5 알고리즘의 해쉬 결과값을 복호화할 수는 없지만 모든 경우의 수가 현대 컴퓨터의 성능으로 커버할 수 있는 정도라면 모든 경우의 수에 대한 문자열을 집어넣은 뒤, 그 중 하나가 해쉬 결과값과 동일한 것을 찾는 브루트 포스 방식을 수행할 수 있기 때문이다. 그래서 보통 MD-5 알고리즘에 SALT라는 임의의 값을 원본에 첨가한 뒤 해시를 적용한다. 이렇게 되면 해시 결과값의 길이가 더 늘어나기 때문에 이전보다 모든 경우의 수를 찾기가 매우 힘들어진다. 물론 이 SALT 값은 해당 SALT 값을 추가한 사람들 간에 공유되는 값이다. 어쨌거나 요즘에는 MD-5 보다는 SHA 계열의 알고리즘을 많이 사용한다는 점을 알아두자.

 

해시의 활용 예시로는 인증서 검증, 디지털 포렌식, 디지털 서명, 방금 알아본 패스워드 단방향 암호화, 블록체인 등에 사용된다.

2. 대칭키만 사용! 아니면 비대칭 키만 사용!

다음은 키를 암호화하고 복호화하는 데 사용되는 대표적인 방식들인 대칭키와 비대칭 키에 대해서 알아보자. 먼저 대칭키이다.

대칭키는 1개의 키로 암호화, 복호화를 모두 수행하는 방식이다. 밑에서 알아볼 비대칭 키방식에 비해 압도적으로 효율적이다. 이 '효율적'이라는 구체적인 의미는 비대칭 키 방식에 대해 설명할 때 알아보도록 하자. 

 

대칭키 방식을 매우 간단히 이해하기 위해서는 XOR 논리 연산을 이해하면 된다. XOR 연산은 두 숫자가 모두 동일할 때 0을 내뱉고, 서로 숫자가 다를 경우 1을 내뱉는 연산이다. 그림은 다음과 같다.

 

XOR 논리연산

 

그런데 이 XOR 연산을 가지고 대칭키를 이해할 수 있다니? 이해를 위해 아래처럼 8비트 범위를 갖는 두 개의 숫자가 있다고 해보자. 그리고 이 2개의 숫자를 XOR 연산을 수행했다.

 

 

그러면 이제 반대로 위 그림에서 노란색과 초록색 간에 XOR 연산을 수행해보자. 

 

 

위 그림에서 초록색과 노란색의 XOR 연산 결과인 빨간색의 이진수가 직전 그림에서 보았던 회색의 이진수랑 동일한 것을 볼 수 있다. 이게 과연 무엇을 의미하는 걸까? 즉, 첫번째 그림이 암호화를, 두번째 그림이 복호화를 의미한다. 그리고 위 그림의 노란색 이진수가 바로 '대칭 키'가 된다. 결국 대칭키에 해당하는 노란색 이진수로 첫번째 그림에서는 암호화를 수행했고, 두번째 그림에서 복호화를 수행하기 위해 암호화에 수행한 동일한 키를 가져다 쓴다는 것이다.

 

이것이 바로 대칭키 방식이다. 대칭키의 대표적인 알고리즘으로는 DES, 3DES, SEED-128, ARIA, AES-128, AES-256 등이 있다.

 

대칭키를 인터넷 환경에서 클라이언트와 서버 간에 Secured 통신할 때 이용한다고 하면 아래 그림처럼 된다.

 

대칭키를 사용할 때의 두 서버 간의 통신 방법

 

하지만 대칭키 방식은 문제가 그림의 3번 단계에 있다. 한 쪽 서버에서 생성한 대칭키를 원격의 서버로 어떻게 이동시키냐는 것이다. 그냥 단순히 인터넷을 통해 전달한다면 보안에 매우 취약하게 된다. 왜냐하면 인터넷이라는 공간은 모두에게 개방되어 있는 Public 공간이기 때문이다. 해커가 인터넷이라는 공간에서 대칭키를 탈취하게 되면 그 데이터는 바로 해커가 복호화하여 들여다볼 수 있게 된다.

 

또 다른 방법으로는 대칭키를 USB와 같은 저장장치에 담아서 실제 원격 서버에 있는 물리적인 공간으로 이동해 원격 서버에 USB 장치를 꼽고 대칭키를 복사하는 것이다. 물론 이러한 방법은 원격 서버가 가까운 물리적인 공간에 있다면 상관없겠지만, 전세계의 어디든 통신할 수 있도록 하는 게 목표인 인터넷이라는 공간에서는 이런 방법은 현실성이 없다.

 

이러한 문제를 해결하기 위해 비대칭키 방식이 등장했다. 비대칭키는 각 서버마다 한 쌍의 키(즉, 총 2개의 키)를 생성하여 서로 상호작용하는 구조이다. 이 중 하나의 키로는 암호화를 수행하고, 나머지 키로는 복호화를 수행한다. 이 한 쌍의 키를 Public 키, Private 키로 구분한다. 비대칭 키 방식으로 어떻게 두 서버 간에 통신할 수 있는지 살펴보자. 먼저 상황은 [클라이언트 → 서버] 로 통신할 때의 단계이다.

 

클라이언트 → 서버로 통신할 때의 비대칭키 방식

 

가장 먼저 클라이언트와 서버 둘 다 한 쌍의 키를 생성한다. 그리고 각자의 Public 키를 교환한다. 이 교환하는 과정을 IKE(Internet Key Exchange)라고 부른다. 그리고 난 뒤, 클라이언트는 서버로 보낼 데이터를 암호화하는데, 이 때, 교환받은 Server의 Public 키로 암호화를 수행한다. 그런 다음 이제 이 암호화된 데이터를 보내기 위한 일종의 채널이 하나 생기는데, 이 채널을 'Tunnel(터널)'이라고 부른다. 이 터널을 통해 암호화된 데이터가 전송이 되면 서버에서는 자신의 Public 키 즉, Server의 Public 키로 복호화를 수행한다.

 

반대인 [서버 → 클라이언트]로 응답을 줄 때는 이제 서버에서는 Client Public 키로 암호화를 수행해서 클라이언트로 터널을 통해 넘겨주면 클라이언트는 자신의 키인 Client의 Public 키로 복호화를 수행하면 된다. 이것이 바로 비대칭키 방식이다.

 

하지만 위 비대칭키 방식은 문제점이 몇 가지 있는데, 먼저 1번 단계인 한 쌍의 키를 생성하는데 시간이 꽤 오래걸린다. 시간이 오래 걸린다는 것은 키를 생성하는 암호화 알고리즘의 복잡도가 높다는 것이고, 복잡도가 높다는 것은 보안성이 높다는 것을 의미한다. 왜 보안성이 높도록 하는걸까? 위 그림에서 보다시피 Public Key를 서로 교환할 때 인터넷을 통해 교환하게 된다. 그러면 인터넷에 존재하는 누군가들은 교환되고 있는 Public Key를 볼 수 있다. 물론 이 Public Key를 갖고 있다고 해서 바로 데이터를 복호화할 수 있는 것은 아니지만 이 Public Key를 가지고 그에 매핑되어 있는 Private Key를 어느정도 유추할 수 있게 된다. 이런 유추 가능성 때문에 최대한 Key의 보안성을 높게 하기 위해서 복잡도가 높은 암호화 알고리즘을 사용하게 될 수 밖에 없게 되고, 이 복잡도가 높은 암호화 알고리즘은 결국 Key를 생성하는 데 시간이 오래 걸리도록 한다. 하지만 이러한 시간이 오래 걸리는 작업을 매 통신마다 수행을 한다고 해보자. 레이턴시가 1,2초만 넘어가도 유저가 이탈하는 상황에서 키를 생성하는 데만 1초가 넘게 걸린다면 문제가 될 것이다.

3. 대칭키와 비대칭키를 혼합하자

비대칭키만 사용하는 방식의 대안으로 대칭키와 비대칭키를 함께 사용하는 방법이 등장한다. 이 방법의 핵심은 클라이언트는 대칭키를 사용하고, 서버는 비대칭키를 사용하는 것이다. 일단 아래 그림을 보자.

 

대칭키와 비대칭키 혼합 방식

 

먼저 클라이언트에서는 대칭키만을, 서버에서는 비대칭키를 생성한다. 그리고 이제 인터넷을 통해 서버는 자신의 Public Key를 클라이언트에 제공한다. 이 때, 클라이언트는 먼저 자신의 대칭키로 평문 데이터를 암호화시킨다. 그리고 난 뒤 서버의 Public Key를 활용해서 자신(클라이언트)의 대칭키 자체를 암호화한다. 그리고 이 2개를 터널로 송신한다. 

 

그러면 이제 서버는 먼저 암호화된 클라이언트의 대칭키를 자신(서버)의 Private Key로 복호화를 수행한다. 이게 가능한 이유는 클라이언트 쪽에서 서버의 Public Key로 암호화를 수행했기 때문임을 잊지말자! 이제 서버가 클라이언트의 대칭키를 얻어냈으니 암호화된 데이터를 클라이언트의 대칭키로 복호화를 수행하면 평문 데이터를 얻어낼 수 있게 된다. 이것이 바로 대칭키와 비대칭키를 혼합하는 방식이다.

 

하지만 이와 같은 방식은 인터넷 공간의 누군가 즉, 해커가 MITM(Man In The Middle) 공격을 수행해서 보안의 취약점이 생길 수 있다. 이 MITM 방식이 어떻게 공격하는지 간략하게 살펴보자. 아래 그림을 보자.

 

MITM 해킹 방식

 

이전 과정처럼 클라이언트는 대칭키, 서버는 비대칭키를 생성한다. 그런데 이번에는 클라이언트와 서버 간의 통신하는 경로인 인터넷의 어디 중간에서 악의적인 의도를 갖는 해커도비대칭 키를 생성한다. 그리고 서버가 클라이언트로 Public Key를 인터넷으로 송신하는 순간 중간에 해커가 서버의 Public Key를 탈취하고, 해커의 Public Key로 바꿔치기하여 클라이언트로 보낸다.

 

이렇게 되면 데이터 송신 측인 클라이언트가 자신의 대칭키를 암호화할 때 사용하는 Public Key를 서버 것이 아닌 해커의 것으로 암호화하게 된다. 당연하게도 클라이언트 측은 인터넷을 통해 전달받은 Public Key가 진짜 서버의 것인지, 해커의 것인지는 눈치채지 못한다. 이렇게 해커의 Public Key로 암호화된 클라이언트 대칭키와 클라이언트 대칭키로 암호화된 데이터가 터널을 통해 송신된다. 이 때 또 해커는 중간에 끼어들어 먼저 암호화된 클라이언트 대칭키를 해커 자신의 Private Key로 복호화한다. 이렇게 알아낸 클라이언트의 대칭키를 이용해서 이제 암호화된 데이터를 복호화할 수 있게 된다.

 

해커는 클라이언트의 데이터를 복호화해서 탈취한 뒤에 더 나아가 2번 단계에서 갖고 있었던 서버의 Public Key로 클라이언트의 대칭키를 다시 암호화해서 서버 쪽으로 보내준다. 이렇게 되면 어찌되었건 서버가 받은 암호화된 클라이언트 대칭키는 서버의 Public Key로 암호화한 셈이기 때문에 서버는 자신의 Private Key로 복호화해서 데이터를 볼 수 있게 된다. 

 

이 상황에서 가장 치명적인 문제는 바로 클라이언트, 서버 모두 자신이 송, 수신한 데이터가 해커에게 탈취된지 눈치채지 못한다는 점이다. MITM 해커 공격을 가능하게 한 가장 근본적인 원인은 클라이언트가 제공받은 Public Key를 무조건적으로 신뢰했기 때문에 발생한 것이다. 따라서 제공받은 Publicy Key가 정말 신뢰할 수 있는지 검증해야만 한다. 그러면 대체 Public Key를 어떻게 검증해야 할까?

3. 공식 인증 기관을 통해 Public Key를 검증하자!

대칭키와 비대칭키를 혼합하는 방식을 사용할 때 보안 취약점의 원인은 클라이언트가 수신받은 Public Key가 정말 서버의 것인지, 해커의 것인지 검증하는 것이라고 했다. 그러면 이를 어떻게 검증할까? 답은 생각외로 간단하다. 이를 검증해주는 제 3의 기관이 존재하면 된다.

 

CA, RA라는 제3자 인증기관을 두어 Public Key를 검증

 

Public Key를 검증하는 제 3의 기관으로서 CA, RA가 존재한다. RA는 CA 보다 밑의 기관이라고 생각하면 된다. 가장 먼저 서버 쪽에서 비대칭키 구매 등록을 RA에 요청하면 RA는 실질적인 비대칭키를 생성하는 역할을 하는 CA에게 전달한다. 그러면 이제 CA는 비대칭키를 RA를 통해서 서버에게 전달해준다. 이렇게 해서 서버는 비대칭키를 갖게 된다. 이 때, 서버의 비대칭 키 중 Public Key에 키 값 말고도 여러가지 부가 정보가 들어있는데, 그 중에 "hash 값"이 들어있다. 이 hash 값은 CA가 갖고 있는 Public/Private Key 중 Private Key로 암호화한 값이며, 이 값으로 추후에 클라이언트가 받은 Public Key가 진짜인지 아닌지 검증하는 역할을 한다. 그리고 이 때 Public Key와 부가적인 정보(hash 값 등..)들을 합쳐 이른바 '인증서' 라고 부른다.

 

어쨌건 이제 서버는 비대칭키가 생성되었으니 자신(서버)의 Public 키를 클라이언트에 제공한다. 클라이언트는 자신의 대칭키를 이 Public 키로 암호화해야 하는데 이를 수행하기 전에 이 Public 키가 진짜 신뢰할만한지 검증해야 한다. 검증하기 위해서 서버의 Public Key에 부가적인 정보인 hash 값을 살펴본다. 그리고 이 hash 값을 복호화하는데, 이 복호화할 때 활용하는 키는 바로 CA의 Public Key를 이용한다. 그렇다면 클라이언트는 CA의 Public Key를 어떻게 가질 수 있는가? 할텐데, 이는 클라이언트(ex. 윈도우, 맥, 리눅스)에서 보안 업데이트를 수행하면 해당 OS와 제휴(?)를 맺고 있는 CA 기관들의 Public Key가 클라이언트의 파일 시스템에 다운로드 되는 것이다. 

 

이렇게 클라이언트가 CA의 Public Key를 갖고 있게 되면 해당 키로 서버의 Public Key에 붙어있는 hash 값을 복호화함으로써 클라이언트는 "이 Public Key가 해커의 것이 아닌 정말 서버의 것이 맞구나!" 라고 검증하게 되는 것이다. 

 

그 이후에는 직전 목차에서 살펴본 것처럼 클라이언트의 대칭키를 암호화하고, 터널링 등 이후의 과정은 동일하다.

 

이렇게 제 3의 기관을 통해서 Public Key를 검증하는 과정이 있다면 인터넷에 돌아다니는 해커들은 중간에 공격을 하더라도 서버의 Public 키에 붙어있는 hash 값 때문에 공격을 할 수가 없다. 왜냐하면 해커들은 클라이언트와 달리 CA의 Public Key를 갖고 있지 않기 때문이다.

 

MITM 공격이 불가능하다!

 

이렇게 서버의 비대칭 키를 RA, CA와 같은 인증기관에 구매를 위탁하고 생성한 뒤 얻은 Public Key와 hash 값과 같은 정보들을 통틀어서 '인증서'라고 부른다고 했다. 이 때, '서버'가 웹서버이고 웹 통신을 수행하면서 해당 인증서를 사용하게 되면 이 인증서를 바로 'SSL 인증서'라고 부르는 것이다. 그리고 이 SSL 인증서를 사용하는 HTTP 통신 프로토콜이 바로 HTTPS인 것이다.

 

참고로 TLS라는 것도 있는데, TLS는 SSL의 발전함에 따라 단점을 보완하면서 나온 것에 불과하다. 간단히 말해서 SSL의 더욱 안전한 버전이라고 보면 된다.