SSL 보안 WEB Security.

SSL 보안 WEB Security

목 차 Web 보안 개요 SSL/ TLS SET

1. Web 보안 개요 배경 현재 많은 기업과 정부 기관, 개인들까지도 웹사이트를 소유
현재 많은 기업과 정부 기관, 개인들까지도 웹사이트를 소유 인터넷 접속을 이용하는 개인이나 회사의 수가 급속히 증가 전자상거래를 위한 웹상의 설비 구축에 많은 노력 증대 인터넷과 웹에는 다양한 종류의 정보 노출에 대한 취약성 따라서 안전한 웹 서비스에 대한 요구가 증가

HTTP reply (HTML, Javascript, VBscript, etc)
1. Web 보안 개요 웹어플리케이션의 전형적인 아키텍처 Web Server DB Web app Client HTTP request (cleartext or SSL) HTTP reply (HTML, Javascript, VBscript, etc) Perl, C/C++, JSP, etc.. ADO, ODBC, etc.. Apache, IIS, Netscape etc… Transport Connector SQL Database n-tiers

1. Web 보안 개요 웹 보안 필요성 인터넷을 통한 웹 서버 공격에 취약. 웹 서버가 침입을 당하면 기업의 명성에 손상 및 금전적인 손실 소프트웨어 내부적 여러 가지 보안상의 문제. 공격자가 웹 서버의 내용, 서버의 데이터나 시스템에 접근. 사용자들은 보안인식 문제점, 보안도구나 지식이 결핍.

1.2 웹 보안 위협 공격방법에 따른 분류 소극적 공격 브라우저와 서버간의 네트워크 트래픽을 엿듣는 것
금지되어 있는 웹 사이트에 들어있는 정보에 대한 접근을 획득하는 것 적극적 공격 다른 사용자로 위장하거나 C/S 간에 전송되는 메시지를 변경하는 것 웹 사이트상의 정보를 변경하는 것 공격위협의 위치에 따른 분류 컴퓨터 시스템 보안의 범주 웹 서버 보안 웹 브라우저의 보안에 대한 주요 사항 네트워크 보안의 범주 브라우저와 서버간의 네트워크 트래픽 보안에 대한 주요 사항

기밀성 인증 무결성 서비스거부 1.2 웹 보안 위협 막기 어려움 암호학적 기술 정당한 사용자로 위장 데이터 위조 암호화,
파괴 부인 사용자 작업방해 사용자 쓰레드 죽이기 거짓요청을 범람시키는 기계 디스크나 메모리 채우기 DNS 공격에 의한 장치 고립 서비스거부 암호학적 기술 사용자의 잘못 판단 거짓 정보가 아니라고 믿음 정당한 사용자로 위장 데이터 위조 인증 암호화, 웹 프럭시 정보의 손실 프라이버시 손실 네트상의 엿듣기 서버의 정보 훔치기 클라이언트 데이터 훔치기 네트워크 구성에 대한 정보 클라이언트가 서버에게 요구 하는 정보 기밀성 암호학적 검사합 기계에 대한 노출 다른 모든 위협에 대한 취약성 사용자 테이터 수정 트로이 목마 브라우저 메모리 수정 전송중인 메시지 트래픽 수정 무결성 대응책 결과 위협

1.2 웹 트래픽 보안에 대한 해결 방법 웹 보안의 방법

1.2 웹 트래픽 보안에 대한 해결 방법 IPSec 을 이용하여 구현 (그림 a) 응용 프로그램에 투명하고 범용적 해결책 제공 선택된 트래픽만을 처리하는 필터링 기능 포함 TCP 바로 위에서 보안을 구현 (그림 b) SSL/TLS를 기본 프로토콜의 일부로 제공 가능(응용프로그램에 투명) SSL을 특정 패키지에 포함(넷스케이프, 인터넷 익스플러에 포함 설치) 응용 프로그램 중심의 보안서비스 구현 (그림 c) 특정 응용프로그램안에 포함 응용프로그램의 보안 요구사항 수용 용이

