오늘도 컴파일

암호화 방식은 크게 대칭키 암호화, 비대칭키 암호화, 단방향 암호화로 구분할 수 있다. 각 암호화 방식은 서로 다른 특징이 있어 특정 용도에 따라 암호화 방식을 선택하게 된다.

대칭키 암호화란

대칭키 암호화는 암호화와 복호화에 동일한 키를 사용하는 암호화 방식이다. 이는 가장 기본적이고 단순한 형태의 암호화 방식으로, 하나의 비밀키로 데이터를 암호화하고 같은 키로 암호화된 데이터를 복호화한다.

대칭키 암호화의 주요 특징은 아래와 같다.

• 암호화와 복호화에 같은 키를 사용
• 빠른 암호화/복호화 속도
• 키의 길이가 상대적으로 짧음
• 안전한 키 교환 방식이 필요

이러한 대칭키 암호화 알고리즘은 다양한데 대표적으로 DES(Data Encryption Standard), AES(Advanced Encryption Standrard), SEED(한국형 블록 암호화 알고리즘)이 있다.

• AES는 DES의 보안 취약점을 보완하여 현재까지 가장 많이 사용되는 대칭키 암호화 알고리즘이다.

특징에서 알 수 있듯 구현이 쉽고 암/복호화 연산 속도가 빠르다는 장점이 있다. 하지만 같은 키를 사용하여 암/복호화하는 만큼 안전하게 키 교환하는 방식이 필요하다. 또한, 많은 사용자가 있는 경우 키 개수도 그만큼 증가하기에 키 관리가 복잡해진다는 문제가 있다.

비대칭키 암호화란

비대칭키 암호화는 데이터를 암호화할 때와 복호화할 때 서로 다른 키를 사용하는 암호화 방식이다. 공개키(Public Key)와 개인키(Private Key)라는 한 쌍의 키를 사용하며, 이 두 키는 수학적으로 연관되어 있다.

공개키는 모든 사람에게 공개되어 누구나 사용할 수 있지만, 개인키는 소유자만이 알고 있어야 한다. 한쪽 키로 암호화한 데이터는 반드시 다른 쪽 키로만 복호화할 수 있다는 특징이 있다.

비대칭키 암호화의 주요 특징은 아래와 같다.

• 암호화와 복호화에 서로 다른 키를 사용
• 키 교환이 필요 없음 (공개키는 공개되어 있음)
• 대칭키 방식보다 느린 암호화/복호화 속도
• 높은 보안성 제공

대표적인 비대칭키 암호화 알고리즘으로는 RSA(Rivest Shamir Adleman), DSA(Digital Signature Algorithm), ECC(Elliptic Curve Cryptography) 등이 있다.

비대칭키 암호화는 키 교환이 필요 없고 높은 보안성을 제공한다는 큰 장점이 있어 대칭키 암호화의 키 교환을 위해 사용하기도 한다. 또한 디지털 서명이 가능하여 부인 방지와 인증에 활용될 수 있다. 하지만 암호화/복호화 과정에서 복잡한 수학적 연산이 필요하여 속도가 느리고, 키의 길이가 대칭키 방식보다 길어 더 많은 시스템 자원을 필요로 한다는 단점이 있다.

단방향 암호화란

단방향 암호화는 해시(Hash) 함수라고도 불리며, 원본 데이터를 암호화된 데이터(해시값)로 변환할 수 있지만 암호화된 데이터로부터 원본 데이터를 복원할 수 없는 암호화 방식이다. 즉, 복호화가 불가능한 암호화 방식이다.

단방향 암호화의 주요 특징은 아래와 같다.

• 복호화가 불가능함 (원본 데이터 복원 불가)
• 동일한 입력값에 대해 항상 같은 해시값을 생성
• 입력값이 조금만 달라져도 완전히 다른 해시값이 생성됨
• 해시값으로부터 원본 데이터를 유추하기 어려움

대표적인 단방향 암호화 알고리즘으로는 MD5(Message-Digest algorithm 5), SHA(Secure Hash Algorithm) 시리즈, bcrypt, PBKDF2(Password-Based Key Derivation Function 2) 등이 있다.

MD5는 128비트 해시값을 생성하는 알고리즘이지만 현재는 보안 취약점이 발견되어 보안이 중요한 용도로는 사용하지 않는다. SHA 시리즈는 SHA-1, SHA-2, SHA-3 등이 있으며, 특히 SHA-256은 현재 가장 널리 사용되는 해시 알고리즘 중 하나이다.

bcrypt와 PBKDF2는 비밀번호 저장을 위해 특별히 설계된 알고리즘으로, 일부러 해시 생성 속도를 늦추고 솔트(salt)를 사용하여 레인보우 테이블 공격 등을 방지할 수 있도록 설계되었다.

이러한 특성 때문에 주로 사용자의 비밀번호를 저장하거나 데이터의 무결성을 검증하는 용도로 사용된다. 예를 들어, 웹 서비스에서는 사용자의 비밀번호를 평문으로 저장하지 않고 해시값으로 변환하여 저장한다. 로그인 시에는 사용자가 입력한 비밀번호를 동일한 해시 함수로 변환하여 저장된 해시값과 비교하는 방식으로 인증을 수행한다.

