Security Mechanisms for Electronic Business Applications...

Preview:

DESCRIPTION

Security Mechanisms for Electronic Business Applications 適用於電子商務的安全機制之研究. Advisor: Dr. Chin-Chen Chang Student: Chia-Chi Wu Date: Jan. 3.2011 Department of Computer Science and Information Engineering, National Chung Cheng University. Outline. Motivation - PowerPoint PPT Presentation

Citation preview

1

Security Mechanisms for Security Mechanisms for Electronic Business ApplicationsElectronic Business Applications

適用於電子商務的安全機制之研究

Advisor: Dr. Chin-Chen Chang Student: Chia-Chi Wu Date: Jan. 3.2011 Department of Computer Science and Information Engineering, National Chung Cheng University

2

OutlineOutlineOutlineOutline

Motivation A novel key agreement scheme in a multipl

e server environment A new sealed-bid electronic auction An authenticated PayWord scheme withou

t public key cryptosystems Digital rights management for multimedia

content over 3G mobile networks Conclusions and future works

3

Motivation (1/3)Motivation (1/3)Motivation (1/3)Motivation (1/3)

• E-Business Activities– Transfer accounts– EDI (Electronic Data Interchange)– Access control– Online services– E-Auction– E-Payment– Digital right– …….

4

MotivationMotivation (2/3)(2/3)MotivationMotivation (2/3)(2/3)

• E-Business Risks– Impersonation– Eavesdropping– Tampering – Privacy– Repudiation– Replay attacks– Fairness – …..

Authentication Key agreement En/decryption Anonymity Signature Timestamp Nonce checking Hash chain …..

5

MotivationMotivation (3/3)(3/3)MotivationMotivation (3/3)(3/3)

Our Research Objectives:• Designing a novel key agreement protocol in

a multiple server environment with low computation

• Developing a sealed bid electronic auction scheme

• Designing an authenticated PayWord scheme without public key cryptosystems

• Digital rights management for multimedia content over 3G mobile networks

• Conclusions

6

A Novel Key Agreement Scheme A Novel Key Agreement Scheme in a Multiple Server Environment in a Multiple Server Environment

(1/8)(1/8)

A Novel Key Agreement Scheme A Novel Key Agreement Scheme in a Multiple Server Environment in a Multiple Server Environment

(1/8)(1/8)

UserToken

Server

UserToken

Server 2

RC

Server 1

Server n

Registration

Registration

Token

7

A Novel Key Agreement Scheme in a A Novel Key Agreement Scheme in a Multiple Server Environment (2/8)Multiple Server Environment (2/8)

A Novel Key Agreement Scheme in a A Novel Key Agreement Scheme in a Multiple Server Environment (2/8)Multiple Server Environment (2/8)

• Criteria– C1: No verification table– C2: Freely Chosen password– C3: Low computation and communication cost– C4: Mutual authentication– C5: Session key agreement– C6: Single registration

• Security Criteria– S1: Session key security– S2: Known-key security

8

A Novel Key Agreement Scheme in a A Novel Key Agreement Scheme in a Multiple Server Environment (3/8) Multiple Server Environment (3/8)

NotationsNotations

A Novel Key Agreement Scheme in a A Novel Key Agreement Scheme in a Multiple Server Environment (3/8) Multiple Server Environment (3/8)

NotationsNotations• Ui: The user i• Sj: The server j• UID : The user identity• PW : The password of the user• RC: The registration center• x : The long secret token of RC • SID : The identity of the server• h( ) : A secure one-way hash function i, vi: The secret information of the user i• Ki,j: The shared key between Ui and Sj• wj: The shared secret key between Sj and RC• Vi,j: The shared parameter which can be computed by Ui and Sj• Ni: A nonce value• Ti: A current timestamp• △T : The expected valid time interval for transmission delay• skk: The session key for the kth session• ⊕: The exclusive-or operation for two bit-strings• Ek(m): Symmetric-key encryption of “m” with key k• Dk(c): Symmetric-key decryption of “c” with key k

9

A Novel Key Agreement Scheme in a Multiple SerA Novel Key Agreement Scheme in a Multiple Server Environment (4/8) ver Environment (4/8)

