Technologies and applications of secure epayment systems
This presentation is the property of its rightful owner.
Sponsored Links
1 / 113

Technologies and Applications of Secure ePayment Systems PowerPoint PPT Presentation


  • 76 Views
  • Uploaded on
  • Presentation posted in: General

Technologies and Applications of Secure ePayment Systems. Introduction. 바람직한 전자상거래의 구조. 상품정보. 고객. 상인. 금융 기관. 지불정보. 주문 / 지불정보. 대금 ( 이체 ). 상품. 대금. secure on-line. on-line. off-line. Credit Card Company. Real Bank. Green Commerce Server. messages. messages. Buyer. goods.

Download Presentation

Technologies and Applications of Secure ePayment Systems

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Technologies and applications of secure epayment systems

Technologies and Applications of Secure ePayment Systems


Introduction

Introduction


Technologies and applications of secure epayment systems

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

상품정보

고객

상인

금융

기관

지불정보

주문/지불정보

대금(이체)

상품

대금

secure on-line

on-line

off-line


Green commerce model

Credit Card Company

Real

Bank

Green Commerce Server

messages

messages

Buyer

goods

Merchant

Green Commerce Model


Technologies

Technologies


Terminology

plaintext

ciphertext

encryption

decryption

cryptography

cryptographers

cryptanalysis

cryptanalysts

cryptology

cryptologists

cipher (cryptographic algorithm)

key

keyspace

cryptosystem

Terminology


Encryption and decryption

Encryption and Decryption

Original

Plaintext

Plaintext

Ciphertext

Encryption

Decryption


Categories of security services iso iec7498 2

Categories of Security Services (ISO/IEC7498-2)

  • Authentication

  • Access Control

  • Data Confidentiality

  • Data Integrity

  • Non-repudiation


Operations in ciphers 1

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

Operations in Ciphers (2)

  • Character-based Algorithms

  • Bit-based Algorithms


Encryption and decryption with a key

Encryption and Decryption with a Key

  • Restricted algorithms

  • Key-based algorithms

K

K

Original

Plaintext

Plaintext

Ciphertext

Encryption

Decryption


Types of 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 Algorithms

    c.f. Message Digest


Technologies and applications of secure epayment systems

대칭형 암호화

K

K

Original

Plaintext

Plaintext

Ciphertext

Encryption

Decryption

  • Symmetric Algorithm, Secret-key Algorithm,

  • 비밀키 암호화 방식

  • DES, IDEA, SEED

  • 속도 빠름, 메시지 길이제한 없음

  • 키 교환이 어려움


Technologies and applications of secure epayment systems

비대칭형 암호화

KB

KV

Original

Plaintext

Plaintext

Ciphertext

Encryption

Decryption

  • Asymmetric Algorithm, Public-key Algorithm,

  • 공개키 암호화 방식

  • RSA, LUC, DSS

  • 속도 느림, 메시지 길이에 제한

  • 키 교환이 쉬움


Technologies and applications of secure epayment systems

공개키 암호시스템의 비교

알고리즘

디지털 서명

키교환

암호/복호화

RSA

가능

가능

가능

LUC

가능

가능

가능

DSS

가능

불가능

불가능

불가능

가능

불가능

Diffie-Hellman


Technologies and applications of secure epayment systems

메시지 다이제스트

Digested

Message

Message

Digest

  • One-way Hash Function

  • Message Digest

  • MD2, MD4, MD5, SHA, SHA-1


Cryptanalysis

Cryptanalysis

  • Kerckhoffs’s assumption

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


Security of algorithms

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:

Step 2:

Protocol for Confidentiality

KB

KV

KS

KS

KB(KS)

Encryption

Decryption

KS

KS

Original

Plaintext

Plaintext

Ciphertext

Encryption

Decryption


Protocol for authentication

Protocol for Authentication

KV

KB

Original

Plaintext

Plaintext

Ciphertext

Encryption

Decryption

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

  • + a


Protocol for integrity

Digest

Digest

Protocol for Integrity

Plaintext

Compare

Encryption

Decryption


Protocol building blocks

Protocol Building Blocks

  • Digital Signatures

  • Digital Envelopes

  • Digital Certificates


Technologies and applications of secure epayment systems

Alice

Bob

KbA

KVA

KbA

M

KVA (M)

M

KVA (M)

