Some Smart Card and Thumb Drive Applications

Part of 22C:169, Computer Security Notes
by Douglas W. Jones
THE UNIVERSITY OF IOWA Department of Computer Science

Bank Cards

One of the original applications of smart-card technology was in smart credit cards. Bank cards are initially programmed by the bank, mailed to a bank customer, and then used by the bank customers in ATMs. The following list of threats is significant:

A card could be duplicated by anyone who handles the card during delivery to the customer. This would allow them to impersonate the legitimate customer.
A card could be duplicated by a customer. Depending on details not given here, this might not pose a threat or it might pose a threat.
A card could be duplicated by a machine that pretends to be an ATM but is actually merely a card duplication machine.
A rigged ATM could eavesdrop on transactions using the card. It is not clear what threats are posed by mere eavesdropping.
A rigged ATM could interfere with transactions using the card, for example, increasing the amount of withdrawals reported to the bank while actually vending only the requested amount. As a result, whoever rigged the ATM could keep the difference.

The first and most obvious defense to put in place is simple: Once programmed, the card must not reveal its secret to the outside world. This prevents eavesdropping and it prevents card duplication.

Let us look at mechanisms for accomplishing this. First, it is noteworthy that ATMs are networked to the bank computers, the same computers that were involved in programming the bank's smart cards. As a result, the bank's computers can share secrets with these smart cards that are never revealed to anyone else. This leads to the following idea:

When inserted in the ATM, the smart card reveals its card number to the ATM, which communicates this number to the bank. The bank's computer now knows the identity of the card, and the problem is to validate the card -- that is, prove that it is indeed an authentic card, without revealing the secret used for this validation. The card knows the secret, and so does the bank computer, but they must not disclose this to anyone eavesdropping on the line between card and bank.

This leads to the following idea for the dialogue between the card and the bank's computer, via the ATM:

Card to bank: My account number is a
At bank: Lookup the secret key k[a] and compute a random number
Bank to Card: n, the nonce.
On card, apply a trapdoor function f to n and the secret value of k[a] stored on the card.
Card to Bank: f(n,k[a])
At bank: Compute f(n,k[a]) and compare it with the value sent by the card. If it matches, the card is authentic.

Note, at this point, the bank knows that the card is authentic, but the card does not know that the bank is authentic, and that neither the card nor the bank have disclosed any secrets to the ATM.
We can use a similar exchange to authenticate the bank to the card, although this poses problems because the card has very little access to random numbers, so it is difficult (not impossible) for the card to generate a nonce.
Having authenticated the card to the bank, and visa versa, the card and bank can now communicate more details about the transaction. Vulnerabilities remain

What if a wire-tap is installed between the bank and the card. An observer can watch the exchange of information and wait until the card and bank have each authenticated each other. At this point, the observer can slip in and carry out the rest of the dialogue, cutting the bank out of the circuit to talk to the card, or cutting the card out of the circuit to talk to the bank. To defend against this, the bank and the card need to agree on an encryption key (perhaps the secret they already share will suffice, but they could also use Diffie Hellman key exchange).

What if the ATM is itself dishonest? Do the bank and the card need to authenticate the ATM itself?

Notice that we must be constantly aware of the tiny memory capacity of the card and the tiny processing capacity of its processor. We cannot store any large databases on the card! The bank knows all ATMs and the bank knows all of its cards, but the card cannot know all banks or all ATMs.
How do we handle an ATM network with hundreds of different banks, where each ATM is networked to one bank, but there are many banks.

Voting Machines

In the 1990's, a company called iMark came out with a voting machine. They envisioned each voter being given a smart card as a voter ID card. The voter ID card would hold the precinct number and party for which that voter was registered. The voting machine, based on a PC with a smart-card reader, would hold all of the different ballots issued by the county.
To vote, the voter would walk up to any voting machine in the county and put his card in the machine's reader. The machine would then read the voter's precinct number and party from the card, display the correct ballot, and allow the voter to vote. As the voter pressed the final button -- the cast ballot button -- the machine would both make a permanent record of the ballot and record that the voter had voted on the voter's smart card.
This model of use, the vote-anywhere model, never happened. It would have required changes in the voting law. What emerged, after Global Election Systems bought iMark, was a conventional polling place model where smart cards were handed to the voter as the voter signed into the polling place. The card held no voter ID information, but as the voter was issued the card, the ballot style was recorded on the card -- this allowed each voting machine to hold ballots for each party in a primary, and it allowed polling places to handle multiple precincts.
Diebold bought Global Election Systems, and then a group at Johns Hopkins University got hold of the source code for the Diebold voting machine. They discovered:

That the dialogue between the smart card was not encrypted and employed no nonces or trapdoor functions. The replies, from the card to the computer, were very simple, and an observer could easily create cards that would appear valid to the voting machine, potentially allowing voters to vote illegally.

That the code on the voting machine to read from the smart card included buffer overflow vulnerabilities. Exploiting these would allow a corrupt smart card to inject executable code into the voting machine.

The Sailau voting system used in Kazakhstan uses smart-cards in a more sophisticated way. It also uses customized thumb drives for key distribution. Unfortunately, all details of the algoritms used to secure the data on the smart cards and thumb drives is a state secret and could not be revealed to anyone. As a result, the security of this system cannot be assessed.
From the outside, the Sailau system used thumb drives, referred to as crypto keys, to distribute private keys to each polling place and possibly also the public key of the Central Election Commission's server. These allow secure communication from the PC on the voter registration table at each polling place to the server.
When a voter signs in at the polling place, a smart card is loaded with a blank ballot. The voter can then vote by taking this smart card to a voting machine. The machine is generic -- it doesn't know anything but how to load a ballot from a smart card, display it on the screen, and allow the voter to record votes on the smart card. The card is then carried back to the polling place PC, where the voted ballot is read off the card and dropped in an electronic ballot box. The smart cards are reused -- as the ballot on the card is read into the ballot box, the card is erased, ready to have a new ballot stored on it.

References

See Analysis of an Electronic Voting System by Tadayoshi Kohno, Adam Stubblefield, Aviel D. Rubin and Dan S. Wallach
See the OSCE/ODIHR Election Observation Mission final report on the 4 December 2005 Presidential Election in Kazakhstan.