technologies and applications of secure epayment systems

Technologies and Applications of Secure ePayment Systems

Introduction

상품

고객 상인 금융기관

상품정보

주문 / 지불정보대금 ( 이체 )

지불정보

대금

on-lineoff-line

secure on-line

바람직한 전자상거래의 구조

Green Commerce Server

Buyer Merchant

Credit Card Company

RealBank

goods

messages messages

Green Commerce Model

Technologies

Terminology plaintext ciphertext encryption decryption cryptography cryptographers cryptanalysis cryptanalysts

cryptology cryptologists cipher (cryptographi

c algorithm) key keyspace cryptosystem

CiphertextEncryption Decryption

PlaintextOriginalPlaintext

Encryption and Decryption

Categories of Security Services (ISO/IEC7498-2) Authentication Access Control Data Confidentiality Data Integrity Non-repudiation

Operations in Ciphers (1) Substitution Ciphers

monoalphabetic cipher (simple substitution cipher)

Caesar Cipher homophonic substitution cipher polygram substitution cipher polyalphabetic substitution cipher

running-key cipher Transposition Ciphers

Operations in Ciphers (2) Character-based Algorithms Bit-based Algorithms

Encryption and Decryption with a Key



K K

Restricted algorithms Key-based algorithms

Types of Key-based Algorithms Symmetric Algorithms

block ciphers electronic codebook (ECB) mode cipher block chaining (CBC) mode …

stream ciphers keystream generator (running-key generator)

Public-Key Algorithmsc.f. Message Digest



K K

• Symmetric Algorithm, Secret-key Algorithm, 비밀키 암호화 방식• DES, IDEA, SEED• 속도 빠름 , 메시지 길이제한 없음• 키 교환이 어려움

대칭형 암호화



KB KV

• Asymmetric Algorithm, Public-key Algorithm, 공개키 암호화 방식• RSA, LUC, DSS• 속도 느림 , 메시지 길이에 제한• 키 교환이 쉬움

비대칭형 암호화

공개키 암호시스템의 비교

디지털 서명알고리즘 암호 /복호화키교환

가능RSA 가능가능가능LUC 가능가능가능DSS 불가능불가능

불가능Diffie-Hellman 불가능가능

DigestedMessage

DigestMessage

• One-way Hash Function• Message Digest• MD2, MD4, MD5, SHA, SHA-1

메시지 다이제스트

Cryptanalysis Kerckhoffs’s assumption

The cryptanalyst has complete details of the cryptographic algorithm and implementation.

Security of Algorithms Unconditionally secure

one-time padc.f. brute-force attack

a ciphertext-only attack Computationally secure

Data complexity Processing complexity Storage requirements



KS KS

KB(KS)Encryption DecryptionKS KS

KB KVStep 1:

Step 2:

Protocol for Confidentiality



KV KB

• 부인방지는 Ciphertext 를 저장해 둠으로써 이룰 수 있음• +

Protocol for Authentication

Digest

Encryption DecryptionDigest

Plaintext

Compare

Protocol for Integrity

Protocol Building Blocks Digital Signatures Digital Envelopes Digital Certificates

• 비대칭형 암호의 공개키 (KbA) 확인 ?

• Trusted Third Party 의 확인 (= 인증 ) 필요

Alice Bob

KbA

KVA

MKV

A (M)

KbA

MKV

A (M)

M' = KbA(KV

A (M))M' = M ???

(e.g.) Message Authentication

인증서의 개념과 필요성 (1)

인증서의 개념과 필요성 (2)

Alice Bob

KbA

KVA

KVT(Kb

A)

MKV

A (M)

KbA

KVT(Kb

A)MKV

A (M)

M' = KbA(KV

A (M))M' = M ???

(e.g.) Message Authentication

Trent

KbT

KVT

KVT(Kb

A)

KbT

CA(Certificate Authority)

Certificate

인증기관의 계층 구조 (1)CA 1

CA 11 CA 12

BobAlice

Kb11

KV11

KV11(Kb

A)

KbA

KVA

KV11(Kb

A)

MKV

A (M)

KbA

KV11(Kb

A) ?MKV

A (M)

M' = KbA(KV

A (M))M' = M ???

