Hardware Security

[ main | schedule | cases | smartcard practicalities | project work | side-channel lab ]

Each group designs and implements a smartcard application. Each of these applications involves one smartcard applet and two terminals that this applet interacts with. (By "terminal" here we do not mean the physical card reader, but the software behind that which takes care of the interaction with the smartcards.)

Keep the terminal applications as simple as possible. These terminals may be connected to - or be part of - physical devices such as a cash register, petrol pump, or car. For testing purposes, you will also have to develop rudimentary simulations of these devices. You are free to use any convenient way to integrate terminals and these (simulations of) devices, and to define convenient interfaces between them. Also, there is no need to implement any of the back-office infrastructure the terminals might require in a real-life scenario.

The descriptions below leaves many options open. Feel free to make you own sensible choices, but keep track of any design choices and assumptions you make.

To keep things interesting, make sure that you record some information on the card itself (e.g. money, rations, access codes for cars, loyalty points). You could just use the card just authentication token, and do everything else in the back-end. (All terminals then need to be permanently online, but in our increasingly online world that is not such a strange assumption. But then the card becomes a generic and dumb authentication token, which is not so interesting. In real life you could simply use a generic Mifare DESfire card and not bother with developing a custom Java Card solution.

E-Purse

Design and implement an electronic purse à la Chipknip. This application consists of:

The balance of the E-purse applet can be creditted at the reload terminal only. In a store the card can be debitted at a POS.

The card should authenticate the reload terminal (only "valid" reload terminals are allowed to increase the balance). The POS should authenticate the card (payment is only possible with "valid" cards). When the keys on one card are compromised, the system as a whole should still be safe.

Rental Car

A Car Rental firm is planning to use smartcards for several purposes. Each customer is given a smartcard. The smartcard is used to identify the customer (with respect to the customer administration data base), but it is also used as an ignition key, and keeps track of the mileage during driving.

Design and implement such a system. The system consists of:

Petrol Rationing

Due to the unfortunate outcome of a war somewhere in the Middle East, the government has found it necessary to introduce a rationing scheme for petrol, where all car owners receive a fixed monthly petrol allowance.

Design and implement a smartcard-based petrol rationing scheme. This application should consist of:

All car owners are given a petrol rationing smartcard that keeps track of how much of their petrol allowance they still have. All petrol pumps are equipped with card terminals, and will only supply petrol upon presentation of a petrol rationing smartcard, and subtract the amount of petrol supplied from the allowance on that card. There are special terminals for charging rationing cards. Inserting the card in a charging terminal will increase the allowance by the fixed monthly allowance - provided the card hasn't been charged already that month.

Loyalty Card

A supermarket wants to give its customers bonus cards so that they can collect loyalty points when they buy items at the store. Design and implement a loyalty application, à la Airmiles. This application consists of:

The loyalty applet keeps track of the balance of loyalty points saved, and the POS can instruct the applet to add or remove loyalty points. Obviously, customers should not be able to increase their balance unless they buy products at the store.