SSL (Secure Socket Layer)
2. SSL/TLS SSL (Secure Socket Layer) 배경 : 1993년 웹에서 안전한 통신을 위해 Netscape社에 의해 개발 특징 : 세션계층에서 적용되며, 응용계층의 FTP, TELNET, HTTP등의 프로토콜의 안전성 보장 기능: 서버 인증, 클라이언트 인증, 기밀성 보장 현황 및 전망 : 현재 많은 전자 쇼핑몰 업체에서 채택, 운영 TLS (Transport Layer Security) 배경 : SSL 3.0 이 표준화된 이후 IETF는 1996년 6월부터 TLS 프로토콜에 대한 표준화 (SSLv3.1) Backward compatible with SSLv3 특징 : SSL 3.0을 기반으로 한 업그레이드 프로토콜 현황 및 전망 : 현재 TLS 1.0이 발표, 지속적 개발 예상

2. SSL/TLS SSL/TLS의사용

2. SSL/TLS SSL/TLS의 위치

2.1 SSL의 기능 서버 인증 기능 사용자는 서버의 신원을 확인
서버의 certificate 와 public ID가 정당 확인 클라이언트의 신뢰 된 인증기관들의 목록에 서버의 인증기관이 포함여부를 확인 (표준 공개키 암호화 기술을 사용) 클라이언트 인증 서버는 클라이언트의 신원을 확인 클라이언트의 certificate 와 public ID가 정당 확인 서버의 신뢰 된 인증기관들의 목록에 클라이언트의 인증기관이 포함여부를 확인 (표준 공개키 암호화 기술을 사용) 암호화된 SSL 연결 클라이언트와 서버 사이에 송/수신 되는 모든 정보는 암호화/복호화 + 무결성

2.1.1 SSL Architecture SSL 구조 : 그림 17.2 2계층 프로토콜로 구성 상위 계층:
Handshake 프로토콜, Cipher Spec 프로토콜, Alert 프로토콜 하위 계층 SSL Record Protocol

2.1.1 SSL Architecture SSL 세션과 연결 연결: 적합한 서비스 위한 전송 형태 peer-to-peer 관계
연결: 적합한 서비스 위한 전송 형태 peer-to-peer 관계 모든 연결은 일시적으로 하나의 세션과 결합됨 세션 : 사용 개시부터 종료까지의 시간 또는 논리적 경로 핸드쉐이크 프로토콜에 의해 생성 복수의 연결간에 공유 가능한 보안 매개변수들의 집합 정의 각 연결는 새 보안 매개변수에 대한 협상 부담을 줄이기 위하여 사용 임의의 상대간에 다중 보안 연결의 존재가 가능하며, 세션은 보통 하나만 설정됨

SSL Record protocol

SSL Record protocol 기밀성 (Confidentiality) 핸드쉐이크 프로토콜은 대칭키 암호를 위한 세션키를 정의한다. IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128 메시지는 암호화 이전에 압축한다. 메시지 무결성 (Message integrity) 인증코드(MAC)를 만드는데 사용될 공유된 비밀키를 정의 similar to HMAC but with different padding

SSL Record protocol 단편화 (Fragmentation)
214byte(16348byte) or 혹은 이보다 작은 블록으로 분해 압축 (Compression) 무 손실 압축 지정된 압축 알고리즘이 없음 인증코드 (MAC) 암호화 (Encryption) IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128

II = 연결 MAC_write_secret = 공유 비밀키 hash = 암호화 해쉬 알고리즘 MD5 또는 SHA-1
pad_ = MD5에서는 48번 (384 비트) 반복되고 SHA-1에서는 40번 (320 비트) 반복되는 0x36 ( ) 바이트 pad_ = MD5에서는 48번 반복되고 SHA-1에서는 40번 반복되는 x5C ( ) 바이트 seq_num = 현재 처리하는 메시지에 대한 순서번호 SSLCompressed.type = 이 단편을 처리하는데 사용되는 상위 레벨의 프로토콜 SSLCompressed.length = 압축된 단편의 길이 SSLCompressed.fragment = 압축된 단편 (만약 압축이 사용되지 않았다면 일반 평문의단편임)

SSL Record protocol SSL record header 컨텐츠 유형 Contents type(8bits) 주요버전
Major Version(8bits) 하위버전 Minor Version(8bits) 압축길이 Compressed Length(16bits)

