Employing Security Channel Protocol in the NFC Environment

WHITEPAPER |

Employing Security Channel Protocol In the NFC Environment

‘Global Platform’ (GP) created specifications that enabled different players to provide digital services and allow devices to be trusted and managed securely by protecting their privacy. In this regard, GP introduced Secure Channel Protocol (SCP) in smart cards to enable devices to exchange data in open channel and to protect against data skimming and establish secure communication. This white paper throws light on the comprehensive design and lucid implementation of Secure Channel Protocol variant three (SCP03) with a dedicated focus towards contactless smart cards. These cards are based on Near Field Communication (NFC) which is used for user authentication for a secure device. Every approach behind the secure communication, the management of ‘encryption keys’, creation of boundaries that form ‘security domain’s’ and how these enable to create a ‘secure channel’ has been discussed. The document lists out various NIST specification which sets the strength of the encryption keys and enables common compliance criteria.

Read on.

Authored by: Ravikiran HV Chaitra Patil

Reviewed by: Shreeranganath Gupta

The Growth of NFC

Short range wireless communication is a major feature of NFC technology. With this inherent nature of short range, smart cards evolved to become contactless smart card as it enabled to have contactless feature with communication happening in vicinity of user, which established physical level trust and security for data exchange. Rapid growth of NFC based mobile units and low-cost deployment allowed various industries to adopt this technology for financial transactions, user authentication, secure login to workplace, secure PC login etc.

Like any other wireless communication systems, NFC has also witnessed the security threats of eavesdropping, data modification, denial of service, relay attacks etc.

Figure 1 - Applications of NFC

With a great adoption of ‘contactless devices - smart cards’ industry noticed an immediate spike in impulsive security threat revolving around NFC communication of smart cards. Presently, enabling both secure communication and interoperability between the various stakeholders such as banks and financial institution is a herculean task. We have discussed these topics in detail in our whitepaper.

Formulating Guidelines to Secure the Environment

GP specifications provided solutions to these problems via SCP as it enabled secure bidirectional communication between the participating entities (ex: a smartcard and a card reader). Identification, mutual authentication and secure messaging constitute the primary features of SCP03 towards securing the communication between the devices. In our

recent product “ORWL” the secure computer, GP compliant SCP03 has been seamlessly implemented as a key component of security and trust establishment between ORWL PC and its companion ‘keyfob’. In subsequent segments, we will discuss ORWL secure computer as a reference with keyfob acting as a ‘contactless smart card’ and ORWL as a NFC reader.

Figure 2 - ORWL Desktop

What is this Global Platform?

Global Platform is a non-profit organization that develops specifications to facilitate secure and interoperable embedded application development for secure chip technology. It is a widely accepted standard for secure management of data and devices such as smart cards, secure elements, SD cards, application processors etc. GP specifications were defined considering stringent security requirements for sensitive data transfer and storage.

More than 41% of the total secure element ecosystem [22+ billion devices] have already adopted this standard. GP specification introduced SCP to protect against data skimming in open channel. SCP03 evolved from legacy SCP01 and SCP02 protocols. SCP02 is vulnerable to a well-known security flaw caused by encrypting data using CBC mode with no random initialization vector (IV). GP added as an amendment to card specification v2.2 in 2014 to mitigate the possible attacks identified in predecessor SCP variants to secure the communication by altering few of the aspects to have true secure channel for communication.

Secure Channel - how is it established?

Secure channel is a communication mechanism to facilitate uncompromised exchange of sensitive data between trusted devices. Every secure channel session has three phases viz, Initiation, Operation and Termination.

In the Initiation phase, entities participating in communication - typically called cards and readers or cards and the off-card entity - exchange credentials to start a secure session.

While in Operation phase, data is exchanged with cryptographic protection based on mutual agreement in the initiation phase.

Termination, the last phase of communication is triggered by anyone of the two communicating parties to close the secure channel. Post termination, no further communication is possible between the two parties unless a new secure session is established between the same.

Figure 3 - Evading Hacking Attempts

