NFC simply about complicated: approaches to the data safety of the participants of NFC-ecosystem - the interview of the IT-Director of NovaCard, Alexey Kovalev for "Cards' World" journal - #3, 2013

This article is devoted to several aspects of NFC UICC-cards structure which are related to data safety. The article must be interesting to the banks, first of all, which are one of the most important participants of NFC-ecosystem. The telecommunication operators can find there the principles which will able to provide them with comfort and secure conditions of data co-existence of different participants on NFC UICC-card.

I would like to remind that there are several variants of location of the Secure Element (hereinafter referred to as SE, English version Secure Element or SE in shot):

- built in the telephone (when a chip of SE is an integral part of the telephone)

-SE in the form of uSD-card

SE in the form of a specialized slipcover

-SE in the form of UICC-card, specially made

The last variant will be described as the most standardized and practiced in this article.

SE has the owner (SE Issuer). In case with UICC-card this is a mobile operator (Mobile Network Operator, MNO). Service provider (SP) renders NFC-services. The Service Provider is the Issuer or the Application Provider. How can data co-existence of different participants of NFC-ecosystem on one SE be provided? How, from one hand, can the opportunity of application load and personalization, status management and application data of different participants on one SE be provided and, from the other hand, independency and safety of each participants?

Standards of the consortium GlobalPlatform contain the answers on these questions.

The standards of this organization are already widely known in banking activities. The modern bank cards as well as NFC UICC-cards support the standards of GlobalPlatform.

I would like to remind that the consortium GlobalPlatform was founded in 1999 as an open independent organization created by the leading players of plastic cards industry. This organization pays more attention to security and safety of it’s the same name platform.

Let’s talk about one of the aspects described in the GlobalPlatform Card Specification – about security domains.

The security domain is a set of data and applications on the card, belonging to the application supplier or the card’s issuer and which allows authenticating of the application supplier as well as establishing secure channels of data exchange between him and the card, managing of card content.

There are three main types of secure domains:

Issuer Security Domain (ISD). This domain is only one, obligatory on the card is the most privilege. With the help of it, it is possible to implement loading, installation, extradition and deletion of any application on the card;

Supplementary Security Domain (SSD). It is the optional security domains which can be presented in quantity on the card and which are intended for the usage by the application suppliers.

Controlling Authority Security Domain (CASD). It is optional security domain being SSD. It serves for the check of a source and the integrity of the applications, loaded on the card as well as is being responsible for loading of initial values of SSD keys.

The domains have hierarchical treelike structure. There is Issuer Security Domain. It can have several Supplementary Security Domains each of them, in their turn, can have subordinate Supplementary Security Domains.

The structure of the security domains can be presented in the form of an entrance of an apartment house. The house (entrance) has the owner – this is the Issuer Security Domain. Flats in the house are the Supplementary Security Domains. The owner of the entrance knows how many flats he has, which of them are free and which of them are busy. He has keys for the entrance. He can give the access to free flats to the new participants.

The owner of a flat has its own keys. Only he has the access to its flat. At that the owner of the flat does not possess some «super-key» and can’t to come into the flats of other participants. The owner of the entrance can provide the owner of a flat with different rights. In particular, to provide him with the right to create rooms in the flat with his own right but not larger than the owner of the flat has. The owner of the flat can have several rooms in his flat which are locked with certain keys.

At that the lodgers which will live in the flats and rooms of their owners are the Application. They have not their own keys – to get the access to their flat they can ask the superior owners to open the doors, belonging to them.

Thus, the task of flats creation and rooms with further provision the keys, belonging to them only, to the owner is a cornerstone of dwelling security and safety of the lodgers of our apartment house.

The Supplementary Security Domains can be created and personalized by their secret keys in the process of cards emission directly. In this case the keys of each such the Security Domain are generated and stored under the protection of Hardware Security Module, HSM) certified by Personalization Bureau providing with emission.

Such the approach of the organization of the card Security Domains hierarchy is applicable to small projects when life cycle of the cards is limited (for example, when starting «pilot») or a number of the participants, potentially possessing the access to the content of a card, is limited.

Another configuration of SE when during the emission the Issuer Security Domain and the Security Domain of Authorized Party is applicable for more long-term and scaled (from the point of view of a number of the participants) projects. Further card’s content management (creation of Supplementary Security Domains, their personalization by keys as well as application loading and personalization) is implemented «Over-The-Air» (OTA), that is only because SE is a SIM-card, installed in the telephone of a subscriber. In this process besides an initiator of change in a card’s content (that is Application Vendor), two mediators will be present in any case: the Issuer and Authorized Party. Role of the Issuer is in secure sending of OTA-messages on the card (using the proper net means), role of the Authorized Party is in providing of confidentiality of the transferred data (keys of created SSD), that is open values of the keys of a new SSD will not be available for anybody but the Application Vendor.

