Security Mechanisms for Electronic Business Applications...
-
Upload
octavius-ferrell -
Category
Documents
-
view
48 -
download
9
description
Transcript of Security Mechanisms for Electronic Business Applications...
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