The Key Behind Secure Channel Establishment

At the core of any secure channel, security keys play a vital role in enabling a trusted environment. NFC cards are preloaded with certain secret keys which act as a unique factor for each card while generating session keys. It’s the Key Management unit that is solely responsible for managing the keys securely. In fact, Key management is the foundation of the security architecture. It defines:

• Non-repeatable key generation (randomness) • secure storage (confidential) • and replacement of the cryptographic keys.

1. Key Types The different key types are:

Key Type Purpose

Static Secure Channel Encryption Does Encryption/Decryption during secure channel Key (Key-ENC) authentication resulting in the generation of session key

Static Secure Channel Message Does MAC generation/verification during secure channel Authentication Code Key (Key-MAC) authentication resulting in the generation of session key

Data Encryption Key (Key-DEK) Carries out Sensitive Data Encryption

Session Secure Channel encryption Maintains Data confidentiality key (S-ENC) [Session keys]

Session Secure Channel Message Ensures Data integrity Authentication Code (S-MAC)

2. How are the Keys Generated? Standard Key Derivation Functions (KDF) are used to generate the necessary cryptographic keys. Keys are derived as per NIST 800-108 with CMAC referred in NIST 800-38B specification.

3. How do they get Loaded on the Card? Generated Keys on the off-card entity are then loaded to the card securely using the GP defined PUTKey command. Based on the selected security level (Refer section 5.4.1), PUTKey command is also encrypted with the Key-DEK. Using this command, off-card entity or authorized key loader secures the right to add a new key set to the domain or replace the existing version of the keys.

4. Where are they Stored? Secure elements (SE) enable absolute secure storage of data and applications on the device memory. It helps to protect the memory content on both reader and the card to prevent malicious attacks. Only a genuine user is vested with the right to access the content after authentication. GP defines domain specific access strategy to store and access the data securely.

Figure 4 - The Keys' Cycle

5. How does the Key Replacement take place? [ORWL - specific approach] Static keys cannot afford to be a part of the open source software since the software is accessible to the entire developer community and possibilities of a compromise are always looming. Such a threat enforces the vendors to replace the security keys in runtime. In one of our recent works, we relied on dynamic security keys instead of static keys and the results were quite encouraging. Take a look at the steps involved:

• Initially, reader and the card establish an unsecure connection and generate key pairs using ‘Elliptic curve Diffie-Hellman (ECDH) Key Establishment protocol. Keys generated using ECDH are considered as base ‘shared secret’ for all subsequent communications • Reader encrypts all the three keys (‘K-ENC, K-MAC, K-DEK’) - based upon mutually agreed symmetric encryption algorithm [AES128 recommended by SCP03] - with the generated shared secret loads on to the card using PUTKey command Note: Since command payload is encrypted with the shared secret, it can only be decrypted by the entities participating in the ECDH secret generation • Upon receiving the encrypted keys, the Card decrypts the payload voluntarily and loads these keys to its own security domain

Figure 5 - Representation of a KMS Server

This approach ensures that each device - called smart card - has its own ‘unique key’ loaded on to its security domain which guarantees further secure messaging. The only known disadvantage of this method is that the Reader is compulsively required to store all the ‘unique keys’ mapped to each individual card thereby adding additional memory footprint. SCP03 recommended key size for AES is 16-Bytes. If we gauge the footprints of all the three keys, it contributes merely ‘48 extra Bytes’ per card. In our design, 80 bytes are adequately reserved for future usage which adds the memory requirement up to 128 Bytes per card. A quick calculation tells us that the servers with 10GB of memory can easily store details of up to 1 million cards. Considering the advantage of the approach, memory overhead reported here seems quite trivial and can be conveniently ignored.

How crucial is Card’s own Security Domain?

Security domain can be considered as a little-yet-crucial region of protected memory on the smart cards which is assigned to the specific applications - applets on JavaCard - running on the card. The security domain receives further categorization based on the purpose it serves.

1. Issuer Security Domain [ISD]

