www.monash.edu.au

A Limited-used Key Generation Scheme A Limited-used Key Generation Scheme for Internet Transactionsfor Internet Transactions

Supakorn Kungpisdan, Supakorn Kungpisdan,

Phu Dung Le, and Phu Dung Le, and

Bala SrinivasanBala Srinivasan

School of Computer Science and Software EngineeringSchool of Computer Science and Software Engineering

www.monash.edu.au

2

Outline

• Overview of Limited-used Key Generation• Existing Limited-used Key Generation

Techniques• The Proposed Technique• Security Analysis• Applications to Credit-card Payment over the

Internet• Conclusion• References

www.monash.edu.au

3

Overview of Limited-used Key Generation

• A shared key has been used for various purposes:A shared key has been used for various purposes:– As authentication tokenAs authentication token– As a key for cryptographic operation e.g. symmetric As a key for cryptographic operation e.g. symmetric

encryption or keyed-hash function.encryption or keyed-hash function.• In payment scenario, credit-card information (CCI) is In payment scenario, credit-card information (CCI) is

considered as authentication token to be transferred in considered as authentication token to be transferred in every transaction.every transaction.

• However, CCI is static, reusable information. It is However, CCI is static, reusable information. It is vulnerable to attacks.vulnerable to attacks.

• Limited-used shared key is preferred.Limited-used shared key is preferred.• This technique also reduces frequency of secret key This technique also reduces frequency of secret key

update process.update process.

www.monash.edu.au

4

Existing Limited-used Key Generation Approaches

Rubin’s Approach [1]Rubin’s Approach [1]

1.1. A client shares A client shares KK with a bank. with a bank.2.2. The client generates a token The client generates a token TT, where, where

T = {fifty-dollars-book-Bob’s-store}T = {fifty-dollars-book-Bob’s-store}K K

3.3. The client sends The client sends TT to the bank to authenticate herself to to the bank to authenticate herself to the bankthe bank. .

4.4. The bank decrypts The bank decrypts TT to receive the information and to receive the information and verify the client.verify the client.

• The value of The value of TT changes in every transaction depending changes in every transaction depending on purchase details. However, the collision might occur.on purchase details. However, the collision might occur.

www.monash.edu.au

5

Existing Limited-used Key Generation Approaches

Li Li et al.et al.’s Approach [2]’s Approach [2]

1.1. A client and a bank share a long-term secret A client and a bank share a long-term secret SS and initial and initial token token TTinitinit..

2.2. The client generates a token The client generates a token TTnewnew and sends it to and sends it to

authenticate herself to the bank, whereauthenticate herself to the bank, where

TTnewnew = h(T = h(Tcurcur||S)||S)

3. The bank verifies 3. The bank verifies TTnewnew from from {T{Tinitinit, S}., S}.

• Security of the system is based on the length of T and S Security of the system is based on the length of T and S and security of hash function.and security of hash function.

www.monash.edu.au

6

Existing Limited-used Key Generation Approaches

Kungpisdan Kungpisdan et al.et al.’s Approach [3]’s Approach [3]

1.1. A client and a bank share a long-term secret A client and a bank share a long-term secret CCICCI. Also they . Also they shares a secret shares a secret YY which has to be updated periodically. which has to be updated periodically.

2.2. The client generates The client generates YYii, i = 1,…,n, i = 1,…,n..

YYii = h(i-bit-shift-of-(CCI,Y)) = h(i-bit-shift-of-(CCI,Y))

3. The client sends 3. The client sends {Y{Yii, i}, i} to the bank. to the bank. ii is randomly chosen. is randomly chosen.

• YYii is then used as a key for encryption and MAC. is then used as a key for encryption and MAC.

• As As YYii is not sent in order, it is difficult to retrieve both Y and is not sent in order, it is difficult to retrieve both Y and

CCI.CCI.

www.monash.edu.au

7

Problems of Existing Approaches

• Although the values of the session secrets Although the values of the session secrets change in every transaction, generation of each change in every transaction, generation of each token is however based on long-term, reusable token is however based on long-term, reusable shared secret.shared secret.

• This offers the opportunity for an attacker to This offers the opportunity for an attacker to compute the shared secret from eavesdropping compute the shared secret from eavesdropping the tokens.the tokens.

www.monash.edu.au

8

The Proposed Technique

• We aim to design an We aim to design an offlineoffline session key session key generation technique which does not rely on generation technique which does not rely on any long-term shared key. any long-term shared key.

• The compromise of the key will not compromise The compromise of the key will not compromise the security of the entire system.the security of the entire system.

