대칭키와 비대칭키 암호화 및 HTTPS 인증 방식 완벽 가이드

암호화 기술의 핵심인 대칭키와 비대칭키 암호화 방식의 원리와 특징, 그리고 이를 활용한 HTTPS 인증 과정에 대한 종합적인 설명이다.

대칭키 암호화 방식

대칭키 암호화는 암호화와 복호화에 동일한 키를 사용하는 방식이다. 이 방식은 단순하면서도 효율적인 암호화 방법으로 오랫동안 사용되어 왔다.

대칭키의 특징

• 동일한 키 사용: 암호화와 복호화에 같은 비밀키를 사용한다
• 처리 속도: 비대칭키 방식에 비해 암호화 및 복호화 속도가 매우 빠르다
• 키 길이: 일반적으로 128비트, 192비트, 256비트 등의 길이를 사용한다
• 알고리즘: AES, DES, 3DES, Blowfish 등이 대표적이다

대칭키 암호화 과정:
1. 송신자: 평문 + 비밀키 → 암호화 → 암호문
2. 수신자: 암호문 + 비밀키 → 복호화 → 평문

대칭키 암호화의 가장 큰 문제점은 안전한 키 교환이다. 통신하는 양측이 동일한 키를 가져야 하므로, 키를 안전하게 전달하는 과정에서 키가 노출될 위험이 있다.

대칭키의 장단점

장점:

• 암호화 및 복호화 속도가 빠르다
• 구현이 상대적으로 간단하다
• 대용량 데이터 암호화에 효율적이다

단점:

• 키 배포 문제가 존재한다
• 통신 상대가 많아질수록 관리해야 할 키의 수가 기하급수적으로 증가한다
• 키가 노출되면 모든 암호화된 데이터가 위험해진다

비대칭키 암호화 방식

비대칭키 암호화는 공개키와 개인키라는 두 개의 서로 다른 키를 사용하는 방식이다. 이 방식은 대칭키의 키 배포 문제를 해결하기 위해 개발되었다.

비대칭키의 특징

• 키 쌍 사용: 공개키(Public Key)와 개인키(Private Key)라는 두 개의 키를 사용한다
• 암호화 방향: 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있고, 개인키로 암호화한 데이터는 공개키로만 복호화할 수 있다
• 처리 속도: 대칭키 방식에 비해 암호화 및 복호화 속도가 느리다
• 알고리즘: RSA, ECC, DSA, Diffie-Hellman 등이 대표적이다

비대칭키 암호화 과정(기밀성):
1. 송신자: 평문 + 수신자의 공개키 → 암호화 → 암호문
2. 수신자: 암호문 + 수신자의 개인키 → 복호화 → 평문

비대칭키 암호화 과정(인증):
1. 송신자: 평문 + 송신자의 개인키 → 암호화 → 암호문
2. 수신자: 암호문 + 송신자의 공개키 → 복호화 → 평문

비대칭키 암호화의 가장 큰 장점은 키 교환 문제를 해결했다는 점이다. 공개키는 누구에게나 공개해도 되므로 안전하지 않은 채널을 통해 전송할 수 있다.

RSA 암호화 방식

RSA는 가장 널리 사용되는 비대칭키 암호화 알고리즘으로, 소인수분해의 어려움에 기반을 둔다.

1. 키 생성 과정:
   • 두 개의 큰 소수 p, q를 선택한다
   • n = p × q를 계산한다
   • φ(n) = (p-1) × (q-1)를 계산한다
   • 1 < e < φ(n)이고 gcd(e, φ(n)) = 1인 e를 선택한다
   • d × e ≡ 1 (mod φ(n))을 만족하는 d를 계산한다
   • 공개키는 (n, e), 개인키는 (n, d)가 된다
2. 암호화 과정:
   • 암호문 C = M^e mod n (M은 평문)
3. 복호화 과정:
   • 평문 M = C^d mod n (C는 암호문)

💡 RSA의 안전성은 큰 수의 소인수분해가 어렵다는 수학적 사실에 기반한다.

비대칭키의 장단점

장점:

• 키 배포 문제를 해결한다
• 디지털 서명을 통한 인증이 가능하다
• 부인 방지(Non-repudiation) 기능을 제공한다

단점:

• 암호화 및 복호화 속도가 느리다
• 키 길이가 대칭키보다 길어야 동일한 보안 수준을 제공한다
• 구현이 복잡하다

HTTPS 인증 방식

HTTPS는 HTTP에 SSL/TLS를 추가하여 통신 내용을 암호화하는 프로토콜이다. HTTPS는 대칭키와 비대칭키 암호화를 모두 사용하여 보안성과 효율성을 동시에 확보한다.