Change Cipher Spec Protocol
암호규격프로토콜(change cipher spec protocol)은 SSL 레코드 프로토콜을 사용하는 3개의 SSL 관련 프로토콜 중 하나이며 가장 간단 하나의 메시지로 되어 있으며 값 1을 갖는 한 바이트로 구성 이 메시지의 목적은 이 연결 상에서 쓰이도록 암호화 단위(suite)를 갱신하여 페딩(padding)상태를 현재상태로 복사하게 하는 것

경고 프로토콜(Alert Protocol)은 대등한 개체에게 SSL-관련 경고를 전달하기 위해 사용
경고 메시지는 압축되고, 암호화된다. 프로토콜에 있는 각 메시지는 2 바이트로 되어 있다. 첫 바이트는 메시지의 심각성을 전달하기 위해 warning(1) 또는 fatal(2)의 값을 가진다. 만일 레벨이 fatal이면, SSL은 즉시 연결을 종료 두 번째 바이트는 특정 경고를 지시하는 코드가 들어 있다.

Handshake Protocol 한 세션동안 이용되는 암호 매개변수 생성 한 세션에서 사용되는 비밀정보를 공유

Handshake Protocol Phase 1. 보안 기능 확립하기 protocol version, session ID, cipher suite, compression method, initial RN Phase 2. 서버 인증과 키 교환 key exchange, request certificate Phase 3. 클라이언트 인증과 키 교환 client sends key exchange, certificate verification Phase 4. 종료 change cipher suite, finish

1 2 3 4 5 6 7 8 9 10 11 12 13 ClientHello ServerHello 클 서
Certificate 8 ClientKeyExchange 9 CertificateVerify 10 ChangeCipherSpec 11 Finished 6 ServerHelloDone 13 2 ServerHello 3 4 ServerKeyExchange 5 CertificateRequest 12 클 라 이 언 트 서 버 Note: Optional or situation-dependent messages that are not always sent

SSL_FORTEZZA_DMS_WITH_RC4_128_SHA
Phase 1. 보안 기능 확립하기 Client_Hello Message ClientRandomValue (32bit+28bytes) Prot:22 Version:3.0 Length… …Length Type:1 ID len Session ID CipherSuite length CipherSuite 1 CipherSuite … … CipherSuite n Cmp n Cmp len Cmp 1 ……… Value Cipher Suite 0,0 0,1 0,2 0,4 SSL_NULL_WITH_NULL_NULL SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_RC4_128_MD5 0,5 SSL_RSA_WITH_RC4_128_SHA 0,7 SSL_RSA_WITH_IDEA_CBC_SHA : 0,30 SSL_FORTEZZA_DMS_WITH_RC4_128_SHA

Phase 1. 보안 기능 확립하기 (cont’d)
Server_Hello Message ClientRandomValue (32bit+28bytes) Prot:22 Version:3.0 Length… …Length Type:2 ID len Session ID(option) CipherSuite Cmp Client_Hello의 cipher suite list에서 한개를 선택한다

Phase 2. 서버 인증 및 키 교환 1 2 3 4 5 6 7 8 9 10 11 12 13 ClientHello

Certificate Chain Length
Phase 2. 서버 인증 및 키 교환 Certificate Message Certificate n Certificate 1 Prot:22 Version:3.0 Length… …Length Type:11 Certificate Chain Length ……… Certificate n Length Certificate 1 Length CA

Phase 2. 서버 인증 및 키 교환 (cont’d)
ServerKeyExchange Message Signed MD5 hash (16 bytes) Prot:22 Version:3.0 Length… …Length Type:12 RSA mod length mod value RSA… RSA exp length RSA exp value C = Me(mod n) e 값 n 값

Phase 2. 서버 인증 및 키 교환 (cont’d)
CertificateRequest Message DN(Distinguished Name) of CA 1 Prot:22 Version:3.0 Length… …Length Type:13 CT length ... CT 2 CAs length CA 1 length CT 1 CT n ……… Server가 받아들일 수 있는 인증기관 List CT Value Certificate Type 1 2 3 4 RSA sign DSS sign RSA sign with fixed Diffie-Hellman DSS sign with fixed Diffie-Hellman 5 RSA sign with ephemeral 6 DSA sign with ephemeral 20 Fortezza DMS

