[네트워크 이론] 암호화 방식

이글은 혼자 공부하는 네트워크(저자 : 강민철)의 책과 강의 내용을 개인적으로 정리하는 글임을 알립니다.

---

• 암호화(encryption): 원문 데이터를 알아볼 수 없는 형태로 변경하는 것을 의미
• 복호화(decryption): 암호화된 데이터를 원문 데이터로 되돌리는 것을 의미

암호화와 복호화는 비단 안전한 데이터 송수신뿐만 아니라 인증서 기반의 검증도 가능하게 한다.

 

암호와 인증서

• 키는 원문 데이터를 수학적 연산을 통해 암호문으로 바꾸는 데 사용되는 값이며, 이 과정을 암호화 알고리즘이라 한다.
• 암호문은 키 없이는 제3자가 의미를 알 수 없도록 설계되며, 복호화를 통해 원문을 되찾을 수 있다.

 

대칭키 암호화 방식과 공개키 암호화 방식

대칭키 암호화 방식

• 대칭 키 암호화 방식은 암호화와 복호화에 동일한 키를 사용하는 방식이다.
• A와 B가 같은 키로 메시지를 주고받으며, 양측이 같은 키를 갖고 있어야 통신이 가능하다는 특징이 있다.
• 대칭 키 방식의 문제점은 키 전달의 어려움에 있다.
• 키가 유출되면 암호화 통신이 무용지물이 되므로 안전한 키 전달 방식이 필수이다. 결국 암호화의 목적은 안전한 전달에 있는데, 키 자체를 안전하게 전달할 수 있다면 암호화가 필요 없어지는 역설이 발생한다.

 

공개키 암호화 방식

공개 키 암호화는 대칭 키 암호화의 한계를 극복하기 위해 등장한 방식으로, 암호화와 복호화에 서로 다른 키를 사용하는 것이 특징이다.

이 두 키는 공개 키와 개인 키로 구성되며, 한 키로 암호화한 내용은 다른 키로만 복호화가 가능하고, 두 키 중 하나만으로는 상대 키를 유추할 수 없다.

따라서 공개 키는 누구에게나 노출해도 무방하며, 개인 키는 반드시 비밀로 유지되어야 한다.

예를 들어 A가 B에게 메시지를 보낼 때는 B의 공개 키로 암호화하고, B는 자신의 개인 키로 이를 복호화하며, 반대로 B가 A에게 메시지를 보낼 때도 동일한 방식으로 진행된다.

대칭 키 암호화는 처리 속도가 빠르다는 장점이 있지만 키 전달이 어렵고, 공개 키 암호화는 속도가 느린 대신 키를 안전하게 공유할 수 있다는 이점이 있다.

 

세션 키

이러한 장단점을 고려해 대칭 키 암호화 방식과 공개 키 암호화 방식을 함께 사용하는 경우가 많다.

예를 들어 대칭 키를 상대에게 안전하게 전달하기 위해 공개 키로 대칭 키를 암호화하고, 개인 키로 암호화된 대칭 키를 복호화할 수 있다.

이렇게 하면 대칭 키를 안전하게 공유함과 동시에 공유된 대칭 키를 이용해 빠르게 암호화와 복호화를 수행할 수 있다.

참고로 이러한 방식으로 활용되는 대칭 키를 세션 키라고 부른다.

 

인증서와 디지털 서명

• 인증서는 단어 그대로 어떤 사실을 증명하기 위한 문서이며, 네트워크뿐 아니라 일상생활에서도 사용된다. 인터넷에서 말하는 인증서는 보통 공개 키 인증서를 의미하며, 이는 공개 키와 그 키의 유효성을 증명하기 위한 전자 문서이다.
• 예를 들어 클라이언트가 민감한 정보를 서버에 보낼 때, 서버는 암호화를 위해 공개 키를 보낸다.
  단순히 공개 키만 받아서는 그것이 진짜(중간에 조작 되었는지)인지 확인할 수 없기 때문에, 서버는 키를 생성한 주체, 조작 여부, 유효 기간 등 다양한 정보를 담은 인증서를 함께 전송한다.
• 이러한 인증서는 인증 기관(CA)에서 발급하며, 이들은 공개적으로 신뢰받는 제3의 기관이다. 인증 기관은 인증서의 발급, 검증, 저장 등의 기능을 수행하며, 대표적으로 IdenTrust, DigiCert, GlobalSign 등이 있다.

인증 기관은 자신이 발급한 공개 키 인증서가 진짜임을 보증하기 위해 서명 값을 포함시키는데, 이 서명은 인증서 내용에 대한 해시 값을 CA의 개인 키로 암호화하여 생성한다.

