이석복 네트워크 (22)network security, public key

===

http://ocw.hanyang.ac.kr/?course=8439

 

===

이번시간은 Network Security를 얘기하기 위한 Security background

다음 시간에 ssl, https, firewall

 

===

network security의 요구조건들

 

confidentiality : 비밀

결국 통신이라는 것은 sender와 receiver사이의 메시지 교환인데

얘네들의 주고받는 메시지가 제3자가 알 수 없어야한다

둘만 알아볼 수 있어야 하고 나머지 사람들은 몰라야 한다

보낼 때 암호화 등의 기법을 사용하면 된다

 

authentication : 인증

지금 말하고 있는 사람이 정말 내가 생각하는 그 사람인지에 대한 확신해야 한다

실생활에선 얼굴 보고 아는데,

네트워크 상황에선 얼굴이 안보여 어떻게 알거야

 

message integrity : 

보내는 사람이 메시지 그대로 변화하지 않고 받아야 한다. 확신을 해야해 중간에 누군가 메시지를 변형한 게 아닌지

 

access and availability : 

network 특화 얘기, 서비스를 제공하는 사람은 24시간 내내 사용자들에게 서비스를 제공할 수 있어야 한다 - 서비스 자체를 못하게 하는 공격자들로부터 방어해야한다

 

===

이 4가지가 지금까지 배운 app layer, tr.... 등 protocol stack에 하나도 포함돼 있지 않다

1970년대 초반에 TCP/IP protocol stack을 디자인할 때 대상자체가 학교, 학자, 연구소.. 여서

attack들에 개념이 없었다

 

컴퓨터 철학으로 녹아들어서 디자인 돼 있었으면 아주 좋았을텐데 예상못했다

 

지금은 새로운 공격들이 발생할 때마다 그때그때 즉흥적으로 patch를 붙이는 식으로 밴드가 붙어있는 상황

 

머지않은 미래에 새로운 procotol로 바뀌면서 security라는 개념이 녹아들어간 디자인으로 변형돼야 한다

현재는 안 들어있어

 

===

암호학 이야기할 때 항상 나오는 친구들

Alice, Bob 착한 사람  --웹브라우저와 웹서버, 클라이언트/서버

Trudy 나쁜 사람 자꾸 훔쳐보려하고..  --얘가 특별한 사람이 아니라 그냥 wifi쓸 때 wireshark키면 진행되는 통신 다 보여, 현재 인터넷 상황은 이런 모니터링에 노출돼 있어

 

우리 목표 : Trudy가 존재함에도 Alice와 Bob이 4가지 요소를 보장하면서 메시지를 주고받을 수 있게 만드는 것

secure한 channel을 제공하는게 할 일

 

===

wireshark로

IP패킷

이더넷 프레임 다 보여

IP패킷을 예로

헤더부분에 src, dst있어. 친구들이 어디 접속하는지 다 보여

wireshark가 DATA도 보여줘 - IP패킷의 DATA는 TCP segment, 헤더 다보이고, segment의 데이터 부분인 app메시지도 그냥 plain 텍스트로 적어놓으면 다 보인다

 

HTTPS를 쓰면 저 segment의 DATA부분인 app메시지 부분은 암호화돼서 안보인다(다음 시간)

하지만 최소한 어디에 접속하는진(IP패킷의 dst) 다 보여

여러분의 인터넷 활동이 다 모니터링 된다

 

===

내 활동 모르게 하고싶다면?

TOR : The Onion Routing

익명성 애플리케이션 툴(쉽게 다운 받아서 쓸 수 있다, 유명한 것)

이걸 쓰면 어느 서버에 접근하는지는 아무도 모르게 해준다

 

어떻게?

보통 클라이언트에서 서버로 직접 접근 하는데, 

전 세계에 TOR에 속하는 relay node들이 5천개 이상 존재하는데

랜덤하게 3개를 선택해서

이런 방식으로 접근하게 한다

모니터링 해보면

src

dst가 저 중간에 거치는 애가 되기 때문에 최종 목적지 자체가 계속 감춰지는 식

 

근데 너무 느리다, 직항이랑 아프리남미유럽 이렇게 거치는 것 비교하면 엄청 느리다. 보통 테러리스트들이 서로간에 교신할 때 쓴다. 걔넨 FBI, CIA한테 추적을 받아 100% 모니터링 당해

 

===

그래서 익명성을 추구하면서 빠른 속도를 내도록 해보자 하는 연구를 다들 하고 있다(이석복 연구실)

또

