[Network] 대칭키 & 공개키

jiny·2026년 2월 14일
computer sciencenetwork

Computer Science

목록 보기
11/16

1. 대칭키 암호화 (Symmetric Key Encryption)

✨ 기본 개념

암호화와 복호화에 동일한 키를 사용하는 방식이다.
송신자와 수신자가 같은 비밀 키를 공유해야 하며, 이 키가 제3자에게 노출되지 않는 것이 보안의 핵심이다.

✨ 작동 원리

✨ 대표적인 알고리즘

대칭키 알고리즘은 데이터를 처리하는 방식에 따라 크게 두 가지로 나뉜다.

  • 블록 암호 (Block Cipher): 데이터를 특정 크기(블록)로 나누어 암호화한다.
    • AES (Advanced Encryption Standard): 현재 표준으로, 가장 널리 사용된다. 128/192/256비트 키가 있다.

      🔑 AES의 비밀키의 길이

      AES에서 128, 192, 256비트라는 숫자는 암호화에 사용하는 비밀키의 길이를 의미한다.
      키가 길어질수록 암호의 복잡성과 보안 강도가 달라지는데, 구체적으로 어떤 차이가 있는지 알아보자.

      1. 키의 길이와 경우의 수
        비트는 컴퓨터가 사용하는 최소 단위(0 또는 1)이다. 키의 길이가 길어질수록 공격자가 무작위로 대입해서 비밀번호를 맞출 수 있는 확률이 기하급수적으로 낮아진다.

        키 길이경우의 수 (조합 가능한 개수)보안 수준
        128 bit2^128 (약 3.4×10^38개)현재 표준, 매우 안전함
        192 bit2^192 (약 6.2×10^57개)고도의 보안 필요 시 사용
        256 bit2^256 (약 1.1×10^77개)최상위 보안, 양자 컴퓨터 대비용
      1. 알고리즘의 복잡도 (라운드 수)
        AES는 데이터를 한 번만 섞는 게 아니라, 여러 번 반복해서 뒤섞는 과정을 거친다. 이 반복 횟수를 '라운드(Round)'라고 하는데, 키가 길수록 더 많이 섞는다.
        • AES-128: 데이터를 10번 뒤섞음
        • AES-192: 데이터를 12번 뒤섞음
        • AES-256: 데이터를 14번 뒤섞음
      2. 보안 vs. 성능의 트레이드오프
        • 보안성: 당연히 256비트가 가장 강력하다. 미국 정부에서 '일급 비밀(Top Secret)'을 보호할 때 256비트 사용을 권고할 정도이다.
        • 성능: 키가 길고 라우드 수가 많을수록 연산량이 늘어나기 때문에 속도는 128비트가 가장 빠르다. 하지만 현대 컴퓨터 성능(특히 AES 전용 가속 기능이 있는 CPU)에서는 그 차이가 미미해서 보통은 128비트나 256비트를 주로 선택한다.
    • DES (Data Encryption Standard) / 3DES (Triple DES): 과거 표준이었으나, 현재는 보안 취약성으로 권장되지 않는다.
  • 스트림 암호 (Stream Cipher): 데이터를 비트/바이트 단위로 순차적으로 암호화한다.
    • ChaCha20: 연산 속도가 빨라 모바일 및 저사양 기기 환경에 최적화되었다.

✨ 장점

  • 압도적인 속도: 연산 과정이 단순해서 공개키 방식보다 수백~수천 배 빠르다.
  • 대용량 처리에 적합: 파일 전체 암호화나 실시간 스트리밍 데이터 처리에 유리하다.
  • 효율적: 컴퓨팅 자원을 적게 사용한다.

✨ 단점

  • 키 배송 문제 (Key Distribution): 송수신자가 안전하게 키를 공유하는 것이 어렵다. 전달 과정에서 탈취되면 보안이 완전히 무너진다.
  • 키 관리의 복잡성: N명이 통신하려면 N(N-1)/2개의 키가 필요하다. (예: 100명이면 4,950개의 키가 필요함)
  • 키 노출 위험: 키가 한 번 유출되면 모든 통신이 위험하다.
  • 무결성 확인의 한계: 단순히 암호화만으로는 데이터가 중간에 변조되었는지 확인하기 어렵다.

