Chapter 8 - 4. 종단점 인증, 5. 전자메일의 보안, 6. TCP 연결의 보안

8.4 종단점 인증

종단점 인증이란 하나의 통신 개체가 다른 개체에게 자신의 신원을 컴퓨터 네트워크상으로 증명하는 작업이다.

예를 들어, 전자 메일 사용자가 서버에 신원을 입증할 수 있다.

서로 간의 인증은 인증 프로토콜의 한 부분으로서 교환된 메시지와 데이터만을 기반으로 수행되어야 한다.

 

대부분의 인증 프로토콜은 다른 프로토콜을 수행하기 전에 수행된다.

즉, 인증 후에 작업을 수행한다.

 

인증 프로토콜 ap(authentication protocol) 2.0

송신자가 이미 알려진 네트워크 주소(IP 주소)를 가지고 통신을 한다면 수신자는 인증 메시지를 가지고온 IP 데이터 그램 출발지 주소가 송신자의 IP 주소와 일치하는지 확인함으로써 앨리스를 인증할 수 있다.

그러나 IP 데이터그램을 생성해서 원하는 출발지 IP 주소를 넣고 그 데이터그램을 라우터로 보낼 수 있으므로 이는 안전하지 못하다.

 

예를 들어, 침입자가 가짜 출발지 주소를 쓰고 데이터를 보낼 수 있는데 이 방법은 IP 스푸핑의 한 형태이다.

침입자가 출발지 주소를 바꾸지 못하게 하면 되겠지만, 이는 강제할 수 없다.

 

인증 프로토콜 ap(authentication protocol) 3.0

인증자와 인증 받는 사람 간에 공유된 비밀번호를 사용할 수 있다.

지메일, 페이스북 등 많은 서비스가 비밀번호 인증을 사용한다.

그러나 이 프로토콜은 안전하지 못하다.

침입자가 송신자의 통신을 도청한다면 송신자의 비밀번호를 알아낼 수 있고, 이후 송신자인 척 할 수 있다.

 

인증 프로토콜 ap(authentication protocol) 3.1

비밀번호를 암호화하여 비밀번호를 엿듣는 것을 막을 수 있다.

송신자와 수신자는 대칭 비밀키를 공유하여 비밀번호를 암호화 복호화할 수 있다.

 

그러나 수신자는 재생 공격(playback attack)의 위험에 노출되어 있다.

침입자는 도청하여 송신자의 암호화된 비밀번호를 저장했다가 나중에 그대로 수신자에게 보낸다.

즉, 송신자인 척 할 수 있다.

 

인증 프로토콜 ap(authentication protocol) 4.0

넌스(nonce)는 프로토콜이 평생에 단 한 번만 사용하는 숫자를 뜻한다.

시나리오

1. 송신자는 메시지를 보낸다.
2. 수신자는 넌스 R을 선택하고 그것을 송신자에게 보낸다.
3. 송신자는 대칭 비밀키를 이용하여 그 넌스를 암호화하고, 암호화된 넌스 K(R)을 수신자에게 보낸다.
   • 해당 송신자가 다음에 또 통신을 하면 R이 바뀌어도 비밀키를 알고 있으므로 또 인증을 받을 수 있다.
   • 그러나 침입자라면 비밀키를 모르고 있으므로 암호화할 수 없다.

8.5 전자메일의 보안

보안은 인터넷 프로토콜 스택 위쪽 4개 계층의 어느 곳에서나 보안 서비스를 제공할 수 있다.

보안이 특정 애플리케이션 계층 프로토콜을 위해 제공되면 그 프로토콜을 사용하는 애플리케이션은 보안 서비스를 사용할 수 있게 된다.

 

보안 기능이 하나 이상의 계층에서 제공되는 이유

보안은 네트워크 계층에서 제공하는 것으로 충분하지 않을까?