Juang’s schemeJuang’s scheme

A Novel Key Agreement Scheme in a Multiple SerA Novel Key Agreement Scheme in a Multiple Server Environment (4/8) ver Environment (4/8)

Juang’s schemeJuang’s schemeRegistration phase

Ui RC

UIDi, PWi

RC sends wj=h(x, SIDj) to Sj via a secure channel after Sj registers at RC.

Computesvi=h(x,UIDi) andμi=vi⊕PWi

Stores UIDi andμi

in the smart card

S1

S2

S3

Sj

Computes ki,j=h(vi,SIDj)

Ewj(ki,j,UIDi)

Stores Ewj(ki,j,UIDi)

10

A Novel Key Agreement Scheme in a Multiple SerA Novel Key Agreement Scheme in a Multiple Server Environment (5/8) ver Environment (5/8)

Juang’s schemeJuang’s scheme

A Novel Key Agreement Scheme in a Multiple SerA Novel Key Agreement Scheme in a Multiple Server Environment (5/8) ver Environment (5/8)

Juang’s schemeJuang’s schemeLogin and session key agreement phase

Ui Sj

When Ui wants to login Sj, he/she inserts the smart card into the card reader and inputs UIDi and PWi into the device.

DecryptsEki,j(ruk,h(UIDi || N1))

Checksh(UIDi || N1)

ComputesEki,j(rsk,N1+1,N2),

skk=h(ruk, rsk, ki,j)

N1, UIDi ,Eki,j(ruk,h(UIDi || N1))

Smart card computes vi =μi⊕PWi ,

ki,j =h(vi, SIDj)

Eki,j(rsk,N1+1,N2)DecryptsEki,j(rsk,N1+1,N2)

ChecksN1+1

Computesskk=h(ruk, rsk, ki,j),

Eskk(N2+1)

Eskk(N2+1)

DecryptsEskk(N2+1)

ChecksN2+1

11

A Novel Key Agreement Scheme in a Multiple SerA Novel Key Agreement Scheme in a Multiple Server Environment (6/8) ver Environment (6/8)

Drawbacks of Juang’s schemeDrawbacks of Juang’s scheme

A Novel Key Agreement Scheme in a Multiple SerA Novel Key Agreement Scheme in a Multiple Server Environment (6/8) ver Environment (6/8)

Drawbacks of Juang’s schemeDrawbacks of Juang’s scheme• When new users join, RC has plenty of

overheads• Si must store each user’s UIDx and Ewj

(kxj, UIDx) in encrypted key table. There are storage consumption and risk.

12

A Novel Key Agreement Scheme in a A Novel Key Agreement Scheme in a Multiple Server Environment (7/8) Multiple Server Environment (7/8)

The proposed schemeThe proposed scheme

A Novel Key Agreement Scheme in a A Novel Key Agreement Scheme in a Multiple Server Environment (7/8) Multiple Server Environment (7/8)

The proposed schemeThe proposed scheme

Registration phase

Ui RC

UIDi, PWi

RC sends wj=h(x, SIDj) to Sj via a secure channel after Sj registers at RC.

Computesμi=x⊕PWi

Stores UIDi μi,and h(

)in the smart card

13

A Novel Key Agreement Scheme in a A Novel Key Agreement Scheme in a Multiple Server Environment (8/8) Multiple Server Environment (8/8)

The proposed scheme (cont.)The proposed scheme (cont.)

A Novel Key Agreement Scheme in a A Novel Key Agreement Scheme in a Multiple Server Environment (8/8) Multiple Server Environment (8/8)

The proposed scheme (cont.)The proposed scheme (cont.)

Ui Sj

UIDi, T1, h(Vij||T1)

