SSL 보안 WEB Security

SSLSSL 보안보안WEB SecurityWEB Security

2

목 차

Web 보안 개요

SSL/ TLS

SET

3

1. Web 보안 개요

배경

현재 많은 기업과 정부 기관 , 개인들까지도 웹사이트를 소유

인터넷 접속을 이용하는 개인이나 회사의 수가 급속히 증가

전자상거래를 위한 웹상의 설비 구축에 많은 노력 증대

인터넷과 웹에는 다양한 종류의 정보 노출에 대한 취약성

따라서 안전한 웹 서비스에 대한 요구가 증가

4

▣ 웹어플리케이션의 전형적인 아키텍처

WebServer DB

DB

Web app

WebClient Web app

Web appWeb app

HTTP request(cleartext or SSL)

HTTP reply (HTML, Javascript,

VBscript, etc)Perl, C/C++, JSP, etc..

ADO, ODBC, etc..Apache, IIS, Netscape etc…

TransportConnector

Connector

SQL Database

n-tiers


5


웹 보안 필요성

인터넷을 통한 웹 서버 공격에 취약 .

웹 서버가 침입을 당하면 기업의 명성에 손상 및 금전적인 손실

소프트웨어 내부적 여러 가지 보안상의 문제 .

공 격 자 가 웹 서 버 의 내 용 , 서 버 의 데 이 터 나 시스템에 접근 .

사용자들은 보안인식 문제점 , 보안도구나 지식이 결핍 .

6

1.2 웹 보안 위협

공격방법에 따른 분류 소극적 공격

브라우저와 서버간의 네트워크 트래픽을 엿듣는 것금지되어 있는 웹 사이트에 들어있는 정보에 대한 접근을

획득하는 것 적극적 공격

다른 사용자로 위장하거나 C/S 간에 전송되는 메시지를 변경하는 것

웹 사이트상의 정보를 변경하는 것

공격위협의 위치에 따른 분류 컴퓨터 시스템 보안의 범주

웹 서버 보안웹 브라우저의 보안에 대한 주요 사항

네트워크 보안의 범주브라우저와 서버간의 네트워크 트래픽 보안에 대한 주요 사항

7

막기 어려움

파괴 부인사용자 작업방해

사용자 쓰레드 죽이기 거짓요청을 범람시키는 기계 디스크나 메모리 채우기 DNS 공격에 의한 장치 고립

서비스거부

암호학적 기술

사용자의 잘못 판단 거짓 정보가 아니라고 믿음

정당한 사용자로 위장 데이터 위조인증

암호화 ,

웹 프럭시

정보의 손실 프라이버시 손실

네트상의 엿듣기 서버의 정보 훔치기 클라이언트 데이터 훔치기 네트워크 구성에 대한 정보 클라이언트가 서버에게 요구 하는 정보

기밀성

암호학적

검사합

정보의 손실 기계에 대한 노출 다른 모든 위협에

대한 취약성

사용자 테이터 수정 트로이 목마 브라우저 메모리 수정 전송중인 메시지 트래픽 수정

무결성

대응책결과위협

1.2 웹 보안 위협

8

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

웹 보안의 방법

9

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

IPSec 을 이용하여 구현 ( 그림 a) 응용 프로그램에 투명하고 범용적 해결책 제공 선택된 트래픽만을 처리하는 필터링 기능 포함

TCP 바로 위에서 보안을 구현 ( 그림 b) SSL/TLS 를 기본 프로토콜의 일부로 제공 가능 (

응용프로그램에 투명 ) SSL 을 특정 패키지에 포함 ( 넷스케이프 , 인터넷

익스플러에 포함 설치 )

응용 프로그램 중심의 보안서비스 구현 ( 그림 c) 특정 응용프로그램안에 포함 응용프로그램의 보안 요구사항 수용 용이

10

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 이 발표 , 지속적 개발 예상

11

2. SSL/TLS

SSL/TLS 의사용

12

2. SSL/TLS

SSL/TLS 의 위치

13

2.1 SSL 의 기능