Phase 3. 클라이언트 인증 및 키 교환 1 2 3 4 5 6 7 8 9 10 11 12 13 ClientHello

Phase 3. 클라이언트 인증 및 키 교환 (cont’d)
Certificate Message If the server has requested a certificate, The client sends a certificate message

Phase 3. 클라이언트 인증 및 키 교환 (cont’d)
ClientKeyExchange Message Encrypted Premaster Secret Prot:22 Version:3.0 Length… …Length Type:16 Server의 공개키로 암호화 48 bytes random value

Master Secret Generation Procedure
SHA ‘A’ Premaster Secret Client Random Server Random ‘CCC’ Hash MD5 Master Secret ( 48 bytes ) ‘BB’

Key Material generation procedure (cont’d)
SHA ‘A’ Master Secret Server Random Client Random ‘BB’ ‘CCC’ Hash MD5 Key Material . . .

Phase 4. 완료 1 2 3 4 5 6 7 8 9 10 11 12 13 ClientHello ServerHello 클 서

Phase 4. 완료 (cont’d) ChangeCipherSpec Message Pending CipherSpec into the current one Record Layer에서 테이터 암호화 때 클라이언트와 서버간 서로 약속한 암호화 알고리즘 사용한다는 것을 통보

Message Authentication Code
Phase 4. 완료 (cont’d) Finished Message Handshake message MAC Encrypted MD5 hash (16 bytes) Prot:22 Version:3.0 Len:0 56 Type:20 36 SHA hash (20 bytes) MD5 Message Authentication Code

Transport Layer Security (TLS)
IETF 표준 RFC 2246 (SSLv3과 유사) SSLv3과의 차이점 버전 번호 Major : 3, minor : 1 메시지 인증코드는 HMAC을 사용 의사난수 함수 경고코드 암호화 계산 인증서 협상 패딩(1,9,17…., 249bytes)

의사난수 함수

치명적인 경고에 대한 목록들 unexpected_message : 부적절한 메시지가 수신되었다.
bad_record_mac : 잘못된 MAC가 수신되었다. decompression_failure : 압축 해제 기능이 부적절한 입력을 받았다.(예를 들면, 압축 해제할 수 없거나 최대 허용 길이보다 더 크게 압축 해제하는 경우) handshake_failure : 송신자가 유효한 옵션들에 주어진 조건에 맞는 보안 매개 변수 세트로 협상할 수 없다. illegal_parameter : 핸드쉐이크 메시지 안의 필드가 범위밖에 있거나 다른 필드와 일치하지 않는다.

치명적인 경고에 대한 목록들 (cont’d)
close_notify : 송신자가 이 연결에서는 더 이상 메시지를 수신하지 않을 것이라는 걸 수신 측에 통고한다. no_certificate : 이용할 수 있는 적절한 인증이 없을 때 인증 요청의 응답으로 보내진다. bad_certificate : 보내어진 인증이 잘못되었다(예를 들면, 검증하지 않은 서명이 포함된 경우). unsupported_certificate : 보내어진 인증의 타입이 지원되지 않는 것이다. certificate_revoked : 인증이 서명자에 의해 취소되었다. certificate_expired : 인증이 만료되었다. certificate_unknown : 다른 몇 가지 지정하지 않은 결과가 인증 처리 중 발생하였다.

Secure Electronic Transaction (SET)
개방 암호화와 인터넷의 신용카드 처리를 보호하기 위해 설계된 보안 규격 Mastercard 의 SEPP, Visa의 STT를 결합한 형태 1996년 개발 SET가 제공하는 서비스 거래에 필요한 모든 당사자간에 안전한 통신 채널을 제공 X.509v3 디지털 인증서를 사용하여 신뢰성을 제공 정보가 언제 어디서 필요하던지 간에, 거래하는 당사자들에게만 유효하므로 프라이버시를 보장

Secure Electronic Transaction (cont’d)
Secure E-Commerce componets

