Transcript chap8(3)

Chapter 8 목차
8.1 네트워크 보안이란 무엇인가?
8.2 암호학의 원리
8.3 메시지 무결성
8.4 종단점 인증
8.5 전자 메일의 보안
8.6 TCP 연결의 보안: SSL
8.7 네트워크 계층의 보안: IPsec
8.8 무선 랜의 보안
8.9 운영상 보안: 방화벽과 침입 방지 시스템
프로토콜 계층과 보안 프로토콜
Application
PGP, …
TCP
SSL
IP
IPsec
Link
802.11 무선 랜 보안
특정 계층에서 하나의 보안 프로토콜로 통일시킬 수는 없을까?
2
전자 메일 보안 목표
 메일의 내용을 다른 사람이 보지 못하도록
한다.(confidentiality)
 이 메일을 보낸 사람이 진짜 Alice인지
확인하고 싶다.(authentication)
 메일의 내용을 혹시 다른 사람이 변경하지
않았는지 확인하고 싶다.(integrity)
3
보안 전자 메일(메시지 암호화)
 Alice는 Bob에게 보안(confidential) 전자 메일을 보내려고 한다.
KS
m
KS
K ( .)
S
+
.
K B( )
K+
B
KS(m )
KS(m )
+
+
KB(KS )
.
K S( )
-
Internet
+
KB(KS )
KS
-
.
K B( )
KB-
Alice:
 대칭 키(KS)를 랜덤하게 생성한다.
 KS를 사용하여 메시지를 암호화 한다.
 Bob의 공개키로 KS 를 암호화한다.
 암호화된 메시지와 암호화된 대칭키를 Bob에게 보낸다.
m
보안 전자 메일(메시지 복호화)
KS
m
KS
K ( .)
S
+
.
K B( )
K+
B
KS(m )
KS(m )
+
+
KB(KS )
.
K S( )
-
Internet
+
KB(KS )
Bob:
 자신의 개인키로 암호화된 대칭키를 복호화한다.
 대칭키로 암호화된 메시지를 복호화한다.
KS
-
.
K B( )
KB-
m
보안 전자 메일(전자 서명)
• Alice는 송신자 인증 정보를 보내려고 한다.
m
H(.)
KA-
-
.
KA( )
-
-
KA(H(m))
KA(H(m))
+
+
KA
Internet
m
• Alice는 전자 서명 메시지를 보낸다.
• 원본 메시지와 함께 전자 서명을 전송한다.
m
+
.
KA( )
H(m )
compare
.
H( )
H(m )
보안 전자 메일(메시지 암호화 + 전자 서명)
• Alice는 전자 메일을 보낼 때 기밀성, 송신자 인증, 메시지 무결성을 보장
하고자 한다.
KAK
A(H(m))
KS
m
KA( )
H( )
.
.
+
.
K S( )
m
KS
+
.
K B( )
K+
B
+
Internet
+
KB(KS )
Alice는 세 개의 키를 사용: 자신의 개인키, Bob의 공개키,
랜덤하게 선택한 대칭키
PGP(Pretty Good Privacy)
 1991년 Philip Zimmerman이 만든 전자 메일의
사실상 표준 암호화 기법
 PGP는 공개 도메인에서 다운로드할 수 있다.
 PGP가 설치되면
소프트웨어는 공개키 쌍을 만든다.
 공개키는 웹 사이트에 공개되거나 공개키 서버에
놓인다.(공개키/사용자 이름)
 개인키는 비밀번호를 사용하여 보호

 어떤 사용자들은 키 서명 파티에 모여서 서로
키를 교환하기도 한다.
8
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가 거래하는 내용, 특히 지불 정보(예,신용카드
번호)를 다른 사람이 보지 않도록 해야 한다.
 Alice가 주문하는 내용을 침입자가 변경하자 않도록
해야 한다.
 Alice가 거래하는 서점이 정말 BBB가 맞는지 확인할
수 있어야 한다. Alice가 책값을 지불했을 때 BBB를
사칭하는 다른 사람이 받는 것은 아닐까?
 BBB는 책을 사는 사람이 진짜 Alice인지 확인할
필요가 있는가?

10
SSL: Secure Sockets Layer
 널리 사용되는 보안 프로토콜


거의 모든 브라우저와 웹
서버에서 지원한다.
https
 원래 Netscape에서 1993년
개발
 IETF 표준 프로토콜:


TLS(transport layer
security): RFC 2246
SSL v3.0의 약간의 변형
 보안 기능



 원래의 목표:




웹 상에서 전자상거래에
적용
암호화 (특별히 신용카드
번호)
웹 서버의 인증
클라이언트 인증(선택)
 모든 TCP 응용에서 사용
가능

Secure socket interface
기밀성(Confidentiality)
무결성(Integrity)
인증(Authentication)
11
SSL과 TCP/IP
Application
HTTP
SSL
TCP
TCP
IP
IP
일반적인 응용
SSL을 사용한 응용
• SSL은 응용 프로그램에 API를 제공한다.
• C와 Java SSL libraries/classes가 제공된다.
12
대칭키 설정
 키 설정(Key establishment)
 통신 개체 간에 공유하는 대칭키를 설정하는 절차
 키 관리(Key management)
 키 설정을 포함해서 키의 유지를 포함하는 일련의