1. 네트워크 계층에서 데이터그램의 모든 데이터를 암호화하고 IP 주소를 인증함으로써 ‘전면적 범위’의 보안을 제공하더라도 사용자 레벨의 보안은 제공할 수 없다.
   • 예를 들어, 인터넷 상거래 사이트는 물건을 구입하려는 고객을 인증하는 데 IP 계층 보안에만 의존할 수는 없다.
2. 프로토콜 상위 계층에서 보안 서비스를 포함한 새로운 인터넷 서비스를 구현하는 일이 점차 쉬워지고 있다.

 

8.5.1 보안 전자메일

보안 전자메일 시스템을 만들기 위해 암호화 원리들을 이용해보자.

 

기밀성

메시지를 대칭키 기술(AES,DES 등)으로 암호화 복호화하여 기밀성을 얻을 수 있다.

그러나 송수신자만 대칭키를 알기에 어렵기 때문에 공개키 암호화(RSA)를 고려하게 된다.

 

그러나 RSA를 통해 메시지를 암호화 복호화 한다면 계산 부하가 너무 심해서 실질적으로 쓸 수 없다.

이를 위해 세션키를 사용한다.

1. 송신자는 임의의 대칭 세션키 Ks를 선택한다.
   • 이 대칭 세션키는 AES나 DES에 사용된다.
2. Ks로 메시지 m을 암호화하여 암호문 1을 얻는다.
3. Ks는 송신자의 공개키로 암호화하여 암호문 2를 얻는다.
4. 이 두개의 암호문을 수신자에게 보낸다.
5. 수신자는 자신의 개인키로 암호문 1을 복호화하여 Ks를 얻을 수 있다.
6. 얻은 Ks로 암호문 2를 복호화하여 m을 얻을 수 있다.

 

이렇게 기밀성을 얻을 수 있다.

 

송신자 인증과 메시지 무결성

이 둘을 얻기 위해 전자서명과 해시 알고리즘을 이용한다.

1. 송신자는 메시지 요약문을 얻기 위해 m에 해시함수를 적용하여 H(m)을 얻는다.
2. 전자 서명을 만들기 위해 해시의 결과를 자신의 개인키로 암호화한다.
3. 메시지 m과 전자서명을 수신자에게 보낸다.
4. 수신자는 송신자의 공개키로 전자서명을 복호화한다.
5. 메세지 m에 해시 알고리즘을 적용한 결과와 4의 결과를 비교하여 같으면 보낸 사람을 확인할 수 있고, 메시지의 무결성을 확인할 수 있다.

 

통합

1. 먼저 송신자 인증과 무결성 과정을 통해 얻은 메시지와 전자서명 꾸러미를 만든다.
2. 이 꾸러미를 메시지 취급하여 기밀성 과정을 통해 수신자에게 전달한다.
3. 수신자는 순서대로 복호화하여 확인한다.

그러나 수신자는 송신자의 공개키를 알아야하고, 송신자는 수신자의 공개키를 알아야 하므로 CA를 통해 공개키를 인증 받아야한다.

 

8.5.2 PGP(Pretty Good Privacy)

PGP는 암호화 기법의 좋은 예로 본질적으로 위 통합과 동일하다.

1. PGP가 설치되면 소프트웨어는 사용자를 위한 공개키 쌍을 만든다.
   • 공개키는 사용자 웹사이트에 게시되거나 공개키 서버에 놓인다.
   • PGP 공개키는 사용자간 신뢰의 그물(web of trust) 속에서 인증된다.
   • 어떤 PGP 사용자들은 키 서명을 위한 모임을 열어 같은 물리적 공간에 모여서 공개키를 교환하고 그들의 개인키로 서명하는 것으로 서로의 키를 보증한다.
2. 개인키는 비밀번호로 보호된다.
   • 개인키를 사용하려면 사용자는 비밀번호로 인증해야한다.