이거 warning 메시지보는 순간 이게 어떻게 가능한거지?의문을 품어야한다

이 메시지가 http를 사용해서(웹브라우저니까 http를 사용) 웹브라우저로 온건데

http protocol은 tcp를 기반으로 하는데

나랑 저 메시지를 보낸 사람이랑 TCP connection이 있어야할 것 아냐

저 warning보낸 사람이랑 나랑 안맺었을건데?

 

===

일단

 

누군가 google이라고 치면 google에 접근하는걸 알고 경고를 보낸 사람이 있을텐데

걘 어디에 자리잡고 있길래 안거야

 

high level하게 얘기하면

우리나라 같은 경우 정부에서 차단을 하고자 하는 사이트들 리스트를 만든다

우리나라에서 국외로 나가는 통로들이 있는데

SKT면 SKT게이트웨이 중에 해외 AT&T랑 연결된 그 위치

그 라우터에다가 app stack까지 씌워서 저 list를 준다

그러면 저 블랙리스트에 해당하는 서버들에 접근하는 유저에 대해서 경고장을 날리는 방식

 

===

그럼 유저는 포기 안하고 해외에 존재하는 open proxy, public proxy, private proxy를 돈주고 쓰든지 해서 저기로 우회해서 접근한대(이게 뭔지 아래에 써있다)

아까 그 SKT라우터를 안거치고 저렇게 해서 간다

우리나라는 이게 가능해

해외에 존재하는 proxy들은 그냥 냅뒀어(블랙리스트 안집어넣었어)

 

===

근데 proxy로 우회하는거 막을 수 있어 기술적으로

왜? 저 proxy서버의 IP는 모든 사람이 다 안다 그럼 정부도 알아

proxy서버까지 블랙리스트에 집어넣으면 이것도 막혀(proxy서버가 별게 아니고 proxy서버로 접근하는거구나 그 다음에 뭔가 또 있겠지)

 

우리나라 정부는 이렇게까진 안함

북한 중국 이집트는 막는대 

중국은 firewall자체가 엄격하게, 페북, 구글, proxy, TOR 다 막아놨다. 북한은 더 심해  --이게 firewall이구나

 

===

warning메시지(이거 HTML페이지) TCP connection 걔랑 맺은게 아닌데 그거 뭔데!

DNS로 구글의 IP로 translation하고 TCP connection이 구글이랑 맺어질텐데

구글에서 warning메시지가 날아온것도 아니고!

 

wireshark보면 어떤식으로 동작하는지 알 수 있다

실제로 이때 어떤 패킷을 주고받는지

->

웹브라우저 구글쩜컴치면 로컬DNS가서 IP를 받아오고(6.6.6.6라고 치면)

제일 처음에 TCP connection 맺어야 하고

- 구글에 SYN패킷, src는 나, dst는 구글(6.6.6.6)

그 다음 HTTP request

 

 

===

가장 손 쉽게 차단하는게 드랍시키는 것. 아까

여기서 나가는 패킷의 트래픽의 dst를 보고 6.6.6.6이면 드랍시킨다

그러면 TCP connection이 안맺어지고, 웹브라우저엔?? 에러가 뜬다

404 not found는 이미 TCP connection 맺어져 있고 다음이야

 

근데 이게 제일 쉬울텐데 이렇게 안하는 이유는 사용자들이 네트워크 문제라고 생각할 수 있다

정부가 시민들에게 주고싶은 메시지인 경고를 보내길 원해

warning.html파일이 여러분에게 전달되게 만들고 싶어

 

===

wireshark 패킷보고 유추한 것

html파일 주려면 http주고받는게 필요하다

-> TCP연결이 필요하다

-> TCP연결 다 하면 부담가

-> dst가 6.6.6.6으로 나가는 건 일단 내보내

-> 구글이 TCP SYN받으면 SYN ACK이 온다

-> 커넥션 맺어짐, 이때 브라우저가 HTTP request를 보낼 수 있어

-> HTTP request안에는 필드들이있고 가장 중요한게 host라는 필드에 브라우저 종류, www쩜구글쩜컴이라는 host네임이 적혀서 애플리케이션 메세지로 나간다

->그럼 SKT의 나가는 라우터는 HTTP request만 본다. 여기서 host필드가 자기가 필터링하고자 하는 리스트에 해당하는게 있으면, (TCP SYN은 http 메세지 아니니까 통과시키고 connection 맺게한 다음) http request보고 딱 걸리면, response를  자기가 만들어서 보낸다 response의 데이터부분에 warning.html을 싣는다