HTTPS의 동작 원리

HTTPS는 초기 연결 설정 시 비대칭키 암호화를 사용하고, 이후 실제 데이터 통신에는 대칭키 암호화를 사용한다.

HTTPS 통신 과정:
1. 초기 연결 설정: SSL/TLS 핸드셰이크 (비대칭키 암호화 사용)
2. 세션키 교환: 비대칭키로 암호화된 대칭키(세션키) 교환
3. 데이터 통신: 세션키를 이용한 대칭키 암호화 통신

자세한 통신 과정:

1. 클라이언트(브라우저)가 서버로 최초 연결 시도를 함
2. 서버는 공개키(엄밀히는 인증서)를 브라우저에게 넘겨줌
3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급함 → 인증기관이 검사 후 세션키!
4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송함
5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음
6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행함

HTTPS는 비대칭키의 안전한 키 교환과 대칭키의 빠른 암호화/복호화 속도라는 두 방식의 장점을 결합한 하이브리드 방식이다.

SSL/TLS 핸드셰이크 과정

SSL/TLS 핸드셰이크는 클라이언트와 서버가 안전한 통신을 위한 매개변수를 협상하는 과정이다.

1. 클라이언트 헬로(Client Hello):
   • 클라이언트가 서버에 연결을 시도한다
   • 지원하는 암호화 알고리즘 목록, 랜덤 데이터, SSL/TLS 버전 정보 등을 전송한다
2. 서버 헬로(Server Hello):
   • 서버는 클라이언트에게 SSL 인증서(서버의 공개키 포함)를 전송한다
   • 서버가 생성한 랜덤 데이터도 함께 전송한다
3. 인증서 검증:
   • 클라이언트는 서버의 SSL 인증서가 신뢰할 수 있는지 확인한다
   • 인증기관(CA)의 공개키를 사용하여 인증서의 디지털 서명을 검증한다
4. 세션키 생성 및 교환:
   • 클라이언트는 클라이언트와 서버의 랜덤 데이터를 조합하여 세션키(대칭키)를 생성한다
   • 생성한 세션키를 서버의 공개키로 암호화하여 서버에 전송한다
5. 세션키 복호화:
   • 서버는 자신의 개인키로 암호화된 세션키를 복호화한다
   • 이제 클라이언트와 서버는 동일한 세션키를 공유하게 된다
6. 핸드셰이크 완료:
   • 클라이언트와 서버는 핸드셰이크가 완료되었음을 서로에게 알린다
   • 이후 모든 통신은 공유된 세션키를 사용한 대칭키 암호화로 이루어진다

⚡ HTTPS는 초기 연결 시 비대칭키 암호화를 사용하여 세션키를 안전하게 교환하고, 이후 통신에는 빠른 대칭키 암호화를 사용하여 효율성을 확보한다.

인증기관(CA)의 역할

인증기관은 디지털 인증서를 발급하고 관리하는 신뢰할 수 있는 제3자이다.

1. 인증서 발급 과정:
   • 서버는 공개키와 서버 정보를 CA에 제출한다
   • CA는 서버의 신원을 확인한 후, 서버 정보와 공개키를 포함한 인증서를 생성한다
   • CA는 자신의 개인키로 인증서에 서명한다
   • 서명된 인증서를 서버에 발급한다
2. 인증서 검증 과정:
   • 클라이언트는 서버로부터 받은 인증서를 확인한다
   • 브라우저에 내장된 CA의 공개키를 사용하여 인증서의 서명을 검증한다
   • 서명이 유효하면 인증서와 그 안에 포함된 서버의 공개키를 신뢰한다

인증기관은 웹의 신뢰 체계를 구축하는 핵심 요소로, 클라이언트가 통신하는 서버가 실제로 자신이 주장하는 서버인지 확인할 수 있게 해준다.

하이브리드 암호화 시스템의 이점

HTTPS에서 사용하는 하이브리드 암호화 시스템(비대칭키 + 대칭키)은 다음과 같은 이점을 제공한다.

1. 보안성:
   • 비대칭키 암호화를 통한 안전한 키 교환
   • 인증기관을 통한 서버 신원 확인
2. 효율성:
   • 초기 연결 후 빠른 대칭키 암호화 사용
   • 대용량 데이터 전송에 적합
3. 확장성:
   • 다수의 클라이언트가 동일한 서버와 안전하게 통신 가능
   • 각 세션마다 고유한 세션키 사용

대칭키와 비대칭키 암호화의 장점을 결합한 HTTPS 프로토콜은 현대 웹의 보안 기반을 형성하며, 사용자 데이터 보호와 안전한 온라인 거래를 가능하게 한다.