Proceeding with the analogue with the apartment house, it is possible to compare the second variant of SE configuration with a house, which door (and keys) is located in the entrance only. At that all the flats have not doors as of the house handing over. The Security Domain of the Authorized Party is the door installation company. The owner of a flat can be sure that the owner of the house will not get the keys from his new door as he trusts the door installation company. Besides of it, this company allows installing of locks, bought by the future owners of the flats, for its doors. Thus, nobody will have the access to the keys for the doors, except the owner of a flat himself.

How is creation of the Supplementary Security Domains implemented and what is more important, their secure personalization by secret keys?

The consortium GlobalPlatform offers two scenarios of implementation of these actions. According to the first, a card generates the key of the Security Domain by itself and then sends it to the Application Vendor in the codified way (pull-model). According to the second, the Application Vendor implements generation of the keys and sends them on the card in the same way (pull-model). In both cases the Authorised Party provides with authenticity of the messaged transferred from/onto the card. Depending on the used scenario as well as on the scheme of data encoding (symmetrical or asymmetrical), the key information in the open way will be applicable to the Application Vendor only or and to the Authorised Party (but not to the Issuer providing with OTA-transportation of the codified messages from/into the card).

After the moment when the owner of a flat has got his keys safety (or after house building or handing over, or then – attracting the door installation company), he has to provide with the access to his flat for those lodgers which will be live there. Besides, the lodgers must be registered in the flats (to put stamp in their passports that is to personalize applications). This work is extremely important and responsible obligation of the owner of the flat, as he is responsible for the security of his lodgers lining in the flats. But the owner of the entrance should control who lives in his house.

Depending on a degree of the confidence between the owners and the lodgers of our house, it is possible to point out several models of the lodger registration in the flats. At that, bearing in mind that the owners of the proper flats provide their lodgers with the security let’s have in view that there is a maximum degree of confidence (Applications belong to the Security Domains) between a lodger and the owner of a flat). It is meant in any model that a concrete lodger (through the owner of his flat) and a passport office that is who have some way of the security of a lodger’s passport at the stage of its handing over the passport office that in nobody has the access to the personal data of a lodger, except the lodger and the passport officer.

Models of lodgers’ registration in flats:

Confidence to the entrance owner. In this case the owner of the entrance occupies with lodgers registration that is his obligation is to transport passports kept out of sight to the passport officer and back to the lodger.

Confidence to the flats owners. In this case the owner of the entrance trusts the work with the passport officer to the owners of flats. However, each require to the passport officer must be certified by the signature of the owner of the entrance.

Full confidence to the flat owners. In this case, the owner of the entrance also trusts the work with the passport officer to the flats owners, but the passport officer need no assurance any more (we may say that the flats owners have a letter of authority from the owner of the entrance).

Above mentioned models of loading, installation and personalization of a card’s application are formalized by the consortium GlobalPlatform in the form of three different configurations of the Seciruty Domains of a card, complying with different business-requirements of a concrete NFC-project.

The main criteria of pointing out of different operating modes of a card is a degree of confidence between the Issuer of the card and the Application Vendor, Moreover, each operating mode of the card admits disintegration of applications loading and installing processes and their personalization (that is card content management and personalization can be divided between different participants of NFC-ecosystem). At that the personalized data of an application is always secured by the Security Domain with which this application is connected beyond the chosen operating mode of the card (that is the Issuer can not get the access to them - his task is in OTA transportation of commands or/and in providing with the right of conditional or unconditional management of the card content).

Theoretically it is admitted the presence of two OTA-platforms, the owner of which are the Issuer and the Application Vendor (or his authorized person called TSM). This fact allows pointing out different variants of the card content management and applications personalization within one mode.

Operating modes of a card and their variants.

Simple Mode. The Issuer of a card occupies with sending the programs of the card content management and personalization. This mode had the variant when the Application Vendor (or its TSM) has his own OTA-platform where application personalization can be implemented only (that is the Issuer loads, installs and cancels applications but does not personalize them).

Delegated Management Mode. This mode implies that the Application Vendor (or his TSM) has his own OTA-platform with the help of which the card content management and their personalization are implemented. However, each command, sent by the Application Vendor on the card mast be certified by the signature of the Issuer – only then it will be processed by the card.

Authorized Mode. This mode differs from the previous one, the Issuer provides the Application Vendor (his Security Domain) with the conditional right to manage the card content (that is there is no necessity in signing of each command).

We should not underestimate the role of the third authorized party, which serves as the link between the participants of NFC-ecosystem that is between a mobile operator – the owners of the SE and Services Providers.

In case of card issuance with created fixed security domains a manufacturer of the card, servicing as a personalization bureau which either personalizes telecommunication part of the card or creates all domains of the card, plays the role of this third party. He provides the mobile operator with a key of a card Issuer and keeps the keys out from all the Supplementary Domains until they will not be required by any Service Provider.

In case of security domains management during life cycle of the card the third party can assumes the role of the authorization center providing with secure personalization of the Supplementary Domains by keys of the Services Provider as well as the role of a technological partner rendering technological services for management of his applications on SE to the Service Provider.

The third party takes care of establishment of interaction with the mobile operators as well as all the problems related to acquisition, installation, set-up, support in an actual state and exploitation of the means of application management on SE, having given the opportunity to focus on his own business to the Service Provider.