Chapter 8 목차 8.1 네트워크 보안이란 무엇인가? 8.2 암호학의 원리 8.3 메시지 무결성 8.4 종단점 인증 8.5 전자 메일의 보안 8.6 TCP 연결의 보안: SSL 8.7 네트워크 계층의 보안: IPsec 8.8 무선 랜의 보안 8.9 운영상 보안: 방화벽과 침입 방지 시스템

프로토콜 계층과 보안 프로토콜 특정 계층에서 하나의 보안 프로토콜로 통일시킬 수는 없을까? Application TCP IP Link PGP, … SSL IPsec 802.11 무선 랜 보안 특정 계층에서 하나의 보안 프로토콜로 통일시킬 수는 없을까?

전자 메일 보안 목표 메일의 내용을 다른 사람이 보지 못하도록 한다.(confidentiality) 이 메일을 보낸 사람이 진짜 Alice인지 확인하고 싶다.(authentication) 메일의 내용을 혹시 다른 사람이 변경하지 않았는지 확인하고 싶다.(integrity)

. 보안 전자 메일(메시지 암호화) - Alice는 Bob에게 보안(confidential) 전자 메일을 보내려고 한다. m KS( ) . KB( ) + - KS(m ) KB(KS ) m KS KB Internet Alice: 대칭 키(KS)를 랜덤하게 생성한다. KS를 사용하여 메시지를 암호화 한다. Bob의 공개키로 KS 를 암호화한다. 암호화된 메시지와 암호화된 대칭키를 Bob에게 보낸다.

. 보안 전자 메일(메시지 복호화) - m KS + Bob: 자신의 개인키로 암호화된 대칭키를 복호화한다. KB( ) + - KS(m ) KB(KS ) m KS KB Internet Bob: 자신의 개인키로 암호화된 대칭키를 복호화한다. 대칭키로 암호화된 메시지를 복호화한다.

. 보안 전자 메일(전자 서명) + Alice는 송신자 인증 정보를 보내려고 한다. - m H( ) . KA( ) - + H(m ) KA(H(m)) m KA Internet compare Alice는 전자 서명 메시지를 보낸다. 원본 메시지와 함께 전자 서명을 전송한다.

. 보안 전자 메일(메시지 암호화 + 전자 서명) + Alice는 전자 메일을 보낼 때 기밀성, 송신자 인증, 메시지 무결성을 보장 하고자 한다. H( ) . KA( ) - + KA(H(m)) m KA KS( ) KB( ) KB(KS ) KS KB Internet Alice는 세 개의 키를 사용: 자신의 개인키, Bob의 공개키, 랜덤하게 선택한 대칭키

PGP(Pretty Good Privacy) 1991년 Philip Zimmerman이 만든 전자 메일의 사실상 표준 암호화 기법 PGP는 공개 도메인에서 다운로드할 수 있다. PGP가 설치되면 소프트웨어는 공개키 쌍을 만든다. 공개키는 웹 사이트에 공개되거나 공개키 서버에 놓인다.(공개키/사용자 이름) 개인키는 비밀번호를 사용하여 보호 어떤 사용자들은 키 서명 파티에 모여서 서로 키를 교환하기도 한다.

Chapter 8 목차 8.1 네트워크 보안이란 무엇인가? 8.2 암호학의 원리 8.3 메시지 무결성 8.4 종단점 인증 8.5 전자 메일의 보안 8.6 TCP 연결의 보안: SSL 8.7 네트워크 계층의 보안: IPsec 8.8 무선 랜의 보안 8.9 운영상 보안: 방화벽과 침입 방지 시스템

웹상에서 상거래에서 요구사항 만약 Alice가 BBB라는 온라인 책방에서 책을 구입할 때, Alice가 거래하는 서점이 정말 BBB가 맞는지 확인할 수 있어야 한다. Alice가 책값을 지불했을 때 BBB를 사칭하는 다른 사람이 받는 것은 아닐까? BBB는 책을 사는 사람이 진짜 Alice인지 확인할 필요가 있는가?

SSL: Secure Sockets Layer 널리 사용되는 보안 프로토콜 거의 모든 브라우저와 웹 서버에서 지원한다. https 원래 Netscape에서 1993년 개발 IETF 표준 프로토콜: TLS(transport layer security): RFC 2246 SSL v3.0의 약간의 변형 보안 기능 기밀성(Confidentiality) 무결성(Integrity) 인증(Authentication) 원래의 목표: 웹 상에서 전자상거래에 적용 암호화 (특별히 신용카드 번호) 웹 서버의 인증 클라이언트 인증(선택) 모든 TCP 응용에서 사용 가능 Secure socket interface

SSL과 TCP/IP HTTP Application SSL TCP TCP IP IP 일반적인 응용 SSL을 사용한 응용 SSL은 응용 프로그램에 API를 제공한다. C와 Java SSL libraries/classes가 제공된다.

대칭키 설정 키 설정(Key establishment) 키 관리(Key management) 통신 개체 간에 공유하는 대칭키를 설정하는 절차 키 관리(Key management) 키 설정을 포함해서 키의 유지를 포함하는 일련의 절차(예, 오래된 키를 새로운 키로 변경 등) 일정한 시간(session) 동안 사용하는 대칭키를 특별히 세션키(session key)라고 한다. 대칭키를 오랫동안 사용하면 공격자에게 노출될 수 있으므로 일정 기간만 사용하고 변경한다.

세션키 설정 방법 서버 기반 키 분배 공개키를 사용한 키 교환 키 교환 알고리즘(Key agreement) Diffie-Hellman