서버 인증 기능 사용자는 서버의 신원을 확인 서버의 certificate 와 public ID가 정당 확인 클라이언트의 신뢰 된 인증기관들의 목록에 서버의 인증기관이 포함여부를 확인 (표준 공개키 암호화 기술을 사용 )

클라이언트 인증 서버는 클라이언트의 신원을 확인 클라이언트의 certificate 와 public ID가 정당 확인 서버의 신뢰 된 인증기관들의 목록에 클라이언트의 인증기관이 포함여부를 확인 (표준 공개키 암호화 기술을 사용 )

암호화된 SSL 연결 클라이언트와 서버 사이에 송/수신 되는 모든 정보는 암호화/복호화 + 무결성

14

2.1.1 SSL Architecture

SSL 구조 : 그림 17.2 2 계층 프로토콜로 구성 상위 계층 :

SSL 동작에 대한 관리 Handshake 프로토콜 , Cipher Spec 프로토

콜 , Alert 프로토콜

하위 계층 SSL Record

Protocol

15

2.1.1 SSL Architecture

SSL 세션과 연결 연결 : 적합한 서비스 위한 전송 형태

peer-to-peer 관계 모든 연결은 일시적으로 하나의 세션과 결합됨

세션 : 사용 개시부터 종료까지의 시간 또는 논리적 경로 핸드쉐이크 프로토콜에 의해 생성 복수의 연결간에 공유 가능한 보안 매개변수들의 집합 정의 각 연결는 새 보안 매개변수에 대한 협상 부담을 줄이기

위하여 사용 임의의 상대간에 다중 보안 연결의 존재가 가능하며 , 세션은

보통 하나만 설정됨

16

SSL Record protocol

17

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

18

SSL Record protocol

단편화 (Fragmentation) 214byte(16348byte) or 혹은 이보다 작은 블록으로 분해

압축 (Compression) 무 손실 압축 지정된 압축 알고리즘이 없음

인증코드 (MAC)

암호화 (Encryption) IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40,

RC4-128

hash ( MAC_write_secret pad_2hash( =MAC_write_secret pad_1 seq_num SSLCompressed.typeSSLCompressed.length SSLCompressed.fragment) )

19

II = 연결 MAC_write_secret = 공유 비밀키 hash = 암호화 해쉬 알고리즘 MD5 또는 SHA-1 pad_1 = MD5 에서는 48번 (384 비트 )

반복되고 SHA-1 에서는 40번 (320 비트 ) 반복되는 0x36 (0010 0110) 바이트

pad_2 = MD5 에서는 48번 반복되고 SHA-1에서는 40번 반복되는 0x5C (0101 1100) 바이트

seq_num = 현재 처리하는 메시지에 대한 순서번호 SSLCompressed.type = 이 단편을 처리하는데 사용되는 상위

레벨의 프로토콜 SSLCompressed.length = 압축된 단편의 길이 SSLCompressed.fragment = 압축된 단편 ( 만약 압축이

사용되지 않았다면 일반 평문의단편임 )

20

SSL Record protocol

SSL record header 컨텐츠 유형

Contents type(8bits) 주요버전

Major Version(8bits) 하위버전

Minor Version(8bits) 압축길이

Compressed Length(16bits)

21

Change Cipher Spec Protocol

암 호규격 프 로 토 콜 (change cipher spec protocol) 은 SSL

레코드 프로토콜을 사용하는 3 개의 SSL 관련 프로토콜 중

하나이며 가장 간단

하나의 메시지로 되어 있으며

값 1 을 갖는 한 바이트로 구성

이 메시지의 목적은 이 연결 상에서 쓰이도록 암호화 단위 (suite)

를 갱신하여 페딩 (padding) 상태를 현재상태로 복사하게 하는 것

22

Alert Protocol

경고 프로토콜 (Alert Protocol) 은 대등한 개체에게 SSL- 관련 경고를 전달하기 위해 사용 경고 메시지는 압축되고 , 암호화된다 .

프로토콜에 있는 각 메시지는 2 바이트로 되어 있다 .

첫 바이트는 메시지의 심각성을 전달하기 위해 warning(1)

또는 fatal(2) 의 값을 가진다 .

