Secure Socket Layer

Socket layer “Socket layer”: 응용 계층과 수송 계층의 사이에 위치 SSL은 HTTP (application)와 TCP (transport) 사이에서 동작한다. application transport network link physical User Socket “layer” OS NIC

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

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

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

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

단순화 된 SSL Protocol Can we talk?, cipher list, RA Certificate, cipher, RB {S}Bob, E(h(msgs,CLNT,K),K) h(msgs,SRVR,K) Data protected with key K Bob Alice S is pre-master secret K = S,RA,RB 으로부터 만들어진 암호화 키 msgs = all previous messages CLNT and SRVR are constants

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를 사용하여 암호화와 MAC key를 계산한다. C: 모든 handshake 메시지에 MAC를 첨부하여 보낸다. S: 모든 handshake 메시지에 MAC를 첨부하여 보낸다.

crypto algorithms의 협상 Cipher list 암호 알고리즘 MAC 알고리즘 RC4, RC2, DES, 3DES, DES40, IDEA MAC 알고리즘 MD5, SHA-1 암호 알고리즘 유형 (stream or block) 해쉬 크기 MD5 : 0 or 16 바이트, SHA-1: 20 바이트 IV 크기 CBC 암호화를 위한 IV 크기

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

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

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

SSL 인증 Alice는 Bob을 인증하지만 Bob은 Alice을 인증하지 못한다. 어떻게 client는 server를 인증하는가? 왜 server는 client를 인증하지 않는가? 원하면, 상호 인증도 가능하다: Bob은 메시지 2에 client의 인증서를 요청할 수 있다. 이것은 client가 인증서를 가질 것을 요구한다. 대신 server는 client의 (암호화된) 암호를 요구할 수 있다.