Requirements

We have seen in Chapters 1 and 2 that the defining characteristic of NFC is the way transactions are initiated: by tapping an NFC-enabled phone to another device.

Often only very minimal data are exchanged during this phase of the transaction: a URL, for example. This is not likely to be sensitive from a security point of view, and the subsequent phases of the transaction can be protected to the extent required by the website, by using web technology (SSL/TLS or IPSec).

In other cases (for access control, payment or loyalty applications, for example) the phone will send information to the other device that is critical to the working of the application and is regarded as sensitive from a security point of view (the unique access control token ID, payment card number or personal details). The level of sensitivity varies: for example, a low-value prepaid balance or loyalty number should be protected but not to the same extent as bank account access credentials, e-commerce certificates or health records.

A smartphone is a relatively open environment: new programs can be downloaded to it, data can be stored in the phone memory and accessed by those programs; many operations can take place in the background, without the knowledge of the phone user. Applications that need greater security therefore make use of a combination of hardware and firmware that can be used to store programs and data securely. We will see in Chapter 10 that it is nearly always best to provide these security functions using a separate microcontroller chip or card with its own memory and cryptographic processing capability. This is called the Secure Element (SE).