• Our technique deploys HMAC as keyed-hash Our technique deploys HMAC as keyed-hash function to generate each session key to function to generate each session key to achieve lightweight operations and satisfactory achieve lightweight operations and satisfactory security.security.

www.monash.edu.au

9

The Proposed Technique

NotationsNotations• KKABAB: a long-term shared key is called “: a long-term shared key is called “master keymaster key” shared ” shared

between Alice and Bobbetween Alice and Bob• DKDK: a shared key updated periodically called “: a shared key updated periodically called “distributed distributed

keykey””• {K{K11,…,K,…,Kmm}}: a set of “: a set of “preference keyspreference keys”” which is not which is not

transferred during transactions.transferred during transactions.• {SK{SK11,…,SK,…,SKnn}}: a limited-used key used in each transaction : a limited-used key used in each transaction

is called “is called “session keysession key””• SIKSIK: a “: a “session initialization keysession initialization key” generated from the ” generated from the

preference keys. preference keys. SIKSIK is used to generate the set of is used to generate the set of session keys.session keys.

www.monash.edu.au

10

The Proposed Technique

{K1,…,Km}

Select KMid1 and KMid2

{SK1,…,SKn}

KKABAB, DK, DK 1.1. Alice shares Alice shares KKABAB with Bob. with Bob.

DKDK is distributed between them. is distributed between them.

2. Alice generates the set of 2. Alice generates the set of KKii, i=1,…,m, i=1,…,m

from from KKABAB and and DK DK

3. Alice selects two preference keys from 3. Alice selects two preference keys from the set of the set of KKii..

SIK, DK 4. Calculate 4. Calculate SIKSIK from from KKMid1Mid1 andand K KMid2Mid2..

5. Calculate 5. Calculate SKSKjj, j=1,…,n, j=1,…,n, from , from SIKSIK and and DKDK..

6. To update 6. To update SKSKjj, Alice returns to step 3., Alice returns to step 3.

www.monash.edu.au

11

The Proposed Technique (Details)

{K1,…,Km}

Select KMid1 and KMid2

{SK1,…,SKn}

KKABAB, DK, DK

SIK, DK

KK11 = h(DK, K = h(DK, KABAB))

KK22 = h(DK, K = h(DK, K11))

……KKmm = h(DK, K = h(DK, Km-1m-1))

- Generate a random number r- KMid1 = middle key of {K1,…,Kr}- KMid2 = middle key of {K1,…,KMid1}

SIK = h(KMid1, KMid2)

SKSK11 = h(SIK, DK) = h(SIK, DK)

SKSK22 = h(SIK, SK = h(SIK, SK11))

……SKSKnn = h(SIK, SK = h(SIK, SKn-1n-1))SK1, r

www.monash.edu.au

12

Session Key Generation

KK11 = h(DK, K = h(DK, KABAB))

KK22 = h(DK, K = h(DK, K11))

……KKmm = h(DK, K = h(DK, Km-1m-1))

SKSK11 = h(SIK, DK) = h(SIK, DK)

SKSK22 = h(SIK, SK = h(SIK, SK11))

……SKSKnn = h(SIK, SK = h(SIK, SKn-1n-1))

www.monash.edu.au

13

Session Key Update

• rmrm = size of set of = size of set of remaining remaining KKii’ ’ ’ ’

www.monash.edu.au

14

Security Analysis

• Security of our technique does not rely on Security of our technique does not rely on KKABAB, but the , but the

set of set of KKii..

• KKii is randomly chosen to generate the set of session key is randomly chosen to generate the set of session key

SKSKjj. .

• Also, Also, KKii is not transmitted during transactions, the attack is not transmitted during transactions, the attack

is difficult.is difficult.

www.monash.edu.au

15

On Attacking Our SystemOn Attacking Our System

• As HMAC is assumed computationally infeasible, it is As HMAC is assumed computationally infeasible, it is difficult to run reverse operation of difficult to run reverse operation of SKSKjj to retrieve to retrieve SIK SIK and and SKSKj-1j-1..

• With HMAC-MD5, the search space is 2With HMAC-MD5, the search space is 2128128..• To guess the input of HMAC, the system allows limited To guess the input of HMAC, the system allows limited

number of tries. If unsuccessful, the fraud is then detected.number of tries. If unsuccessful, the fraud is then detected.• To retrieve To retrieve DKDK, an attacker has to eavesdrop from , an attacker has to eavesdrop from SKSK11, ,

where where SKSK11=h(SIK,DK)=h(SIK,DK), and successfully decipher it., and successfully decipher it.• However, as the set of However, as the set of SKSKjj is updated frequently, the is updated frequently, the

retrieved retrieved SIKSIK is no longer used in the system. is no longer used in the system.• In worst case, if the attack is successful, the fraud will be In worst case, if the attack is successful, the fraud will be