M' = KbA(KVA (M))

M' = M ???

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

(e.g.) Message Authentication

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

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


Technologies and applications of secure epayment systems

(e.g.) Message Authentication

CA

(Certificate Authority)

Trent

Certificate

KbT

KVT

KVT(KbA)

Alice

Bob

KbT

KbA

KVA

KVT(KbA)

KbA

KVT(KbA)

M

KVA (M)

M

KVA (M)

M' = KbA(KVA (M))

M' = M ???

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


Technologies and applications of secure epayment systems

CA 1

Kb11

KV11

CA 11

CA 12

KV11(KbA)

Kb1

KbA

KV11(KbA) ?

M

KVA (M)

KbA

KVA

Alice

Bob

KV11(KbA)

M

KVA (M)

M' = KbA(KVA (M))

M' = M ???

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


Technologies and applications of secure epayment systems

Kb1

KV1

CA 1

KV1(Kb11)

KV1(Kb12)

Kb11

KV11

CA 11

CA 12

KV1(Kb11)

KV11(KbA)

Kb1

KbA

KV1(Kb11)

KV11(KbA)

M

KVA (M)

KbA

KVA

Alice

Bob

KV1(Kb11)

KV11(KbA)

M

KVA (M)

M' = KbA(KVA (M))

M' = M ???

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


Technologies and applications of secure epayment systems

Root CA

CA 1

CA 11

CA 12

CA 13

CA 111

CA 112

CA 133

Alice

Bob

Carol

  • Certificate Chain Validation

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


Encryption summary

Bob’s Computer

Alice’s Computer

Bob’s Private

Key Exchange Key

1

2

Alice’s Private

Signature Key

PROPERTY

Decrypt

Encrypt

Digital

Signature

Digital

Envelope

6

Message Digest

5

9

Message

PROPERTY

PROPERTY

Message

Digest

3

7

Decrypt

Encrypted

Message

Symmetric

Key

Encrypt

Symmetric

Key

Encrypted

Message

Encrypted

Message

10

Alice’s

Certificate

Alice’s

Certificate

Digital

Envelope

compare

4

8

Bob’s

Certificate

Encrypt

Decrypt

Message

Digest

Digital

Envelope

Digital

Signature

Bob’s Public

Key-Exchange

Key

Alice’s Public

Signature Key

Encryption Summary


Cryptography and law

SET의 보안 목표

Confidentiality (기밀성)

신용카드 번호의 보안

Authentication (인증)

구매자가 카드의 소유자가 맞는가?

Integrity (무결성)

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

Linkage (연결성)

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

보안 기법

대칭형 암호화

비대칭형 암호화

Message Digest

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

국내 법규

전자거래 기본법

전자서명법

Cryptography and Law


Applications

Applications


Technologies and applications of secure epayment systems

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

  • 전자현금 시스템

    • Ecash (DigiCash)

  • 신용카드 기반 시스템

    • Green Commerce Model (First Virtual Holdings)

    • SET (Visa & Master)

  • 전자수표 시스템

    • Electronic Check (Financial Services Technology Consortium)

  • 전자 자금이체

    • Security First Network Bank


Electronic check

Electronic Check

  • 전자수표 시스템

  • Financial Services Technology Consortium (FSTC)에서 수행한 프로젝트

  • 현재의 종이로 된 수표의 모델을 구현

  • 현재의 은행간 결제 통로를 이용

    • Electronic Check Presentment (ECP)

    • Auto Clearing House (ACH) Network


Technologies and applications of secure epayment systems

전자현금 시스템

  • 금액형(IC 카드형): 인증, 무결성

    • 개방형 / 폐쇄형

    • 접촉식 / 비접촉식

    • 익명카드 / 기명카드

    • server-side / client-side

  • Coin 형(네트웍 형): …


Technologies and applications of secure epayment systems

전자현금의 필수요소

  • 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

DigiCash (1)

  • 전자화폐 발행 - "Ecash"(단위: cyberbuck)

  • 전자화폐 계좌 관리 - First Digital Bank (FDB)

  • FDB와의 인터페이스: Digital Wallet이라는 클라이언트 소프트웨어 이용

  • Mark Twain Bank (Boston, USA)와 연계


Digicash 2