SET 참여자 카드 소지자(Cardholder) : 공인된 신용카드의 소지자 상인(Merchant) : 상품 판매자, 지불카드를 받는 상인은 취득자와 관계설정 필요 발행인(Issuer) : 지불카드를 제공하는 금융기관, 카드소지자의 빚에 대한 지불 책임 취득자(Acquirer) : 상인과 거래를 개설하고 지불처리하는 금융기관, 지불넷을 이용하여 발행인으로부터 상환 지불 게이트웨이(Payment Gateway) : 취득자가 SET 지불기능을 위해 은행카드 지불망에 연결하여 운영 인증 기관(CA: Certification Authority) : 공개키 인증서 발행 기관

1) 신용카드 사용 계정개설 2) 인증서 발급 3)서명메시지 확인용, 키 교환용, PG 공개키 인증서 복사본 4) 구매할 품목의 주문을 요청 8) 주문에 대한 확인을 응답 9) 상인은 고객에게 상품전송 6) 주문과 지불정보를 상인에게 전송 7) 지불인증을 요구 10) 상품 대금 지불 청구 5) 주문확인하고 상인의 신분보증 응답

고객이 계정을 개설한다. 고객은 인증서를 받는다. 상인들은 인증서를 가지고 있다. 고객이 주문을 한다. 상인이 확인한다. 주문과 지불이 보내진다. 상인은 지불 인증을 요구한다. 상인은 주문을 확인한다. 상인은 상품이나 서비스를 제공한다. 상인은 지불을 요구한다.

