A Limited-used Key Generation Scheme for Internet Transactions

1. A Limited-used Key Generation Scheme for Internet Transactions Supakorn Kungpisdan, Phu Dung Le, and Bala Srinivasan School of Computer Science and Software Engineering

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

3. Overview of Limited-used Key Generation • A shared key has been used for various purposes: • As authentication token • As a key for cryptographic operation e.g. symmetric encryption or keyed-hash function. • In payment scenario, credit-card information (CCI) is considered as authentication token to be transferred in every transaction. • However, CCI is static, reusable information. It is vulnerable to attacks. • Limited-used shared key is preferred. • This technique also reduces frequency of secret key update process.

4. Existing Limited-used Key Generation Approaches Rubin’s Approach [1] • A client shares K with a bank. • The client generates a token T, where T = {fifty-dollars-book-Bob’s-store}K • The client sends T to the bank to authenticate herself to the bank. • The bank decrypts T to receive the information and verify the client. • The value of T changes in every transaction depending on purchase details. However, the collision might occur.

5. Existing Limited-used Key Generation Approaches Li et al.’s Approach [2] • A client and a bank share a long-term secret S and initial token Tinit. • The client generates a token Tnew and sends it to authenticate herself to the bank, where Tnew = h(Tcur||S) 3. The bank verifies Tnew from {Tinit, S}. • Security of the system is based on the length of T and S and security of hash function.

6. Existing Limited-used Key Generation Approaches Kungpisdan et al.’s Approach [3] • A client and a bank share a long-term secret CCI. Also they shares a secret Y which has to be updated periodically. • The client generates Yi, i = 1,…,n. Yi = h(i-bit-shift-of-(CCI,Y)) 3. The client sends {Yi, i} to the bank. i is randomly chosen. • Yi is then used as a key for encryption and MAC. • As Yi is not sent in order, it is difficult to retrieve both Y and CCI.

7. Problems of Existing Approaches • Although the values of the session secrets change in every transaction, generation of each token is however based on long-term, reusable shared secret. • This offers the opportunity for an attacker to compute the shared secret from eavesdropping the tokens.

8. The Proposed Technique • We aim to design an offline session key generation technique which does not rely on any long-term shared key. • The compromise of the key will not compromise the security of the entire system. • Our technique deploys HMAC as keyed-hash function to generate each session key to achieve lightweight operations and satisfactory security.

9. The Proposed Technique Notations • KAB: a long-term shared key is called “master key” shared between Alice and Bob • DK: a shared key updated periodically called “distributed key” • {K1,…,Km}: a set of “preference keys” which is not transferred during transactions. • {SK1,…,SKn}: a limited-used key used in each transaction is called “session key” • SIK: a “session initialization key” generated from the preference keys. SIK is used to generate the set of session keys.

10. The Proposed Technique • Alice shares KAB with Bob. • DK is distributed between them. KAB, DK 2. Alice generates the set of Ki, i=1,…,m from KAB and DK {K1,…,Km} 3. Alice selects two preference keys from the set of Ki. Select KMid1and KMid2 SIK, DK 4. Calculate SIK from KMid1and KMid2. 5. Calculate SKj, j=1,…,n, from SIK and DK. {SK1,…,SKn} 6. To update SKj, Alice returns to step 3.

11. The Proposed Technique (Details) K1 = h(DK, KAB) K2 = h(DK, K1) … Km = h(DK, Km-1) KAB, DK {K1,…,Km} • Generate a random number r • KMid1 = middle key of {K1,…,Kr} • KMid2 = middle key of {K1,…,KMid1} Select KMid1and KMid2 SIK = h(KMid1, KMid2) SIK, DK SK1 = h(SIK, DK) SK2 = h(SIK, SK1) … SKn = h(SIK, SKn-1) {SK1,…,SKn} SK1, r

12. Session Key Generation K1 = h(DK, KAB) K2 = h(DK, K1) … Km = h(DK, Km-1) SK1 = h(SIK, DK) SK2 = h(SIK, SK1) … SKn = h(SIK, SKn-1)

13. ’ ’ ’ ’ Session Key Update • rm = size of set of • remaining Ki

14. Security Analysis • Security of our technique does not rely on KAB, but the set of Ki. • Ki is randomly chosen to generate the set of session key SKj. • Also, Ki is not transmitted during transactions, the attack is difficult.

15. On Attacking Our System • As HMAC is assumed computationally infeasible, it is difficult to run reverse operation of SKj to retrieve SIK and SKj-1. • With HMAC-MD5, the search space is 2128. • To guess the input of HMAC, the system allows limited number of tries. If unsuccessful, the fraud is then detected. • To retrieve DK, an attacker has to eavesdrop from SK1, where SK1=h(SIK,DK), and successfully decipher it. • However, as the set of SKj is updated frequently, the retrieved SIK is no longer used in the system. • In worst case, if the attack is successful, the fraud will be detected if the an authorized person fails to use the session key. A new Kiis then chosen for next transactions.

16. Applications to Credit-card Payment over the Internet Credit-cad payment over SSL Consider the message sent from client to merchant: CM: {OD, Price, IDI, CCN}K Applying our technique, CM: {OD, Price, IDI, h(Price, SKj, CCN, r)}K OD = order descriptions IDI = issuer’s ID CCN = credit-card number

17. Applications to Credit-card Payment over the Internet (cont’d) SET Protocol [4] Consider PI in SET protocol sent from merchant to payment gateway, {TID, h(OD, Price), Price, IDM, CCI}KPG Applying our technique, {TID, h(OD, Price), Price, IDM, SKj, r}KPG IDM = merchant’s ID KPG = payment gateway’s public key CCI = credit-card information

18. Applications to Credit-card Payment over the Internet (cont’d) Conventional Credit-card Payment • Conventional e-commerce a accepts 16-digit credit-card number to authenticate a client. • Its length must be 128 bits, readable by the client. • HMAC-MD5 can be used to generate SKj as it can produce 128 bits output. • Alphanumeric characters are preferred. • Thus, the search space is reduced to 3611 (the first 4 digits are issuer’s ID and the last digit is checksum).

19. Conclusion • Security of existing techniques are based on long-term secret. They do not secure against long-term key compromise. • Security of our technique does not rely on long-term keys, but dynamically chosen preference keys which are not transmitted during transactions. • Our technique is successfully applied to payment protocols. With its lightweight operations, it is suitable for mobile applications. • As future work, we aim to analyze performance of the payment protocols applying our technique. Also, we aim to apply the technique to other kinds of Internet applications.

20. References [1] Rubin, A.D., Wright, R.N.: Offline Generation of Limited-Use Credit Card Numbers. LNCS 2339 (2002) 196-209 [2] Li, Y., Zhang, X.: A Security-Enhanced One-Time Payment Scheme for Credit Card. Proc. Int. Workshop on Research Issues on Data Engineering: Wed Services for E-Commerce and E-Government Applications (2004) 40-47 [3] Kungpisdan, S., Srinivasan, B., Le, P.D.: Lightweight Mobile Credit-Card Payment Protocol. LNCS 2904 (2003) 295-308 [4] Mastercard and Visa: SET Protocol Specifications.

21. Thank You Question?