Transcript Cryptography

Technologies and Applications
of Secure ePayment Systems
Introduction
바람직한 전자상거래의 구조
상품정보
지불정보
고객 주문/지불정보 상인
대금(이체)
상품
금융
기관
대금
secure on-line
on-line
off-line
Green Commerce Model
Credit Card
Company
Real
Bank
Green Commerce
Server
messages
Buyer
messages
goods
Merchant
Technologies
Terminology








plaintext
ciphertext
encryption
decryption
cryptography
cryptographers
cryptanalysis
cryptanalysts






cryptology
cryptologists
cipher
(cryptographic
algorithm)
key
keyspace
cryptosystem
Encryption and Decryption
Plaintext
Encryption
Ciphertext
Decryption
Original
Plaintext
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)




homophonic substitution cipher
polygram substitution cipher
polyalphabetic substitution cipher


Caesar Cipher
running-key cipher
Transposition Ciphers
Operations in Ciphers (2)


Character-based Algorithms
Bit-based Algorithms
Encryption and Decryption
with a Key


Restricted algorithms
Key-based algorithms
K
Plaintext
Encryption
K
Ciphertext
Decryption
Original
Plaintext
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 Algorithms
c.f. Message Digest

대칭형 암호화
K
Plaintext
Encryption
K
Ciphertext
Decryption
• Symmetric Algorithm, Secret-key Algorithm,
비밀키 암호화 방식
• DES, IDEA, SEED
• 속도 빠름, 메시지 길이제한 없음
• 키 교환이 어려움
Original
Plaintext
비대칭형 암호화
KB
Plaintext
Encryption
KV
Ciphertext
Decryption
• Asymmetric Algorithm, Public-key Algorithm,
공개키 암호화 방식
• RSA, LUC, DSS
• 속도 느림, 메시지 길이에 제한
• 키 교환이 쉬움
Original
Plaintext
공개키 암호시스템의 비교
알고리즘
디지털 서명
키교환
암호/복호화
RSA
가능
가능
가능
LUC
가능
가능
가능
DSS
가능
불가능
불가능
Diffie-Hellman
불가능
가능
불가능
메시지 다이제스트
Message
Digest
• One-way Hash Function
• Message Digest
• MD2, MD4, MD5, SHA, SHA-1
Digested
Message
Cryptanalysis

Kerckhoffs’s assumption

The cryptanalyst has complete details of
the cryptographic algorithm and
implementation.
Security of Algorithms

Unconditionally secure
one-time pad
c.f. brute-force attack



a ciphertext-only attack
Computationally secure



Data complexity
Processing complexity
Storage requirements
Protocol for Confidentiality
Step 1:
KS
Step 2:
Plaintext
KB
Encryption
KV
KB(KS)
KS
Encryption
Decryption
KS
KS
Ciphertext
Decryption
Original
Plaintext
Protocol for Authentication
KV
Plaintext
Encryption
KB
Ciphertext
Decryption
Original
Plaintext
• 부인방지는 Ciphertext를 저장해 둠으로써 이룰 수 있음
•+a
Protocol for Integrity
Plaintext
Digest
Compare
Digest
Encryption
Decryption
Protocol Building Blocks