✨ 실제 사용 사례

  • 파일/디스크 암호화 (BitLocker, FileVault)
  • VPN 터널 내부 데이터 암호화
  • 데이터베이스 암호화

✨ 보완 기술

  1. 하이브리드 암호화 (Hybrid Encryption)
    대칭키의 '속도'와 공개키의 '안전한 키 전달' 장점을 결합한 방식이다.
    이 방식은 현대 웹 보안의 핵심인 SSL/TLS(HTTPS)의 기반이 되었다.
    • 키 교환: 상대적으로 느린 공개키 방식을 사용하여 '대칭키'만 안전하게 주고받는다.
    • 본 통신: 일단 키가 공유되면, 실제 데이터는 빠른 대칭키 방식으로 암호화하여 통신한다.
  1. MAC (Message Authentication Code)
    대칭키를 활용해 데이터의 무결성(변조 여부)과 인증(보낸 사람 확인)을 보장하는 기술이다.
    송신자가 메시지와 키를 조합해 만든 '해시값(MAC)'을 함께 보내면, 수신자가 동일한 키로 확인하여 데이터가 안전한지 검증한다.

2. 공개키 암호화 (Public Key Encryption / Asymmetric Key)

✨ 기본 개념

두 개의 키 쌍을 사용하여 보안 문제를 해결한다.

  • 공개키 (Public Key): 누구에게나 공개 가능, 암호화에 사용
  • 개인키/비밀키 (Private Key): 본인만 보관, 복호화에 사용

✨ 수학적 원리

일방향 함수(One-way Function)에 기반한다.

  • 공개키로 암호화하기는 쉽지만
  • 개인키 없이 복호화하기는 사실상 불가능하다. (수학적으로 매우 어려움)

✨ 작동 원리

공개키 방식은 어떤 키로 먼저 암호화하느냐에 따라 목적이 완전히 달라진다.

  1. 암호화 통신 (기밀성 보장)
    • 목적: "나만 읽을 수 있게 해줘"
    • 방법: 수신자의 공개키로 암호화 ➡️ 수신자의 개인키로 복호화
    • 결과: 수신자의 개인키를 가진 사람만이 내용을 볼 수 있다. (Confidentiality)
    • 예시
      1. Bob이 키 쌍(공개키, 개인키) 생성
      2. Bob의 공개키를 Alice에게 전달
      3. Alice가 Bob의 공개키로 메시지 암호화
      4. Bob이 자신의 개인키로 복호화
        💡 Bob만 읽을 수 있음 (Confidentiality 보장)
  1. 전자 서명 (무결성, 인증 보장)
    • 목적: "이거 진짜 내가 보낸 거 맞아"
    • 방법: 송신자의 개인키로 암호화(서명) ➡️ 송신자의 공개키로 복호화(검증)
    • 결과: 송신자의 공개키로 풀린다는 것은, 오직 송신자의 개인키로만 만들어졌음을 증명한다. (Authenticity, Integrity)
    • 예시
      1. Alice가 개인키로 메시지 서명 (암호화)
      2. 서명된 메시지를 Bob에게 전송
      3. Bob이 Alice의 공개키로 서명 검증 (복호화)
        💡 Alice가 보냈음을 증명 (Authenticity 보장)
        💡 메시지가 변조되지 않았음을 보장 (Integrity 보장)

✨ 대표적인 알고리즘

  • RSA (Rivest-Shamir-Adleman)
    • 원리: 아주 큰 두 개의 소수를 곱하기는 쉽지만, 그 곱 결과값을 다시 소인수분해하기는 매우 어렵다는 수학적 원리를 이용한다.
    • 특징: 가장 오래되고 검증된 알고리즘이지만, 보안 수준을 높이려면 키 길이가 너무 길어져야 한다는 단점이 있다.
  • ECC (Elliptic Curve Cryptography)
    • 원리: 타원곡선 위의 점들 사이의 복잡한 연산(이산로그 문제)을 이용한다.
    • 특징: RSA보다 훨씬 적은 비트 수로도 동일한 보안을 제공한다. (예: RSA 3072비트의 보안성 = ECC 256비트)
    • 장점: 키가 작아 연산이 빠르고 에너지를 적게 소비하여 스마트폰, IoT 기기, 블록체인(비트코인 등)에서 표준으로 쓰인다.
  • DSA/ECDSA
    • 특징: 오직 전자서명을 생성하고 검증하기 위해 만들어졌다. (전자서명 전용)
  • Diffie-Hellman (디피-헬먼)
    • 원리: 공개된 채널에서 두 사람이 서로의 정보를 교환하여, 제3자는 알 수 없는 공통의 비밀키를 만들어 내는 방식이다.
    • 특징: 데이터를 직접 암호화하는 용도가 아니라, 대칭키 암호화에 쓸 '키를 안전하게 교환'하기 위한 용도로만 사용된다.