이중서명 (Dual signature) 다른 두 수신 측에 보내질 두 가지 메시지를 연결함으로 고객이 불필요한 정보노출 없이 자신을 인증할 수 있다. 고객은 이중 서명을 만들며, 개인 서명키와 함께 한 해쉬값 암호화 상인은 OI를 받고 서명을 확인 은행은 PI를 받고 서명을 확인 고객은 OI와 PI을 연결하고 그 연결을 증명 DS = EKRC[MD(H( MD(H(PI)) || MD(H(OI)) )]

Dual Singnature 이중서명 (Dual signature)

SET 주요거래 유형 구매 요청(purchase request)
고객이 상인을 위한 OI, 은행을 위한 PI메시지를 상인에게 전송 지불 허가(payment authorization) 신용카드의 신용확인을 위한 상인과 지불 게이트웨이간의 구매허가 검증 지불 확인(payment capture) 상인이 지불을 획득하기 위해 확인요청과 확인응답으로 이루어진 지불확인 트랜잭션에서 지불 게이트웨이 사용

SET 구매 요청 교환의 주요 4개 메시지 initiate request 고객이 상인에게 인증서 요청
고객의 신용카드, 요청/응답의 ID, 요청/응답의 확인용 비표 initiate response 상인의 서명한 응답 비표, 처리ID, 상인의 서명 인증서, Payment Gateway 키 교환 인증서 purchase request 구매요청(카드 소지자는 상인과 게이트웨이 인증서을 확인하고, 일회용 대칭암호키(Ks), OI, PI 등을 생성) purchase response 주문을 승인응답(대응하는 거래 번호를 참조하라는 응답 블록과 서명을 상인의 서명 인증서와 함께 고객에게 전송)

구매요청(purchase request) 구매 관련 정보(Purchase-related information)
상인이 게이트웨이에게 전송 PI 고객의 개인키로 서명된 PI와 OI로 계산된 이중 서명 OI 메시지 다이제스트(OIMD) 주문-관련 정보(Order-related information) 상인이 필요로 하는 것 OI 고객 개인키로 서명되고, PI와 OI로 계산된 이중서명 PI 메시지 다이제스트(PIMD) 카드 소지자 인증서(cardholder certificate) 상인과 지불 게이트웨이에게 필요한 카드 소지자의 공개키

Purchase Request (Customer)

구매응답 구매응답 (Purchase Response) 상인은 구매 요청 메시지를 받고 다음을 수행
1. CA 서명에 의한 카드 소지자의 인증서를 검증 2. 고객의 공개 서명키를 사용하여 이중 서명을 검증 3. 주문을 처리하고 허가를 위해 지불 정보를 지불 게이트웨이로 전송 4. 카드 소지자에 구매 응답을 전송 카드소지자 소프트웨어는 구매 응답 메시지를 받고 다음을 처리 상인의 인증서 검증 응답 블록의 서명을 확인 응답에 의거하여 사용자에게 메시지 디스플레이 주문의 상황에 따른 데이터베이스 갱신

Purchase Request (Merchant)

지불 허가 카드 소지자로부터 주문 처리시 상인은 지불 게이트웨이와 거래허가확인과정을 처리 지불허가는 상인이 지불 받을 수 있음을 보장 지불 허가 교환은 2개의 메시지로 구성 Authorization Request 상인은 허가요청 메시지를 지불 게이트웨이로 전송 Authorization Response 상인에게 허가 응답을 전송

Authorization Request 메시지 구성
지불 허가 Authorization Request 메시지 구성 구매-관련 정보(Purchase-related information) PI + DS + OIMD + 전자 봉투 허가-관련 정보(Authorization-related information) 상인의 개인 서명키로 서명되고 상인에 의해 생성된 일회용 대칭 키로 암호화된 거래 ID를 포함하는 허가 블록 전자 봉투 지불 게이트웨이의 공개키-교환키로 일회용 키을 암호화하여 형성 인증서(Cardholder certificate) Cardholder의 서명키 인증서 Merchant의 서명키 인증서 Merchant의 키 교환 인증서

지불 게이트웨이 지불 게이트웨이의 처리과정 1. 모든 인증서를 검증
2. 대칭 키를 얻기 위해 허가 블록의 전자 봉투를 해독한 다음 허가 블록을 복호화 한다. 3. 허가 블록에 있는 상인의 서명을 검증 4. 대칭 키를 얻기 위해 지불 블록의 전자 봉투를 해독한 다음 지불 블록을 복호화 한다. 5. 지불 블록의 이중 서명을 검증한다. 6. 상인으로부터 받은 거래 ID가 고객으로부터 (간접적으로) 받은 PI에 있는 거래 ID와 맞다는 것을 확인한다. 7. 발행인으로부터 허가를 요청하고 받는다. 발행인으로부터 허가를 획득하면 지불게이트웨이는 상인에게 Authorization Response(허가응답)

지불 허가 Authorization Response 메시지 구성
허가-관련 정보(Authorization-Related Information) 게이트웨이의 개인 서명키로 서명되고 게이트웨이에 의해 생성된 일회용 대칭 키로 암호화된 허가 블록을 포함한다. 상인의 공개 키-교환키로 암호화된 일회용 키가 들어 있는 디지털 봉투를 포함한다. 확인 토큰 정보(Capture token information) 전자 봉투와 함께 서명되고 암호화되는 확인 토큰. 이 토큰은 상인에 의해 처리되지 않는다. 인증서(Certificate) 게이트웨이의 서명 키 인증서 게이트웨이로부터 허가후에 상인은 고객에게 상품과 서비스를 제공

지불 확인 상인은 2개의 메시지로 구성된 지불확인 거래에 지불 게이트웨이를 사용(capture request: 확인요청, capture response: 확인응답) 상인의 Capture Request 메시지 구성 상인은 지불액과 거래 ID를 포함하는 확인요청 블록을 생성/서명/암호화 처리 메시지는 상인의 서명키, 키-교환 키 인증서, 이 거래를 위해 허가응답에서 받은 암호화된 확인토큰을 포함 지불 게이트웨이의 Capture Response 메시지 구성 확인요청 블록을 복호하고 검증하며 확인토큰 블록을 복호하고 검증 개인 지불망을 통해 발행인에게 보내지는 요청을 생성 이 요청은 일정 금액이 상인의 계좌로 이동되도록 조치 지불 게이트웨이는 상인에게 Capture Response 메시지로 지불을 통보 메시지는 게이트웨이가 서명하고 암호화한 확인응답을 포함 상인은 확인 응답을 저장하여 미래의 문제에 대비

SSL 보안 WEB Security.

Similar presentations

Presentation on theme: "SSL 보안 WEB Security."— Presentation transcript:

Similar presentations

About project

지원

로그인

Auth with social network:

SSL 보안 WEB Security.

Similar presentations

Presentation on theme: "SSL 보안 WEB Security."— Presentation transcript:

Similar presentations

About project

지원