->response메시지는 IP패킷에 담는데 dst는 구글에 접속하려고 했던 나, src는 구글IP로(거짓말로)

->HTTP request를 받는순간 자기가 구글인척하면서 src에 구글 IP를 집어넣고 warning.html을 담은 HTTP response메시지를 보낸다

->그럼 클라이언트는 방금 생성한 TCP connection통해서 들어온거라서 내가 요청한 index.html파일 온거구나 해서 warning.html을 딱 띄운다

 

그럼 구글은 TCP connection형성하고 더이상 안오니까 timeout돼서 connection없어짐

 

구글에 접속하려고 했던 나는 구글이랑 왔다갔다 했던 정보가 있지만 딸랑 warning.html만 띄워지고 TCP쪽에서 서로간에 부조화가 일어나면서 끊어짐

 

===

우리나라에서 검열하는게 IP주소를 보고 검열하는게 아니라 HTTP request의 host를 본다

 

라우터긴한데 app layer까지 동작하는 필터링 기능이 있는 것(firewall이라 불린다, 얘는 다 보고있다)

 

===

Alice & Bob 이 메세지를 주고 받고 싶다

confidentiality를 위해 trudy가 봐도 알 수 없게 plaintext를 ciphertext로 바꿔줘야해 -> 암호화encryption

암호화하는 과정에 필요한 요소는 key

 

Alice가 보낼 때 plain text를 암호화 key로 한번 적용시켜주면 ciphertext가 된다

ciphertext를 Bob이 갖고 있는 key로 decryption되게하면 plain text가 나오는 개념

 

Ka(m) : alice의 key로 암호화한 ciphertext

Kb(Ka(m)) : Bob의 key로 적용시켜서 해독한

 

===

암호화하는 기법이 크게 두가지

Symmetric(대칭) key방식

암호화하고 해독하는 key가 같다, 대칭적

연산 빠름

문제는 같은 키를 공유해야한다 : 사전에 미리 만나거나, 뭔가 비밀스러운 채널을 통해 키를 공유 했어야 해, 인터넷 상에서 쉬운 일이 아니다 원래 알던 친구도 아니고

이걸 고대에서부터 고민했다

 

이걸 우리 약간 이전세대 1970년대 초반에 해결함

 

===

Diffie와 Hellman이라는 사람이 혁신적인 새로운 암호화 기법 생각해냄

사전에 미리 만나지 않아도 비밀스러운 메세지를 전달하는 방법

 

모든 사람이 각자 두가지 종류의 키를 갖는다

A라는 사람을 예로 들어

하나는 모든 사람에게 공개한 A의 public key

하나는 A만 알고 있는 private key

 

B가 A에게 보내고자 하는 메시지가 있을 때

A의 Public Key는 공개 돼 있으니까, 그걸로 암호화하고

그거를 풀수 있는건 오로지 A의 private key

 

Diffie&Hellman은 어떻게 하면 저걸 수학적으로 구현할 수 있는지는 안했고 저 개념만

 

===

학계에서 이걸 구현하기 위한 수학적인 알고리즘을 찾다가

3년 뒤에 MIT교수 R이란 사람 S란 사람 A란 사람 세 교수가 발표함 = RSA라는 알고리즘

(사실 영국 정보부에서 이미 개발해서 쓰고 있었던건데 국가 기밀이라서 발표를 안하고, RSA 세 사람만 돈 많이 벌었다)

 

===

특징

어떤 키를 먼저 적용시키든 간에 동일한 결과가 나온다 - 유용하대

 

===

단점 : 수학적인 연산, 지수승이 올라가는, 대칭키보다 CPU가 백배 천재 일한다

그래서 메시지 전체를 암호화할때는 public key방식의 암호화가 쓰이지 않고 

 

시메트릭키 방식은 일단 그게 있으면 만사오케이니까

시메트릭키의 키를 비밀스럽게 전달할 때 public key방식을 사용하고

시메트릭키를 생성한 이후엔 메세지 자체는 시메트릭키를 사용해서 암호화

혼합해서 사용

 

===

Authentication

내가 이야기하고 있는 사람이 내가 생각하는 그 사람이 맞는가

주장만 하면 안된다 Trudy도 주장은 할 수 있어

트루디가 그대로 재사용할 수 있는것은 인증으로 사용할 수 없어

password를 집어넣는다고 해도 Trudy가 그대로 사용할 수 있으면 안돼

 

Trudy는 둘이 주고 받는 메시지를 모니터랑 할 수 있어. 그 모니터링 한 결과를 갖고 똑같이 사용할 수 있으면 안된다

 

===

