Suggestions for Secure Smart Card Engineering (Part 1 - Secure Channel Protocol)


Smart Cards have been in the field for decades but the current state of the security of Smart Cards and their uses are still plagued by disaster. Recent papers [1] have shown that improper design and implementation of security protocols have resulted in the Smart Cards being insecure. The Smart Card IC chips themselves that have a Common Criteria 5+ and above certification and more desirably with inclusive of FIPS 140-2 Level 2 and above certification are somewhat much more secure but the weakest link of any security system is where it is at it's weakest. One of the enduring weakest link of the Smart Card disaster is the application and protocol design between the host machine (Smart Card reader) and the Smart Card itself instead of the end-user themselves.

Smart Cards communicate to the reader via a logical protocol called a Application Data Protocol Unit (APDU) which is equivalent to the TCP/IP protocol for the Internet but this lightweight protocol is made for the Smart Cards to lessen overhead when transferring data between the Smart Card and the reader. Just like the TCP/IP, the APDU were not intended to be a secure protocol for Smart Card communication in the beginning despite it's application in the security-centric field. This seems to be a mis-step by it's original designers to exclude protocol security into the blueprint of the APDU protocol. Subsequent Smart Card forums like the GlobalPlatform added the Secure Channel Protocol (SCP) notably SCP02 and recently SCP03 into the SCP specification for the host card reader to "securely" communicate with the Smart Card [2]. SCP01 and 02 (which is version 1 and 2 of SCP) is a symmetric keyed ciphering mechanism using DES (1 key) or TDES (2 Key) with TDES (2 Key) default but most of the depths and details are left open for interpretation by Smart Card OS makers and developers. NXP's JCOP Card OS defaults to DES-based ciphering mechanisms (DES/TDES) wth CBC block ciphering mode for the JCOP OS. The AES-based SCP comes with the introduction of SCP03 (version 3) [3] and a asymmetric based SCP10 [2].

Despite the existence of the SCP protocols to secure the APDU data flow between the Smart Card and reader, It is interesting to note that the adoption of SCP-based protocol security or such equivalent enforcement of security on the data flow between the card and reader have not been thoroughly enforced due to the fact that papers [1] have shown existence of a lack of implementation of these secure protocols in security critical deployments. Without the proper use of the SCP channels, communication between the card and reader can be observed and tampered. The advancement of IC chip technology allows attackers to overlay a modified smart card chip or sensitive electronics on top of the original card's chip to intercept and tamper with proper APDU data flow. This is the equivalent to intercepting and modifying TCP/IP communication over the open Internet without HTTPS or badly implement HTTPS (including export cipher suites - DES cipher). It is as good as the "Wild Wide Web" again but now in the form of "Chip-and-PIN". The primary fall of Smart Card security engineering like most failed security engineering is bad protocol designs and implementations that are either not properly reviewed by the relevant experts and the open IT Security community.

Another deeper problem with the poor security engineering around Smart Card technology in the the field requiring multiple players (e.g. eCommerce and decentralized eCash) is blind trust in the host machine with the reader. Malicious readers in a multi-player environment are equivalent to "Lilith" or "Eve" in the context of Cryptography which has the ability to listen to a communication channel and tamper it at will [4]. From the perspective of Network Security, without a validation authority, there is no trust anchor whatsoever.

Interesting to note, GlobalPlatform is supposed to be an open forum for Smart Card development but a membership and some contact information have to be registered online before you are allowed to download the latest specifications (including the SCP03 specification) without clearly specifying the License Agreement in a clear form prior to interested parties handing their contact information over.

Some lessons learnt from the SSL and TLS protocols and other Network Security protocols can be used as a pointer to improve Smart Card data flow security. TLS specifications has been actively depreciating export cipher suites and weak cipher suites which Smart Card makers and GlobalPlatform could take on similar approach. The majority of availability of Smart Cards with SCP02 (2 Key TDES) in the market should also be depreciated as soon as possible and switch over to SCP03 (AES cipher) with making the SCP03 specifications open and free to the general public without needing to sign up any sort of online form or to agree to any sort of hidden or explicit License Agreement.

The enforcement of using SCP03 or SCP10 channels or some form of encrypted and authenticated SCP to secure the Smart Card APDU datagrams in all APDU communication between the card and host must be required in future Smart Card implementations. This ensures that the Smart Card and host are both secured and authenticated to each other (either by symmetric or asymmetric key methods). Forward Secrecy and replay resilience must also be enforced with a session key being negotiated and a 32 bit random session counter that will terminate connection from either the host or card side whenever a replay attack is suspected and a new session has to be re-negotiated. Encryption and MAC-ing of the APDU datagram can be done to just the Data portion of the APDU datagram or for added security, to the entire APDU datagram. The argument of overhead for securing the datagram packets can be counteracted by the cryptographic co-processor each Smart Card possess and using either a TDES 3 Key (not 2 Key) or an AES cipher for encryption and an implementation of a HMAC-SHA2 based algorithm where the HMAC should be easily implemented in the Smart Card OS and the SHA engine leveraging the cryptographic co-processor in the Smart Card for a symmetric keyed SCP scheme. Asymmetric schemes may use RSA, ECC and Diffie-Hellman (both traditional and ECC-based) to authenticate the identities of the host and the card and also negotiating and wrapping symmetric session keys.