만일 레벨이 fatal 이면 , SSL 은 즉시 연결을 종료

두 번째 바이트는 특정 경고를 지시하는 코드가 들어 있다 .

23

Handshake Protocol

한 세션동안 이용되는 암호 매개변수 생성

한 세션에서 사용되는 비밀정보를 공유

24

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

25

1 ClientHello

7 Certificate

8 ClientKeyExchange

9 CertificateVerify

10 ChangeCipherSpec

11 Finished

6ServerHelloDone

13Finished

2ServerHello

3Certificate

4ServerKeyExchange

5CertificateRequest

ChangeCipherSpec

12

클

라

이

언

트

서

버

Note: Optional or situation-dependent messages that are not always sent

26

Phase 1. 보안 기능 확립하기

1. Client_Hello Message

ClientRandomValue(32bit+28bytes)

Prot:22 Version:3.0 Length…

…Length Type:1 Length…

…Length Version:3.0

ID len

Session ID

CipherSuite length CipherSuite 1

CipherSuite 2 … … CipherSuite n

Cmp nCmp 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

27

Phase 1. 보안 기능 확립하기 (cont’d)

2. Server_Hello Message

ClientRandomValue(32bit+28bytes)



…Length Version:3.0

ID len

Session ID(option)

CipherSuite Cmp

Client_Hello 의 cipher suite list 에서

한개를 선택한다

28

1 ClientHello

7 Certificate

8 ClientKeyExchange

9 CertificateVerify

10 ChangeCipherSpec

11 Finished

6ServerHelloDone

13Finished

2ServerHello

3Certificate

4ServerKeyExchange

5CertificateRequest

ChangeCipherSpec

12

클

라

이

언

트

서

버


Phase 2. 서버 인증 및 키 교환

29

Phase 2. 서버 인증 및 키 교환

3. Certificate Message

Certificate n

Certificate 1



…Length Certificate Chain Length

………

Certificate n Length

Certificate 1 Length

CA

CA

CA

CA

CA

30

Phase 2. 서버 인증 및 키 교환 (cont’d)

4. ServerKeyExchange Message

Signed MD5 hash(16 bytes)



…Length RSA mod length

mod value

RSA…

RSA exp length

RSA exp value C = Me(mod n)

e 값

n 값

31

Phase 2. 서버 인증 및 키 교환 (cont’d)

5. CertificateRequest Message

DN(Distinguished Name) of CA 1



…Length 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

32

1 ClientHello

7 Certificate

8 ClientKeyExchange

9 CertificateVerify

10 ChangeCipherSpec

11 Finished

6ServerHelloDone

13Finished

2ServerHello

3Certificate

4ServerKeyExchange

5CertificateRequest

ChangeCipherSpec

12

클

라

이

언

트

서

버


Phase 3. 클라이언트 인증 및 키 교환

33

Phase 3. 클라이언트 인증 및 키 교환 (cont’d)

7. Certificate Message If the server has requested a certificate,

The client sends a certificate message

34

Phase 3. 클라이언트 인증 및 키 교환 (cont’d)

8. ClientKeyExchange Message

Encrypted Premaster Secret



…Length

Server 의 공개키로암호화

48 bytes random value

35

SHA

‘A’ Premaster Secret Client Random Server Random

‘CCC’ Premaster Secret Client Random Server Random

HashPremaster Secret


SHA

SHA

MD5

MD5

MD5

Hash Hash Hash

Master Secret ( 48 bytes )


‘BB’ Premaster Secret Client Random Server Random

Master Secret Generation Procedure

36

SHA

‘A’ Master Secret Server Random Client Random

‘BB’ Master Secret Server Random Client Random

‘CCC’ Master Secret Server Random Client Random

HashMaster Secret

HashMaster Secret

HashMaster Secret

SHA

MD5

MD5

MD5

Hash Hash Hash

Key Material

. . .

. . .

SHA

Key Material generation procedure (cont’d)

37

1 ClientHello

7 Certificate

8 ClientKeyExchange

9 CertificateVerify

10 ChangeCipherSpec

11 Finished

6ServerHelloDone

13Finished

2ServerHello