소프트웨어 개발을 할 때 라이브러리(Library)와 프레임워크(Framework)라는 용어를 자주 접하고 사용도 해본다.

이 두 가지 모두 개발자가 코드를 작성하고 관리하는 데 도움을 주는 것은 비슷하지만, 실제 역할과 사용 방법에 있어서 중요한 차이가 있다.

라이브러리(Library)

라이브러리는 특정 기능이나 작업을 수행하는 데 사용되는 재사용 가능한 코드 모음이다. 예를 들어서, 수학적 계산을 위한 함수 집합이나 데이터베이스 접근을 위한 도구 같은 것들이 라이브러리에 포함된다. 라이브러리는 개발자가 필요할 때 호출하여 사용할 수 있는 모듈 형태로 제공된다.

라이브러리는 아래와 같은 특징을 가진다.

• 재사용성 : 여러 프로젝트에서 동일한 라이브러리를 재사용할 수 있어 코드의 중복 최소화
• 모듈성 : 특정 기능에 초점을 맞추어 작은 모듈로 구성
• 호출 방식 : 개발자가 필요할 때 라이브러리를 호출하여 사용

프레임워크(Framework)

프레임워크는 애플리케이션의 구조를 제공하는 뼈대이다. 개발자는 이 뼈대 위에 자신만의 기능을 추가하여 애플리케이션을 개발한다. 프레임워크는 일련의 규칙, 가이드를 제공하여 개발 과정을 표준화하고 효율성을 높일 수 있다.

프레임워크는 아래와 같은 특징을 가진다.

• 제어 역전 : 프레임워크가 개발자의 코드를 호출하여 실행
• 구조 제공 : 애플리케이션의 전반적인 구조와 흐름 정의
• 통합 도구 : 다양한 기능을 통합 제공하며 특정 작업에 대한 최적화된 방법 제시

주요 차이점

가장 큰 차이점은 제어 역전이다. 라이브러리는 개발자가 필요할 때 호출하여 사용하지만, 프레임워크는 프레임워크 자체가 애플리케이션의 흐름을 제어하고 개발자의 코드를 프레임워크에서 호출하여 사용한다.

SSL(Secure Sockets Layer)와 TLS(Transport Layer Security)는 다른 프로토콜이다. 메시지 인증 방식과 Cipher Suite의 차이가 있지만, TLS가 SSL에 기반하여 보안 취약점을 해결한 프로토콜이고, 현재는 SSL을 완전 대체하여 SSL은 더 이상 사용되지 않아 사람들은 거의 동의어처럼 사용한다.

우선 TLS는 보안 연결을 위해 사용하는 프로토콜인데 TLS를 말하기에 앞서 TCP 3-Way Handshake, 대칭키 암호화, 비대칭키 암호화 이 3가지를 먼저 짚고 넘어가고자 한다.

TCP

TLS는 TCP 위에서 작동하는 보안 프로토콜이기 때문에 TCP의 연결 수립 이후에 TLS 보안 연결 수립이 진행된다.

우선 TCP는 3-Way handshake로 연결 수립이 되는데 과정은 아래 사진과 같다.

연결을 시도하는 Client에서 Server로 SYN 신호를 보내 통신하고 싶다는 의사를 보낸다.

그리고 Server에서 이를 수락하면 SYN/ACK로 수락 의사를 보낸다.

만약 거절하게 된다면 RST(Reset) 신호로 통신을 종료하게 된다.

마지막으로 수락 의사를 받은 Client가 수락 의사를 확인했다는 의미로 ACK를 보내면 TCP 연결 수립이 완료된다.

하지만 TCP 3-way handshake만 하여 연결을 수립한 통신은 양측에서 암호화된 암호문이 아닌 평문을 주고받기 때문에 패킷을 감청할 경우 내용이 그대로 보인다는 보안 취약점이 있다. 이를 보완해 주는 것이 TLS이다.

비대칭키 암호화 & 대칭키 암호화

암호화 방식을 나누면 크게 대칭키 암호화와 비대칭키 암호화, 해시 암호화로 나눌 수 있다. 다만, 본 게시글에서는 해시 암호화에 대해 다루지 않으므로 생략한다.

• 대칭키 암호화

대칭키 암호화는 암호화할 때 사용한 Key를 이용해 복호화가 가능한 방식이다.

위처럼 1개의 암호를 사용하여 암/복호화가 가능한 방식인데, 이 방식은 구현도 쉽고 속도도 빠르다. 하지만 가장 큰 문제인 "키 배송 문제(Key distribution problem)"가 있다. 키를 하나만 가지고 관리하며 암/복호화하기 때문에 유출 시 큰 문제가 발생하는데, 이 키를 송신 노드, 발신 노드 양 측에 안전하게 전달하여 가질 수 있게 하는 방법이 반드시 필요하다는 점이고 이를 "키 배송 문제 (Key distribution problem)"라고 한다.

• 비대칭키 암호화