Digital Signatures
Digital Envelopes
Digital Certificates
인증서의 개념과 필요성 (1)
(e.g.) Message Authentication
Alice
KbA
KVA
M
KVA (M)
Bob
KbA
M
KVA (M)
M' = KbA(KVA (M))
M' = M ???
• 비대칭형 암호의 공개키(KbA) 확인 ?
• Trusted Third Party의 확인(=인증) 필요
인증서의 개념과 필요성 (2)
(e.g.) Message Authentication
Trent
KbT
KVT
Alice
KbA
KVA
KVT(KbA)
M
KVA (M)
KVT(KbA)
CA
(Certificate Authority)
Certificate
Bob
KbT
KbA
KVT(KbA)
M
KVA (M)
M' = KbA(KVA (M))
M' = M ???
인증기관의 계층 구조 (1)
CA 1
CA 11
Kb11
KV11
CA 12
KV11(KbA)
Kb1
Alice
KbA
KVA
KV11(KbA)
M
KVA (M)
Bob
KbA
KV11(KbA) ?
M
KVA (M)
M' = KbA(KVA (M))
M' = M ???
인증기관의 계층
구조 (2)
K
CA 1
b
1
KV1
KV1(Kb11)
KV1(Kb12)
CA 11
Kb11
KV11
CA 12
KV1(Kb11)
KV11(KbA)
Alice
KbA
KVA
KV1(Kb11)
KV11(KbA)
M
KVA (M)
Kb1
Bob
KbA
KV1(Kb11)
KV11(KbA)
M
KVA (M)
M' = KbA(KVA (M))
M' = M ???
인증기관의 계층 구조 (3)
Root CA
CA 1
CA 11
CA 111
Alice
CA 12
CA 112
Bob
• Certificate Chain Validation
CA 13
…
Carol
CA 133
…
Encryption Summary
Bob’s Computer
Alice’s Computer
1
2
Bob’s Private
Key Exchange Key
Alice’s Private
Signature Key
PROPERTY
Decrypt
Encrypt
Digital
Signature
Message Digest
5
Digital
Envelope
6
9
Message
PROPERTY
PROPERTY
3
Message
Digest
7
Encrypt
Symmetric
Key
Alice’s
Certificate
Decrypt
Encrypted
Message
Encrypted
Message
Symmetric
Key
Encrypted
Message
10
Alice’s
Certificate
Digital
Envelope
4
Bob’s
Certificate
compare
8
Encrypt
Decrypt
Bob’s Public
Key-Exchange
Key
Digital
Envelope
Digital
Signature
Alice’s Public
Signature Key
Message
Digest
Cryptography and Law

SET의 보안 목표


신용카드 번호의 보안

Authentication (인증)


수취인이 변경되지 않았
는가?
Linkage (연결성)


구매자가 카드의 소유자
가 맞는가?
Integrity (무결성)


보안 기법
Confidentiality (기밀성)



지불정보와 주문정보간
의 연결성


대칭형 암호화
비대칭형 암호화
Message Digest
암호문(전자문서)의 법
적 효력
국내 법규


전자거래 기본법
전자서명법
Applications
인터넷상의 전자지불시스템

전자현금 시스템


신용카드 기반 시스템



Green Commerce Model (First Virtual Holdings)
SET (Visa & Master)
전자수표 시스템


Ecash (DigiCash)
Electronic Check (Financial Services Technology
Consortium)
전자 자금이체

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.Matonis]