The use of SCP relies heavily on the availability of such protocols on the card which leaves a huge gap in protocol security. This forces the card developer to create proprietary card protocols which might be insecure. Furthermore, symmetric SCP channels seem to lack Forward Secrecy properties. The below will be a list of suggestions to secure the APDU datagrams from the point of view of a Smart Card developer trying to create his/her own protocol or from the point of view of GlobalPlatform of Smart Card regulatory bodies seeking to improve on their SCP protocols. The suggestions below take into consideration the very limited resource a Smart Card possess and the small packet length the APDU buffer in the Smart Card could afford for the APDU datagram packets. Considering that some low end Smart Cards can only sustain a 37 byte APDU buffer size (minimum APDU packet size in JavaCard specification) [5], a 2 byte nonce (total) would be acceptable for very short term security for 2^(16/2) session messages before a re-negotiation is required. Smart Card developers or regulation bodies may take these suggestions into account.

  1. Symmetric Keyed Protocol with Forward Secrecy:

    Host and card may use their embedded key sets to negotiate session keys by either the card sending a random key, the host sending a random key or both parties sending random keys to each other wrapped in the embedded key sets. An example where both parties send random keys to each other can concatenate half of the card's random key and concatenate half of the host's random key to merge and form into a full length key. Another method is for both the host and card's random keys to be XOR-ed to each other to derive a session key. SHA hashing can be applied to the final session key derived from the host and card's randomly generated keys to make the key more random (CSPRNG style). The subsequent encryption and message authentication can rely on this session key (must have enough length otherwise hash it to derive more key materials). If the derived materials have unused bytes, they can be used to derive the 4 byte replay prevention counter (last 4 bytes of the original unused key material) or a safer approach is for either sides to force 4 bytes of random nonce to each other or both sides to again contribute 2 bytes of nonce and merge them into a 4 byte counter nonce to protect against replay attacks.

  2. Asymmetric Keyed Protocol with Forward Secrecy:

    Asymmetric cryptography usually leverages on wrapping symmetric session keys with asymmetric encryption (in the case of RSA) or to attempt a key negotiation (in the case of Diffie-Hellman based protocols including the ECDH). Purely RSA based key wrapping protocols are rather straightforward by having the RSA public keys wrapping session keys and sending to the intended parties while the Diffie-Hellman based protocols would require the choosing of prime (p), generator (g) and generating a Y value (Alice's Y = g^a mod p) for exchanging and taking in the other party's Y value to generate S (Alice's S = Bob's Y ^ a mod p) and the S is used to determine the session encryption and MAC-ing keys (also the 4 byte or 2 byte nonce for replay prevention).

    In a RSA context, mutual attestation of each other's keys (of host and card) or only attesting the card's key similar to TLS's server authentication or client and server authentication but without the TLS structure and protocol formats to reduce overhead and performance can be carried out. The host and card can use the "Symmetric Keyed Protocol with Forward Secrecy" methods to use RSA to wrap random bytes for negotiating a final session key set which either side can either force the key set onto the other party or both sides work together to come out with half of the random bytes and merge the random bytes or perform some operations on the random bytes to derive a session key. A Diffie-Hellman can also be used to negotiate the session keys while using a long term RSA or DSA key to sign the Diffie Hellman values for authenticity. More higher end Smart Cards do support ECC-based key negotiations and signatures by first negotiating ECDH parameters then use a long term RSA, DSA or ECDSA key to sign the ECDH parameters. One consideration for such an approach is whether the host is required to produce a valid keypair attestation to the card before session is accepted (similar to a client and server TLS authentication scheme) and to improve security, the use of certificate pinning and trusted CA certificate to sign both the host and card's keypair before being deployed. The use of trusted CAs together with card and host authentication schemes produces somewhat more overhead but strengthens security and trust between card and host knowing that a malicious MITM attack is unlikely to succeed which would have prevented such an incident [1].

    A note for Smart Card implementors would be to weight the security benefits necessary versus speed of the proprietary protocol of the GlobalPlatform SCP10 asymmetric protocol is not used. The transportation of security parameters like the Public Keys and asymmetric values for Diffie-Hellman based protocols may not fit comfortably into a single APDU packet (considering it is a standard 256 byte buffer) due to 5 bytes reserved for APDU protocol headers. A full 256 bytes (2048 bit) asymmetric key requires at least 2 transmission to fully send out the entire Public Key bytes of a 2048 bit key. A method of "chaining" or multiple packet data flow control is required to create a proprietary secure channel protocol.

  3. Multiple Party Trust and Attestation:

    In the context of an electronic payment made via a payment Smart Card (a.k.a Chip-and-PIN), the host (card terminal) might be hostile or have been sabotaged and security engineers and regulation bodies have to take into account of putting in defenses against such an attack vector. The authentication of the card terminal might be required which the card terminal would need a secure SAM card that has been authorized by the bank or payment authority by signing the terminal's long term certificate and for all cryptographic operation to take place in the approved and authorized SAM card containing the authorized long term keys. The card equipped with the bank's or payment authority's certificate would establish a secure channel to the bank or authority to authenticate payment card terminal and via the card terminal's network. Once the terminal has been verified as a genuine channel the terminal can cryptographic sign the amount to be paid and other critical payment information of the merchant to the card which the card will use the secure channel it established with the authority while using the card terminal's network to send payment information and the payment terminal itself will also have a session with the bank to share information of the payment that is being executed. This would verify the authenticity of all parties involved but that does not handle correctness of execution or possibly tampered terminals or cards. The problem of secure PIN entry into a foreign card terminal can be daunting and dangerous. This will be touched in the following topics on Secure Smart Card Engineering.


References

  1. When Organized Crime Applies Academic Results: A Forensic Analysis of an In-Card Listening Device
  2. GlobalPlatform Card Specifciation Version 2.2
  3. GlobalPlatform Launches Secure Channel Protocol 03
  4. How Smartcard Payment Systems Fail
  5. JavaCard APDU Class


Publication Info
Published On: 26th Oct 2015
Author: Thoth


CONTACT