✨ 장점

  • 키 배송 문제의 근본적 해결: 대칭키처럼 "비밀키를 어떻게 안 들키고 보내지?"라고 고민할 필요가 없다. 누구나 볼 수 있는 공개키만 던져주면 되기 때문이다.
  • 확장성: N명이 통신해도 각자 1개의 키 쌍(총 N개)만 필요해서, 관리가 매우 효율적이다.
  • 부인 방지 (Non-repudiation): 자신의 개인키로 서명한 메시지는 나중에 "내가 보낸 거 아니다"라고 발뺌할 수 없다. 이는 전자상거래나 계약에서 매우 중요한 법적 근거가 된다.

✨ 단점

  • 속도 저하의 원인
    • 대칭키는 컴퓨터가 가장 잘하는 단순 비트 연산(XOR, Shift)을 수행한다.
    • 공개키는 거듭제곱, 모듈로(나머지) 연산 등 복잡한 수학적 계산을 수행하므로 CPU 자원을 훨씬 많이 소모한다.
  • 중간자 공격 (Man-in-the-Middle Attack): 공개키 자체는 안전하지만, "이 공개키가 진짜 그 사람 것인가?"를 확인해주는 인증서(Certificate) 시스템이 없으면 해커가 중간에서 키를 가로채서 바꿔치기할 위험이 있다.
  • 키 크기: 보안 강도를 높이려고 RSA 키를 4096비트 이상으로 늘리면 연산 속도가 급격히 느려지는 문제가 발생한다.

✨ 핵심 보완: 공개키를 어떻게 믿을까?

공개키 방식의 가장 큰 약점은 "내가 받은 Bob의 공개키가 진짜 Bob의 것인가?"이다. 해커가 Bob인 척 자신의 공개키를 보낼 수 있기 때문이다.
이를 해결하기 위해 PKI(공개키 기반 구조)가 존재한다.

  • CA (인증 기관): 정부나 신뢰할 수 있는 기관(예: Digicert, KISA 등)이 공개키의 주인을 확인해 준다.
  • 디지털 인증서: CA가 "이 공개키는 진짜 Bob의 것입니다"라고 보증하며 자신의 개인키로 설명한 일종의 '디지털 신분증'이다.

✨ 실무 적용: 하이브리드 방식 (SSL/TLS)

실제 HTTPS 통신에서는 공개키 방식만 쓰지 않는다. 너무 느리기 때문이다.

  • 악수 (Handshake): 공개키 방식으로 서로를 확인하고, 앞으로 쓸 대칭키를 안전하게 공유한다.
  • 데이터 전송: 공유된 대칭키를 사용하여 실제 데이터를 빠르게 주고받는다.

3. 보안의 3요소: CIA Triad

보안은 단순히 '암호화'만 한다고 완성되지 않는다. 정보를 안전하게 지키기 위해서는 아래 세 가지 요소가 유기적으로 맞물려야 한다.

✨ 핵심 개념

  • Confidentially (기밀성): "허락된 사람만 봐라." 오직 인가된 사용자만이 정보에 접근할 수 있어야 한다.
  • Integrity (무결성): "중간에 바뀌지 마라." 정보가 전송 중에 누군가에 의해 수정되거나 삭제되지 않았음을 보장해야 한다.
  • Authenticity (인증성): "진짜 네가 보낸 거 맞아?" 정보를 보낸 사람이 사칭자가 아닌 실제 본인임을 확인하는 것이다.
  • (+) Non-repudiation (부인 방지): "나중에 딴소리하지 마라." 메시지를 보낸 사람이 나중에 "나는 그런 거 보낸 적 없다"라고 부정할 수 없게 만드는 법적 효력이다.

✨ 방식별 보안 요소 충족 현황

단순히 암호화만 한다고 모든 보안 요소가 해결되지 않는다는 점이 핵심이다.

