Proven by Intelligence
보이지 않는 안전을 인텔리전스로 증명하다.
기술 인사이트를 만나보세요.
│TLS 1.2 암호화통신 시리즈 기술노트
[NeoCertManager] TLS 1.2 암호화 통신 ⑴ - TLS 1.2 암호화 통신의 원리
[NeoCertManager] TLS 1.2 암호화 통신 ⑵ - TLS 1.2 암호화 알고리즘
15.TLS는 결국 AES로 데이터를 암호화한다.
TLS 암호화 통신의 실제 주인공은 AES 같은 대칭키 암호화 알고리즘입니다.
웹페이지, 로그인 정보, 결제 정보, 쿠키, API 요청과 응답 등 실제 데이터는 대부분 AES로 암호화됩니다.
왜냐하면 AES는 빠르고 안전하기 때문입니다.
하지만 AES를 사용하려면 서버와 클라이언트가 같은 AES 키를 가지고 있어야 합니다.
그래서 TLS 1.2에서는 RSA를 이용해 AES 키를 안전하게 교환합니다.
그리고 이 과정에서 SHA 계열 Hash 알고리즘을 이용하여 데이터와 Handshake 메시지가 위변조되지 않았는지 검증합니다.
16. TLS 1.2 암호화 통신 전체 흐름
TLS 1.2의 동작을 쉽게 설명하면 다음과 같습니다.
1. 클라이언트가 서버에 접속 요청을 보냅니다.
2. 서버는 인증서를 보냅니다.
3. 클라이언트는 인증서에 포함된 RSA 공개키를 확인합니다.
4. 클라이언트는 AES 통신에 사용할 비밀 재료를 생성합니다.
5. 클라이언트는 이 값을 RSA 공개키로 암호화해서 서버에 보낸다.
6. 서버는 RSA 개인키로 복호화합니다.
7. 양쪽은 동일한 세션키를 만든다.
8. 이후 실제 데이터는 AES로 암호화합니다.
9. SHA 기반 Hash/HMAC으로 위변조 여부를 검증합니다.
17. ClientHello
TLS 통신은 클라이언트의 인사로 시작됩니다.
이를 ClientHello라고 합니다.
클라이언트는 서버에게 다음과 같은 정보를 보냅니다.
지원하는 TLS 버전
지원하는 암호 알고리즘 목록
Client Random
Client Random은 클라이언트가 생성한 난수입니다.
나중에 세션키를 만드는 재료로 사용됩니다.
쉽게 말하면 클라이언트가 “나는 이런 보안 방식을 지원하고, 이 난수도 함께 보냅니다”라고 말하는 단계입니다.
18. ServerHello
서버는 클라이언트의 요청에 응답합니다.
이를 ServerHello라고 합니다.
서버는 다음 정보를 보냅니다.
선택한 TLS 버전
선택한 Cipher Suite
Server Random
서버 인증서
Server Random도 세션키 생성에 사용되는 난수입니다.
서버 인증서에는 서버의 공개키가 포함되어 있습니다.
19. 서버 인증서와 RSA 공개키
서버 인증서는 단순한 파일이 아닙니다.
서버가 진짜인지 확인하기 위한 신분증입니다.
예를 들어 사용자가 은행 사이트에 접속한다고 하면,
브라우저는 서버가 보낸 인증서를 확인합니다.
이 인증서는 신뢰할 수 있는 인증기관이 발급했는가?
인증서의 도메인이 내가 접속한 도메인과 일치하는가?
인증서가 만료되지 않았는가?
인증서가 폐기되지 않았는가?
이 검증이 성공하면 브라우저는 서버를 신뢰할 수 있다고 판단합니다..
TLS 1.2의 RSA Key Exchange 방식에서는 이 인증서 안에 들어 있는 RSA 공개키를 이용해 세션키 재료를 암호화합니다.
20. Premaster Secret 생성
클라이언트는 Premaster Secret이라는 비밀값을 생성합니다.
Premaster Secret은 최종 AES 키가 아니라 AES 키를 만들기 위한 원재료입니다.
Premaster Secret
= 클라이언트가 생성한 비밀 재료
클라이언트는 이 값을 서버에 안전하게 전달해야 합니다.
하지만 공개망에 그대로 보내면 공격자에게 노출됩니다.
그래서 서버 인증서에 포함된 RSA 공개키로 암호화합니다.
21. RSA 공개키로 Remaster Secret 암호화
클라이언트는 다음 과정을 수행합니다.
그리고 암호화된 값을 서버로 보냅니다.
공격자가 중간에서 이 값을 가로채도 서버의 RSA 개인키가 없으면 복호화할 수 없습니다.
22. 서버는 RSA 개인키로 복호화한다
서버는 자신만 보유한 RSA 개인키로 Encrypted Permaster Secret을 복호화합니다.
이제 클라이언트와 서버는 동일한 Premaster Secret을 갖게 됩니다.
하지만 아직 실제 AES 키는 아닙니다.
23. Master Secret
TLS 1.2는 Premaster Secret만으로 바로 세션키를 만들지 않습니다.
다음 값을 함께 사용합니다.
이 값들을 TLS의 PRF, 즉 Pseudo Random Function에 입력하여 Master Secret을 만듭니다.
PRF 내부에서는 Hash 기반 연산이 사용됩니다.
TLS 1.2에서는 선택된 Cipher Suite에 따라 SHA-256 또는 SHA-384 등이 사용될 수 있습니다.
PRF 내부에서는 Hash 기반 연산이 사용됩니다.
TLS 1.2에서는 선택된 Cipher Suite에 따라 SHA-256 또는 SHA-384 등이 사용될 수 있습니다.
24. Session Key 생성
Master Secret이 만들어지면 TLS는 여기서 여러 개의 키를 파생합니다.
하나의 키만 사용하는 것이 아니라 용도별로 여러 키를 만듭니다.
예를 들면 다음과 같습니다.
Client Write Key는 클라이언트가 서버로 데이터를 보낼 때 사용하는 암호키입니다.
Server Write Key는 서버가 클라이언트로 데이터를 보낼 때 사용하는 암호키입니다.
MAC Key는 메시지 무결성을 검증하는 데 사용됩니다.
이렇게 방향별, 용도별로 키를 나누는 이유는 보안을 강화하기 위해서입니다.
25. AES 기반 실제 데이터 암호화
Handshake가 끝나면 실제 통신 데이터는 AES로 암호화됩니다.
예를 들어 사용자가 로그인 정보를 보낸다고 하면,
서버는 같은 AES 세션키로 복호화합니다.
이제 공격자가 네트워크 패킷을 가로채도 AES 세션키를 모르면 내용을 알 수 없습니다.
26. SHA 기반 무결성 검증
TLS에서는 암호화만 중요한 것이 아닙니다.
데이터가 중간에서 바뀌지 않았는지도 중요합니다.
공격자가 암호문을 해석하지 못하더라도 일부 값을 바꾸려고 시도할 수 있기 때문입니다.
그래서 TLS는 Hash 기반 검증을 사용합니다.
TLS 1.2에서는 전통적으로 HMAC 구조를 사용합니다.
HMAC은 Hash-based Message Authentication Code의 약자입니다.
쉽게 말하면 “비밀키를 함께 사용하는 Hash 검증값”입니다.
단순 Hash는 누구나 계산할 수 있습니다.
하지만 HMAC은 비밀키를 알아야 올바른 값을 만들 수 있습니다.
수신자는 동일한 키로 다시 계산합니다.
값이 같으면 데이터가 변경되지 않았다고 판단합니다.
값이 다르면 중간에서 변조되었거나 손상된 것입니다.
27. SHA는 TLS에서 어디에 쓰일까?
SHA는 TLS 1.2에서 여러 위치에 사용됩니다.
첫째, Handshake 과정에서 Master Secret과 키를 파생하는 데 사용됩니다.
둘째, 메시지 무결성 검증을 위한 HMAC에 사용됩니다.
셋째, 인증서 서명 검증에도 사용됩니다.
넷째, Handshake 전체 메시지가 중간에서 변조되지 않았는지 확인하는 Finished 메시지에도 사용됩니다.
즉 SHA는 단순히 파일 Hash를 계산하는 역할만 하는 것이 아니라 TLS 신뢰 체계 전반에 사용됩니다.