DigiCash (2)

  • 구매자에 대한 지원

    • 클라이언트 소프트웨어 제공 : Digital Wallet

    • 익명성 보장 : Blinded Withdrawal

  • 판매자에 대한 지원

    • Ecash 지불 소프트웨어 지원: 구매자들로 부터 자동적으로 Ecash를 수집

    • Remote shop server: 자신의 서버가 없는 판매자들에게 인터넷 상점을 열도록 해 준다


Digicash 3

DigiCash (3)

  • 전자현금 시스템의 문제점 보완

    • 개인정보 보호문제 - Blinded Withdrawal

      • FDB에서 발행하는 전자현금의 일련번호를 역추적 할 수 없도록 하는 기법으로 특정한 번호의 화폐가 누구에게 전해졌는지 알 수 없도록 한다


Digicash 4

DigiCash (4)

  • 전자현금의 중복사용 문제점 보완

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

    • 현금 사용기한


Technologies and applications of secure epayment systems

신용카드 기반 시스템

  • 기존의 신용카드 거래를 인터넷 상에서 지원

  • 인터넷 상에서 가장 많이 구현되고 있는 시스템

  • 효과적인 거래유형

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


Technologies and applications of secure epayment systems

인증기관

SSL용

인증서

1. 상품정보

3. 지불정보

고객

Browser

상인

TTF

2. 주문/지불정보

4. 지불승인

상품

대금

대금

on-line

SSL

off-line

X.25 / 자체암호화

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


Ssl secure socket layer

SSL (Secure Socket Layer)

Client

Server

Server Certificate

SSL

Handshake

Protocol

SSL

Handshake

Protocol

Client Certificate

Encrypted secret key

Digital signature

SSL

Record

Protocol

SSL

Record

Protocol

Encrypted data with MAC

* MAC : Message Authentication Code


Technologies and applications of secure epayment systems

기존 SSL 방식의 장단점

  • 장점

    • 단순, 명료

    • 개발 및 유지보수 용이

    • 고객 사용 편리

      • 웹 브라우저만 사용

      • 인증서 자동 관리

  • 단점

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

    • 보안성 낮음

      • DES key size = 40bits< 128bits

      • RSA key size = 512bits< 1024bits


Secure electronic transaction

Secure Electronic Transaction

  • 전자상거래에서 지불정보를 안전하고 비용효과적으로 처리할 수 있도록 규정한 프로토콜

  • 신용카드 기준

  • VISA, Master

  • Version 1.0 - 1997년 5월 31일 발표


Set history

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)


Technologies and applications of secure epayment systems

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

SET의 목적


Technologies and applications of secure epayment systems

SET의 대상

상품정보

고객

상인

금융

기관

지불정보

주문/지불정보

대금(이체)

상품

대금

secure on-line

out-of-scope


Technologies and applications of secure epayment systems

SET의 참여자

  • Cardholders (고객)

  • Merchants

  • Payment Gateways

  • Certificate Authorities

    • Key Authentication in PKI

    • CCA, MCA, PCA, GCA, BCA, RCA

      * Kerberos - Symmetric Algorithm, KDC


Technologies and applications of secure epayment systems

SET 기반 시스템 구조도

SET-based

Systems

Out-of-scope

Systems

R C A

B C A

G C A

P C A

C C A

M C A

Financial

Institution

Cardholder

Merchant

P G


Set transaction

Receiver

C

M

PG

CCA

MCA

PCA

Sender

PInitReq

PReq

InqReq

CardCInitReq

RegFormReq

CertReq

CertInqReq

C

-

PInitRes

PRes

InqRes

AuthReq

CapReq

AuthRevReq

CapRevReq

CredReq

CredRevReq

PCertReq

BatchAdminReq

Me-AqCInitReq

CertReq

CertInqReq

M

-

AuthRes

CapRes

AuthRevRes

CapRevRes

CredRes

CredRevRes

PCertRes

BatchAdminRes

Me-AqCInitReq

CertReq

CertInqReq

PG

-

CardCInitRes

RegFormRes

CertRes

CertInqRes

CCA

-

MCA

Me-AqCInitRes

CertRes

CertInqRes

-

PCA

Me-AqCInitRes

CertRes

CertInqRes

-

SET Transaction의 종류


Payment flow

PInitReq

PInitRes

PReq

AuthReq

AuthRes

PRes

Payment Flow

Cardholder

Merchant

Payment

Gateway


Inquiry flow