ISD is the mandatory, card issuer representative. It is the first application that gets installed on the card and doesn’t possess a security domain lifecycle state of its own as it inherits the life cycle state of the card.

2. Supplementary Security Domain [SSD]

SSD is created by the application owners - such as a franchise or a supermarket - who prefer to have their own secure application environment. They also provide cryptographic services using keys that are completely separate from and outside the purview of the Card Issuer. The number of SSDs which can be created by the application provider on each card is limited only by the memory availability.

3. Controlling Authority Security Domain [CASD]

Controlling Authority Security Domain [CASD]CASD is responsible for enforcing the security policy against all the application code loaded onto the card. It’s a type of supplementary security domain.

Figure 6 - Security Domains at a Glance

All the security domains existing on the card are responsible for managing their own keys. Those keys are stored in the security domain using PUTKey command after authorization and secure connection establishment. Every key that exists on the card has a unique combination of key version and an identifier using which different applications can opt to use different set of base keys to initialize the secure channel.

The first phase i.e. Secure Channel Initialization

Implicit and explicit initialization are the two secure channel initialization approaches; classified based on which entity mandates the security.

1. Implicit Initialization

A secure channel can be enforced by the card itself when it receives the first Application Protocol Data Unit (APDU). Here, the card is aware of the security level required for being functional. Also, it may know which key sets need to be put into service for default secure communication.

2. Explicit Initialization

An off-card entity can initiate the secure channel by sending a command APDU. Here, the off-card entity must instruct the card on security level requirements and which keys are to be used.

Figure 7 - Initialization - A flow diagram

The final Phase - Secure Channel Establishment

Two types of secure channels are widely adopted:

Direct: allows the application to implement the security policy

Indirect: application relies on security domain to implement the protocol.

1. The different levels of Security

SCP operates based on the security level (which can be set in EXTERNAL_AUTH command). The card can enforce a mandatory security level for each command. Also, for each command; different security levels can be configured too. Security level is derived from combination of AUTHENTICATED, C_DECRYPTION, R_ENCRYPTION, NO_SECURITY_LEVEL, CMAC and R_MAC.

2. What happens after Authentication?

On completion of successful mutual authentication, both card and readers have ‘Challenge’ of each other. Using static keys; ‘self’ and ‘other party’ challenges, both reader and card will generate a new set of keys termed session keys. These keys are unique per session based on the fact that 8 Byte challenges of both the parties are unique every time. Though the challenges are exchanged on an open channel, session keys are not compromised as key derivation is largely dependent on secret key sets secret key sets which are loaded using PUTKEY command dynamically.

i) External Auth Command External authenticate command is used to authenticate the off-card entity during the explicit secure channel initiation. Command APDU: 84 82 01 00 10 5D 69 F9 E9 A3 33 EC D3 AF 06 A6 C0 08 65 BF 20

Code Length Comments

CLA 1 byte Class byte value as per GP spec

INS 1 byte Instruction byte value

P1 1 byte Security level

P2 1 byte Always set to 0

Lc 1 byte Host cryptogram + MAC length

Data 16 byte Host cryptogram + MAC(Generated on Off-card entity)

Host cryptogram and MAC are verified on the card as part of the authentication process. On successful execution of “External Authenticate” command, the secure channel between an off-card entity and the card is established.

The Last Step - Achieving Secure Communication

Secure communication is the eventual objective of establishing a secure channel. This is achieved with the help of message encryption and MAC codes discussed below:

1. Encryption Based on the selected security level, messages are encrypted. SCP03 recommends using the 128-bit AES in CBC mode for all encryptions as described by NIST 800-38A. AES is compliant to FIPS 140-2. All messages are encrypted with the session key ‘S-ENC’. Since encryption keys are session based, it provides strong protection against relay attacks with the unique payload for each message despite the exchanged data being same in each session.

2. Message Authentication Codes Another powerful technique of MACing is used by the SCP03 to validate the data integrity. MAC values are chained in each session to ensure that messages have been received in the same order as intended. Both message and response may have authentication code based on security level configurations selected in channel initialization. Below diagram explains the APDU command data encryption and CMAC generation in accordance to SCP03.