방식기밀성무결성인증성부인방지특징
대칭키 암호화✅❌❌❌내용만 숨길 뿐, 변조 여부는 모름
공개키 암호화✅❌❌❌수신자만 읽게 할 뿐, 보낸 이는 모름
MAC (메시지 인증 코드)❌✅✅❌대칭키를 공유한 사람끼리만 확인 가능
전자 서명❌✅✅✅제3자에게도 보낸 이를 증명할 수 있음

✨ 왜 암호화만으로는 '무결성'과 '인증성'이 안 될까?

  • 암호화의 한계: 해커가 암호문을 가로채서 내용을 읽지는 못하더라도(기밀성), 암호문의 비트 몇 개를 임의로 바꿔버릴 수 있다. 수신자가 이를 복호화하면 깨진 글자가 나오겠지만, 이것이 전송 오류인지 해커의 변조인지 알 방법이 없다.
  • 인증의 한계: 누군가 내 공개키로 암호화해서 메시지를 보냈을 때, 그게 진짜 내 친구인지 아니면 내 공개키를 주워온 해커인지 알 수 없다.

✨ 해결사: MAC과 전자 서명

  • MAC (Message Authentication Code)
    • 메시지에 '비밀번호(대칭키)'를 섞어서 만든 특수한 꼬리표이다.
    • 메시지가 1비트라도 바뀌면 꼬리표 값이 달라지므로 무결성을 확인하고, 같은 키를 가진 사람만 만들 수 있으니 인증도 된다.
  • 전자 서명
    • 개인키로 도장을 찍는 방식이다.
    • 누구나 내 공개키로 확인해 볼 수 있으므로, 전 세계 누구에게나 "이건 진짜 내가 보낸 것"임을 증명하고 나중에 발뺌도 못 하게 한다.

✨ 실무에서의 조합: AEAD (Authenticated Encryption)

현대 보안 통신(예: AES-GCM)에서는 기밀성과 무결성을 따로 챙기지 않고, '인증된 암호화(AEAD)'라는 방식을 쓴다.
암호화를 하면서 동시에 무결성 체크용 꼬리표(Tag)를 하나로 합쳐서 만드는 것이다.

4. 하이브리드 암호화 방식

✨ 왜 하이브리드인가?

암호화의 두 세계관을 합친 이유는 단순하다. "안전하게 열쇠를 전달하고(공개키), 그 열쇠로 빠르게 대화하자(대칭키)"는 것이다.

  • 공개키의 역할: 대칭키를 안전하게 포장하는 '금고' 역할 (Key Wrapping)
  • 대칭키의 역할: 실제 데이터를 주고받는 '고속도로' 역할 (Bulk Encryption)

✨ 작동 과정

  • 1단계: 안전한 열쇠 전달 (공개키 방식 사용)
    • 공개키 요청 및 전달: 클라이언트(Alice)가 서버(Bob)에게 접속하면, 서버는 자신의 공개키를 보내준다. 이 공개키는 누구나 가질 수 있는 '열려 있는 금고'와 같다.
    • 세션키(대칭키) 생성: 클라이언트는 이번 대화에서만 딱 한 번 쓰고 버릴 임시 대칭키(세션키)를 스스로 만든다.
    • 열쇠 포장(암호화): 클라이언트는 서버에게 받은 공개키(금고) 안에 자신이 만든 세션키(열쇠)를 넣고 잠근다. 이제 이 금고는 서버의 개인키가 없으면 전 세계 누구도 열 수 없다.
    • 금고 전송 및 해제: 클라이언트가 잠긴 금고를 서버에게 보낸다. 서버는 자신만 가진 개인키로 금고를 열어 세션키(열쇠)를 꺼낸다.
      • 결과: 이제 Alice와 Bob은 똑같은 비밀 열쇠(세션키)를 안전하게 공유하게 되었다.
  • 2단계: 빠르고 안전한 대화 (대칭키 방식 사용)
    • 고속 암호화 통신: 공유된 세션키를 사용하여 데이터를 암호화하고 주고받는다. 대칭키 방식이라 연산이 매우 단순하고 빠르다.
    • 보안 유지: 이 세션키는 이번 연결이 끝나면 파기되므로, 나중에 혹시라도 키가 유출될 위험을 최소화한다.