그래서

나 앨리스야

증명해봐 하고 challenge로 랜덤넘버를 보냄

앨리스는 랜덤넘버를 둘 사이에 공유한 키로 암호화해서 보내면

밥이 복호화 시켰을 때 R이 나오면 된다

 

이 방식은 결국 키가 필요해. 둘 사이에 키를 어떻게 만드는지가 문제

 

===

흔히 비밀키 공유에 대한 문제가 없는 public 방식을 사용해서 인증을 한다

나앨리스야

검증해봐 랜덤넘버

앨리스가 자기 프라이빗키로 R을 암호화해서보내고

밥이 앨리스의 퍼블릭키로 풀어서 R이 나오면 된다

 

===

message integrity

메시지가 중간에 변형되지 않았느냐 = 보낸 사람이 작성한 그대로인가

 

일상 생활에서도 중요한 문서는 봉투에 담고 밀봉, 도장 = 열리지 않았을 뿐만 아니라 봉인한 사람은 도장으로 알 수 있게 서명을 남김

 

여기서도 public key cryptograph를 활용해서 메시지가 중간에 변형되지 않았단 것을 증명한다

Bob이 Alice한테 m이란 메시지를 보낼때 Bob의 private key로 encryption하면

원래 메시지 + encryption한 메세지

Alice는 public key로 적용시키면 m이 나와 => 원래 메시지가 나온단 것은 Bob의 private key로 암호화했다는 말이고 private key는 Bob밖에 없어서 메시지가 중간에 변형되지 않았다는 걸 해준다

▽퍼->프, 프->퍼 순이어야 되네, 프+프 하면 복호화안되네

 

메세지가 너무 길면 암호화하는데 오래걸려서 보통 메시지 전체를 하는게 아니고 메세지를 우선 hash를 통과한 hash값, 이걸 Message digests(음식물소화), 메시지를 소화시켰다

을 암호화해서 사용한다

 

방금 했던 자기자신의 private key로 암호화하는 것을 sign이라고 한다 = digital signature

 

Message digests자체를 signing한걸 사용한다

 

===

메세지를 보내면서 intigrity를 증명하기 위해

메시지의 hash값을 private key로 signing해서 보내면

 

받는 사람은 메시지도 받고 저것도 받고

그럼 메시지를 hash통과시킨 값이랑

public key로 푼 값이랑 비교해서 같냐 해서 확인하는 방식이다

 

===

보니까 Pulbic key cryptography 여기저기에 쓰이네 유용하다

개념 다시 얘기하면

A가 B한테 비밀 메시지를 보낼 때 B의 퍼블릭키를 갖고와서 암호화, 그럼 B가 풀 수 있다

근데??

널려있어서 가져온 B의 public key가 다른 사람것이라면? 그럼 그 다른 사람이 풀 수 있다

 

public key가 B것인지를 확신할 수 있어야해 이걸 어떻게 할거야? public key를 못 믿겠어 이게 가장 중요한 문제다

현재 public key 시스템에선 public key를 인증하는 인증서라는 것을 등장시켜서 해결한다

 

===

믿을만한 공인 기관이 발행한 인증서를 각자 갖고 다니는 것

 

인증서엔

이름(A의)

public key(A의)

이거 적혀있다 인증서가 별게 아니다

이게 뭘로 증명돼 있냐?인증기관의 private key로 암호화돼서 있다 그렇게 돼 있으면 그 인증서는 인증기관이 만든것

그럼 우리는 인증기관의 public key를 갖고 있는 것

이걸로 어 풀리네 하면 인증기관이 만든게 맞고 그게 A의 public key가 되는 것

 

그럼 인증 기관의 public key는 어떻게 믿어?

우리가 쓰는 브라우저에 크롬, 파폭.. 아예 처음부터 release될 때 이게 들어가 있다 믿을 수 밖에 없게. 하드코딩 돼 있다

 

우리나라는 금결원의 key

국제적으로는 뭐 어떤 베리싸인?뭐그거

 

public key시스템은 이건 믿고 시작해야돼. 이걸 믿어야 trust가 형성돼

 

===

근데 https, ssl표준 자체는 일반 유저들이 이걸(▽저 인증기관의 public key를 말하는 듯?) 들고 다니는건 아니다(내일 할 것)

'이런 인증서'는 서버들이 들고다니면서 하는 것

우리나라가 구조가 좀 이상한 것. 전 세계 어딜가도 이걸 유저가 들고 다니지 않아 서버측에서 갖고 있어. 결국에는 우리나라도 바뀔 것 순리대로