Kb1

인증기관의 계층 구조 (2)CA 1

CA 11 CA 12

BobAlice

Kb1

KV1

KV1(Kb

11)KV

1(Kb12)

Kb11

KV11

KV1(Kb

11)KV

11(KbA)

KbA

KVA

KV1(Kb

11)KV

11(KbA)

MKV

A (M)

KbA

KV1(Kb

11)KV

11(KbA)

MKV

A (M)

M' = KbA(KV

A (M))M' = M ???

Kb1

인증기관의 계층 구조 (3)

CA 1

CA 12CA 11 CA 13

CA 112CA 111 CA 133

BobAlice Carol

…

…

• Certificate Chain Validation

Root CA

Encryption SummaryAlice’s Computer

PROPERTYEncrypt

Alice’s PrivateSignature Key

DigitalSignature

Alice’sCertificate

Bob’sCertificate

Encrypt

SymmetricKey

Encrypt

Bob’s PublicKey-Exchange

Key

EncryptedMessage

DigitalEnvelope

Bob’s Computer

DigitalEnvelope

Decrypt

Bob’s PrivateKey Exchange Key

EncryptedMessage

DigitalSignature

Decrypt

SymmetricKey

Decrypt

Alice’s PublicSignature Key

compare

Message Digest

Message Digest

Message Digest

1 2

3

4

7

8

6

10

9Message

5

EncryptedMessage

DigitalEnvelope

PROPERTYPROPERTY


Cryptography and Law SET 의 보안 목표

Confidentiality ( 기밀성 ) 신용카드 번호의 보안

Authentication ( 인증 ) 구매자가 카드의 소유자가

맞는가 ? Integrity ( 무결성 )

수취인이 변경되지 않았는가 ?

Linkage ( 연결성 ) 지불정보와 주문정보간의

연결성

보안 기법 대칭형 암호화 비대칭형 암호화 Message Digest

암호문 ( 전자문서 ) 의 법적 효력

국내 법규 전자거래 기본법 전자서명법

Applications

인터넷상의 전자지불시스템 전자현금 시스템

Ecash (DigiCash) 신용카드 기반 시스템

Green Commerce Model (First Virtual Holdings) SET (Visa & Master)

전자수표 시스템 Electronic Check (Financial Services Technology Co

nsortium) 전자 자금이체

Security First Network Bank

Electronic Check 전자수표 시스템 Financial Services Technology

Consortium (FSTC) 에서 수행한 프로젝트 현재의 종이로 된 수표의 모델을 구현 현재의 은행간 결제 통로를 이용

Electronic Check Presentment (ECP) Auto Clearing House (ACH) Network

전자현금 시스템 금액형 (IC 카드형 ) : 인증 , 무결성

개방형 / 폐쇄형 접촉식 / 비접촉식 익명카드 / 기명카드 server-side / client-side

Coin 형 ( 네트웍 형 ) : …

전자현금의 필수요소 Digital Cash & Monetary Freedom [J.W.Mato

nis] 보안성 (Security) 익명성 (Anonymity) 휴대가능 (Portability) 양방향 (Two-way) Off-line 에서도 수행가능 (Off-line capability) 가분성 (Divisibility) 영구성 (Infinite duration) 상용화 정도 (Wide acceptability) 사용자 친숙성 (User-friendly) 화폐발행의 자유 (Unit-of-value freedom)

DigiCash (1) 전자화폐 발행 - "Ecash"( 단위 : cyberbuck) 전자화폐 계좌 관리 - First Digital Bank (FDB) FDB 와의 인터페이스 : Digital Wallet 이라는

클라이언트 소프트웨어 이용 Mark Twain Bank (Boston, USA) 와 연계

DigiCash (2) 구매자에 대한 지원

클라이언트 소프트웨어 제공 : Digital Wallet 익명성 보장 : Blinded Withdrawal

판매자에 대한 지원 Ecash 지불 소프트웨어 지원 : 구매자들로

부터 자동적으로 Ecash 를 수집 Remote shop server: 자신의 서버가 없는

판매자들에게 인터넷 상점을 열도록 해 준다

DigiCash (3) 전자현금 시스템의 문제점 보완

