[CS] 대칭키 & 비대칭키 / HTTPS 통신 방법

대칭키와 비대칭키는 데이터 보안 및 통신에서 중요한 역할을 하며, 정보를 안전하게 보호하고 전달하기 위해 사용되는 암호화 기법이다.
자세한 내용들보다는 내가 기억하기 쉽게 이해한 과정을 서술해보려 한다. 앞으로 나올 "자물쇠를 잠구는 행위"는 암호화, "자물쇠를 여는 행위"는 복호화를 뜻한다.

대칭키

암호화하는 키와, 복호화하는 키가 같다고 하여 대칭키라고 불린다. 대칭키 기법을 이해하기 쉽게 한줄로 표현해 보면 아래와 같다.

열쇠1로 자물쇠를 잠그고, 받을 사람에게 열쇠1과 자물쇠를 보내준다.

출처 : https://velog.io/@minj9_6/%EB%8C%80%EC%B9%AD%ED%82%A4%EC%99%80-%EB%B9%84%EB%8C%80%EC%B9%AD%ED%82%A4%EB%8A%94-%EB%AC%B4%EC%8A%A8-%EC%B0%A8%EC%9D%B4%EA%B0%80-%EC%9E%88%EC%9D%84%EA%B9%8C

대칭키 방식은 간단한 연산을 사용해 암호화를 진행한다. XOR 연산, 치환, 전치 등 단순한 연산으로 암호화를 진행해 빠른 연산이 가능하다. 하지만 암호화, 복호화 시 같은 키를 사용하기 때문에 안전하게 키를 전달하는 부분에서 신경을 많이 써야 한다. 암호화한 데이터를 여러 사람에게 공유해야 할 경우 키가 많이 생성되고 이것을 관리하는데 어려움이 있을 수 있다.

대칭키는 대용량의 데이터를 암호화해야하는 경우 사용되고 예시로 파일 암호화, VPN, 디스크 암호화등에 사용된다.

대칭키의 장점

1. 빠른 속도 : 대칭키 암호화 연산은 단순하게 진행하기 때문에 속도가 빠르다.
2. 낮은 자원 소모 : 간단한 연산으로 암/복호화가 가능하기 때문에 자원이 제한 적인 환경(모바일, 임베디드)에 적합하다.
3. 대용량 데이터 암호화 : 데이터의 크기가 커질수록 1에 나온 장점인 빠른 속도로 인해 효율적이다. (동영상, 대규모 데이터베이스 암호화)

대칭키의 단점

1. 키 관리 : 암호화, 복호화에 같은 키를 사용하기 때문에 키를 공유하는 과정에서 노출될 위험을 특별히 신경 써야 한다. 키가 노출될 경우 전체 과정이 위험해질 수 있다.
2. 공유 증가 시 키 관리 어려움 : 여러 명에게 암호화된 데이터를 전송해야할 경우 공유하는 키의 수가 늘어나기 때문에 관리에 어려움이 있다.

비대칭키

대칭키와 반대로 암호화하는 키와 복호화하는 키가 다른 방식이 비대칭키 방식이다. 이 방식에는 두 가지의 키를 각각 공개키, 개인키라고 부른다. 

공개키: 공개키는 누구나 접근할 수 있다. teho 공개키라 명시하고 세상에 공개한다.
비밀키: 비밀키는 공개키와 짝을 이루며 개인이 꼭 갖고 보안을 유지해야한다.

사실 위의 설명을 보면 암/복호화에 대한 내용을 작성하지 않고 애매모호하게 작성해 두었다.

이유는 비대칭키 방식은 공개키가 세상에 공개되어 있다는 점을 이용하여 상황에 맞게 사용할 수 있다. 아래와 같이 두 가지의 경우의 수가 발생하기 때문이다.

출처 : https://www.2e.co.kr/news/articleView.html?idxno=301700

공개키 암호화 & 개인키 복호화

모든 사람이 "teho 공개키"에 접근할 수 있다. "teho 공개키"로 암호화를 해서 전송하면 "teho 비밀키"로만 복호화할 수 있다.

이 뜻은 보안이 유지되어야 하는 내용을 전송하고 이것을 볼 수 있는 사람을 특정한다는 것이다. 그렇기 때문에 기밀성이 중요한 경우 사용된다. 암호화된 메시지 전송(WhatsApp같은 비밀 메신저), 암호화폐 거래 정보 기록 등에 사용된다. 

WhatsApp의 예시에 대한 설명을 A가 B에게 메세지를 보내는 경우를 예시로 설명해보면 아래와 같다.

1. A는 메세지를 받을 B의 공개키를 통해 메세지를 암호화해서 전송한다.
2. B는 A가 보낸 암호화된 메세지를 자신(B)의 개인키로 복호화하여 메세지를 확인한다.
3. C가 B가 보내는 메세지를 중간에 탈취하더라도 C의 개인키로는 복호화할 수 없어 내용을 확인할 수 없다.