detected if the an authorized person fails to use the detected if the an authorized person fails to use the session key. A new session key. A new KKii is then chosen for next transactions.is then chosen for next transactions.

www.monash.edu.au

16

Applications to Credit-card Payment over the Internet

Credit-cad payment over SSLCredit-cad payment over SSL

Consider the message sent from client to Consider the message sent from client to merchant:merchant:

CCM: M: {OD, Price, ID{OD, Price, IDII, CCN}, CCN}KK

Applying our technique,Applying our technique,

CCM: M: {OD, Price, ID{OD, Price, IDII, h(Price, SK, h(Price, SKjj, CCN, r)}, CCN, r)}KK

OD = order descriptionsIDI = issuer’s IDCCN = credit-card number

www.monash.edu.au

17

Applications to Credit-card Payment over the Internet (cont’d)

SET Protocol [4]SET Protocol [4]

Consider PI in SET protocol sent from merchant Consider PI in SET protocol sent from merchant to payment gateway,to payment gateway,

{TID, h(OD, Price), Price, ID{TID, h(OD, Price), Price, IDMM, CCI}, CCI}KPGKPG

Applying our technique,Applying our technique,

{TID, h(OD, Price), Price, ID{TID, h(OD, Price), Price, IDMM, SK, SKjj, r}, r}KPGKPG

IDIDMM = merchant’s ID = merchant’s ID

KPGKPG = payment gateway’s = payment gateway’s public keypublic keyCCI = credit-card informationCCI = credit-card information

www.monash.edu.au

18

Applications to Credit-card Payment over the Internet (cont’d)

Conventional Credit-card PaymentConventional Credit-card Payment• Conventional e-commerce a accepts 16-digit credit-card Conventional e-commerce a accepts 16-digit credit-card

number to authenticate a client.number to authenticate a client.• Its length must be 128 bits, readable by the client.Its length must be 128 bits, readable by the client.

– HMAC-MD5 can be used to generate HMAC-MD5 can be used to generate SKSKjj as it can as it can

produce 128 bits output.produce 128 bits output.– Alphanumeric characters are preferred.Alphanumeric characters are preferred.

• Thus, the search space is reduced to 36Thus, the search space is reduced to 3611 11 (the first 4 (the first 4 digits are issuer’s ID and the last digit is checksum).digits are issuer’s ID and the last digit is checksum).

www.monash.edu.au

19

Conclusion

• Security of existing techniques are based on long-term Security of existing techniques are based on long-term secret. They do not secure against long-term key secret. They do not secure against long-term key compromise.compromise.

• Security of our technique does not rely on long-term keys, Security of our technique does not rely on long-term keys, but dynamically chosen preference keys which are not but dynamically chosen preference keys which are not transmitted during transactions.transmitted during transactions.

• Our technique is successfully applied to payment Our technique is successfully applied to payment protocols. With its lightweight operations, it is suitable for protocols. With its lightweight operations, it is suitable for mobile applications.mobile applications.

• As future work, we aim to analyze performance of the As future work, we aim to analyze performance of the payment protocols applying our technique. Also, we aim to payment protocols applying our technique. Also, we aim to apply the technique to other kinds of Internet applications.apply the technique to other kinds of Internet applications.

www.monash.edu.au

20

References

[1] Rubin, A.D., Wright, R.N.: Offline Generation of Limited-Use [1] Rubin, A.D., Wright, R.N.: Offline Generation of Limited-Use Credit Card Numbers. LNCS 2339 (2002) 196-209Credit Card Numbers. LNCS 2339 (2002) 196-209

[2] Li, Y., Zhang, X.: A Security-Enhanced One-Time Payment [2] Li, Y., Zhang, X.: A Security-Enhanced One-Time Payment Scheme for Credit Card. Proc. Int. Workshop on Research Scheme for Credit Card. Proc. Int. Workshop on Research Issues on Data Engineering: Wed Services for E-Commerce Issues on Data Engineering: Wed Services for E-Commerce and E-Government Applications (2004) 40-47and E-Government Applications (2004) 40-47

[3] Kungpisdan, S., Srinivasan, B., Le, P.D.: Lightweight Mobile [3] Kungpisdan, S., Srinivasan, B., Le, P.D.: Lightweight Mobile Credit-Card Payment Protocol. LNCS 2904 (2003) 295-308Credit-Card Payment Protocol. LNCS 2904 (2003) 295-308

[4] Mastercard and Visa: SET Protocol Specifications.[4] Mastercard and Visa: SET Protocol Specifications.

www.monash.edu.au

21

Thank You

Question?