비대칭키 암호화는 공개키(Public Key), 비밀키(Private Key)로 두 개를 한 쌍으로 하는 암호를 사용한다. 한 개의 키로 암호화 하면 반드시 다른 한 개의 키로만 복호화가 가능한 방식이다. 공개키는 공공에 배포하도록하고 비밀키는 서버에서 유출되지 않도록 관리한다.

공개키를 가지고 암호화하여 전송하면 공개키에 대응되는 비밀키를 가지고 있는 노드만 복호화하여 평문을 볼 수 있다. 이 방식은 대칭키 암호화 방식보다 구현이 어렵고 속도도 느리지만 공개키를 이용하여 키 배송 문제가 발생하지 않는 특징이 있다.

그래서 비대칭키는 어떠한 데이터를 암/복호화하는 데 사용하기보다 대칭키의 키 배송 문제를 해결하거나 인증 목적으로 사용하는 것이 일반적이다.

TLS

이제 이 글의 본론인 TLS의 동작 원리이다. TLS는 앞서 말했던 내용을 모두 이용한다. 기본적으로 대칭키 암호화 방식을 이용해서 보안 통신을 구현하는 것이고, 대칭키 암호화 방식을 사용하기 위해 키 배송 문제를 비대칭키 암호화로 해결하는 과정이 TLS Handshake이다.

3-Way Handshake 이후 TLS 보안 연결인 경우 위와 같은 단계들이 수행된다.

1. 클라이언트에서 Client Hello 메시지를 보낸다.

해당 메시지는 클라이언트에서 지원이 가능한 암호화 알고리즘 종류 (Cipher Suite), TLS 버전, 클라이언트 측에서 생성한 난수가 포함되어 있다.

만약 서버에서 해당 메시지를 수신하였는데 모든 암호화 알고리즘이 서버에서 지원되지 않거나 TLS 버전이 상이한 경우 보안 통신을 수행할 수 없으므로 연결이 종료된다.

2. 서버에서 Server Hello 메시지를 보낸다.

서버는 클라이언트로부터 전달받은 암호화 알고리즘 중에 서버에서 사용할 알고리즘을 하나 선택한다. Server Hello 메시지에는 그렇게 선택된 암호화 알고리즘, 서버 측에서 생성한 난수 그리고 SSL/TLS 인증서(Certification)가 포함되어 있다.

클라이언트에서 Server Hello를 수신받으면 SSL/TLS 인증서가 유효한지 검사를 진행한다.

3. 클라이언트에서 Client Key Exchange 메시지를 보낸다.

클라이언트 측에서 생성한 난수와 서버 측에서 수신받은 난수를 조합하여 PreMasterSecret을 생성한다.

PreMasterSecret은 추후 통신에 사용될 대칭키인 세션키(Session Key)를 생성하기 위한 비밀키이며 이 PreMasterSecret은 아직까지는 비대칭키 암호화를 사용하여 서버에 전송한다.

4. 클라이언트와 서버 각각 Session Key 생성

클라이언트와 서버는 모두 클라이언트 생성 난수, 서버 생성 난수, PreMasterSecret를 가지고 있기 때문에 동일한 알고리즘을 거치면 같은 Session Key를 생성할 수 있다.

f(preMasterSecret, clientRandom, serverRandom) = masterSecret
f(masterSecret, clientRandom, serverRandom) = sessionKey

이제 클라이언트와 서버는 각자 세션키를 통해 서로가 누구인지 알 수 있고, 데이터를 안전하게 암호화하여 보낼 수 있게 되었다.

5. 서로 Change Cipher Spec 메시지를 보낸다.

이제 대칭키 암호인 Session Key를 클라이언트와 서버가 안전하게 보관하게 되었으므로 속도가 느린 비대칭키 암호화를 사용할 필요가 없어졌다.

2. Server Hello 단계에서 지정했던 암호화 알고리즘을 이용할 것이고 Session Key라는 대칭키 암호를 이용해 추후 데이터 통신을 진행할 것이라는 메시지를 서로에게 보낸다.

Wireshark 프로그램을 이용해 실제로 TLS Handshake가 진행되었던 로그이다.

+ HTTP와 같이 비연결성(Connectionless), 무상태(Stateless)한 프로토콜에서 TLS를 사용하게 되면 매번 위 단계를 수행해야 하는가 싶지만, 그렇지 않다. TLS Handshake를 통해 도출되는 Session Key는 서버 측에서 대부분 만료 기간을 정해놓는다. 그 시간 안에서는 재사용이 가능하다. 따라서 만료되지 않았다면 매번 호출 때마다 위 단계를 수행하지 않고 클라이언트에서 기억하고 있던 Session Key를 Client Hello에 함께 보내게 된다.

SSL/TLS Version

• SSL 2.0 - 1994 공개
• SSL 3.0 - 1995 공개
• TLS 1.0 - 1999 공개
• TLS 1.1 - 2006 공개
• TLS 1.2 - 2008 공개
• TLS 1.3 - 2018 공개

2020년 이후 대부분 브라우저는 TLS 1.1 이하 버전에 대한 지원 중단.