제3자가 주고받는 메시지를 훔쳐보거나 메시지를 가로체 변조할 수 있기 때문에 암호화가 필요하다.
암호화(encryption)는 원문 데이터를 알아볼 수 없는 형태로 변경하는 것을 의미한다.
반대로 복호화(decryption)란 암호화된 데이터를 원문 데이터로 되돌리는 과정을 말한다.
암호화와 복호화는 비단 안전한 데이터 송수신뿐만 아니라 인증서 기반의 검증도 가능하게 한다.
암호와 인증서
먼저 암호화와 복호와의 원리를 이해해보자. 암호화와 복호화의 핵심은 키이다.
대칭 키 암호화 방식과 공개 키 암호화 방식
컴퓨터 보안에서 사용되는 키는 언뜻 보면 무작위해 보이는 문자열처럼 생겼다. 키와 원문 데이터에 수학적 연산 과정을 거치면 암호문이 생성된다. 이 수학적 연산 과정을 '암호화 알고리즘'이라 부른다. 그리고 암호문을 수신자 측에서 복호화하면 원문 메시지를 얻을 수 있다.
주고받는 데이터를 암호화하고 복호화하는 방법에는 대칭 키 암호화와 비대칭 키 암호화라는 두 가지 방식이 있다. 비대칭 키 암호화는 공개 키 암호화라고도 부른다.
대칭 키 암호화(symmetric key cryptography)
대칭 키 암호화 방식에서는 암호화와 복호화에 동일한 키를 사용한다. 다시 말해 메시지를 암호화할 때 사용하는 키와 복호화할 때 사용하는 키가 동일하다.
하지만 대칭 키 암호화 방식에는 한 가지 문제가 있다. 바로 상대방에게 안전하게 키를 전달하기가 어렵다는 점이다. 대칭 키 암호화 방식은 복호화에 동일한 키를 사용하므로 키가 유출되면 큰 문제가 발생한다. 그렇기에 상대방에게 키를 안전하게 전달하는 방법이 필요하다.
그런데 생각해 보면 애초에 암호화를 사용하는 목적 자체가 '제3자의 도청과 변조를 피해 상대방에게 안전하게 정보를 전달하는 것'이다. 만약 상대방에게 키를 안전하게 전달할 수 있는 방법이 있다면 그 방법으로 메시지를 주고받으면 됐지, 굳이 암호화를 할 필요가 없을 것이다.
공개 키 암호화(public key cryptography)
그래서 등장한 것이 공개 키 암호화 방식이다. 비대칭 키 암호화라고도 부른다. 암호화와 복호화에 단일한 키를 사용했던 대칭 키 암호와는 달리, 공개 키 암호 방식에서는 암호화를 위한 키와 복호화를 위한 키가 다르다. 한 키로 암호화했다면 다른 키로 복호화할 수 있다. 이 한 쌍의 키를 각각 공개 키와 개인 키라 부른다.
참고로, 한 키로 암호화하고 다른 키로 복호화가 가능하다해도 한 키로는 다른 키를 유추할 수 없다. 다시 말해 공개 키만으로는 개인 키를 유추할 수 없고, 반대로 개인 키만으로 공개 키를 유추할 수도 없다.
공개 키로 암호화하고 개인 키로 복호화할 수 있다면, 공개 키는 이름처럼 누구에게나 공개해도 무방한 것이다. 암호화만을 위해 사용되었기 때문에, 공개 키를 안다고 해서 원문 메시지를 유추할 수 있는 것이 아니기 때문이다.
예를 들어 A가 B에게 특정 문자열을 안전하게 전송하고자 한다면, 일단 A가 B의 공개 키를 요청하고 B는 A에게 공개 키를 전달한다. A는 전달받은 B의 공개 키로 메시지를 암호화한 뒤 그 암호문을 B에게 전송한다. B는 개인 키가 있으므로 암호를 복호화해서 특정 문자열을 확인할 수 있다.
반대로 B가 A에게 메시지를 안전하게 보내고 싶을 때도 동일한 과정을 거친다.
각각의 장단점
대칭 키 암호화 방식과 공개 키 암호화 방식은 각각 장단점이 있다. 대칭 키 암호화는 키를 안전하게 전송하기 어렵지만, 적은 부하 덕분에 암호화 및 복호화를 빠르게 수행할 수 있다.
반면 공개 키 암호화는 암호화 및 복호화에 시간과 부하가 상대적으로 많이 들지만, 키를 안전하게 공유할 수 있다.
이러한 장단점을 고려해 대칭 키 암호화 방식과 공개 키 암호화 방식을 함께 사용하는 경우가 많다. 예를 들어 대칭 키를 상대에게 안전하게 전달하기 위해 공개 키로 대칭 키를 암호화하고, 개인 키로 암호화된 대칭 키를 복호화할 수 있다. 이렇게 하면 대칭 키를 안전하게 공유함과 동시에 공유한 대칭 키를 이용해 빠르게 암호화/복호화를 수행할 수 있다.
참고로 이러한 방식으로 활용되는 대칭 키를 세션 키라고 부른다.
인증서와 디지털 서명
인증서는 말 그대로 무엇인가를 증명하기 위한 문서를 의미한다.
네트워크에서 사용되는 '인증서'라는 용어는 일반적으로 공개 키 인증서를 일컫는다. 공개 키 인증서란 공개 키와 공개 키의 유효성을 입증하기 위한 전자 문서이다.
예를 들어 우리의 컴퓨터와 웹 서버가 공개 키 암호화 방식으로 통신한다고 가정해 보자. 우리의 컴퓨터는 웹 서버로부터 공개 키를 전달받게 된다. 이때 우리가 전달받은 공개 키가 정말 신뢰할 수 있는 것인지, 전송 도중에 조작되지는 않았는지 확신할 수 없다. 그래서 서버는 공개 키뿐만 아니라 누가 생성했는지, 조작되지는 않았는지, 유효 기간은 언제까지인지 등의 내용을 포함한 인증서를 전송한다.
이러한 인증서는 인증 기관이라는 제3의 기관에서 발급한다. 인증 기관은 인증서의 발급, 검증, 저장과 같은 역할을 수행할 수 있는 공인 기관이다. 일반적으로는 CA라고 중려서 부른다.
CA가 발급한 인증서에는 '인증서가 진짜이며, 이를 보증한다'라는 내용을 담은 서명값이 있다. 클라이언트는 이 서명 값을 바탕으로 인증서를 검증할 수 있다.
서명 값은
1) 인증서 내용에 대한 해시 값(fingerprint)을
2) CA의 개인 키로 암호화하는 방식으로 만들어진다.
CA는 이렇게 얻어낸 정보를 서명 값으로 삼아 클라이언트에게 인증서와 함께 전송한다.
웹 브라우저를 통해 서버로부터 서명 값이 붙은 인증서를 전달받았다고 가정해 보자. 인증서 검증을 위해 가장 먼저 할 일은 서명 값과 인증서를 분리하는 것이다. CA의 공개 키는 공개되어 있기에, 서명 값은 CA의 공개 키로 복호화할 수 있다. 서명 값을 CA의 공개 키로 복호화하면 '인증서 내용에 대한 해시 값'을 얻을 수 있다. 다음으로 인증서 데이터에 대한 해시 값을 직접 구한 뒤, 이를 복호화한 값과 비교한다.
만일 값이 일치한다면 전달받은 인증서는 확실히 CA의 개인 키로 만들어졌다고 보장할 수 있다.
개인 키로 암호화된 메시지를 통해 공개 키로 복호화함으로써 신원을 증명하는 이러한 절차를 디지털 서명이라 부른다.
HTTPS: SSL과 TLS
지금까지 대칭 키 암호화와 공개 키 암호화 방식, 그리고 공개 키 인증서를 학습했다. 이를 기반으로 동작하는 프로토콜로 SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)가 있다. SSL과 TLS는 인증과 암호화를 수행하는 프로토콜이며, TLS는 SSL을 계승한 프로토콜이다. 초기 SSL 2.0과 SSL 3.0을 거처 TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3이 순차적으로 출시되었다.
따라서 SSL과 TLS의 작동 과정은 사용되는 암호 알고리즘과 버전에 따라 세부적인 차이가 있을 수 있으나 큰 틀에서 보면 유사하다.
SSL/TLS를 사용하는 대표적인 프로토콜은 HTTPS이다. HTTPSsms HTTP 메시지의 안전한 송수신을 위해 개발된 프로토콜이다.
오늘날 주로 사용되는 TLS 1.3을 기반으로 HTTPS가 어떻게 동작하는지 간략하게 알아보자.
HTTPS 메시지는 크게 다음과 같은 단계를 거쳐 송수신된다.
1) TCP 쓰리 웨이 핸드셰이크
2) TLS 핸드셰이크
3) 암호화된 메시지 송수신
TLS 핸드셰이크의 핵심은 두 가지이다. 하나는 암호화 통신을 위한 키를 교환한다는 점이고, 또 하나는 인증서 송수신과 검증이 이루어진다는 점이다.
가장 먼저 클라이언트는 ClientHello 메시지를 보낸다. 이 메시지는 암호화된 통신을 위해 서로 맞춰봐야 할 정보들을 제시하는 메시지이다. 지원하는 TLS 버전, 사용 가능한 암호화 방식과 해시 함수, 키를 만들기 위해 사용할 클라이언트의 난수 등이 포함되어 있다. 이때, '사용 가능한 암호화 방식과 해시 함수'를 담은 정보를 암호 스위트(cipher suite)라고 한다.
서버는 ClientHello 메시지에 대한 응답으로 ServerHello 메시지를 전송한다.ClientHello 메시지가 암호화 이전에 맞춰 봐야 할 정보들을 제시하는 메시지라면, ServerHello 메시지는 제시된 정보들을 선택하는 메시지이다. 따라서 이 메시지에는 선택된 TLS 버전, 암호 스위트 등의 정보, 키를 만들기 위해 사용할 서버의 난수 등이 포함되어 있다. ClientHello 메시지와 ServerHello 메시지를 주고받으면 암호화된 통신을 위해 사전 협의해야 할 정보들이 결정된다. 이렇게 결정된 정보를 토대로 서버와 클라이언트는 암호화에 사용할 키를 만들어낼 수 있다.
이것이 TLS 핸드셰이크에서의 키 교환이다. 이 단계 이후부터 클라이언트와 서버는 키로 암호화된 암호문을 주고받을 수 있게 된다.
또 서버는 Certificate 메시지와 CertificateVerify 메시지를 전송한다. 이는 각각 인증서와 검증을 위한 디지털 서명을 의미한다. 클라이언트는 이 메시지를 토대로 서버의 공개 키를 검증하게 된다. 이어서 서버와 클라이언트는 TLS 핸드셰이크의 마지막을 의미하는 Finished 메시지를 주고 받는다.
이제 TLS 핸드셰이크를 통해 얻어낸 키를 기반으로 암호화된 데이터를 주고받으면 된다. 참고로 TLS 1.3에서는 Finished 메시지와 함께 암호화된 메시지를 전송할 수 있다.