인증서 내용
- 서버의 도메인 이름 (예: www.example.com)
- 서버의 공개 키
- 인증서 유효 기간
- 누가 발급했는지 (발급자 정보)
- 서명 값 (signature) -> 이 인증서 전체 내용을 요약한 해시 값을 CA(인증 기관)의 개인 키로 암호화한 값(서명값=해시를 암호한 값)
- 해시 함수(이 해시 함수를 통해서 서명값이 만들어진다.)

클라이언트는 서버로부터 받은 인증서의 서명 값을 인증서에서 제공하는 CA의 공개 키로 복호화하여 해시 값을 얻고, 동시에 인증서의 실제 내용으로부터 새롭게 해시 값을 계산한 후 두 값을 비교한다

중요

일반적으로는 공개키로 암호화하고 개인키로 복호화 하는데, 반대로 CA는 개인키로 서명 값을 암호화 하고, 복호화 할 수 있는 공개키를 공개한다.
따라서 공개키를 통해서 암호화된 서명 값을 복호화할 수 있다.
서명값을 복호화 하면 해시값이 나온다.

따라서 해시 값은 해시 함수를 적용시킨 결괏 값이므로, 인증서에 포함된 해시 함수에 직접 값(서명을 제외한 인증서의 전체 내용)을 넣어서 해시값과 같은 값이 나오는지 확인하여 서명의 진위를 파악한다.

서명이 진짜라고 판단되었다면 인증서의 내용도 사실이 되는 것이다.

이 값이 일치한다면 인증서는 CA의 개인 키로 만들어진 것이므로 신뢰할 수 있다는 결론에 도달하게 된다. 이러한 절차를 통해 메시지의 신원을 증명하는 과정을 디지털 서명이라 부른다.

 

대표적인 해시 함수
대표적인 해시 함수로는 MD5, SHA-1, SHA-2(SHA-256, SHA-384, SHA-512) 등이 있다.
보안 강도는 MD5 < SHA-1 < SHA-256 < SHA-384 < SHA-512 순이다.
현재 MD5, SHA-1은 보안이 취약하여 사용이 권장되지 않는다.

 

 

HTTPS(SSL과 TLS)

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 인증과 암호화를 수행하는 보안 프로토콜이며, TLS는 SSL의 상위 호환이다.

TLS 1.0부터 TLS 1.3까지 발전해 왔으며, SSL은 더 이상 사용되지 않는다.

참고로 1.0, 1.1은 취약점이 발견되어 쓰지 않는 것을 권장하고, 1.3이 가장 안전하다.

SSL/TLS를 사용하는 대표적인 프로토콜은 HTTPS이다.

HTTPS는 TLS 1.3을 기반으로 세 단계로 이루어진다.

1. TCP 3-way 핸드셰이크
2. TLS 핸드셰이크
3. 암호화된 메시지 송수신

 

먼저 TCP 연결이 수립된 후 TLS 단계가 시작된다.

왼쪽은 TCP 핸드셰이크, 오른쪽은 TLS 핸드셰이크

 

TLS 핸드셰이크는 인증서 송수신과 키 교환이 핵심이다.

이 과정에서 클라이언트는 서버의 인증서를 받고, 신뢰 여부를 검증하며, 암호화 통신에 사용할 키를 협상한다.

클라이언트의 ClientHello 메시지

• 암호화된 통신을 위해 서로 맞춰 봐야 할 정보들을 제시하는 메시지
• 지원 TLS 버전, 암호화 스위트, 키 생성에 필요한 난수 등이 포함

 

서버의 ServerHello 메시지

• ServerHello 메시지는 제시된 정보들을 선택하는 메시지
• 선택된 TLS 버전, 암호화 스위트, 키 생성에 필요한 난수 등이 포함

ClientHello,  ServerHello를 주고 받으면 암호화 통신을 위해 사전 협의해야 할 정보들이 결정된다.

이러한 협의를 통하여 서버와 클라이언트는 암호화에 사용할 키를 생성한다.

 

TLS 핸드셰이크에서 인증서 및 인증서 검증

• 서버는 이후 Certificate 및 CertificateVerify 메시지를 통해 자신의 인증서를 클라이언트에 전송
• 클라이언트는 이를 검증하여 서버의 신원을 확인
• 마지막으로 Finished 메시지를 주고받으며 핸드셰이크를 종료

 

마지막으로 합의된 키를 기반으로 함호화된 데이터를 송수신 한다.

암호화 스위트
사용가능한 암호화 방식과 해시 함수를 담은 정보를 암호 스위트라고 한다.