TLS(v1.2) - RFC5246 정리 (1)

1. 소개

 

TLS는 TLS Record Protocol + TLS Handshake Protocol이다. 

• TLS Record Protocol
  • 상위 Protocol(Application Layer)로부터 데이터를 받아서 클라이언트와 서버간에 협의된 Security 파라미터 기반으로 데이터를 가공하고 전송하는 단계.
• TLS HandShake Procol
  • TLS Record Protocol에서 클라이언트와 서버간의 협의를 통해 정해야할 Security 파라미터들을 교환하고 결정하는 단계

 

그림 1. https://www.websequencediagrams.com/#open=517958

위의 그림은 TLS Record Protocol과 TLS HandShake Protocol을 간략화한 그림이다.

 

(A), (E) : 이 단계는 좀 이상하긴 한데, 시퀀스 다이어그램을 원하는 형태로 그리기 위해서 넣은 것이다. 별 의미 없다.

(C) ~ (D) : TLS Record Protocol에서 사용할 Security Parameter를 실제 결정하는 단계로 TLS HandShake 단계라고한다.

이 단계에서 서버와 클라이언트 정보 교환은 PlainText 기반으로 진행하기 때문에 암호화되어 있지 않다.

따라서 Wireshark와 같은 툴을 사용하면 이 단계에서 동작을 Monitoring 할 수 있다.

다만 TLS Record Layer에서 사용하는데 공개해서는 안될 정보는 보통 비대칭 암호화를 사용한다.

상세 내용은 TLS HandShake 과정에서 살펴 본다.

(F) : (C) ~(D)단계가 완료되면 TLS Record Layer의 Security Parameter가 모두 결정되고, 암호화 채널이 구성된다.

Secure Channel이라고 하며, 암호화 방식은 대칭키 암호화 방식으로 Secure Channel이 구성된다.

 

지금까지 계략적으로 살펴본 것이고, 이제 TLS Protocol을 상세하게 살펴보도록 한다.

 

2. Security Parameters of TLS Record Protocol

 

TLS Handshake 과정을 통해서 TLS Record Protocol에서 사용하기 위해서 결정되어야 할 Security 파라미터 항목은 다음과 같다.

• connection end
  • client 또는 server : 즉 클라이언트 단인지 서버단인지를 나타낸다.
• RRF (Pseudorandom Function) algorithm
  • 해쉬알고리즘
• bulk encryption algorithm
  • TLS Record block을 암호화할 알고리즘 (대칭키 암호화 알고리즘)
• MAC algorithm
  • TLS Record의 메세지 무결성 검사에 사용될 알고리즘
• compression algorithm
  • TLS Record에 사용된 데이터 암축 방식
• master secret
  • 48 Byte로 대칭키 암호화 알고리즘에 사용될 암호화 키를 만드는데 사용된다.
• client random
  • 32 Byte 값으로 클라이언트가 생성한 값
• server random
  • 32 Byte 값으로 서버가 생성한 값

위에 기술된 Security Parameter가 결정되면 다음과 같은 6개의 항목을 생성한다.

• client write MAC key
• server write MAC key
• client write encryption key
• server write encryption key
• client write IV
• server write IV

사용 예는 client write 파라미터들은 서버 단에서 사용되고 클라이언트로부터 받은 TLS Record를 처리하는데 사용된다.

결론적으로 서버와 클라이언트에서 대칭키 암호화 채널을 구성하기 위해서 필요한 암호화 키 정보와 Initial Vector 및

암호화 채널의 무결성 검증을 위한 MAC Key를 결정하는 것이다.

 

3. TLS Record Protocol 동작

 

이제 모든 것을 결정되었다. 이제 서버와 클라이언트는 생성된 6개의 항목을 이용해서 서로 데이터를 주고 받는다. 이 때 각 전송 시에 아래와 같은 정보를 서로 관리하고 있다.

• compression state
  • compression algorithm의 현재 상태
• cipher state
  • encryption algorithm의 현재 상태
• MAC key
  • 현재 전송 상태에서 MAC key
• sequence number
  • 각 연결 상태마다 시퀀스 번호를 부여하고 있다. 2^64 -1 값을 넘을 수 없고, Rolling될 수도 없다.

각 TLS Record 전송 시마다 위의 상태를 서로 Check한다. 만약 변경되거나 정의되지 않은 방식으로 동작할 때는 Erorr로 처리된다.

여기서 sequence number에 주목해야 할 점이 있다.

TLS에서 replay attack이 가능여부에 대한 내용이 stack overflow에 많은 논의 거리이다.

결론적으로 seqeunce number에 의해서 replay attack은 불가능하다고 개인적으로 생각한다.

 

4. 마무리

 

정확하게 정리했는지는 확실치 않지만, 적어도 RFC 문서를 읽기 전에 읽으면 이해하는데 도움이 될 것으로 판단된다.

TLS HandShake는 다른 페이지를 이용해서 정리하도록 한다.