3. PGP는 전자메일과 같은 방식으로 사용자에게 메시지를 전자서명하거나 암호화하거나 둘다 하거나 하는 선택지를 제공한다.
   • 개인키, 공개키, 해시 알고리즘, RSA가 있으니 모두 가능하다.

8.6 TCP 연결의 보안: TLS

보안 서비스가 추가되어 향상된 TCP 버전을 흔히 TLS(Transport Layer Security) 라고 부른다.

TLS는 기밀성, 데이터 무결성, 서버인증과 클라이언트 인증을 통해 TCP를 향상하여 보안 서비스를 제공한다.

TLS는 TCP를 보호하기 때문에 TCP 상에서 일어나는 어떠한 애플리케이션에든 사용될 수 있다.

 

TLS는 소켓을 사용하는 간단한 API를 제공하는데, TCP의 API와 유사하다.

TLS는 애플리케이션 계층에 존재하나 개발자의 관점에서는 보안 서비스로 강화된 TCP 서비스를 제공하는 트랜스포트 프로토콜이다.

 

8.6.1 TLS 개요: almost TLS

TLS를 이해하기 위해 TLS의 단순화된 버전인 almost-TLS를 먼저 설명한다.

almost-TLS 는 핸드셰이크, 키 유도, 데이터 전송이라는 세 단계로 되어 있다.

 

핸드셰이크

1. 클라이언트는 서버와 TCP 연결을 설립한다.
2. 서버가 진짜 서버인지 확인한다.
   • 클라이언트는 hello 메시지를 보내고, 서버는 CA로부터 인증된 인증서를 보내어 클라이언트는 인증서 내의 공개키가 서버의 것이라는 것을 믿을 수 있다.
3. TLS 세션에 필요한 모든 대칭키를 생성하기 위해 서버와 클라이언트가 사용할 주 비밀키(Master Secret, MS)를 생성하여 전송한다.
   • MS를 보낼 때, 서버의 공개키로 암호화하여 EMS(Encrypted Master Secret)를 만든다.
   • 서버는 자신의 개인키로 EMS를 복호화 하여 MS를 얻는다.
   • 즉, 둘은 둘만 아는 MS를 알게 된다.

 

키 유도

공유한 MS는 모든 암호화와 데이터 무결성 검사를 위한 대칭 세션키로 사용될 수 있으나 일반적으로 각각 다른 암호화 키를 사용하는 것이 좀 더 안전하다.

따라서 MS를 이용하여 4개의 키를 만든다.

• E(b) = 클라이언트가 서버에 보내는 데이터에 대한 세션 암호화 키
• M(b) = 클라이언트가 서버에 보내는 데이터에 대한 세션 HMAC(메시지 인증 코드) 키
• E(a) = 서버가 클라이언트에 보내는 데이터에 대한 세션 암호화 키
• M(a) = 서버가 클라이언트에 보내는 데이터에 대한 세션 HMAC(메시지 인증 코드) 키

이는 단순히 MS를 4개의 키를 쪼개어 이루어진다.

2개의 암호화 키는 데이터를 암호화하고, 2개의 HMAC 키는 데이터 무결성을 확인하는 데 사용된다.

 

데이터 전송

TCP는 바이트 스트림 프로토콜이므로, TLS가 애플리케이션 데이터를 끊임없이 암호화하고 암호화된 데이터를 TCP에 쉴 새 없이 전달하는 것이 자연스럽다.

그렇다면 HMAC은 언제 해야할까?

분명한건 전체 세션 시간 동안 전송된 모든 데이터의 무결성을 확인하는 일이 TCP 세션이 종료될 때까지 미뤄둘 수 없다는 것이다.

TLS는 데이터 스트림을 레코드로 쪼개고 각 레코드에 무결성 검사를 위한 HMAC을 덧붙인 후 이 레코드+HMAC을 암호화한다.

HMAC을 생성하기 위해 클라이언트는 레코드 데이터와 키 M(b)를 해시 함수에 넣는다.