T2, h(Vij'||T2)

Eskk(T2+1)

Login and session key agreement phase

Ui inserts the smart card into the card reader and inputs UIDi and PWi into the device.

Smart card computesVi,j=h(h(μi⊕PWi, SIDj) ||UIDi )

ComputesVi,j '= h(wj|| UIDi) Checks T-T1△T andh(Vij|| T1)=h(Vij '|| T1)Generates h(Vij '||T2)

?

Checks T-T2△T andh(Vij' ||T2)= h(Vij||T2)

?

Computes skk=h(T1||T2|| Vij)Eskk(T2+1)

Computes skk=h(T1||T2|| Vij')Decrypts and checks T2+1

Eskk(T2+1) Eskk(T2+1)

14

A Novel Key Agreement Scheme in a A Novel Key Agreement Scheme in a Multiple Server Environment SuperioritiesMultiple Server Environment Superiorities

A Novel Key Agreement Scheme in a A Novel Key Agreement Scheme in a Multiple Server Environment SuperioritiesMultiple Server Environment Superiorities

• No encrypted key table needed• Mutual authentication without RC’s

support• Efficiency• Practicability

15

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (1/11)Auction (1/11)

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (1/11)Auction (1/11)

• Traditional English auction• Dutch auction • Sealed-bid auction.

16

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (2/11)Auction (2/11)

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (2/11)Auction (2/11)

• Requirements– Anonymity– Public verifiability– Non-repudiation– Traceability– Accountability of

bidder– Unforgeability– Fairness

– Privacy– Confidentiality– Low overhead cost

17

A New Sealed-bid Electronic AuctiA New Sealed-bid Electronic Auction (3/11) on (3/11) Liaw et al.’s protocolLiaw et al.’s protocol

A New Sealed-bid Electronic AuctiA New Sealed-bid Electronic Auction (3/11) on (3/11) Liaw et al.’s protocolLiaw et al.’s protocol

• The advertisement stage– The auctioneer broadcasts M1 and its signature o

n the Internet.• The registration stage

Bidder B

EPT [Binfo, PB, r, M1]

Third party T Web

M1, H(r), H(w), H(x), H(y), H(z)

EPB [M1, r, x, Bid]

18

A New Sealed-bid Electronic AuctiA New Sealed-bid Electronic Auction (4/11) on (4/11) Liaw et al.’s protocolLiaw et al.’s protocol

A New Sealed-bid Electronic AuctiA New Sealed-bid Electronic Auction (4/11) on (4/11) Liaw et al.’s protocolLiaw et al.’s protocol

Bidder B Third party T Bank A Auctioneer UEPA [M1, Bid, payment,

deposit, y]

EPB [M1, Bid, Certd, y]

E PT [M1, Bid, Certd, price, y, r]

EPB [M1, Bid, order, price, r]

E PU [M1, order, Max-p, z]

The bidding stage

19

A New Sealed-bid Electronic AuctiA New Sealed-bid Electronic Auction (5/11) on (5/11) Liaw et al.’s protocolLiaw et al.’s protocol

A New Sealed-bid Electronic AuctiA New Sealed-bid Electronic Auction (5/11) on (5/11) Liaw et al.’s protocolLiaw et al.’s protocol

Third party TWebSSU

<M1, Max-p, order>,

M2, H(M2, bill)EPA

[M2, Bid, Max-p,

x, zx, pay]

Auctioneer U

EPU [M2, Bid, Max-p,

zx, paid]

Bank A

EPB[M2, Bid, Max-p,

paid, bill]

Bidder B

The exchange of the product and the payment stage

20

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (6/11)Auction (6/11)

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (6/11)Auction (6/11)

• The drawbacks of Liaw et al.’s scheme – The conspiracy attack– The forgery attack– No privacy

21

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (7/11) Our schemeAuction (7/11) Our schemeA New Sealed-bid Electronic A New Sealed-bid Electronic Auction (7/11) Our schemeAuction (7/11) Our scheme

• The advertisement stage – U computes SSU <M1, H(bill)>, and then bro

adcasts them and their plaintext to everyone.

• The registration stage Bidder B

{SignB, EKB (Binfo, NB, KB, M1),

E PT [KB ]}

Third party T Web

M1, H(x), H(y), P

EKB [M1, NB+1, x, Bid]

SignB=SSB<Binfo, NB, H(KB)>

22

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (8/11) Our schemeAuction (8/11) Our schemeA New Sealed-bid Electronic A New Sealed-bid Electronic Auction (8/11) Our schemeAuction (8/11) Our scheme

The bidding stageBidder B Third party TBank A

{Bid||(M1, Certd, sealed-bid)||SSB<Bid, sealed-bid>}

EKB(M1, Bid, order, y)|| SST

<Bid, order, sealed-bid>

EPA[Bid, payment, deposit]

EPB [Bid, Certd]

Certd : A deposit deducting certification

23

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (9/11) Our schemeAuction (9/11) Our schemeA New Sealed-bid Electronic A New Sealed-bid Electronic Auction (9/11) Our schemeAuction (9/11) Our scheme

The opening stage

Bidder B Third party T Web

(all order’s and sealed-bid’s),

Bid|| EKB(order, rB

-1 mod P)

(all order’s and ri-1’s), (M1, Max-p, W- order)

|| ||TS i i

i iS order sealed bid Time

24

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (10/11) Our schemeAuction (10/11) Our schemeA New Sealed-bid Electronic A New Sealed-bid Electronic Auction (10/11) Our schemeAuction (10/11) Our scheme

The exchange of the product and the payment stage

Bidder B Bank A Auctioneer U

EPA [M1, Bid, Max-p, pay]

EPU[M1, SST

<Bid, order, sealed-bid >]

EPU[M1, Bid, Max-p, paid]

EPB[M2, Bid, Max-p, paid, bill]

25

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (11/11) Computation Auction (11/11) Computation

comparisonscomparisons

A New Sealed-bid Electronic A New Sealed-bid Electronic Auction (11/11) Computation Auction (11/11) Computation

comparisonscomparisons

Stage Liaw et al.’s scheme

Proposed scheme

The advertisement stage

nTexp nTexp+nTh

The registration stage

2nTexp+5nTh 2nTexp+2 nTsym +3nTh

The bidding stage 5nTexp 4nTexp+ nTsym

The opening stage 0 Texp+ nTsym+ n Tmm

The exchange of the product and the payment stage

4 Texp +2 TXor 3Texp+ Tsym

Total (8 n+4) Texp+5nTh +2 TXor

(7 n+3) Texp+4nTh +(4 n+1)Tsym

+ n Tmm

26

An Authenticated PayWord ScheAn Authenticated PayWord Scheme without Public Key Cryptosystme without Public Key Cryptosyst

ems ems

An Authenticated PayWord ScheAn Authenticated PayWord Scheme without Public Key Cryptosystme without Public Key Cryptosyst

ems ems

• In 1996, Rivest and Shamir proposed a well known micro-payment scheme, called “PayWord”.

• Drawbacks:– The certificate abuse attack.– The customer’s public key is issued by a

bank.

27

Adachi et al.’s improved Adachi et al.’s improved scheme (2005)scheme (2005)

Adachi et al.’s improved Adachi et al.’s improved scheme (2005)scheme (2005)

Credit Authentication PhaseC Bank Vender

Request

Reply

IDC , M

M = (IDV , w0, n, E) SKC

CC =(IDC , M, YES, rV, I)SKB

(IDC , M, rV) Withdraws from C

CC

A valid message

28

Adachi et al.’s improved Adachi et al.’s improved scheme (2005)scheme (2005)

Adachi et al.’s improved Adachi et al.’s improved scheme (2005)scheme (2005)

Purchase Phase

C Vender

(wi, i)

Validate wi-1=h(wi)

Checks iStores (wi, i)

If i=n, the vender performs settlement phase.

29

Adachi et al.’s improved Adachi et al.’s improved scheme (2005)scheme (2005)

Adachi et al.’s improved Adachi et al.’s improved scheme (2005)scheme (2005)

Settlement Phase

BankVender

(wk, k), CC

Checks hk(wk) with w0

Stores (wk, k),

money

30

Drawbacks of Adachi et al.’s Drawbacks of Adachi et al.’s schemescheme

Drawbacks of Adachi et al.’s Drawbacks of Adachi et al.’s schemescheme

• Prepaid

• (wk, k) is released in the public channel and

unauthenticated.

• PKI signature is inefficient.

31

The proposed schemeThe proposed schemeThe proposed schemeThe proposed schemeCredit Authentication Phase

C Bank Vender

Note:M = (IDV , w0, n, E)

RC=grc mod P

RV=grv mod P

SK= RC rv mod P= RVrc mod P

(IDC||(PWC||M||RC||NC||IDV)KC,B ) (IDC||(PWC||M||RC||NC||IDV)KC,B )||(IDV||(PWV||IDC||RV||NV)KV,B)

(IDV||(IDC||M||RC||IC||NV+1)KV,B) || (IDC||(IDV||RV||NC+1)KC,B)

(IDC||(IDV||RV||NC+1)KC,B)||h(M, SK)

32

The proposed schemeThe proposed schemeThe proposed schemeThe proposed schemePurchase Phase

C Vender

(IDC, wi⊕SK, i)

Validate wi-1=h(wi)

Checks iStores (wi, i)

If i=n, the vender performs settlement phase.

33

The proposed schemeThe proposed schemeThe proposed schemeThe proposed schemeSettlement Phase

BankVender

IDV||(PWV||IDC||wk||k)KV,B

Decrypt messageChecks PWV

Checks hk(wk) with w0

Stores (wk, k), money

34

Ticket circulation model Ticket circulation model [21][21]

Ticket circulation model Ticket circulation model [21][21]

Network

Issuer CA Service Provider

Service Provider

Shop

User

Broker User

CARD

Issue (wholesale)

Transfer(sale) Transfer TransferRedeem(Consume/Present)

35

Simplified UMTS-AKA Simplified UMTS-AKA mechanism [15] mechanism [15]

Simplified UMTS-AKA Simplified UMTS-AKA mechanism [15] mechanism [15]

USIM

f2

f3

f4

RANDK

RES

CK

IK

Cipheringfacility

ENCR_TMSI

TMSI

RAND, AUTN

RES

f2

f3

f4

RANDK

XRES

CK

IK

Cipheringfacility

TMSI

ENCR_TMSI

AUTNGeneration

ParametersMO

36

Note:

• USIM: UMTS subscriber identity module

• MO: mobile operator

• TMSI: temporary mobile subscribe identity

• IMSI: international mobile subscriber identity

• AUTN: H(RAND, K, parameters)

37

IDM3G protocol flowchart IDM3G protocol flowchart [15] [15]

IDM3G protocol flowchart IDM3G protocol flowchart [15] [15]

U USIM/UE MO SP

a. User authentication

b. UMTS--AKA: {CK, IK, ENCR_TMSI}

1. HTTP Request

2. HTTP Reply: <AuthnRequest>

3. Calculation of RAND, ENCR_SP_IP

4. RAND, ENCR_SP_IP, MAC1

5. Ticket {SP_IP, RAND, IMSI}, Currrent AV, TMSI

6. HTTP: <AuthnResponse>{MO_ID, ENCR_TMSI, RAND, MAC2}

7. SAML: Request {ENCR_TMSI, RAND, MAC2}

8. Ticket Identification, TMSI comparison

9. SAML: Response {ATTRIBUTES}

10. HTTP Reply

timer

38

Note:

• AV( Authentication Vector): {CK, IK, Auth, RAND and XRES}

• MAC1=H(RAND, ENCR_SP_IP, IK)

• MAC2=H(RAND, ENCR_TMSI, IK)

• ATTRIBUTES: the IMSI of the specific user

39

Drawbacks of IDM3G Drawbacks of IDM3G protocolprotocol

Drawbacks of IDM3G Drawbacks of IDM3G protocolprotocol

• Indirect communication• No shared session key• No DR management

40

NotationsNotationsNotationsNotations• Z: A public huge number is greater than 10000• N1, N2: The nonce values are generated by UE • a, b: The seeds of the hash function are generated by UE• t1: A specific serial number which represents a start date of the D

R• t2: A serial number which denotes the valid date of the DR• t3: A serial number which denotes the transfer date of the DR• t: A serial number which denotes the current date• T: A timestamp• Ek(m): Symmetric-key encryption of “m” with key k• CK: A pre-shared encryption key between UE and MO• IK: A pre-shared integrity key between UE and MO• TK: A temporary key between the user and SP• AK: A session key for access services

41

Online registration stageOnline registration stage Online registration stageOnline registration stage U USIM/UE MO SP

a. User authentication

b. UMTS--AKA: {CK, IK, ENCR_TMSI}

1. HTTP Request: <Registration>

2. HTTP Reply: <AuthnRequest>

3. Calculation of RU, ENCR_SP_IP, TK

4. RU, ENCR_SP_IP, ENCR_TK, MAC1

5. Ticket {SP_IP, RU, IMSI}, Currrent AV, TMSI, TK

6. HTTP: <AuthnResponse>{MO_ID, ENCR_TMSI, RU, MAC2}

7. SAML: Request {ENCR_TMSI, RU, MAC2}

8. Ticket Identification, TMSI comparison

9. SAML: Response {RU, TK}

10. HTTP Reply: {Ready_Registration, ENCR_RS, MAC3}

timer

11. HTTP Request: <Registration>{ENCR_Reg_Data, N1, MAC4}

12. HTTP Reply: <Registration> {RU, ENCR_UID, ENCR_Parameters, MAC5}

42

Note:• MAC1=H(RU, ENCR_SP_IP, ENCR_TK, IK)• MAC3=H(RU, RS, TK)• Reg_Data={UID, Payment, t2, UID_PW_DIGEST, a,

b}

• MAC4=H(Reg_Data, N1, RU, RS)

=Ht1(a) =HZ-t2(b)

• Parameters={, , Z, N1+1}

• MAC5=H(ENCR_UID, ENCR_Parameters, RU, RS)• UE stores {UID, , , Z, t2, t1}

43

Login and access service Login and access service stagestage

Login and access service Login and access service stagestage

USIM/UE MO SP

10. HTTP Reply: {Ready_Login, ENCR_RS, MAC3}

11. HTTP Request: <login>{ENCR_SERVICE_REQ, MAC4}

12. HTTP Reply: {ENCR_STREAM}

44

Note:

• MID: multimedia identity

• SERVICE_REQ:{UID, MID, N2, UID_PW_DIGEST, RS+1}

• SP computes AK=H(N2 Ht-t1() Ht2-t())

• UE computes AK=H(N2 Ht-t1() Ht2-t())

• SP stores (t1, t2, , ) in user A’s record.

45

Transfer transaction Transfer transaction stagestage

Transfer transaction Transfer transaction stagestage

UA MO SP UB

1. SP_IP, ENCR_TRANS_REQ, T, MAC6

2. SAML: Request{ENCR_TRANS_REQ, T, MAC6}

5. HTTP: {Transfer_Data}

7. ENCR_CONFIRM, MAC 78. NEW_ENCR_CONFIRM, MAC8

9. OK

3. Verifies UIDA_PW_DIGEST

4. Stores (Ht3-t1(α), β, t3, t2)

6. Stores (UIDB, Ht3-t1(α), β, Z, t3, t2)

46

Note:• CKA, IKA and TKA have been established.• ENCR_TRANS_REQ=ETKA(UIDA, UIDA_PW_DIG

EST, Ht3-t1(), , UIDB)• MAC6=H(ENCR_TRANS_REQ, T, IKA) • SP stores (Ht3-t1(), , t3, t2) in user B’s record.• SP stores (TRANS_REQ, T, MAC6) in user A’s rec

ord.• Transfer_Data=ETKB(UIDB, t3, t2, Ht3-t1(), , UIDA)

• B stores (UIDB, Ht3-t1(), , Z, t3, t2) in his UE.

• ENCR_CONFIRM=ECKB(H(Ht3-t1(), , t3, t2))

• B’s AK=H(N2 Ht-t3(Ht3-t1())Ht2-t())

47

ConclusionsConclusionsConclusionsConclusions

• Four security mechanisms of E-business– key agreement– electronic auction– The electronic paying services– Digital management over 3G

• Low computation cost• Transmission efficiency• Ubiquitous computing

48

Thanks for your Thanks for your attentionattention

Thanks for your Thanks for your attentionattention

Recommended