3Certificate

4ServerKeyExchange

5CertificateRequest

ChangeCipherSpec

12

클

라

이

언

트

서

버


Phase 4. 완료

38

Phase 4. 완료 (cont’d)

10.ChangeCipherSpec Message Pending CipherSpec into the current one Record Layer 에서 테이터 암호화 때 클라이언트와

서버간 서로 약속한 암호화 알고리즘 사용한다는 것을 통보

39

Phase 4. 완료 (cont’d)

11.Finished Message

Handshakemessage

MAC

Encrypted

MD5 hash(16 bytes)

Prot:22 Version:3.0 Len:056 Type:20 Len:036

0

SHA hash(20 bytes)

MD5Message Authentication Code

(16 bytes)

40

Transport Layer Security (TLS)

IETF 표준 RFC 2246 (SSLv3 과 유사 )

SSLv3 과의 차이점 버전 번호

Major : 3, minor : 1 메시지 인증코드는 HMAC 을 사용 의사난수 함수 경고코드 암호화 계산 인증서 협상 패딩 (1,9,17…., 249bytes)

41

의사난수 함수

42

치명적인 경고에 대한 목록들

unexpected_message : 부적절한 메시지가 수신되었다 .

bad_record_mac : 잘못된 MAC 가 수신되었다 .

decompression_failure : 압축 해제 기능이 부적절한 입력을 받았다 .( 예를 들면 , 압축 해제할 수 없거나 최대 허용 길이보다 더 크게 압축 해제하는 경우 )

handshake_failure : 송신자가 유효한 옵션들에 주어진 조건에 맞는 보안 매개 변수 세트로 협상할 수 없다 .

illegal_parameter : 핸드쉐이크 메시지 안의 필드가 범위밖에 있거나 다른 필드와 일치하지 않는다 .

43

치명적인 경고에 대한 목록들 (cont’d)

close_notify : 송신자가 이 연결에서는 더 이상 메시지를 수신하지 않을 것이라는 걸 수신 측에 통고한다 .

no_certificate : 이용할 수 있는 적절한 인증이 없을 때 인증 요청의 응답으로 보내진다 .

bad_certificate : 보내어진 인증이 잘못되었다 ( 예를 들면 , 검증하지 않은 서명이 포함된 경우 ).

unsupported_certificate : 보내어진 인증의 타입이 지원되지 않는 것이다 .

certificate_revoked : 인증이 서명자에 의해 취소되었다 .

certificate_expired : 인증이 만료되었다 .

certificate_unknown : 다른 몇 가지 지정하지 않은 결과가 인증 처리 중 발생하였다 .

44

Secure Electronic Transaction (SET)

개방 암호화와 인터넷의 신용카드 처리를 보호하기 위해 설계된 보안 규격

Mastercard 의 SEPP, Visa 의 STT 를 결합한 형태 1996 년 개발

SET 가 제공하는 서비스 거래에 필요한 모든 당사자간에 안전한 통신 채널을

제공 X.509v3 디지털 인증서를 사용하여 신뢰성을 제공 정보가 언제 어디서 필요하던지 간에 , 거래하는

당사자들에게만 유효하므로 프라이버시를 보장

45

Secure Electronic Transaction (cont’d)

Secure E-Commerce componets

46


SET 참여자 카드 소지자 (Cardholder) : 공인된 신용카드의 소지자 상인 (Merchant) : 상품 판매자 , 지불카드를 받는 상인은

취득자와 관계설정 필요 발행인 (Issuer) : 지불카드를 제공하는 금융기관 , 카드소지자의 빚에 대한 지불 책임

취득자 (Acquirer) : 상인과 거래를 개설하고 지불처리하는 금융기관 , 지불넷을 이용하여 발행인으로부터 상환

지불 게이트웨이 (Payment Gateway) : 취득자가 SET 지불기능을 위해 은행카드 지불망에 연결하여 운영

인증 기관 (CA: Certification Authority) : 공개키 인증서 발행 기관

47


1) 1) 신용카드 신용카드 사용 계정개설사용 계정개설

