The previous application, the counter, is interesting because we can make it evolve into some kind of an electronic purse, i.e., a real-life application. This is very nice, but the problem with this kind of real-life application (a payment application) is rather useless if you are not (at least) a bank.
I therefore decide to move to a different example, which could be useful to everybody who owns a smart card: a password safe. We all need a lot of passwords, and smart cards are not really useful (yet?) for Web authentication. This means that we have to manage quite a number of logins and passwords. And for those of use who use more than one e-mail in their everyday life, things can get quite difficult. Therefore, I chose that application as a useful example.
Writing this application will take many steps, and the two first steps are a functional description and a small security analysis.
The use case is very simple. The card is queried directly by the user in order to retrieve the identifier and password associated to a name. The objective is to make all this very simple, without even trying to interface the card with a browser. The objective is not automation, but simply a safe place for storing your passwords.
Here are the basic features of the application:
- Associate a name (e.g., Amazon) with an identifier (e.g., johndoe) and a password (e.g., 7He-30s5). The name does not need to be a URL, because we don’t intend the application to be usable from a browser.
- Search for a given name, and then retrieve the identifier and password associated to it.
- List all available names.
We may add more features later, when we will need them. Since we are on a smart card, we can notice that this store/search/retrieve pattern looks a lot like TLV records, so we will use these standard structures.
This application is quite classical and simple, so we can do a basic security analysis:
- Assets. The assets are easy to identify. The most important ones are the passwords, and secondary assets are identifiers. There are at least two reasons for making the identifiers assets. First, knowing somebody’s identifier may be sufficient for some attacks (for instance, spamming a blog); then, many persons have a tendency to use the same passwords for the same identifier, which makes the identifier sensitive. In both cases, the most important propertyis confidentiality, and integrity also needs to be considered, in particular for the passwords.
- Threats. The threat consists of anything that can be done when the identifiers and passwords are known. In many cases, including the Amazon example above, this includes the ability to make purchases in the name of the victim.
- Countermeasures. The first obvious countermeasure is to define a master password, and to make sure that the assets are not available until the master password has been presented. The next countermeasures consist in protecting the integrity and confidentiality of the stored data.
- Impact of countermeasures. When designing countermeasures, it is important to understand the (possibly negative) impact of countermeasures. Here, there is no major issue, except the possible loss of the passwords. We will here consider two different issues: the loss of the master password, and the loss of the card. In both cases, the issue is to backup the data as required. We will therefore consider this.
In the next steps, we will construct the application, adding the various features in little steps, and focusing every time on a particular Java Card feature:
- First, we will construct the storage and search engine, focusing on the management of persistent data in Java Card.
- Then, we will add the master password, focusing on the management of authentication data in Java Card.
- Then, we will secure the sensitive data, using data structures provided by the platform.
- Then, we will make the application usable on some weak platforms, by adding an explicit encryption layer, focusing on Java Card’s cryptographic routines.
- Then, we will add a way to backup the application data, by first studying the security impact, and then writing the code for the backup.
- Finally, we will look at ways to test the application, with a specific focus on unit testing.