The New MAC Chaining Value generated is considered as the MAC Chaining Value for the next consecutive command. Below figure illustrates MAC Chaining for commands.

Compliance

Global platform - as specifications provider - helps assess the implementation of embedded devices to meet the security specifications. This section briefs various compliance standards which contactless smart cards and readers need to adhere to for secure operation. Below are the compliance measures we adhered to in ORWL design along with GP 2.1 Specifications.

1. FIPS140-2 Level 4 Compliance Federal Information Processing Standards (FIPS) defines the security level requirements for cryptographic modules. NIST coordinates and provides the FIPS 140 standards for software and hardware component. It is mandatory to protect the cryptographic module within the system to provide confidentiality and integrity. FIPS 140-2 defines four different levels of security: level-1 to level-4 where level-1 is the level of lowest security and level-4 is the level of highest security. Level-4 security is mandatory for a physically unprotected environment. SCP03 by itself doesn’t provide the FIPS 140-2 level 4 compliance. Combination of hardware - Crypto accelerator - and software design is essential to provide such a security. Read ORWL story of security compliances and security audit here.

2. NIST 800-38B Compliance All Key Derivation Functions, Encryption and MAC algorithms used in the secure ecosystem must be NIST specification compliant in order to provide the intended true security for the product. The software and the hardware must together ensure the NIST compliance.

3. FIPS140-2 Level 4 Compliance This is interoperability compliance defined by International Standards Organization (ISO) for secure messaging, access rights and content management. This standard is independent of underlying technology and enables the application to design its own command sets with APDUs. Software design for NFC contactless card must be compliant to ISO 7816-4 to be interoperable with devices manufactured by various vendors.

Conclusion Global Platform defined SCP03 algorithm provides all the necessary security and randomness for contactless communication. It guarantees the security against all types of relay & replay attacks, out-of-order delivery attacks and algorithm substitution attacks. Our experiments have also proved that there are no backdoors left for any type of attacks on the system which adopts SCP03 for OTA interface. If SCP03 is implemented with the help of NIST and FIPS compliant crypto engines, it is the best possible secure solution available out there today.

Learn more about PathPartner’s IoT solutions and product engineering services

More resources available at www. Pathpartnertech.com/industries/internet-of-things. For an in-depth discussion, contact us at [email protected]

References • [ NFC Forum ] https://nfc-forum.org/

• [NIST Computer Security Publications and RFC’s] https://csrc.nist.gov/publications

• [ ARM Trust Zone] https://community.arm.com/processors/trustzone-for-armv8-m/

• [Global Platform specifications] https://www.globalplatform.org/

• [EMVCo] https://www.emvco.com/

• [JavaCardOS Forum] https://www.javacardos.com/about/

About PathPartner

PathPartner Technology is a leader in providing technology solutions and product engineering services for developing innovative intelligent systems. PathPartner offers a portfolio of enabling products and comprehensive services spanning embedded systems, hardware design, and system integration. We work with device manufacturers, system integrators and solution providers across diverse industry domains such as automotive, consumer electronics, drones, video surveillance, medical devices etc. Our deep technology expertise in multimedia systems, deep learning solutions, vision-based systems, connectivity technologies, and imaging pipelines coupled with our experience in underlying hardware platforms, enables us to provide complete solutions to our customers while expediting their time to market, and future proofing investments.

Headquartered in Bangalore, India, PathPartner has presence in USA, Europe and Japan. To learn more about us, please visit www.pathpartnertech.com.

Contact Us PathPartner Technology Pvt. Ltd. #16, PSS Plaza, 1st and 2nd Floor, New Thippasandra Main Road, HAL III Stage, Bangalore-560075.

Other presence: Bay Area, USA | Tokyo, Japan | Munich, Germany

Phone: +91 80 6772 2000 | +1 408 242 7411 | +81 905546681

Email: [email protected]

Website: www.pathpartnertech.com