개인키 암호화 & 공개키 복호화

이 방식은 개인키로 암호화여 전송하며, 전송자의 공개키를 사용하여 누구나 복호화할 수 있다.

이 방식은 누구나 암호화된 데이터를 복호화할 수 있기 때문에 보안보다는 무결성과 신원 인증을 할 수 있다는 것이 중요하다. 본인이 갖고 있는 개인키로 암호화를 하기 때문에 B라는 사기 꾼이 A인척 사칭을 해서 문서를 보내도 A의 공개키로 복호화가 안되기 때문에 신원인증이 되지 않는다. 이런 특성을 이용해 본인임을 인증하는 디지털 서명, 블록체인 거래 서명, 전자 여권 등에 사용된다.

비대칭키의 장점

1. 높은 보안성 : 중요한 개인키를 공유하거나 전송할 필요가 없으므로 키 관리가 용이하다.
2. 확장성 : 키를 공유할 필요가 없기 때문에 여러 사용자 간의 통신이 필요한 대규모 환경에서도 키 관리가 효율적이다.

비대칭키의 단점

1. 느린 속도 : 비대칭키를 사용한 암호화 시 복잡한 수학 연산이 진행되어 대칭키보다 속도가 느리다.
2. 복잡한 연산 : 많은 계산을 필요로 하여 하드웨어 자원이 많이 제한적인 경우 불리하다.

하이브리드 방법-> HTTPS 통신 방법(대칭키, 비대칭키 혼합 방식)

HTTPS 통신 방식(SSL/TLS 방식 -> 보안 프로토콜)에는 대칭키, 비대칭키 방식을 혼합한 하이브리드 방식을 사용한다. 대칭키는 속도는 빠르지만 키를 공유하는 과정에서 위험성이 있고, 비대칭키는 보안은 좋지만 속도는 느리기 때문에 둘을 혼합해서 보안 성능도 좋고 속도도 빠른 방법을 만든 것이다.

이 과정을 설명하기 전에 CA와 SSL 인증서를 알고 있어야 한다.

• CA : Certificate Authority라는 뜻으로 서버에게 "너는 우리가 인증한 안전한 곳이야"라는 뜻을 담은 SSL 인증서를 발급해 주는 곳이다. 배포를 해본 경험이 있다면 HTTPS를 적용하기 위해 Let's Encrypt, ACM(AWS Certificate Manager)를 들어 봤을 것이다.
• SSL 인증서 : CA가 발급하는 인증서다. 신뢰할 수 있는 서버라는 것을 증명해 준다. 서비스 정보(인증서 발급한 CA, 서비스 도메인 등), 서버의 공개키 같은 내용이 담겨 있다.

배경 지식을 이해했다면 본격적으로 HTTPS 통신에 하이브리드 방식이 적용되는 과정을 설명해 보겠다.

1. 클라이언트가 서버에 접속하면서 TLS 버전 등과 같은 기본 정보를 서버한테 전송 (Client Hello 과정)

2. 서버는 클라이언트에게 서버의 공개키가 포함된 SSL인증서 전송 (Server Hello 과정)

3. 클라이언트는 신뢰 가능한 기관인 CA를 통해 발급된 인증서가 맞는지 검증

4. 신뢰할 수 있다면 클라이언트는 SSL 인증서에 있던 서버의 공개키로 클라이언트의 대칭키를 암호화하여 전송 -> 비대칭키 암호화
(이때 클라이언트의 대칭키는 세션키라고 한다. 특정 세션에서만 유효한 대칭키여서 세션키라고 부른다. 세션이 끝나면 폐기)

5. 서버는 서버의 개인키로 클라이언트가 보낸 대칭키를 복호화한다. -> 개인키 복호화

6. 서버가 복호화한 대칭키는 클라이언트에서도 갖고 있기 때문에 앞으로의 통신에서는 해당 대칭키로 암/복호화를 진행하며 통신한다. -> 대칭키 방식

한번 더 간단히 정리하자면 서버-클라이언트 통신 시 사용할 클라이언트의 대칭키를 서버에 전송할 때 서버의 공개키로 암호화, 서버의 개인키로 복호화하여 안전하게 대칭키를 전달하고 이후의 통신에서는 클라이언트의 대칭키를 사용해 빠른 속도를 유지한다.

HTTPS 방식 간단 설명

번외: SSL 인증서는 믿을 수 있는가?

공부를 하면서 SSL인증서가 너무 허술한 것이 아닌가? 하는 생각이 있었는데 이 역시 비대칭키 방식을 사용한다. 

지금 상황은 CA가 발급한 인증서라는 것을 믿을 수 있는가?이다. 이는 위에서 공부했던 개인키 암호화 & 공개키 복호화를 사용해서 CA에서 발급한 인증서라는 것을 보장받을 수 있다.