네트워크를 통해서 전달되는 정보는 해커 등을 통해 중간에 도청, 변조, 위조가 가능하다.
따라서 이러한 데이터의 송 수신처에서 안전을 보장받을 수 있도록 암호화와 서명의 개념을 사용한다.
암호화란
데이터의 기밀성을 보장하기 위한 기술이다.
데이터의 기밀성이란 내용을 숨기고 이 내용을 볼 수 있도록 허가 받은 사람만이 확인할 수 있도록 제어하는 것이다.
이 허가를 제어하기 위해 데이터의 원문을 열어볼 수 있는 키(Key)라는 개념을 사용한다.
암호화에는 크게 대칭키 암호화, 비대칭키 암호화 두 가지 방식이 있다.
대칭키 암호화는
같은 키로 암호화 및 복호화 가능하며 연산 속도가 빠르다.
그러나 암호화하는 쪽과 복호화하는 쪽이 같은 키 값을 공유하고 있어야 하는데, 이 값을 네트워크 등을 통해 주고받으면 키가 노출되기에 키 관리가 비교적 어렵다.
대칭키 암호화의 암복호화 방식은 다음과 같다.
[보내는 쪽]
원문
↓
비밀키로 암호화
↓
암호문
↓
전송
[받는 쪽]
암호문
↓
같은 비밀키로 복호화
↓
원문
아래와 같이 빠르게, 자주, 대용량의 데이터를 암복호화 해야하는 상황에서 자주 쓰인다.
- 파일 암호화
- DB 컬럼 암호화
- HTTPS에서 실제 데이터 암호화
- 세션 기반 통신
대표적인 대칭키 알고리즘으로는 AES 를 주로 사용하며, ChaCha20, 구형으로는 DES, 3DES 를 사용하기도 한다.
비대칭키 암호화는
비대칭키 암호화는 서로 다른 두 개의 키를 사용한다.
- 공개키 (Public Key)
- 개인키 (Private Key)
암호화 하는 공에서는 공개키를 이용하여 암호화하고, 받는 쪽에서는 개인키로 복호화하는 방식이다.
대칭키 암호화 방식의 키 공유 문제는 해결할 수 있지만 속도가 느린 단점이 있다.
비대칭키 암호화의 암복호화 방식은 다음과 같다.
[서버]
공개키 공개
개인키 비공개
[클라이언트]
원문
↓
서버의 공개키로 암호화
↓
암호문 전송
[서버]
암호문
↓
개인키로 복호화
↓
원문
위와 같이 서버의 공개키는 노출되어도 상관 없기 때문에 모두가 사용할 수 있으므로,
양쪽이 같은 키를 가지고 있거나 보내는 쪽이 키를 보관해야할 필요가 없다.
따라서 키 공유가 어려운 인터넷 환경 등에 적합하며, 빠른 연산을 필요로 하는 대용량 데이터 암복호화에는 부적합하기에 아래와 같은 곳에서 사용된다.
- HTTPS 초기 핸드셰이크
- 암호화 키 교환
- 인증서 기반 통신
- 토큰, 비밀값 전달
비대칭키 알고리즘으로는 RSA, ECC (ECDH, ECDSA), ElGamal 등이 있다.
대칭키와 비대칭키의 조합
대칭키와 비대칭키는 두 개를 조합하여 상호 보완적으로 사용할 수 있는데,
대칭키의 키 전달 문제와 비대칭키의 느린 연산을 보완하게 위해서 비대칭키로 대칭키를 전달하는 방식을 사용할 수 있다.
아래는 실제 HTTPS 에서 사용하는 암호화 방식이다.
1. 서버 공개키 획득
2. 클라이언트가 랜덤 대칭키 생성
3. 서버 공개키로 대칭키 암호화
4. 서버가 개인키로 복호화
5. 이후 통신은 대칭키로 진행
서명이란
데이터의 무결성과 작성자 신원을 보장하기 위한 기술이다.
즉 이 데이터가 중간에 바뀌지 않았고, 특정 주체가 생성했다는 것을 증명하는 과정이다.
서명의 방식은 아래와 같다.
[보내는 쪽]
원문
↓
해시(SHA-256)
↓
개인키로 서명
↓
서명값 + 원문 전송
[받는 쪽]
원문 → 해시
서명값 → 공개키로 검증
↓
해시 일치 여부 확인
주의해야 할 것은 서명은 데이터를 숨기기 위한 수단이 아니므로 내용은 그대로 노출되며, 변조 여부만 확인하는 기술이라는 점이다.
원문을 바로 개인키로 서명하지 않는 이유는 개인키로 전체 메시지를 암호화하게 되면 느리기 때문에 짧은 길이로 변환할 수 있는 해시를 거친 뒤 개인키로 서명하게 된다.
HTTPS, JWT, DKIM, OAuth 등에서 위변조 방지를 위해 이러한 서명 검증 방식을 사용한다.
(펼치기) 암호화는 공개키로, 서명은 개인키로 암호화하는 이유가 궁금하다면
암호화와 서명의 목적이 다르기 때문이다.
암호화는 "내가 암호화 한 것을 특정인이 아니면 해석하지 못하게 하는 것"에 초점이 있다.
따라서 노출되어 있는 공캐키로 암호화를 하고, 그것을 받는 쪽에서 자신만이 알고 있는 개인키를 복호화를 한다.
그러나 서명은 "내가 만들었음을 증명"하는 것에 목적이 있다.
따라서 보낸 곳에서 자신만이 알고 있는 개인키로 서명을 하고, 해당 데이터가 필요한 서버/클라이언트/제3자 어디에서든 공개키로 서명을 검증하여 사용할 수 있어야 한다.
만약 공개키로 서명을 하게 된다면 아무나 악의적으로 보내는 곳을 위조할 수 있게 된다.
'클라우드' 카테고리의 다른 글
| SMTP 프로토콜과 Relay 설정 (0) | 2026.05.19 |
|---|---|
| AD 계정 사용자의 프로필(Profile) 개념 (0) | 2026.05.04 |
| [쿠버네티스] 쿠버네티스에서 yaml config 파일 작성하는 방법과 pod 만들어보기 (1) | 2023.11.23 |
| [쿠버네티스] 쿠버네티스의 기본 구성요소 (1) | 2023.11.20 |
| 클라우드란? 클라우드 개념 쉽고 간단하게 이해하기 (0) | 2023.11.10 |