InqReq

InqRes

Inquiry Flow

Cardholder

Merchant

Payment

Gateway


Authorization reversal flow

AuthRevReq

AuthRevRes

Authorization Reversal Flow

Cardholder

Merchant

Payment

Gateway


Capture flow

CapReq

CapRes

Capture Flow

Cardholder

Merchant

Payment

Gateway


Capture reversal flow

CapRevReq

CapRevRes

Capture Reversal Flow

Cardholder

Merchant

Payment

Gateway


Credit flow

CredReq

CredRes

Credit Flow

Cardholder

Merchant

Payment

Gateway


Credit reversal flow

CredRevReq

CredRevRes

Credit Reversal Flow

Cardholder

Merchant

Payment

Gateway


Pg key exchange certificate

PCertReq

PCertRes

PG Key Exchange Certificate

Cardholder

Merchant

Payment

Gateway


Batch administration

BatchAdminReq

BatchAdminRes

Batch Administration

Cardholder

Merchant

Payment

Gateway


Cardholder certificate issuance

CardCInitReq

CardCInitRes

RegFormReq

RegFormRes

CertReq

CertRes

Cardholder Certificate Issuance

Cardholder

CCA


M or pg certificate issuance

Me-AqCInitReq

Me-AqCInitRes

CertReq

CertRes

M or PG Certificate Issuance

Merchant or PG

MCA

or PCA


Certificate issuance inquiry

Cardholder, Merchant, or PG

CCA,

MCA,

or PCA

CertInqReq

CertInqRes

Certificate Issuance Inquiry


Encryption summary1

Bob’s Computer

Alice’s Computer

Bob’s Private

Key Exchange Key

1

2

Alice’s Private

Signature Key

PROPERTY

Decrypt

Encrypt

Digital

Signature

Digital

Envelope

6

Message Digest

5

9

Message

PROPERTY

PROPERTY

Message

Digest

3

7

Decrypt

Encrypted

Message

Symmetric

Key

Encrypt

Symmetric

Key

Encrypted

Message

Encrypted

Message

10

Alice’s

Certificate

Alice’s

Certificate

Digital

Envelope

compare

4

8

Bob’s

Certificate

Encrypt

Decrypt

Message

Digest

Digital

Envelope

Digital

Signature

Bob’s Public

Key-Exchange

Key

Alice’s Public

Signature Key

Encryption Summary


Purchase request response

OI

C

+

PI

C

Payment Gateway

Purch Res

M

+

1

+

+

C

M

CA

CA

Purchase Request & Response


Technologies and applications of secure epayment systems

PReq 메시지 구조

PReq = < PReqDualSigned, PReqUnsigned >

PReqDualSigned = { PIDualSigned, OIDualSigned }

PIDualSigned =

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

OIDualSigned = L(OIData, PIData)


Idempotency

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

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

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

DER Encoding

  • Encoded =Identifier Octet+ Length Octet+ Contents

    e.g.)

    "en "

    1A 03 65 6E 20


Identifier octet

Identifier Octet

Bit8

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

0

0

← universal

0

1

←application

1

0

←context-specific

1

1

←private

0

←primitive

1

←construct

x

x

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

Universal Tag Assignment


Object identifier

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

Identifier Octet Example


Length octet

Length octet

  • Simple (1byte) : 0bbbbbbb

  • Long : 1bbbbbbbxxH xxH xxH

뒤 Byte 수

xxxxxx : content octet 길이 (byte)


Content 1

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

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

Example of PInitReq (2)

  • DER Encoding

    rrpid04 14 87 FB 2B 3D 61 62 ...

    language1A 03 65 6E 20-- en

    localID-C04 14 6C 69 64 63 2D 6C ...

    chall-C04 14 88 FB 2B 3D 61 62 ...

    brandID1A 0D 42 72 61 6E 64 3A ...

    bin12 06 39 39 39 39 39 39

    thumbsA1 0D 30 0B

    digestAlgorithm30 09

    algorithm06 05 2B 0E 03 02 1A -- sha1


Messages in set

Messages in SET

MessageWrapper ::= SEQUENCE {

messageHeaderMessageHeader,

message[0] EXPLICIT MESSAGE.&TYPE (Message),

mwExtensions[1] MsgExtensions { { MWExtensionsIOS } }

OPTIONAL}