절차(예, 오래된 키를 새로운 키로 변경 등)
 일정한 시간(session) 동안 사용하는 대칭키를
특별히 세션키(session key)라고 한다.

대칭키를 오랫동안 사용하면 공격자에게 노출될 수
있으므로 일정 기간만 사용하고 변경한다.
세션키 설정 방법
 서버 기반 키 분배
 공개키를 사용한 키 교환
 키 교환 알고리즘(Key agreement)
 Diffie-Hellman
서버 기반 키 분배
 신뢰할 수 있는 서버(TTP)가 세션키 생성하여
그것을 암호화하여 전송한다.
A1
A2
K1
Ek1(k15)
A6
K6
Ek15(m)
A5
K5
K2
TTP
Ek5(k15)
Key
source
A3
K3
A4
K4
공개키를 이용한 키 교환
 송신자는 수신자의 공개키(KB+)를 사용하여
세션키(KAB)를 암호화하여 전송한다.
m
KAB(m)
KB
+(K
Alice
AB)
KAB(m)
KB-(KAB)
Bob
키 교환(key agreement):
Diffie-Hellman 알고리즘
 Diffie-Hellman 키 교환 알고리즘은 두 개체가
서로 공유할 수 있는 비밀키를 생성하여 같이
사용할 수 있도록 한다.
Diffie-Hellman 키 교환 알고리즘
 공개된 값들:
 큰 값의 소수 p, generator g (primitive root of p)
 Alice의 비밀값: a, Bob의 비밀값: b
a
 A  B: g (mod p)
b
 B  A: g (mod p)
a b = gab (mod p)
ba
ab (mod p)
 Alice의 계산: (g ) = g
ab (mod p)
 대칭키 = g
 Bob의 계산: (g )
SSL의 절차
 Handshake: client는 server를 인증하고
key를 계산하는데 필요한 값들을 교환한다.
 Key 계산: client는 server는 비밀값을
사용하여 키를 계산한다.
 데이터 전송: 데이터는 레코드로 쪼개서
MAC을 첨부하고 암호화하여 전송한다.
 연결 종료: Special messages to securely
close connection
19
SSL: Handshake (1)
목적
1. 서버 인증
2. crypto algorithms의 협상
3. 키 설정
4. 클라이언트 인증(선택 사항)
20
SSL: Handshake (2)
1.
2.
3.
4.
5.
6.
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를 첨부하여
보낸다.
21
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
22
SSL: Handshaking (3)
단계 5와 6은 협상 과정에서 중간자 공격을 막기
위해 수행한다.
 Client의 crypto algorithm 중에는 강한
알고리즘과 약한 알고리즘이 있다.
 중간자 공격(Man-in-the middle)으로 알고리즘
명단에서 강한 알고리즘을 삭제할 수 있다.
 단계 5와 6의 메시지는 암호화된다.
23
SSL: Handshaking (4)
 Client와 sever의 random nonce를 사용하는 이유는?
 만약 Trudy가 Alice와 Bob 사이에 교환되는 모든
메시지를 복사했다고 하자.
 다음날, Trudy는 Bob과 TCP 연결을 설정하고 전날
Alice가 보냈던 똑같은 메시지를 순서대로 보낸다.
 Bob(온라인 서점)은 Alice가 같은 주문을 다시
하는 것으로 생각한다.
 해결책: Bob은 연결할 때 마다 새로운 random
nonce를 보낸다. 따라서 오늘의 키는 어제의 키와
다르게 된다.
 따라서 Trudy의 메시지는 Bob의 MAC 검증에서
실패하게 된다.
24
Key 계산
 한 개의 키로 모든 암호화를 하는 것은 나쁜 방법이다.
 MAC에서 사용하는 키와 암호화 키는 다른 것을 사용한다.
 4개의 키:
 Kc = client의 암호화 키(대칭키)
 Mc = client의 MAC key(비밀값)
 Ks = server의 암호화 키(대칭키)
 Ms = server의 MAC key(비밀값)
 Key들은 다음의 값을 사용하여 해쉬 함수의 출력값을
짤라서 사용한다.

Client의 nonce, sever의 nonce, master secret
25
SSL 레코드 구성
data
data
fragment
record
header
data
fragment
MAC
encrypted
data and MAC
record
header
MAC
encrypted
data and MAC
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)
26
SSL 레코드 형식
1 byte
content
type
2 bytes
3 bytes
SSL version
length
data
MAC
Data와 MAC은 대칭키 알고리즘으로 암호화
27
Type와 Seq number의 사용
encrypted
bob.com
28
SSL 예
RA
RB
{g, p, gB}
gA
RA
RB
{g, p, gB}
gA
여기서부터
암호화 시작
29
키 계산
 앞의 경우: {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)
30