개인정보 보호문제 - Blinded Withdrawal FDB 에서 발행하는 전자현금의 일련번호를

역추적 할 수 없도록 하는 기법으로 특정한 번호의 화폐가 누구에게 전해졌는지 알 수 없도록 한다

DigiCash (4) 전자현금의 중복사용 문제점 보완

A 에서 C 로 현금이 전달될때 이 현금은 일단 FDB 에 가서 중복사용이 아님을 확인한 후 C 에게로 돌아온다 .

현금 사용기한

신용카드 기반 시스템 기존의 신용카드 거래를 인터넷 상에서 지원 인터넷 상에서 가장 많이 구현되고 있는

시스템 효과적인 거래유형

소액의 물품구입이나 서비스의 대금 지불

기존 SSL 방식의 지불정보 보안

on-lineoff-line

대금

3. 지불정보4. 지불승인

상품

고객Browser

상인

TTF

카드사

1. 상품정보2. 주문 / 지불정보

대금

인증기관SSL 용인증서

SSLX.25 / 자체암호화

SSL (Secure Socket Layer)

SSL

Handshake

Protocol

SSL

Handshake

Protocol

Server Certificate

Client Certificate

Encrypted secret key

Digital signature

Encrypted data with MAC

* MAC : Message Authentication Code

ServerClient

SSLRecordProtocol

SSLRecordProtocol

기존 SSL 방식의 장단점 장점

단순 , 명료 개발 및 유지보수 용이 고객 사용 편리

웹 브라우저만 사용 인증서 자동 관리

단점 지불정보 ( 카드번호 , 계좌번호 , 비밀번호 , …) 가 상인에게

노출 보안성 낮음

DES key size = 40bits < 128bits RSA key size = 512bits < 1024bits

Secure Electronic Transaction 전자상거래에서 지불정보를 안전하고

비용효과적으로 처리할 수 있도록 규정한 프로토콜

신용카드 기준 VISA, Master Version 1.0 - 1997 년 5 월 31 일 발표

SET History 1995 MasterCard and others propose SEPP 1995 Visa and Microsoft propose STT Feb 1996 all parties agree on SET 1996 Trials based on preliminary version (V 0.

0) May 1997 V 1.0 in final form Nov 1997 Interoperability program begins Dec 1997 formation of SET Secure Electronic

Transaction, LLC (SetCo)

SET 의 목적 Payment Security

confidentiality authentication integrity linkage

Interoperability between various vendors existing standards exportable technology any combination of H/W

and S/W

Market Acceptance ease of implementation minimal impact on

merchant, acquirer, and payment system applications and infrastructure

minimize change to the relationship between acquirers and merchants, and cardholders and issuers

상품

고객 상인 금융기관

상품정보

주문 / 지불정보대금 ( 이체 )

지불정보

대금

out-of-scope

secure on-line

SET 의 대상

SET 의 참여자 Cardholders ( 고객 ) Merchants Payment Gateways Certificate Authorities

Key Authentication in PKI CCA, MCA, PCA, GCA, BCA, RCA

* Kerberos - Symmetric Algorithm, KDC

Merchant

FinancialInstitution

Cardholder

C C A

P G

P C AM C A

B C A

G C A

R C ASET-basedSystems

Out-of-scopeSystems

SET 기반 시스템 구조도

C

M

PG

CCA

MCA

PCA

C M PG CCA MCA PCA

-

-

-

-

-

-

PInitReqPReqInqReq

PInitResPResInqRes

CardCInitResRegFormResCertResCertInqRes

AuthResCapResAuthRevResCapRevResCredResCredRevResPCertResBatchAdminRes

Me-AqCInitResCertResCertInqRes

Me-AqCInitResCertResCertInqRes

AuthReqCapReqAuthRevReqCapRevReqCredReqCredRevReqPCertReqBatchAdminReq

CardCInitReqRegFormReqCertReqCertInqReq

Me-AqCInitReqCertReqCertInqReq

Me-AqCInitReqCertReqCertInqReq

Receiver

Sender

SET Transaction 의 종류

Cardholder MerchantPaymentGateway

PInitReq

PInitRes

PReq

AuthReq

AuthRes

PRes

Payment Flow