MessageHeader ::= SEQUENCE {

versionINTEGER { setVer1(1) } (setVer1),

revisionINTEGER (0) DEFAULT 0,-- V1.0

…}

Message ::= CHOICE {

purchaseInitRequest[0] EXPLICIT PInitReq,

purchaseInitResponse[1] EXPLICIT PInitRes,

…}


Example of pinitreq 3

Example of PInitReq (3)

3081A9304D020101180F31393937303931343039

303332315AA0078005313336353981147D65C916

1864C31442422EACE3976ABE919B099B1A185345

545245462053616D706C652043617264686F6C64

6572A058A056305404147D65C9161864C3144242

2EACE3976ABE919B099B1A02656E040531333635

390414E5E6F5E172CF833DB31F720E9EF1001BD2

F6CCB41A04433030311206333534393032A10D30

0B300906052B0E03021A0500


Certificate chain validation

Certificate Chain Validation

Hierarchy of Trust

Root Sig.

Brand Sig.

GCA Sig.

PCA Sig.

CCA Sig.

MCA Sig.

Cardholder Signature

Merchant Signature

Merchant Key Exch.

PG Signature

PG Key Exchange


Public root key 1

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

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

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 Format of X.509 (1)

Certificate ::= SIGNED {

EncodedCertificate

}

SIGNED { ToBeSigned } ::= SEQUENCE {

toBeSignedToBeSigned,

algorithmAlgorithmIdentifier {{SignatureAlgorithms}},

signatureBIT STRING

}

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


Certificate format of x 509 2

Certificate Format of X.509 (2)

UnsignedCertificate ::= SEQUENCE {

version[0] CertificateVersion,

serialNumberCertificateSerialNumber,

signatureAlgorithmIdentifier {{SignatureAlgorithms}},

issuerName,

validityValidity,

subjectName,

subjectPublicKeyInfoSubjectPublicKeyInfo{{SupportedAlgorithms}},

issuerUniqueID[1] IMPLICIT UniqueIdentifier OPTIONAL,

subjectUniqueID[2] IMPLICIT UniqueIdentifier OPTIONAL,

extensions[3] Extensions

}


Certificate extensions

Certificate Extensions

  • X.509 Extensions

    • KeyUsage

    • PrivateKeyUsagePeriod

  • SET Private Extensions

    • HashedRootKey : only in Root certificates

    • CertificateType


Certificate validity

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

Certificate Usage Period (1)

e.g.)

C :1998.6.10 ~ 1999.6.9certificate

1998.6.10 ~ 1999.6.9private key

CCA :1998.1.1 ~ 1999.12.31certificate

1998.1.1 ~ 1998.12.31private key


Certificate usage period 2

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 identifier

Algorithm Identifier

AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet }

::= SEQUENCE {

algorithmALGORITHM-IDENTIFIER.&id({InfoObjectSet}),

parametersALGORITHM-IDENTIFIER.&Type(

{InfoObjectSet} [email protected]}) OPTIONAL

}


Name 1

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

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

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 Revocation Lists).


Ca compromise recovery 1

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

