보안의 시작을 알리는 개념인 `대칭키`와 `비대칭키`
처음 이 개념들을 마주할 때는 그저 외우기에 급했지만, 동작 플로우를 이해하면 쉽게 이해할 수 있는 개념이라고 생각된다.
이번 글의 목표는 다음과 같다.
- 대칭키와 비대칭키의 개념과 장단점을 정리한다.
- 비대칭키를 활용한 암호화와 인증 과정을 흐름도를 통해 이해한다.
- 대칭키를 안전하게 공유하는 방법을 알아보고, 공개키 위조 문제의 해결 방안을 간략히 살펴본다.
1. 대칭키
: 암호화, 복호화에 사용하는 키가 동일한 암호화 방식이다.
- 장점
- 알고리즘이 단순해 암호화/복호화 속도가 빠르다.
- 단점
- 키 공유 문제
- 송수신자 간의 동일한 키를 안전하게 공유하기 어렵다.
- 확장성 문제
- 사용자 수가 많아지면, 각 쌍마다 고유한 키가 필요해 키 관리가 복잡해진다.
- N명이 서로 통신하려면 nC2 = n(n-1)/2 개의 키가 필요하다.
- 인증 문제
- 암호화는 가능하지만 서명이나 인증이 어렵다.
- 누가 암호화 된 데이터를 보냈는지 송신자 확인이 불가능하다.
- 키 공유 문제
- 대표적인 알고리즘
- AES, DES, SEED 등
Q. 대칭키를 어떻게 안전하게 공유할까?
A. 비대칭키를 활용한 대칭키 공유
대칭키가 어떻게 공유되는지 도식화하며 구체적인 흐름을 나타내었지만, 핵심적인 과정은 다음과 같아진다.
- 서버는 공개키(Public Key)를 클라이언트에 전송한다.
- 클라이언트는 자신이 생성한 대칭키를 서버의 공개키로 암호화해서 전송한다.
- 서버는 자신의 개인키(Private Key)로 복호화하여 대칭키를 획득한다.
- 이후부터는 대칭키를 사용하여 통신한다.
즉, 비대칭키는 대칭키 교환에만 사용되고, 데이터 전송은 대칭키로 한다.
이러한 방식은 대칭키의 키 공유 문제를 보완하고, 비대칭키의 암/복호화 속도가 낮은 단점을 보완하여 빠르고 암호화 된 통신이 가능하게 한다.
2. 비대칭키
: 암호화, 복호화에 사용하는 키가 서로 다른 암호화 방식이다.
누구나 볼 수 있는 공개키(Public Key)와 오직 본인만 갖고 있는 개인키(Private Key)를 사용한다.
- 장점
- 키 공유 문제 해결
- 공개키는 누구나 가져도 되기 때문에, 인터넷을 통한 전송이 가능하다.
- 확장성 문제 해결
- 사용자 수가 많아져도, 각자 자기 키 쌍만 관리하면 된다.
- N명이 서로 통신을 하는 경우에도, N개의 공개키와 개인키만 있으면 된다.
- 인증 문제 해결
- 개인키로 암호화하고 공개키로 복호화하면, 송신자의 신원을 증명할 수 있다.
- 키 공유 문제 해결
- 단점
- 알고리즘이 복잡해 암호화/복호화 속도가 느리다.
- 대표적인 알고리즘
- Diffie Hellman, RSA, DSA, ECC 등
Q. 비대칭키는 암호화와 인증에 어떻게 사용될까?
A-1. 암호화 관점
사용자의 데이터를 서버에게 전송할 때, 서버의 공개키를 다운받아 암호화하는 방식이다.
이는 서버의 개인키를 사용해서만 복호화를 할 수 있기 때문에, 데이터의 안전한 전송이 가능하다.
상세 동작은 다음과 같다.
- 송신자는 수신자의 공개키를 얻는다.
- 메시지를 수신자의 공개키로 암호화한다.
- 암호화 된 메시지를 수신자에게 전송한다.
- 수신자는 자신의 개인키로 복호화한다.
- 원본 메시지를 확인한다.
A-2. 인증 관점
사용자의 데이터를 서버에게 전송할 때, 사용자의 개인키로 암호화하는 방식이다.
사용자의 공개키는 공개되어 있으므로, 인증은 누구나 검증이 가능하다.
상세 동작은 다음과 같다.
- 송신자는 메시지에서 해시값을 생성한다.
- 해시값을 자신의 개인키로 서명한다. → 전자서명
- 메시지와 서명을 수신자에게 전송한다.
- 수신자는 송신자의 공개키로 서명을 복호화한다. → 해시값 1
- 수신자가 받은 메시지로 직접 해시를 계산한다. → 해시값 2
- 두 해시값을 비교하여, 메시지가 위조되지는 않았는지(무결성) 송신자가 진짜인지 확인한다.
A-3 암호화와 인증을 모두 적용한 관점
송신자의 공개키는 공개되어 있어, 서명은 누구나 검증이 가능하다.
즉, 서명은 메시지의 무결성과 송신자의 신원은 보장하지만, 메시지 자체에 암호화가 적용되지 않아 기밀성이 보장되지 않는다.
만약 메시지의 기밀성이 필요한 경우, 디지털 서명 외에 수신자의 공개키로 메시지를 암호화하면 된다. (암호화 방식과 동일)
- 송신자가 메시지에 대해 서명 생성
- [메시지 + 서명]을 수신자의 공개키로 암호화
- 수신자만 복호화 가능 → 원본 메시지 + 서명 확인 가능
- 수신자는 송신자의 공개키로 서명을 검증
Q. 공개키가 위조될 수도 있지 않나요?
맞다! 암호화 관점, 인증 관점에서 모두 놓쳤던 부분이 있다.
비대칭키 방식에서는 공개키로 암호화를 하든, 복호화를 하든 상대방에게 공개키를 받아오는 과정이 반드시 필요하다.
그러면 어떻게 암호화 과정에서 수신자의 공개키를, 인증 과정에서 송신자의 공개키를 안전하게 얻을 수 있을까??
만약 해커가 위조된 공개키를 전달하는 경우, 수신자는 그 공개키로 암호화하거나 서명을 검증하게 된다.
이 경우 공격자는 데이터를 가로채거나 인증 위조가 가능해진다.
이를 방지하기 위해서 공개키가 위조되지 않는 안전한 키라는 것을 보장할 수 있어야 하는데, 이 때 등장하게 된 개념이 CA(Certificate Authority)이다. CA는 신뢰할 수 있는 제 3의 기관으로, 공개키와 소유자 정보를 확인한 뒤에 CA 자신의 개인키로 서명을 하여 디지털 인증서를 발급하는 역할을 한다. 이 공개키가 누구의 것인지를 CA가 보증을 하는 것이다.
네트워크 상에서 디지털 인증서를 활용한 통신 흐름은 다음과 같아진다.
- A 서버는 자신의 공개키와 도메인 정보를 담은 CSR(Certificate Signing Request)을 생성하고, CA에 전달한다.
- CA는 실제로 A 서버가 도메인을 소유하고 있는지 등을 검증한 뒤, CA 자신의 개인키로 A 서버의 디지털 인증서를 발급한다.
- A 서버는 이 디지털 인증서를 TLS HandShake 과정에서 클라이언트에게 전송한다.
- B 클라이언트 운영체제나 브라우저에 내장된 루트 CA의 공개키로 인증서를 검증해서, A의 공개키가 위조되었는지 검증한다.
cf. 대부분의 운영체제와 브라우저는 주요 루트 인증기관의 공개키(루트 인증서)를 기본적으로 내장하고 있어, 인증서의 진위를 검증할 수 있다.
참고 문서
- 암호화 프로토콜의 전체적인 흐름과 CA 등장 배경
https://wooono.tistory.com/106
- 디지털 인증서 원리, 기밀성 및 무결성 보장을 위한 노력
'CS' 카테고리의 다른 글
| HMAC•RSA 알고리즘을 사용한 JWT Signature (0) | 2025.04.06 |
|---|