서버 기반 키 분배 신뢰할 수 있는 서버(TTP)가 세션키 생성하여 그것을 암호화하여 전송한다. A1 A2 K1 K2 TTP Ek1(k15) A6 Key source A3 Ek15(m) K6 K3 Ek5(k15) A5 A4 K5 K4

공개키를 이용한 키 교환 송신자는 수신자의 공개키(KB+)를 사용하여 세션키(KAB)를 암호화하여 전송한다. KAB(m) m Bob Alice

키 교환(key agreement): Diffie-Hellman 알고리즘

Diffie-Hellman 키 교환 알고리즘 공개된 값들: 큰 값의 소수 p, generator g (primitive root of p) Alice의 비밀값: a, Bob의 비밀값: b A  B: ga (mod p) B  A: gb (mod p) Bob의 계산: (ga)b = gab (mod p) Alice의 계산: (gb)a = gab (mod p) 대칭키 = gab (mod p)

SSL의 절차 Handshake: client는 server를 인증하고 key를 계산하는데 필요한 값들을 교환한다. Key 계산: client는 server는 비밀값을 사용하여 키를 계산한다. 데이터 전송: 데이터는 레코드로 쪼개서 MAC을 첨부하고 암호화하여 전송한다. 연결 종료: Special messages to securely close connection

SSL: Handshake (1) 목적 서버 인증 crypto algorithms의 협상 키 설정 클라이언트 인증(선택 사항)

SSL: Handshake (2) C -> S: crypto algorithms의 종류, client nonce (Rc) S -> C: 선택한 알고리즘 + 인증서 + server nonce (Rs) C: 인증서(certificate)를 검증, server의 공개키를 추출, pre_master_secret을 생성하여 server의 공개키로 암호화하여 server에 보낸다. C와 S: 각자 pre_master_secret과 nonces를 사용하여 encryption과 MAC key를 계산한다. C: 모든 handshake 메시지에 MAC를 첨부하여 보낸다. S: 모든 handshake 메시지에 MAC를 첨부하여 보낸다.

crypto algorithms의 협상 Cipher spec Cipher Algorithm (RC4, RC2, DES, 3DES, DES40, IDEA) MAC Algorithm (MD5, SHA-1) Cipher Type (stream or block) Is Exportable (true or false) Hash size (0 or 16 bytes for MD5, 20 bytes for SHA-1) IV size: IV size for Cipher Block Chaining(CBC) encryption

SSL: Handshaking (3) 단계 5와 6은 협상 과정에서 중간자 공격을 막기 위해 수행한다. Client의 crypto algorithm 중에는 강한 알고리즘과 약한 알고리즘이 있다. 중간자 공격(Man-in-the middle)으로 알고리즘 명단에서 강한 알고리즘을 삭제할 수 있다. 단계 5와 6의 메시지는 암호화된다.

SSL: Handshaking (4) Client와 sever의 random nonce를 사용하는 이유는? 만약 Trudy가 Alice와 Bob 사이에 교환되는 모든 메시지를 복사했다고 하자. 다음날, Trudy는 Bob과 TCP 연결을 설정하고 전날 Alice가 보냈던 똑같은 메시지를 순서대로 보낸다. Bob(온라인 서점)은 Alice가 같은 주문을 다시 하는 것으로 생각한다. 해결책: Bob은 연결할 때 마다 새로운 random nonce를 보낸다. 따라서 오늘의 키는 어제의 키와 다르게 된다. 따라서 Trudy의 메시지는 Bob의 MAC 검증에서 실패하게 된다.

Key 계산 한 개의 키로 모든 암호화를 하는 것은 나쁜 방법이다. 4개의 키: MAC에서 사용하는 키와 암호화 키는 다른 것을 사용한다. 4개의 키: Kc = client의 암호화 키(대칭키) Mc = client의 MAC key(비밀값) Ks = server의 암호화 키(대칭키) Ms = server의 MAC key(비밀값) Key들은 다음의 값을 사용하여 해쉬 함수의 출력값을 짤라서 사용한다. Client의 nonce, sever의 nonce, master secret

SSL 레코드 구성 data MAC fragment encrypted data and MAC record header record header: {content type; version; length} MAC: MAC(Mx, sequence number||type||data) Note: no sequence number field Fragment: each SSL fragment 214 bytes (~16 Kbytes)

SSL 레코드 형식 content type SSL version length MAC data 1 byte 2 bytes Data와 MAC은 대칭키 알고리즘으로 암호화

Type와 Seq number의 사용 hello certificate, nonce KB+(MS) = EMS type 0, seq 1, data type 0, seq 2, data type 0, seq 3, data type 1, seq 4, close type 1, seq 2, close bob.com encrypted

SSL 예 RA RA RB RB {g, p, gB} {g, p, gB} gA gA 여기서부터 암호화 시작 handshake: ClientHello (RA) handshake: ServerHello (RB) handshake: Certificate {g, p, gB} handshake: ServerHelloDone handshake: ClientKeyExchange {gA} ChangeCipherSpec Finished application_data Alert: warning, close_notify RA RB RB {g, p, gB} {g, p, gB} gA gA 여기서부터 암호화 시작

키 계산 앞의 경우: {g, p, gA, gB}에서 pre-master secret 계산 Pre-master secret에서 master secret 계산 Client nonce(RA), server nonce(RB), master secret에서 다음의 4개의 key와 2개의 IV값을 계산한다. client MAC key server MAC key client encryption key server encryption key client initialization vector (IV) server initialization vector (IV)