http://www.kocw.net/home/search/kemView.do?kemId=1169634
컴퓨터네트워크
인터넷을 동작시키는 컴퓨터네트워크 프로토폴을 학습한다.
www.kocw.net
https://media.pearsoncmg.com/intl/ge/2021/cws/ge_kurose_compnetwork_8/cw/index.php
Companion Website | Computer Networking: A Top-Down Approach, Global Edition, 8/e
VideoNotes Video tutorials illustrating key concepts from the text.
media.pearsoncmg.com
Network security
OSI 7계층이나 TCP/IP 계층에서는 security layer를 찾아볼 수 없다. 보안에 대한 개념은 저러한 계층들을 설계할 때 아예 녹아들지 않은 것이다. 따라서 security layer란 없고 보안과 관련된 프로토콜들은 한 계층에 모여있지 않으며 여러 계층에 여러 프로토콜로서 각각 존재한다. 이번 장에서는 그러한 보안(network security)에 대해 배워볼 것이다. 과연 네트워크에서 보안은 어떻게 이루어지는 것일까.
What is network security?
네트워크 시큐리티는 다음의 것들을 요구한다.
confidentiality(기밀성)
- 오직 발신자와 수신자만 메시지 내용을 이해해야 한다.
- 보내는 사람은 메시지를 암호화하고 받는 사람은 메시지를 복호화한다.
authentication(인증)
- 발신자와 수신자가 서로의 신원을 확인할 수 있어야 한다.
- 발신자 혹은 수신자가 아닌 엉뚱한 사람이 발신자 혹은 수신자인 척할 때 우리는 그것이 가짜라는 것을 알아차려야 한다.
- 너 진짜 너 맞아? 나 진짜 나 맞아! 를 증명하는 것.
message integrity(메시지 무결성)
- 메시지가 중간에 변형되지 않았음을 확인할 수 있어야 한다.
- 만약 메시지의 변형을 감지 못한다면 잘못된 데이터를 가지고 서로 통신하는 꼴이므로 그래선 안 된다.
access and availability(접근 및 가용성)
- 서비스를 제공하는 사람은 24시간 언제나 서비스를 제공할 수 있어야 함.
Alice, Bob, Trudy
우리들의 네트워크 상황은 다음과 같은 그림으로 도식화할 수 있다. Alice와 Bob이 평화롭게 소통하고 있는 와중 Trudy가 패킷을 가로채거나 삭제하거나 내용을 변경하거나 하는 등등의 나쁜 짓을 하려는 상황이다. 우리는 아래 그림을 토대로 계속해서 암호화에 대해 배울 것이다.
암호화 개요
암호화란 발신자와 수신자만 메시지의 내용을 알아볼 수 있도록 메시지를 의미 없는 문자의 나열로 바꾸는 것을 뜻한다. 아래는 암호화의 개요를 나타낸 그림이며 이를 말로 간단히 표현하자면 다음과 같다. Alice가 plaintext를 암호화하여 ciphertext로 변환한 뒤 Bob에게 전송한다. 중간에 있는 Trudy가 해당 cipertext를 훔쳐보더라도 그 내용을 파악할 수가 없는 반면, Bob은 특정 알고리즘을 통해 ciphertext를 복호화하여 원본 메시지인 plaintext를 얻어낼 수 있다.
암호화/복호화 방식을 사용하면 네트워크 시큐리티의 요구 사항인 confidentiality(기밀성), authentication(인증), message integrity(메시지 무결성)를 충족시킬 수 있다.
암호화 방식에는 대칭 키 암호화와 공개 키 암호화가 있다.
Symmetric key cryptography(대칭 키 암호화)
Bob과 Alice가 같은(symmetric) 키를 사용하여 암호화를 진행하는 것을 대칭 키 암호화라 한다. 송신자가 대칭 키로 암호화하면 수신자는 송신자가 사용한 것과 동일한 대칭 키를 사용하여 복호화하는 방식이다. 좀 더 자세히 예시를 들자면, Alice가 대칭 키를 사용하여 메시지를 암호화한 뒤 Bob에게 전송한다. 이때 Trudy가 중간에서 메시지를 훔쳐보더라도 암호화된 메시지를 복호화할 대칭 키를 갖고 있지 않으니 Trudy는 해당 메시지가 무슨 내용인지 알 수가 없다. (기밀성 충족) 그렇게 메시지는 Bob에게 도착하고 Bob은 대칭 키를 사용하여 메시지를 복호화한다. Authentication(인증)과 Message integrity(메시지 무결성)는 이따 뒤에서 배울 MAC(Message Authentication Code)을 통해 충족시킨다. 일단 여기서는 메시지를 암호화하여 기밀성을 충족된다는 것만 알고 넘어가자.
이러한 대칭 키 암호화 방식은 공개 키 암호화 방식보다 빠르다.
그런데 여기 한 가지 문제점이 있다. 대칭 키 암호화 방식을 사용하려면 서로 같은 키를 가져야 하는데, 맨 처음 그 키를 교환할 때의 메시지 암호화는 무엇을 통해 할 수 있냐는 것이다. 다시 말해, 서로에게 대칭 키가 없는 태초의 순간에 대칭 키가 담긴 메시지를 암호화해서 보내야 하는데, 대칭 키가 없는데 메시지를 어떻게 암호화하느냐는 것이다.
그러게...... 어떻게 보안을 지키며 안전하게 symmetric key를 교환할 수 있지?
Public Key Cryptography(공개 키 암호화)
공개 키와 개인 키를 가지고 암호화/복호화를 진행하는 것을 뜻한다. 공개키는 말 그대로 누구나 다 볼 수 있게 외부에 공개하는 키이고 개인 키는 자기 자신만 가지고 있는, 공개하지 않는 키이다. Bob의 공개 키로 message를 암호화하면 Bob의 개인 키로 복호화할 수 있고, 그 반대로 Bob의 개인 키로 message를 암호화하면 Bob의 공개 키로 복호화할 수 있는 특징을 갖고 있다. 또, 공개 키 암호화 방식을 사용하면 대칭 키 암호화의 문제였던 Symmetric key 교환 문제를 해결할 수 있다.
공개 키 암호화 방식은 대칭 키 암호화 방식에 비해 시간이 오래 걸린다는 단점이 있다. 따라서 Symmetric key를 교환할 때 공개 키 암호화 방식을 사용하고 이후에는 대칭 키를 사용하여 메시지를 암호화/복호화하는 것이 보통이다.
Digital signatures
Digital signature는 위 그림에 나타나 있는 대칭 키 암호화 방식의 특징을 이용하여 네트워크상에서 본인이 정말 본인이 맞는지를 상대방에게 인증(authentication)하는 방법이다. 예를 들면 다음과 같다. Bob은 두 값이 담긴 메시지(m, Bob's_private_key(H(m)))를 보낸다. 여기서 m이란 그냥 메시지이고 Bob's_private_key(H(m))이란 특정 해시 함수에 m을 넣은 뒤 나온 결괏값을 Bob의 개인 키로 암호화한 것을 뜻한다. Alice는 메시지를 받아 m은 Bob이 Bob's_private_key(H(m))를 만들 때 사용한 것과 동일한 해시 함수에 넣어 H(m)을 만들고, Bob's_private_key(H(m))는 Bob의 공개 키를 사용하여 H(m)으로(H(m) = Bob's_public_key(Bob's_private_key(H(m))); 공개 키 암호화의 특징 참고) 만든다. 해시 함수에 m을 넣어 얻은 H(m)과 Bob의 공개 키를 사용하여 얻어낸 H(m)이 같다는 것은 상대방이 보낸 메시지가 정말 Bob의 개인 키로 암호화되어 있었다는 것을 뜻하고 Bob의 개인 키는 Bob만 가지고 있는 것이므로 상대방이 Bob이 맞는다는 것을 확인(인증)하게 된다. 이러한 방식으로 본인임을 인증(authentication)하는 것을 Digital signature라고 한다. 아래 그림은 상기 과정을 알기 쉽게 보여준다.
참고로 송수신 과정에서 메시지를 해시 함수에 넣어 메시지의 길이를 일정하게 고정하는 과정을 message digest(메시지 소화/메시지 요약; 길었던 메시지가 일정한 길이로 변환되니까.)라 한다.
공개 키 암호화 방식을 사용하여 symmetric key를 안전하게 교환하는 방법
Alice는 대칭 키가 담긴 메시지를 Bob의 공개 키로 암호화한 뒤 Bob에게 전송한다. 중간에서 Trudy가 해당 메시지를 훔쳐보더라도 Trudy는 Bob의 개인 키를 갖고 있지 않으므로 복호화할 수 없다. Bob은 전송받은 메시지를 본인의 개인 키로 복호화해 공개 키를 습득한다. 이로써 Alice와 Bob이 동일한 대칭 키를 안전하게 가질 수 있게 되었다.
여전한 문제...
공개 키 사용해서 대칭 키 교환하고 디지털 사인하고 뭐 digest 다 좋은데 어쨌든 이 방법을 사용하려면 Alice는 Bob의 Bob은 Alice의 공개 키가 필요하다. 만약 Bob이 Alice에게 Alice의 공개 키를 요청하여 Alice가 자신의 공개 키를 Bob에게 전송하는 도중 Trudy가 자신의 공개 키를 Alice의 공개 키인 척 바꿔치기해서 Bob에게 전달한다면(Digital signature는 public key가 필요하므로 아직 Digital signature를 사용할 수 없고 따라서 바꿔치기가 돼도 모름) Bob은 Alice와의 통신에서 Trudy의 공개 키를 사용하여 메시지를 암호화할 것이고 그 메시지는 Trudy가 중간에서 가로채 본인의 개인 키로 복호화할 수 있을 것이다. 이런 상황은 어떻게 방지할 수 있을까. 한마디로 누군가가 건네준 Public key를 어떻게 믿지?
Public key 인증서
믿을 만한 인증 기관(CA, Certificate Authority)이 있다. Alice가 인증 기관에 자신의 공개 키와 자신의 정보를 전달하면 인증 기관은 해당 정보를 확인하고 Alice가 이상한 녀석은 아닌지 확인한 뒤 문제가 없다면 Alice의 공개 키와 여러 정보가 들어있는 인증서를 만들고 해당 인증서를 인증 기관의 개인 키로 암호화한 뒤 Alice에게 발급한다. 나중에 Bob이 Alice에게 Alice의 공개 키를 요청할 때 Alice는 이 인증 기관의 개인 키로 암호화된 인증서를 Bob에게 전달한다. 만약 중간에 Trudy가 인증서를 가로채 인증 기관의 공개 키를 사용하여 인증서를 복호화한 뒤 인증서 정보를 변경하더라도 정작 인증 기관의 개인 키를 가지고 있지 않으니 다시 암호화할 수 없고 따라서 중간에 장난을 치더라도 모두가 이를 인지하게 된다. Bob은 문제없이 인증 기관의 개인 키로 암호화된 인증서를 받고 해당 인증서를 인증 기관의 공개 키를 통해 복호화하여 Alice의 공개 키와 Alice의 여러 정보를 얻는다. 이러한 과정을 통해 Alice의 Public key를 안전하게 받을 수 있으며, 만약 Alice가 Trudy와 같은 나쁜 녀석이었다면 인증 기관이 Alice에게 인증서를 발급해 주지 않았을 것이므로 Alice라는 사람 자체를 신용할 수도 있게 된다.
** 중간에 Trudy가 Alice의 인증서를 본인의 인증서로 바꿔치기하면 Trudy의 공개 키로 Alice와 Bob이 통신하는 것이 아닌가?
: 인증 기관이 Trudy에게 인증서를 발급해 줄 리 없으므로 인증서를 바꿔치기할 수는 없다.
** 인증 기관(CA)과 인증 기관의 공개 키(CA's public key)는 누구한테 받는 것일까
: 인증 기관과 인증 기관의 공개 키는 네트워크를 통해 누군가에게 동적으로 전달받는 것이 아니라 애초에 브라우저 안에 하드 코딩되어있기 때문에 인증 기관과 인증 기관의 공개 키는 믿을 수 있다.
SSL(Secure Sockets Layer), TLS(Transport Layer Security)
SSL과 TLS는 거의 같은 말이다. SSL이 버전 1.0이면 TLS는 버전 2.0 같은 느낌으로 TLS가 좀 더 최신의 것을 뜻한다. SSL 혹은 TLS는 TCP가 제공해주지 않는 보안을 Application에게 제공해 주는 라이브러리다. 따라서 Application을 만들 때 SSL library가 제공하는 interface를 사용하여 손쉽게 보안을 챙길 수 있다. 예를 들어, 우리가 앞에서 배운 인증서 요청하고 인증서 복호화해서 공개 키 추출하고 하는 일들을 SSL이 interface 형태로 제공해 주는 것이다. 만약 이러한 SSL이 없었다면 모든 Application 제작자들은 보안에 관련된 공통된 작업을 각자 반복해서 했을 것이다. SSL은 이러한 불편을 없애준다.
SSL은 TCP 계층 위에 있다. 따라서 SSL 사용 이전에 TCP connection(3-way handshaking)이 완료되어 있어야 한다. 아래 사진을 참고하자. (그렇다고 새로운 계층이 생긴 건 아니고 그냥 위치상 저 정도에 위치한다는 것)
HTTP는 Application 계층에 있는 프로토콜이므로 SSL을 사용할 수 있다. SSL을 사용하는 HTTP를 HTTPS(HTTP + SSL)라 부른다. 아래 그림을 참고하자.
HTTPS에서의 SSL 동작 - https://goodgid.github.io/TLS-SSL/
공개 키 방식은 대칭 키 방식에 비해 현저히 느리기 때문에 SSL은 공개 키와 대칭 키를 혼합하여 사용한다. 실제 내용을 담은 데이터는 대칭 키를 사용해 암호화하고 대칭 키를 공개 키 방식을 사용해 암호화한다. SSL 통신은 (핸드 셰이크 > 세션 > 세션 종료) 세 가지 단계를 거친다.
Step 1. (핸드 셰이크)
client Hello: server에 접근하기
- 클라이언트는 "랜덤한 데이터"와 "현재 지원할 수 있는 암호화 방식"을 서버에 전달한다.
Step 2. (핸드 셰이크)
server Hello: server의 응답
- 서버는 "인증서", "서버가 만든 랜덤한 데이터", "클라이언트가 보낸 현재 지원 가능한 암호화 방식 중 하나의 방식"을 클라이언트에게 전달한다.
Step 3. (핸드 셰이크)
client의 server 검증
- 클라이언트는 인증서를 CA의 공개키로 복호화한다. 정상적으로 복호화가 된다면 해당 인증서는 해당 CA의 개인 키로 암호화된 것이므로 CA가 해당 인증서를 보장하며, 따라서 서버를 신뢰할 수 있게 된다. 그리고 클라이언트가 전송한 랜덤 데이터와 서버가 전송한 랜덤 데이터를 조합하여 pre master secret key를 생성한다. 인증서를 복호화해서 얻은 서버의 공개 키로 pre master secret key를 암호화하여 서버에게로 전송한다.
Step 4. (핸드 셰이크)
클라이언트가 전송한 pre master secret key 복호화
- 서버는 클라이언트가 서버의 공개 키로 암호화한 pre master secret key를 복호화한다. 이제 클라이언트와 서버가 같은 pre master secret key를 갖게 되었다.
** 여기서 pre master secret key는 그대로 사용하진 않는다. 공개된 알고리즘을 사용하여 4가지 Key로 나눈다. 그 이유는 혹시라도 키가 유출될 때 피해를 최소화하기 위해서이다. 이는 아래와 같다.
- 클라이언트에서 서버로 가는 데이터를 암호화하는 용도
- 클라이언트에서 서버로 가는 데이터의 integrity를 체크하기 위한 용도
- 서버에서 클라이언트로 가는 데이터를 암호화하는 용도
- 서버에서 클라이언트로 가는 데이터의 integrity를 체크하기 위한 용도
Step 5. (세션)
서버와 클라이언트의 session key 생성 및 통신
- 서버와 클라이언트는 일련의 과정을 거쳐 master secret을 만들고 master secret을 이용하여 Sessin key를 만든다.
- 서버와 클라이언트는 해당 session key를 이용하여 데이터를 대칭 키 형식으로 암호화/복호화하며 통신한다.
Step 6. (세션 종료)
세션 종료
- 데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알린다. 이때 통신에서 사용한 대칭키(session key)를 폐기한다.
- 세션의 수립과 종료는 아주 짧은 시간에 일어나기 때문에 그동안 암호가 해독된다고 해도 이미 대칭 키는 폐기된 상태일 것이다.
** 동일한 동작을 다시 한번 설명하자면 다음과 같다. - https://crypto.stackexchange.com/questions/27131/differences-between-the-terms-pre-master-secret-master-secret-private-key
1. Alice가 "Alice가 지원할 수 있는 암호화 방식들"과 자신이 만든 랜덤한 값 "R_Alice"를 Bob에게 보낸다.
2. Bob이 자신의 "인증서"와 "Alice가 지원할 수 있는 암호화 방식 중 하나" 그리고 자신이 만든 랜덤한 값 "R_Bob"을 Alice에게 보낸다.
3. Alice는 S(pre master secret)를 생성하고(이 경우 위에서 본 것과 다르게 무작위로 생성됨) 그것을 Bob의 공개키로 암호화 한 뒤 Bob에게 보낸다.
4. Bob이 잘 받았음을 Alice에게 알린다.
4_1. Alice와 Bob은 각각 함수를 통해 K(master secret)를 생성한다. 이때 S와 R_Alice, R_Bob이 사용된다.
5. 4_1에서 만든 K를 특정 알고리즘을 통해 4가지 키로 만든 후 해당 키를 사용하여 암호화(대칭 키 방식)된 통신을 한다.
SSL 레코드
여러 프로토콜의 동작을 그들의 encapsulate를 보면 알 수 있듯 SSL의 동작도 SSL의 encapsulate를 보면 쉽게 파악할 수 있다. SSL은 Application layer에서 넘어온 message(data)를 단편화하고 압축한 뒤 MAC을 생성하여 data 부분 뒤에 붙인다. 그리고 data와 MAC을 함께 암호화하고 그것에 SSL 레코드 헤더를 붙여 record로 만든 뒤 Transport layer로 전달한다. 여기서 record란 응용 계층의 message나 전송 계층의 segment처럼 SSL에서의 data format을 말한다. record에서 가장 중요한 것은 MAC이다. MAC은 해시 함수에 (대칭 키, data, sequence, type)을 넣은 값을 뜻한다. (MAC = Hash(대칭 키, data, sequence, type)) MAC은 공격자가 중간에서 여러 장난을 치는 것을 방지해 주는데, 어떤 방식으로 어떤 장난을 방지해 주는지 알아보자.
MAC의 해시 함수에 들어가는 H(data)는 record의 data 변질을 감지할 수 있도록 도와준다. 따라서 H(data)는 데이터 무결성(data integrity)을 보장해 준다. 예를 들면 다음과 같다. Alice가 Bob에게 패킷을 전송한다. Trudy가 중간에서 record의 data를 변질시킨다. 수신자는 본인이 받은 record의 data를 해시 함수에 넣어 H(data)를 만들고 그렇게 만든 H(data)와 본래 record 안에 있던 H(data)를 비교한다. 서로의 값이 다르니 변질하였다고 판단한다. MAC의 해시 함수에 들어가는 나머지 값들(대칭 키, sequence, type)도 동일한 방식으로 동작하며 단지, 보장하는 대상만 다르다. H(대칭 키)는 authentication을 보장해 주며 sequence는 record의 순서를 보장해 준다. 마지막으로 type은 악의적인 TCP FIN을 막는 용도로 사용하는데, type이 1이면 아직 도착할 메시지들이 남았다는 뜻이고 type이 0이면 이제 다 보냈다는 뜻이다. 예를 들어, type이 1인데 TCP FIN이 오면 그것을 악의적인 TCP FIN으로 판단하여 drop하는 방식이다.
** MAC은 왜 해시 함수를 통해 만들어질까. 그냥 계속 하던대로 암호화 기법을 통해 만들면 안 될까?
: 해시 함수의 계산은 암호화 과정의 계산에 무척 간단하다. 따라서 해시가 암호화보다 빠르다. 어차피 MAC은 이후에 data와 함께 암호화가 될 텐데 생성할 때도 암호화를 통해 생성할 필요는 없다. 정리하자면 굳이 이중으로 암호화할 필요가 없고 암호화는 해시보다 느리기 때문에 MAC은 해시 함수를 통해 만들어진다.
'네트워크' 카테고리의 다른 글
| 컴퓨터 네트워크 기본 9 (2) | 2023.01.15 |
|---|---|
| 컴퓨터 네트워크 기본 8 (0) | 2023.01.11 |
| 컴퓨터 네트워크 기본 7 (0) | 2023.01.11 |
| 컴퓨터 네트워크 기본 6 (0) | 2023.01.09 |
| 컴퓨터 네트워크 기본 5 (0) | 2023.01.09 |