InqReq

InqRes

Inquiry Flow


AuthRevReq

AuthRevRes

Authorization Reversal Flow


CapReq

CapRes

Capture Flow


CapRevReq

CapRevRes

Capture Reversal Flow


CredReq

CredRes

Credit Flow


CredRevReq

CredRevRes

Credit Reversal Flow


PCertReq

PCertRes

PG Key Exchange Certificate


BatchAdminReq

BatchAdminRes

Batch Administration

Cardholder CCA

CardCInitReq

CardCInitRes

Cardholder Certificate Issuance

RegFormReq

RegFormRes

CertReq

CertRes

Merchant or PG

MCAor PCA

Me-AqCInitReq

Me-AqCInitRes

M or PG Certificate Issuance

CertReq

CertRes

Cardholder, Merchant, or PG

CCA,MCA,or PCA

CertInqReq

CertInqRes

Certificate Issuance Inquiry

Encryption SummaryAlice’s Computer

PROPERTYEncrypt

Alice’s PrivateSignature Key

DigitalSignature


Bob’sCertificate

Encrypt

SymmetricKey

Encrypt

Bob’s PublicKey-Exchange

Key

EncryptedMessage

DigitalEnvelope

Bob’s Computer

DigitalEnvelope

Decrypt

Bob’s PrivateKey Exchange Key

EncryptedMessage

DigitalSignature

Decrypt

SymmetricKey

Decrypt

Alice’s PublicSignature Key

compare

Message Digest

Message Digest

Message Digest

1 2

3

4

7

8

6

10

9Message

5

EncryptedMessage

DigitalEnvelope

PROPERTYPROPERTY


OIC

PIC

1 +

Payment Gateway

CCA

+

+

Purch ResM

MCA

+

Purchase Request & Response

PReq 메시지 구조PReq = < PReqDualSigned, PReqUnsigned >

PReqDualSigned = { PIDualSigned, OIDualSigned }

PIDualSigned ={ SO(C, PI-TBS), EX(P, PI-OILink, PANData) }

OIDualSigned = L(OIData, PIData)

Idempotency Message delivery is not guaranteed. SET allows the sender to repeat the

request with a guarantee that the outcome shall be the same regardless of whether the request was lost or the response was lost.

RRPID (Request/Response Pair ID.) and XID (Transaction ID.)

Interoperability Independent on H/W, S/W, and techniques. External standards supported by SET

network : MIME, HTTP, TCP/IP data representation & encoding : ASN.1, DER cryptography : DES, RSA, SHA-1, HMAC, PKCS,

OAEP certificates : X.509 ISO codes for country names, currencies, ...

Example of PInitReq (1) ASN.1

PInitReq ::= SEQUENCE {rrpid RRPID,language Language,localID-C LocalID,localID-M [0] LocalID OPTIONAL,chall-C Challenge,brandID BrandID,bin BIN,thumbs [1] EXPLICIT Thumbs OPTIONAL,piRqExtensions [2] MsgExtensions OPTIONAL }

DER Encoding Encoded = Identifier Octet

+ Length Octet+ Contents

e.g.)

"en "

1A 03 65 6E 20

Identifier Octet

Bit8 Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1

0 00 11 01 1

01

x x x x x

← universal← application← context-specific← private← primitive← construct

← tag number

Universal Tag Assignment 1 : Boolean 2 : Integer 3 : Bit String 4 : Octet String 5 : NULL 6 : Object Identifier 7 : Object Descriptor 8 : External 9 : Real

10 : Enumerated 12 - 15 : reserved 16 : Sequence, Seq

uence-of 17 : Set, Set-of 18-22, 25-27 : Char

acter String 23, 24 : Time 28 - … : reserved

Object Identifier All objects in the world has a unique identifier.

Person, Companies, Messages, Algorithms, …

Top Authorities CCITT (ITU) = 0 ISO = 1 Joint of ISO and CCITT = 2

e.g.)RSA = { 1, 2, 840, 113549, 1, 1, 1 }SET = { 2, 23, 42 }

Identifier Octet Example 01 : Boolean 02 : Integer 03 : Bit String 04 : Octet String 05 : NULL 06 : Object Identifier 07 : Object Descriptor 08 : External 09 : Real 0A : Enumerated