보안성(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 방식의 지불정보 보안
인증기관
SSL용
인증서
1. 상품정보
고객
Browser
3. 지불정보
상인
2. 주문/지불정보
TTF
상품
4. 지불승인
대금
대금
on-line
off-line
SSL
X.25 / 자체암호화
카
드
사
SSL (Secure Socket Layer)
Client
Server
Server Certificate
SSL
Client Certificate
SSL
Handshake
Encrypted secret key
Handshake
Protocol
SSL
Record
Protocol
Digital signature
Encrypted data with MAC
* MAC : Message Authentication Code
Protocol
SSL
Record
Protocol
기존 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

Market Acceptance


Interoperability




between various vendors
existing standards
exportable technology
any combination of H/W
and S/W

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
SET의 대상
상품정보
지불정보
고객 주문/지불정보 상인
대금(이체)
상품
금융
기관
대금
secure on-line
out-of-scope
SET의 참여자




Cardholders (고객)
Merchants
Payment Gateways
Certificate Authorities


Key Authentication in PKI
CCA, MCA, PCA, GCA, BCA, RCA
* Kerberos - Symmetric Algorithm, KDC
SET 기반 시스템 구조도
SET-based
Systems
Out-ofscope
Systems
RCA
BCA
GCA
CCA
MCA
PCA
Financial
Institution
Cardholder
Merchant
PG
SET Transaction의 종류
Receiver
Sender
C
C
-
M
PInitReq
PReq
InqReq
AuthRes
CapRes
AuthRevRes
CapRevRes
CredRes
CredRevRes
PCertRes
BatchAdminRes
PG
CCA
MCA
PCA
CCA
MCA
PCA
CardCInitReq
RegFormReq
CertReq
CertInqReq
PInitRes
PRes
InqRes
M
PG
AuthReq
CapReq
AuthRevReq
CapRevReq
CredReq
CredRevReq
PCertReq
BatchAdminReq
Me-AqCInitReq
CertReq
CertInqReq
Me-AqCInitReq
CertReq
CertInqReq
-
CardCInitRes
RegFormRes
CertRes
CertInqRes
Me-AqCInitRes
CertRes
CertInqRes
Me-AqCInitRes
CertRes
CertInqRes
-
Payment Flow
Cardholder
Payment
Gateway
Merchant
PInitReq
PInitRes
PReq
AuthReq
AuthRes
PRes
Inquiry Flow
Cardholder
Merchant
InqReq
InqRes
Payment
Gateway
Authorization Reversal Flow
Cardholder
Payment
Gateway
Merchant
AuthRevReq
AuthRevRes
Capture Flow
Cardholder
Payment
Gateway
Merchant
CapReq
CapRes
Capture Reversal Flow
Cardholder
Payment
Gateway
Merchant
CapRevReq
CapRevRes
Credit Flow
Cardholder
Payment
Gateway
Merchant
CredReq
CredRes
Credit Reversal Flow
Cardholder
Payment
Gateway
Merchant
CredRevReq
CredRevRes
PG Key Exchange Certificate
Cardholder
Payment
Gateway
Merchant
PCertReq
PCertRes
Batch Administration
Cardholder
Merchant
Payment
Gateway
BatchAdminReq
BatchAdminRes
Cardholder Certificate
Issuance
Cardholder
CCA
CardCInitReq
CardCInitRes
RegFormReq
RegFormRes
CertReq
CertRes
M or PG Certificate Issuance
Merchant
or PG
MCA
or PCA
Me-AqCInitReq
Me-AqCInitRes
CertReq
CertRes
Certificate Issuance Inquiry
Cardholder,
Merchant,
or PG
CCA,
MCA,
or PCA
CertInqReq
CertInqRes
Encryption Summary
Bob’s Computer
Alice’s Computer
1
2
Bob’s Private
Key Exchange Key
Alice’s Private
Signature Key
PROPERTY
Decrypt
Encrypt
Digital
Signature
Message Digest
5
Digital
Envelope
6
9
Message
PROPERTY
PROPERTY
3
Message
Digest
7
Encrypt
Symmetric
Key
Alice’s
Certificate
Decrypt
Encrypted
Message
Encrypted
Message
Symmetric
Key
Encrypted
Message
10
Alice’s
Certificate
Digital
Envelope
4
Bob’s
Certificate
compare
8
Encrypt
Decrypt
Bob’s Public
Key-Exchange
Key
Digital
Envelope
Digital
Signature
Alice’s Public
Signature Key
Message
Digest
Purchase Request &
Response
OI
C
+
Payment Gateway
Purch Res
+
1
+
PI
C
+
C
M
CA
M
CA
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
0
0
1
1
0
1
0
1
Bit6
Bit5
Bit4
0
1
x
x
Bit3
Bit2
Bit1
← universal
← application
← context-specific
← private
← primitive
← construct
x
x
x
← 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,
Sequence-of
17 : Set, Set-of
18-22, 25-27 :
Character 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



Bit String


01 01 00 : false
01 01 FF : true
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
language
localID-C
chall-C
brandID
bin
thumbs
digestAlgorithm
algorithm
04 14 87 FB 2B 3D 61 62 ...
1A 03 65 6E 20
-- en
04 14 6C 69 64 63 2D 6C ...
04 14 88 FB 2B 3D 61 62 ...
1A 0D 42 72 61 6E 64 3A ...
12 06 39 39 39 39 39 39
A1 0D 30 0B
30 09
06 05 2B 0E 03 02 1A
-- sha1
Messages in SET
MessageWrapper ::= 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
Certificate Chain Validation
Hierarchy of Trust
Root Sig.
Brand Sig.
GCA Sig.
CCA Sig.
Cardholder
Signature
Merchant
Signature
MCA Sig.
Merchant
Key Exch.
PCA Sig.
PG
Signature
PG Key
Exchange
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:
CCA :
1998.6.10 ~ 1999.6.9
1998.1.1 ~ 1998.12.31
Cardholder’s certificate is INVALID after
1998.12.31 !!!
Certificate Usage Period (1)
e.g.)
C:
CCA :
1998.6.10 ~ 1999.6.9 certificate
1998.6.10 ~ 1999.6.9 private key
1998.1.1 ~ 1999.12.31 certificate
1998.1.1 ~ 1998.12.31 private key
Certificate Usage Period (2)
e.g.)
C:
CCA :
GCA :
BCA :
RCA :
1998.6.10 ~ 1999.6.9
1998.1.1 ~ 1999.12.31
1998.1.1 ~ 2000.12.31
1998.1.1 ~ 2001.12.31
1998.1.1 ~ 2002.12.31
Algorithm Identifier
AlgorithmIdentifier { 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


Merchant Certificate Cancellation


Issuer maintains the list of canceled payment
cards.
PG maintains the list of the merchants.
Payment Gateway Certificate Revocation

PCA include the certificate in CRLs (Certificate
Revocation 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
}
PInitRes
PInitRes ::= S { M, PInitResData }
S { SIGNER, ToBeSigned } ::= SignedData ( … )
PInitResData ::= SEQUENCE {
transIDs
TransIDs,
rrpid
RRPID,
chall-C
Challenge,
chall-M
Challenge,
brandCRLIdentifier
[0] EXPLICIT BrandCRLIdentifier OPTIONAL
peThumb
[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
responsible 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의 지불정보 보안
Out-ofscope
인증기관
인증서
고객
Browser
Wallet
인증서
1. 상품정보
2. 주문/지불정보
인증서
3. 지불정보
상인
상품
4. 지불승인
P
G
대금
대금
on-line
off-line
SET 정의 암호화
X.25 / 자체암호화
카드사
Host
SET 방식의 장단점

장점



지불정보가 상인에게 노출되지 않도록 이중(dual)
으로 암호와
보안성 높음 (Key size 큼)
단점


시스템이 복잡해지고 시스템 부하가 큼
별도의 고객 S/W(Digital Wallet) 필요


사용 불편 (별도의 사용법, Setup)
유지보수 어려움
SDT의 지불정보 보안
고객
Web
Browser
1. 상품정보
2. 주문정보
상인
상품
SSL 인증서
5. 이체통보
on-line
off-line
3. 지불정보
대금
인증서
인증
기관
인증서
대금
고객 4. 대금(이체) 상인
은행
은행
SSL (128 bits)
SDT 정의 암호화
기존 은행망
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의 지불정보 보안
고객
Web
Browser
1. 상품정보
인증서
인증
2. 주문정보
상인
기관
상품
SSL 인증서
인증서
5. Capture
4. 승인통보
대금
3. 지불정보
상인
고객
대금
대금
카드사
은행
on-line
off-line
SSL (128 bits)
SCT 정의 암호화
기존 은행망
요약

Technologies





암호학
대칭형, 비대칭형, 메시지다이제스트
전자서명, 전자봉투, 전자인증서
전자문서와 법률
Applications

전자수표, 전자현금, 신용카드, 계좌이체