✨ 실제 적용 사례: TLS/SSL (HTTPS)

웹 브라우저가 HTTPS로 통신할 때

  1. Handshake 단계 (신뢰 구축)
    단순히 키만 주고받는 게 아니라, 상대방이 진짜인지 확인하는 과정이 포함된다.
    • 인증서 검증: 서버는 자신의 공개키가 담긴 '디지털 인증서'를 보낸다. 브라우저는 이 인증서가 신뢰할 수 있는 기관(CA)에서 발급되었는지 확인하여 사칭 사이트를 걸러낸다.
    • 세션키(Session Key) 합의: 양측은 통신하는 동안에만 잠깐 쓰고 버릴 일회용 대칭키를 만든다.
  1. 데이터 전송 단계 (효율적 통신)
    • 대칭키 암호화: Handshake에서 합의된 세션키를 사용하여 HTTP 데이터를 암호화한다. 덕분에 고화질 영상이나 대용량 파일도 빠르게 주고받을 수 있다.
  1. 추가 보안 장치: HMAC (무결성 보장)
    • 데이터를 보낼 때마다 HMAC(Hash-based MAC)이라는 꼬리표를 붙인다.
    • 만약 해커가 중간에서 암호화된 데이터의 1비트라도 건드리면, 수신 측에서 즉시 알아채고 연결을 끊어버린다.

✨ 하이브리드 방식의 핵심 이점 요약

구분해결하는 문제얻는 효과
공개키 활용키 배송 문제 (Key Distribution)모르는 사이라도 안전하게 통신 시작 가능
대칭키 활용속도 및 자원 소모 문제CPU 부담 감소, 실시간 대용량 통신 가능
인증서 활용중간자 공격 (MITM)접속한 사이트가 가짜가 아님을 보장

5. 실전 활용법

✨ 대칭키를 사용하는 경우

  • 로컬 파일/디스크 암호화: 내 컴퓨터의 하드디스크를 통째로 암호화할 때는 속도가 생명이다. 나 혼자만 쓰는 키이므로 '키 배송 문제'가 없어 대칭키가 가장 효율적이다.
  • 데이터베이스(DB) 암호화: 수백만 건의 고객 정보를 실시간으로 읽고 써야 하는 DB 서버에서는 연산이 복잡한 공개키를 쓸 수 없다.
  • IoT 센서 데이터: 전력 소모가 적어야 하는 작은 센서들은 복잡한 수학 계산(공개키)을 감당하기 어렵기 때문에 가벼운 대칭키 방식을 선호한다.

✨ 공개키를 사용하는 경우

  • 전자서명 및 신원 인증: "이 소프트웨어는 마이크로소프트가 만든 게 확실합니다"라는 것을 증명할 때 사용한다. 누구나 검증할 수 있어야 하므로 공개키가 필수이다.
  • 블록체인 및 암호화폐: 비트코인 지갑 주소가 바로 '공개키'이다. 내가 내 지갑의 주인임을 증명할 때 '개인키'로 서명을 한다.
  • SSH 초기 접속: 서버에 처음 원격 접속할 때, 비밀번호 대신 내 공개키를 등록해두면 안전하게 본인 인증을 할 수 있다.

✨ 하이브리드를 사용하는 경우

  • HTTPS/TLS (웹 보안): 전 세계 불특정 다수와 안전하고 빠르게 통신해야 하는 웹의 특성상, 하이브리드 방식은 선택이 아닌 필수이다.
  • 메신저 종단간 암호화 (E2E): 카카오톡(비밀채팅), 시그널, 와츠앱 등에서 사용한다.
    • 처음 대화할 때 상대방과 공개키로 '대화방 비밀키'를 나누고,
    • 실제 메시지는 그 대칭키로 암호화해서 보낸다. (서버도 내용을 볼 수 없게 보호)
  • VPN 초기 설정: 회사 외부에서 사내망에 접속할 때, 처음 연결을 맺는 과정(터널링)은 공개키로, 이후 쏟아지는 데이터 통신은 대칭키로 처리한다.
  • 이메일 암호화 (PGP): 이메일 본문은 대칭키로 암호화하고, 그 대칭키를 수신자의 공개키로 한 번 더 감싸서 보낸다.
profile
jiny
이전 포스트

[Network] UDP

다음 포스트

[Network] HTTP & HTTPS

0개의 댓글