30 : Sequence, Sequence-of

31 : Set, Set-of 12 : Numeric String 13 : Printable String 14 : TeleTex String 15 : VideoTex String 16 : IA String 17 : Universal Time 18 : Generalized Time 1A : Visual String 1B : General String

Length octet Simple (1byte) : 0bbbbbbb Long : 1bbbbbbb xxH xxH xxH

뒤 Byte 수

xxxxxx : content octet 길이 (byte)

Content (1) Boolean

01 01 00 : false 01 01 FF : true

Bit String content octet 첫 byte 는 마지막 byte 의

사용하지 않는 bit 수 표시 0~7 NULL

05 00

Content (2) Object Identifier

byte1 = 1st number * 40 + second number

e.g.) { 2, 100, 3 } ==> 180, 3 180 = 10110100 ==> 0000001 0110100

06 03 813403

Example of PInitReq (2) DER Encoding

rrpid 04 14 87 FB 2B 3D 61 62 ...language 1A 03 65 6E 20 -- enlocalID-C 04 14 6C 69 64 63 2D 6C ...chall-C 04 14 88 FB 2B 3D 61 62 ...brandID 1A 0D 42 72 61 6E 64 3A ...bin 12 06 39 39 39 39 39 39thumbs A1 0D 30 0BdigestAlgorithm30 09algorithm 06 05 2B 0E 03 02 1A -- s

ha1

Messages in SETMessageWrapper ::= SEQUENCE {

messageHeader MessageHeader,message [0] EXPLICIT MESSAGE.&TYPE (Message),mwExtensions [1] MsgExtensions { { MWExtensionsIOS } }

OPTIONAL }MessageHeader ::= SEQUENCE {

version INTEGER { setVer1(1) } (setVer1),revision INTEGER (0) DEFAULT 0, -- V1.0… }

Message ::= CHOICE {purchaseInitRequest [0] EXPLICIT PInitReq,purchaseInitResponse [1] EXPLICIT PInitRes,… }

Example of PInitReq (3)3081A9304D020101180F31393937303931343039

303332315AA0078005313336353981147D65C916

1864C31442422EACE3976ABE919B099B1A185345

545245462053616D706C652043617264686F6C64

6572A058A056305404147D65C9161864C3144242

2EACE3976ABE919B099B1A02656E040531333635

390414E5E6F5E172CF833DB31F720E9EF1001BD2

F6CCB41A04433030311206333534393032A10D30

0B300906052B0E03021A0500

Merchant Signature

Cardholder Signature

CCA Sig.

PG Signature

PCA Sig.MCA Sig.

Brand Sig.

GCA Sig.

Root Sig.

PG Key Exchange

Merchant Key Exch.

Hierarchy of Trust

Certificate Chain Validation

Public Root Key (1) Root Certificate

Self-signed Certificate Root Certificate Generation

R1 = Root key pair #1 C1 = Certificate for Root key #1 (contains H2) R2 = Root key pair #2 H2 = Hash (thumbprint) of the public component of

R2

Public Root Key (2) Initial Distribution

The initial Root certificate, it’s public key or the hash of the public key are delivered with the SET application software.

Initial Authentication Compare the received Root certificate with

the delivered one. Compare the hash of the received Root

certificate with that entered by the EE.

Public Root Key (3) Update

R3 = public component of Root key #3 H3 = hash of R3 C2 = certificate for Root key #2 (contains

H3) Validation

validates the signature applied using R2 compares the hash of R2 with H2

Certificate Format of X.509 (1)Certificate ::= SIGNED {

EncodedCertificate}

SIGNED { ToBeSigned } ::= SEQUENCE {toBeSigned ToBeSigned,algorithm AlgorithmIdentifier {{SignatureAlgorithms}},signature BIT STRING

}

EncodedCertificate ::= TYPE-IDENTIFIER.&Type (UnsignedCertificate)

Certificate Format of X.509 (2)UnsignedCertificate ::= SEQUENCE {

version [0] CertificateVersion,serialNumber CertificateSerialNumber,signature AlgorithmIdentifier {{SignatureAlgorithms}},issuer Name,validity Validity,subject Name,subjectPublicKeyInfo SubjectPublicKeyInfo{{SupportedAlgorithms}},issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,extensions [3] Extensions

}

