Magnetic Stripe cards
The intention of this section is to demonstrate how cryptographic principles are (usually) applied to magnetic stripe cards in a practical context.
PIN Processing
The PIN principle is based on the fact that nobody other than the legitimate cardholder has knowledge of the PIN. Thus when a PIN is provided for a customer:
Normally, a PIN is a 4-digit numeric value. Other schemes exist, but we will use this format for illustration as it is a common standard.
When a PIN is issued, the sequence of events is as follows:
At this point, the only place the PIN value exists is inside the PIN mailer. The PIN cannot be derived from the PIN offset.
When the card is used and the PIN entered, the PIN offset is calculated again from the entered PIN, using the PIN working keys and compared to the stored offset value to determine if the correct PIN was entered. Clearly this means that when a PIN is validated, the validating system must have access to the PIN working keys used during initial PIN issue or subsequent PIN change.
It should be re-emphasised that the offset comprises selected digits from the cipher text. Typically this would be 4-6 digits. It is not possible to recreate the keys or derive the PIN from this value.
Notes:
I. In some implementations, the PIN offset is stored on the magnetic stripe on the card. This is intended to be used in terminals which can perform local PIN validation. However, this technique is becoming rare as it prevents deployment of user-selectable PIN's.
II. Where the user is given the option to change PIN, the new offset is calculated in realtime and written to the database. Note that if the PIN is forgotten, it cannot be recreated.
III. The method described above is generic. There are many variations, such as the IBM3624 Method-A, Diebold method, and so on, however the principle remains the same.
IV. In many methods, the framework exists for using different key pairs based on an index value, usually stored on the magnetic stripe. This is a single digit value denoting the index of the key pair to be used. The intent is so that a) the same keys are not used across the entire cardbase, and c) that new keys can be used on re-issue without affecting existing cards.
CVV processing
It was quickly understood that the proliferation of financial cards exposed institutions to risk from counterfeiters. In the credit card world, this came from manufacture of cards with or without magnetic stripe encoding that possessed valid numbers and seemingly valid names and logos. In the ATM card arena, attackers observed PIN number entry 'over the shoulder', collated these PIN's with information from discarded receipts and so on, and constructed their own magnetic stripes on dummy cards for use at their leisure with observed PIN numbers.
These threats and others led to the introduction of the Card Verification Value, a non-derivable sequence of digits constructed by cryptographic process and written to the magnetic stripe of the card. This means that electronic captures of transactions (either at ATM or Point of Sale) are effectively protected against counterfeiters.
A combination of static data such as account number is triple encrypted using a special Card Verification key pair. Selected digits from the result are used to create the CVV, and this is written onto the magnetic stripe.
Similar comments apply to CVV as those for Pin Offset; As the CVV consists of few digits, and triple encryption is used, the CVV keys and values are highly secure and presence of a valid CVV provides an added level of confidence that the card is not counterfeit.
It should be noted that CVV is simply an additional protection method; it is not foolproof. It does not, for instance, protect against fraudulent captures of magnetic stripe data using, say, fake ATM's.
A further development of CVV, CVV2, is used for telephone authorisations. A similar (although not identical) calculation is performed as for CVV, and selected digits from the result are physically printed on the back of the card. These digits can then be requested by a call centre wishing to determine if the caller is really in possession of the card. Once again, this is an additional check, and not foolproof.
Cryptography in a normal ATM withdrawal
Consider a common ATM transaction:
There's an awful lot of cryptography going on in this process. For simplicity, we'll assume the acquiring and issuing bank are the same.
The cryptography activity is identified in italics in the sequence:
1. A customer inserts his card in the ATM
The magnetic stripe is read and stored in a buffer in the ATM
2. The customer enters his PIN
The PIN is entered into a tamper-proof PIN pad The stored PIN is stored in a security module in hardware
3. The customer requests cash
The message is constructed in the ATM The PIN (and possibly more) is enciphered under the Terminal key
The message is sent to the host, possibly enciphered in comms hardware.
On receipt at the host, the comms level encryption is deciphered The CVV is calculated and compared to the value on the magstripe The PIN under the Terminal key is deciphered The PIN offset or PVV is calculated The PIN offset or PVV is compared to the database of PVV's
4. The transaction is approved, cash is dispensed
Cryptography in an EFTPoS Transaction
Even in a signature authorised environment, the CVV from the magnetic stripe can be validated at the host system to detect counterfeit cards. Clearly this only works in online environments as the CVV validation requires a cryptographic calculation to be performed at the host.
[Note: It is possible, and some manufacturers support, local key storage on EFTPoS devices and distributed terminals. Because of the key management complications, these devices are not considered here]
A more common use of cryptography in EFTPoS environments (and, increasingly in ATM and other traffic) is the MAC (Message Authentication Code). The MAC check can be thought of as a value calculated from the contents of all the critical fields in a message (such as card number and amount) and passed through a cryptographic algorithm. Although the message is carried over transmission lines in clear, the validation of the MAC field at the recipient will determine whether fields have been tampered with. [for the technically minded, MAC can be thought of as an encrypted LRC field]. The overhead of MAC is quite small. (The MAC is defined as 16 bytes in ISO8583).
In cases where cryptography is required for widespread dissemination to the public (such as PC based home banking) ordinary DES is too complex to manage securely. More appropriate and more secure algorithms such as RSA have evolved and been deployed in these environments - they are outside the scope of this paper but review of public key algorithms is especially encouraged where appropriate.
Wednesday, September 19, 2007
CREDIT CARD SMART CARD DEBIT CARD TECNOLOGY
Credit Card
Practically every online business accepts credit cards, and so should yours. But you should be prepared to shop around and ask questions before settling on a provider for your credit card merchant account. This article lets you know what to expect. Maybe you haven’t been in business long enough to have to confront this issue yet, especially if you started small. Sooner or later, though, you will have to face the fact that customers prefer to make purchases using their credit cards. What’s more, when they can use their credit card, customers tend to buy more. To someone who sells anything online, be it web hosting services or collectibles through eBay, the implication is plain: you need to be able to accept credit cards. Maybe you’re still fighting it. To be able to accept credit cards, you know that you need to get a merchant account. Maybe you think it will be too expensive, or too complicated, or that you won’t qualify. While it is a good idea to shop around for an account, and there are certain questions you need to ask, it’s a relatively easy process – certainly much easier than running a business! Still not convinced? Let me give you a few points to think about. The average customer won’t take you seriously as a business unless you accept credit cards. Even arts and crafts vendors at malls take credit cards; you’re trying to sell goods and services over the Internet! Most people who buy anything online do it with a credit card; they won’t be inclined to change their habits just for you. You may have conducted some business via Western Union or PayPal. Those methods aren’t enough. Too many people are unfamiliar with Western Union. As to PayPal, there are still too many horror stories circulating about it. What it comes down to is a matter of trust. If you can accept credit cards, this means you have a merchant account, which means your name, address, and social security number are on file with a bank somewhere – so you’re not a fly-by-night. From your customer’s point of view, you’re less likely to be a crook. For argument’s sake, let’s say that you have been conducting business via cash, check, and PayPal up to this point. When should you get a real merchant account? Look at your PayPal receipts. When your monthly sales volume reaches $1,000 or more, it’s time to get real. You might even consider making the move before that point if your sales are showing a consistent upward trend.