Signed Data (PKCS#7)

SignedData ::= SEQUENCE {

sdVersionINTEGER { sdVer2(2) } (sdVer2),

digestAlgorithmDigestAlgorithmIdentifiers,

contentInfoContentInfo,

certificates[2] IMPLICIT Certificates OPTIONAL,

crls[3] IMPLICIT CRLSequence OPTIONAL,

signerInfosSignerInfos

}


Pinitres

PInitRes

PInitRes ::= S { M, PInitResData }

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

PInitResData ::= SEQUENCE {

transIDsTransIDs,

rrpidRRPID,

chall-CChallenge,

chall-MChallenge,

brandCRLIdentifier[0] EXPLICIT BrandCRLIdentifier OPTIONAL

peThumb[1] EXPLICIT CertThumb,

thumbs[2] EXPLICIT Thumbs OPTIONAL,

piRsExtensions[3] MsgExtensions {{ PIRsExtensionsIOS }}

OPTIONAL }


Ca compromise recovery 2

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

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

SET Version 2.0

  • 1998년 말 발표 예정 ← 미 발표

  • 포함내용

    • Smartcard (chipcard) support

    • Debit card support

    • Multi-crypto algorithms (including ECC 알고리즘)


Secure debit transaction

Secure Debit Transaction


Technologies and applications of secure epayment systems

Out-of-scope

인증기관

인증서

인증서

인증서

1. 상품정보

고객

Browser

Wallet

상인

P

G

카드사

Host

3. 지불정보

2. 주문/지불정보

4. 지불승인

상품

대금

대금

on-line

SET 정의 암호화

off-line

X.25 / 자체암호화

SET의 지불정보 보안


Technologies and applications of secure epayment systems

SET 방식의 장단점

  • 장점

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

    • 보안성 높음 (Key size 큼)

  • 단점

    • 시스템이 복잡해지고 시스템 부하가 큼

    • 별도의 고객 S/W(Digital Wallet) 필요

      • 사용 불편 (별도의 사용법, Setup)

      • 유지보수 어려움


Technologies and applications of secure epayment systems

1. 상품정보

인증서

고객

Web

Browser

상인

인증기관

2. 주문정보

상품

SSL 인증서

인증서

5. 이체통보

대금

3. 지불정보

고객은행

상인은행

4. 대금(이체)

대금

on-line

SSL (128 bits)

기존 은행망

off-line

SDT 정의 암호화

SDT의 지불정보 보안


Technologies and applications of secure epayment systems

SDT의 보안 목표

  • 기밀성

    • 지불정보

  • 인증

    • 고객 인증

    • 고객은행 인증

    • 상인 인증

  • 무결성

    • 지불정보

    • 이체통보


Technologies and applications of secure epayment systems

SDT의 주 내용

  • 고객 – 상인

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

  • 고객 – 고객은행

    • 고객은행의 웹사이트에서 지불정보 입력

    • 보안이 강화된 (128 bits) SSL 사용

      • 고객 인증서 사용 방식 / Password 방식

      • E.g.) Xecure-Web

  • 고객은행 – 상인은행

    • 기존의 은행망을 사용하여 계좌이체

  • 고객은행 – 상인

    • SDT가 정의한 내용에 따라 이체 통보 메시지를 암호화하여 전달

  • 인증기관 – 고객, 상인, 고객은행

    • 인증서 발행


Technologies and applications of secure epayment systems

SDT의 특징

  • 단순, 명료

  • 개발 및 유지보수 용이

  • 고객 사용 편리 (웹 브라우저만 사용)

  • 보안성 높음 (key size = 128 bits)

  • 지불정보가 상인에게 노출되지 않음

  • 직불 외에 신용카드 지불 등에도 수정 없이 사용가능


Technologies and applications of secure epayment systems

SDT의 의의

  • 기존 방식은 지불정보가 상인에게 노출되는 것을 용인하거나, 아니면 노출되지 않도록 하기 위하여 복잡한 과정을 거쳐야 했음

  • 지불정보가 상인을 거치지 않고 금융기관에 직접 전달되도록 처리

    • 고객이 지불 정보를 금융기관의 웹 사이트에 직접 입력하도록 함

    • 이때, 고객은 금융기관의 URL을 확인할 수 있음

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


Technologies and applications of secure epayment systems

SDT 사용상의 이점

  • 사용자 입장

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

  • 상인 입장

    • 고객의 지불 정보를 자신이 직접 다루지 않으므로 지불 정보 관련 사고 발생시 책임회피 가능

  • 금융기관 입장

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

  • SI 업체

    • 표준 Solution 개발 및 판매 가능


Sct smt sqt

SCT, SMT, SQT, …

  • SDT (Secure Debit Transation)

    • 직불

  • SCT (Secure Credit Transaction)

    • 신용카드, 후불

  • SMT (Secure Money Transaction

    • 전자현금

  • SQT (Secure Cheque Transaction)

    • 수표, 어음


Technologies and applications of secure epayment systems

1. 상품정보

인증서

고객

Web

Browser

상인

인증기관

2. 주문정보

상품

SSL 인증서

인증서

4. 승인통보

5. Capture

대금

3. 지불정보

고객카드사

상인은행

대금

대금

on-line

SSL (128 bits)

기존 은행망

off-line

SCT 정의 암호화

SCT의 지불정보 보안


Technologies and applications of secure epayment systems

요약

  • Technologies

    • 암호학

    • 대칭형, 비대칭형, 메시지다이제스트

    • 전자서명, 전자봉투, 전자인증서

    • 전자문서와 법률

  • Applications

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


  • Login