Certificate Extensions X.509 Extensions

KeyUsage PrivateKeyUsagePeriod …

SET Private Extensions HashedRootKey : only in Root certificates CertificateType …

Certificate Validity

e.g.)

C : 1998.6.10 ~ 1999.6.9

CCA : 1998.1.1 ~ 1998.12.31

Cardholder’s certificate is INVALID after 1998.12.31 !!!

Certificate Usage Period (1)

e.g.)

C : 1998.6.10 ~ 1999.6.9 certificate

1998.6.10 ~ 1999.6.9 private key

CCA : 1998.1.1 ~ 1999.12.31 certificate

1998.1.1 ~ 1998.12.31 private key

Certificate Usage Period (2)

e.g.)

C : 1998.6.10 ~ 1999.6.9

CCA : 1998.1.1 ~ 1999.12.31

GCA : 1998.1.1 ~ 2000.12.31

BCA : 1998.1.1 ~ 2001.12.31

RCA : 1998.1.1 ~ 2002.12.31

Algorithm IdentifierAlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet }

::= SEQUENCE {

algorithm ALGORITHM-IDENTIFIER.&id({InfoObjectSet}),

parameters ALGORITHM-IDENTIFIER.&Type(

{InfoObjectSet} {@algorithm}) OPTIONAL

}

Name (1) Cardholder Name

Country Name=Country of Issuing Financial Institute

Organization Name=Brand ID Organizational Unit Name=Name of Issuing

Financial Institute Organizational Unit Name=Promotional Card

Name(Optional) Common Name=Unique Cardholder ID

Name (2) Object Identifier

Country Name = { 2, 5, 4, 6 } Organization Name = { 2, 5, 4, 10 } Organizational Unit Name = { 2, 5, 4, 11 } Common Name = { 2, 5, 4, 3 }

Unique Cardholder ID Keyed-hashed Account Number HMAC-SHA1 algorithm

Certificate Revocation Cardholder Certificate Cancellation

Issuer maintains the list of canceled payment cards.

Merchant Certificate Cancellation PG maintains the list of the merchants.

Payment Gateway Certificate Revocation PCA include the certificate in CRLs (Certificate Re

vocation Lists).

CA Compromise Recovery (1) Distribution of CA CRL

PCA → PG : Me-AqCInitRes message CCA → C : in all downstream response PG → M : AuthRes message M → C : PInitRes or PRes message

Signed Data (PKCS#7)SignedData ::= SEQUENCE {

sdVersion INTEGER { sdVer2(2) } (sdVer2),

digestAlgorithm DigestAlgorithmIdentifiers,

contentInfo ContentInfo,

certificates [2] IMPLICIT Certificates OPTIONAL,

crls [3] IMPLICIT CRLSequence OPTIONAL,

signerInfos SignerInfos

}

PInitResPInitRes ::= S { M, PInitResData }

S { SIGNER, ToBeSigned } ::= SignedData ( … )

PInitResData ::= SEQUENCE {transIDs TransIDs,rrpid RRPID,chall-C Challenge,chall-M Challenge,brandCRLIdentifier [0] EXPLICIT BrandCRLIdentifier OPTIONALpeThumb [1] EXPLICIT CertThumb,thumbs [2] EXPLICIT Thumbs OPTIONAL,piRsExtensions [3] MsgExtensions {{ PIRsExtensionsIOS }}

OPTIONAL }

CA Compromise Recovery (2) BrandCRLIdentifier

list of all CA CRLs that are current The CAs and Payment Gateway are respo

nsible for retrieving the BCI Distribution message on a daily basis.

The BCI is included in all downstream response messages.

SET Criticisms Not interoperable yet Not general availability Too complex Too slow performance Doesn’t support

Smartcards Debit Cards Micropayments Anonymous cash

SET Version 2.0 1998 년 말 발표 예정 ← 미 발표 포함내용

Smartcard (chipcard) support Debit card support Multi-crypto algorithms (including ECC

알고리즘 )

Secure Debit Transaction

SET 의 지불정보 보안