2) 2) 인증서 발급인증서 발급 3)3) 서명메시지 확인용서명메시지 확인용 ,,키 교환용키 교환용 ,,PG PG 공개키 인증서 복사본공개키 인증서 복사본

4) 4) 구매할 품목의 주문을 요청구매할 품목의 주문을 요청

8) 8) 주문에 대한 확인을 응답 주문에 대한 확인을 응답 9) 9) 상인은 고객에게 상품전송상인은 고객에게 상품전송6) 6) 주문과 지불정보를 상인에게 전송주문과 지불정보를 상인에게 전송

7) 7) 지불인증을 요구지불인증을 요구

10) 10) 상품 대금 상품 대금 지불 청구지불 청구

5) 5) 주문확인하고 상인의 신분보증 응답주문확인하고 상인의 신분보증 응답

48


1. 고객이 계정을 개설한다 .

2. 고객은 인증서를 받는다 .

3. 상인들은 인증서를 가지고 있다 .

4. 고객이 주문을 한다 .

5. 상인이 확인한다 .

6. 주문과 지불이 보내진다 .

7. 상인은 지불 인증을 요구한다 .

8. 상인은 주문을 확인한다 .

9. 상인은 상품이나 서비스를 제공한다 .

10.상인은 지불을 요구한다 .

49


이중서명 (Dual signature) 다른 두 수신 측에 보내질 두 가지 메시지를 연결함으로 고객이 불필요한 정보노출 없이 자신을 인증할 수 있다 .

고객은 이중 서명을 만들며 , 개인 서명키와 함께 한 해쉬값 암호화상인은 OI 를 받고 서명을 확인은행은 PI 를 받고 서명을 확인고객은 OI 와 PI 을 연결하고 그 연결을 증명