레코드+HMAC 꾸러미를 암호화 하기위해 E(b) 를 사용하여 TCP로 전송한다.

 

그러나 만약 침입자가 TCP 세그먼트 스트림에서 스트림을 삽입, 삭제, 교환할 수 있다면 위 방법은 안전하지 않다.

예를들어, 침입자가 2개의 세그먼트 순서를 바꾼 후 TCP 세그먼트 번호까지 그에 맞게 변경하여 서버에 보낸다면 서버의 TLS는 문제 없이 이를 애플리케이션 계층에 넘겨준다.

 

TLS는 순서번호를 이용해서 이 문제를 해결한다.

클라이언트는 순서 번호 카운터를 유지하며 TLS 레코드를 보낼 때마다 하나씩 증가시킨다.

HMAC을 계산할 때 HMAC 키 M(b)와 레코드 데이터와 순서 번호를 합친 결과의 해시로 사용한다.

서버는 클라이언트의 순서번호를 추적해서 자신의 HMAC 계산을 할 때 적절한 순서 번호를 포함시켜 레코드의 데이터 무결성을 확인한다.

 

TLS 레코드

첫 세 필드는 암호화되지 않는다.

타입 필드는 핸드셰이크 메시지인지 데이터를 담은 메시지인지 나타낸다.

 

8.6.2 TLS의 완전한 개념 : TLS

이제 완전한 버전의 TLS를 살펴보자.

TLS 핸드셰이크

TLS는 서버와 클라이언트에게 특정 대칭키 알고리즘이나 공개키 알고리즘을 사용하도록 강제하지 않는다.

대신 핸드셰이크 과정에서 암호화 알고리즘을 합의하고, 서로에게 넌스를 보내 세션키를 생성한다.

시나리오

1. 클라이언트는 넌스와 함께 자신이 지원하는 암호화 알고리즘의 목록을 보낸다.
   • 넌스를 사용하는 이유는 만약 침입자가 모든 메시지를 엿들은 후 그대로 서버에게 보내게 된다면, 순서번호를 둔다고 하더라도 그것 또한 그대로 일치하므로 서버에서는 똑같은 메시지를 한번 더 들은 것으로 인지하기 때문이다.
   • 넌스를 포함하면 모든 메시지는 유일성을 가지게 되므로 보안에 안전해진다.
2. 목록으로부터 서버는 대칭키 알고리즘, 공개키 알고리즘, HMAC 키와 함께 HMAC 알고리즘을 선택한다.
3. 선택 결과와 인증서, 서버 넌스를 클라이언트에게 보낸다.
4. 클라이언트는 인증서를 확인하고 서버의 공개키를 알아낸 후 PMS(Pre-Master-Secret)을 생성한다. 이 PMS를 서버의 공개키로 암호화한 후 서버에게 보낸다.
5. 클라이언트와 서버는 같은 키 유도 함수를 사용하여 PMS와 넌스로부터 MS를 계산한다.
6. 이 MS는 2개의 암호화 키와 2개의 HMAC 키를 생성하기 위해 분할된다.
7. 이후 모든 메시지는 암호화되고 인증된다.
8. 클라이언트는 모든 핸드셰이크 메시지의 HMAC을 전송한다.
9. 서버는 모든 핸드셰이크 메시지의 HMAC을 전송한다.
   • 8, 9번 과정은 처음 암호화되지 않은 메시지에 대한 침입자의 수정을 대비해서 지금까지 주고 받은 메시지의 일치 불일치를 확인하는 것이다.

 

연결 종료

단순히 바로 TCP FIN 세그먼트를 보내 종료시키면 문제를 발생시킬 수도 있다.

침입자가 임의로 TCP FIN 세그먼트를 보내 종료시키는 절단 공격 문제가 발생한다.

이를 해결하기 위해 레코드의 타입 필드에 그 레코드가 TLS 세션 종료를 수행할 것인지를 표시한다.