on-lineoff-line

대금

3. 지불정보

4. 지불승인상품상인 P

G

1. 상품정보

2. 주문 / 지불정보

대금

인증기관

인증서

SET 정의 암호화X.25 / 자체암호화

카드사Host

인증서 인증서

Out-of-scope

고객Browser

Wallet

SET 방식의 장단점 장점

지불정보가 상인에게 노출되지 않도록 이중 (dual)으로 암호와

보안성 높음 (Key size 큼 ) 단점

시스템이 복잡해지고 시스템 부하가 큼 별도의 고객 S/W(Digital Wallet) 필요

사용 불편 ( 별도의 사용법 , Setup) 유지보수 어려움

SDT 의 지불정보 보안

5. 이체통보

상품

1. 상품정보2. 주문정보

고객WebBrowser

상인

고객은행

4. 대금 ( 이체 )대금3. 지불정보

상인은행

대금

인증기관

인증서

인증서

on-lineoff-line

SSL (128 bits)SDT 정의 암호화

기존 은행망

SSL 인증서

SDT 의 보안 목표 기밀성

지불정보 인증

고객 인증 고객은행 인증 상인 인증

무결성 지불정보 이체통보

SDT 의 주 내용 고객 – 상인

상인의 웹 사이트 ( 쇼핑몰 ) 에서 장바구니를 이용하여 주문정보 전달

고객 – 고객은행 고객은행의 웹사이트에서 지불정보 입력 보안이 강화된 (128 bits) SSL 사용

고객 인증서 사용 방식 / Password 방식 E.g.) Xecure-Web

고객은행 – 상인은행 기존의 은행망을 사용하여 계좌이체

고객은행 – 상인 SDT 가 정의한 내용에 따라 이체 통보 메시지를 암호화하여

전달 인증기관 – 고객 , 상인 , 고객은행

인증서 발행

SDT 의 특징 단순 , 명료 개발 및 유지보수 용이 고객 사용 편리 ( 웹 브라우저만 사용 ) 보안성 높음 (key size = 128 bits) 지불정보가 상인에게 노출되지 않음 직불 외에 신용카드 지불 등에도 수정 없이

사용가능

SDT 의 의의 기존 방식은 지불정보가 상인에게 노출되는 것을

용인하거나 , 아니면 노출되지 않도록 하기 위하여 복잡한 과정을 거쳐야 했음

지불정보가 상인을 거치지 않고 금융기관에 직접 전달되도록 처리 고객이 지불 정보를 금융기관의 웹 사이트에 직접

입력하도록 함 이때 , 고객은 금융기관의 URL 을 확인할 수 있음

네트웍 상 도청 등의 방지는 보안이 강화된 SSL(Key size = 128bits) 을 사용

SDT 사용상의 이점 사용자 입장

자신의 지불 정보가 상인에게 전달되지 않으므로 지불 정보 보안에 좀 더 확신을 가질 수 있음

상인 입장 고객의 지불 정보를 자신이 직접 다루지 않으므로 지불

정보 관련 사고 발생시 책임회피 가능 금융기관 입장

개별 금융기관별로 고객 인증을 위한 나름대로의 방법 적용 가능 . 따라서 , 사고 발생의 소지를 줄일 수 있음

SI 업체 표준 Solution 개발 및 판매 가능

SCT, SMT, SQT, … SDT (Secure Debit Transation)

직불 SCT (Secure Credit Transaction)

신용카드 , 후불 SMT (Secure Money Transaction

전자현금 SQT (Secure Cheque Transaction)

수표 , 어음

SCT 의 지불정보 보안

4. 승인통보

상품

1. 상품정보2. 주문정보

고객WebBrowser

상인

고객카드사

대금대금3. 지불정보

상인은행

대금

인증기관

인증서

인증서

on-lineoff-line

SSL (128 bits)SCT 정의 암호화

기존 은행망

SSL 인증서5. Capture

요약 Technologies

암호학 대칭형 , 비대칭형 , 메시지다이제스트 전자서명 , 전자봉투 , 전자인증서 전자문서와 법률

Applications 전자수표 , 전자현금 , 신용카드 , 계좌이체

technologies and applications of secure epayment systems

Documents