DS = EKRC[MD(H( MD(H(PI)) || MD(H(OI)) )]

50

Dual Singnature

이중서명 (Dual signature)

51

SET

주요거래 유형 구매 요청 (purchase request)

고객이 상인을 위한 OI, 은행을 위한 PI 메시지를

상인에게 전송

지불 허가 (payment authorization)

신용카드의 신용확인을 위한 상인과 지불 게이트웨이간의

구매허가 검증

지불 확인 (payment capture)

상인이 지불을 획득하기 위해 확인요청과 확인응답으로

이루어진 지불확인 트랜잭션에서 지불 게이트웨이 사용

52

SET

구매 요청 교환의 주요 4 개 메시지 initiate request

고객이 상인에게 인증서 요청 고객의 신용카드 , 요청 /응답의 ID, 요청 /응답의 확인용 비표

initiate response 상인의 서명한 응답 비표 , 처리 ID, 상인의 서명 인증서 , Payment Gateway 키 교환

인증서 purchase request

구매요청 ( 카드 소지자는 상인과 게이트웨이 인증서을 확인하고 , 일회용 대칭암호키 (Ks), OI, PI 등을 생성 )

purchase response 주문을 승인응답 ( 대응하는 거래 번호를 참조하라는 응답 블록과

서명을 상인의 서명 인증서와 함께 고객에게 전송 )

53

구매요청

구매요청 (purchase request) 구매 관련 정보 (Purchase-related information)

상인이 게이트웨이에게 전송– PI– 고객의 개인키로 서명된 PI 와 OI 로 계산된 이중 서명 – OI 메시지 다이제스트 (OIMD)

주문 - 관련 정보 (Order-related information) 상인이 필요로 하는 것

– OI– 고객 개인키로 서명되고 , PI 와 OI 로 계산된 이중서명 – PI 메시지 다이제스트 (PIMD)

카드 소지자 인증서 (cardholder certificate) 상인과 지불 게이트웨이에게 필요한 카드 소지자의 공개키

54

Purchase Request (Customer)

55

구매응답

구매응답 (Purchase Response)

상인은 구매 요청 메시지를 받고 다음을 수행1. CA 서명에 의한 카드 소지자의 인증서를 검증 2. 고객의 공개 서명키를 사용하여 이중 서명을 검증 3. 주문을 처리하고 허가를 위해 지불 정보를 지불

게이트웨이로 전송 4. 카드 소지자에 구매 응답을 전송

카드소지자 소프트웨어는 구매 응답 메시지를 받고 다음을 처리 상인의 인증서 검증 응답 블록의 서명을 확인 응답에 의거하여 사용자에게 메시지 디스플레이 주문의 상황에 따른 데이터베이스 갱신

56

Purchase Request (Merchant)

57

지불 허가

카드 소지자로부터 주문 처리시 상인은 지불 게이트웨이와 거래허가확인과정을 처리

지불허가는 상인이 지불 받을 수 있음을 보장

지불 허가 교환은 2 개의 메시지로 구성 Authorization Request

상인은 허가요청 메시지를 지불 게이트웨이로 전송 Authorization Response

상인에게 허가 응답을 전송

58

지불 허가

Authorization Request 메시지 구성 구매 - 관련 정보 (Purchase-related information)

PI + DS + OIMD + 전자 봉투 허가 - 관련 정보 (Authorization-related information)

상인의 개인 서명키로 서명되고 상인에 의해 생성된 일회용 대칭 키로 암호화된 거래 ID 를 포함하는 허가 블록

전자 봉투– 지불 게이트웨이의 공개키 - 교환키로 일회용 키을

암호화하여 형성 인증서 (Cardholder certificate)

Cardholder 의 서명키 인증서Merchant 의 서명키 인증서Merchant 의 키 교환 인증서

59

지불 게이트웨이

지불 게이트웨이의 처리과정 1. 모든 인증서를 검증2. 대칭 키를 얻기 위해 허가 블록의 전자 봉투를 해독한

다음 허가 블록을 복호화 한다 .3. 허가 블록에 있는 상인의 서명을 검증 4. 대칭 키를 얻기 위해 지불 블록의 전자 봉투를 해독한

다음 지불 블록을 복호화 한다 .5. 지불 블록의 이중 서명을 검증한다 . 6. 상 인 으 로 부 터 받은 거 래 ID 가 고객으 로 부 터 (

간접적으로 ) 받은 PI 에 있는 거래 ID 와 맞다는 것을 확인한다 .

7. 발행인으로부터 허가를 요청하고 받는다 . 발행인 으 로 부 터 허가 를 획 득 하 면 지불게 이 트 웨 이 는

상인에게 Authorization Response(허가응답 )

60

지불 허가

Authorization Response 메시지 구성 허가 - 관련 정보 (Authorization-Related Information)

게이트웨이의 개인 서명키로 서명되고 게이트웨이에 의해 생성된 일회용 대칭 키로 암호화된 허가 블록을 포함한다 .

상인의 공개 키 - 교환키로 암호화된 일회용 키가 들어 있는 디지털 봉투를 포함한다 .

확인 토큰 정보 (Capture token information) 전자 봉투와 함께 서명되고 암호화되는 확인 토큰 . 이

토큰은 상인에 의해 처리되지 않는다 .

인증서 (Certificate) 게이트웨이의 서명 키 인증서

게이트웨이로부터 허가후에 상인은 고객에게 상품과 서비스를 제공

61

지불 확인

상인은 2 개의 메시지로 구성된 지불확인 거래에 지불 게이트웨이를 사용 (capture request: 확인요청 , capture response: 확인응답 )

상인의 Capture Request 메시지 구성 상인은 지불액과 거래 ID 를 포함하는 확인요청 블록을 생성 /서명 /

암호화 처리 메시지는 상인의 서명키 , 키 - 교환 키 인증서 , 이 거래를 위해 허가응답에서 받은 암호화된 확인토큰을 포함

지불 게이트웨이의 Capture Response 메시지 구성 확인요청 블록을 복호하고 검증하며 확인토큰 블록을 복호하고 검증 개인 지불망을 통해 발행인에게 보내지는 요청을 생성 이 요청은 일정 금액이 상인의 계좌로 이동되도록 조치 지불 게이트웨이는 상인에게 Capture Response 메시지로 지불을

통보메시지는 게이트웨이가 서명하고 암호화한 확인응답을 포함

상인은 확인 응답을 저장하여 미래의 문제에 대비

Documents

SSL 보안 WEB Security