Encryption Transaction with 3DES Team W2 Yervant Dermenjian (W21) Taewan Kim (W22) Evan Mengstab(W23) Xiaochun Zhu(W24) Objective: To implement a secure credit card transaction using 3DES encryption using Kerberos-style authentication. Current Stage: Design Proposal 01/21/2004 Team Manager: Rebecca Miller

What’s Wrong with Credit Purchases? Point-of-sale terminals transmit your name, credit card number, and expiration dates ‘in the clear’ (unencrypted). Using Kerberos-style authentication, we can transmit encrypted information that can be verified by the card authorizer without actually containing sensitive information.

Triple Data Encryption Standard Difficult to decipher for large encryption keys Symmetric Key Cipher – encryption & decryption use same key Based on DES – a very trusted cipher Encryption utilized in new ATMs Free to use Accepted as the new standard for federal agencies in 1999

Kerberos-style Authentication Encrypt card expiration date using credit card number and secret PIN as encryption key. The data payload is arbitrary. Only the cardholder and card acquirer have the key. Provides authentication without transmitting sensitive information.

How It Works Transmit: name, merchant, price, encrypted expiration date Card company has cc# and PIN to decrypt packet If expiration date matches, purchase is approved CC# and PIN are never transmitted, but essential to authenticate

Security In Making Purchases Identity theft is a growing problem Sensitive information never transmitted Uses existing cards and phone network Credit and charge card fraud costs cardholders and issuers hundreds of millions of dollars each year

Design Diagram Name Reg b’100 CC# Reg b’54 PIN Reg b’14 ExpDate Reg b’11 MerchID b’25 MerchPrice b’12 Concatenate Pin+CC# = Encryption Key 3DES encryption of Expiration Date using PIN+CC# Key Package Packager MerchID-Name-Payload- Price Output Input

Current Status Block Diagram breakdown of functions  Decisions on packet encryption(100%)  Analysis of 3DES algorithm(10%) C Language software implementation of encryption and decryption(0%) Verilog HDL(0%) Verilog Gate-level design(0%) Schematic Representation(0%) Chip Layout(0%) SPICE Simulation(0%)

Design Decisions Cardholder’s name encoded in shortened ASCII, only 32 letters (4 bytes). Merchant ID shortened to 5 letters. Merchandise Cost capped at $4,096 (12 bits) Credit Card number and PIN concatenated as key. Longer key -> Stronger encryption. Transmitted data  Unencrypted: Cardholder’s name, Merchant’s ID, purchase amount  Encrypted: expiration date

Design Alternatives Rijndael (AES) encryption algorithm  Does not comply with standard for ATMs  Larger silicon area Clock-synchronized random number key  Incompatible with current credit cards  Difficult to keep smart chip in card synchronized with server

Problems and Questions Should sensitive data (PIN and CC#) be the encrypted data or the encryption key? Less secure to encrypt purchase price, creating variable encrypted messages using the same key? Need a rough transistor count. Is this encryption difficult to crack but still manageable to realize in hardware?