In contrast to magnetic stripe cards, as well as many other authentication technologies, today’s more sophisticated multi-application smartcards feature a wide menu of possible security functions. These security functions can each have its own access control rules which can be a secret of varying type, for example, PIN, symmetric key, biometrics, etc. Some of these have been canvassed already in this document:
• PIN-protected card access, with fine-grained access controls to data objects so that different areas of memory can be subject to different security rules. Likewise, functions in the card, including those realised using card applications downloaded into multi-programmable smartcards, can also be PIN-enabled, to help safeguard lost and stolen smartcards against potential abuse.
• Cardholder verification – the card may use a built-in PIN or biometric template to prevent misuse if lost or stolen.
• Card and terminal verification – the card and the card reader mutually authenticate to ensure each is genuine.
• Cryptography - including private key storage, on-chip key generation, symmetric encryption, public key security functionality, certificate storage and management. A smartcard may have sufficient processing power, especially if manufactured with a cryptographic co-processor, to carry out a range of cryptographic functions independently from external equipment to enforce a number of security functions. These include both symmetric and asymmetric (public key) functions. In particular, digital signatures may be generated on the card, without ever releasing the private signing key to the outside world4.
Device security and prevention of counterfeiting, cloning or skimming are provided by a number of high-integrity features resistant to unauthorised access. For example, low-level codes or serial numbers can be hard-wired or ‘burnt’ into the smartcard hardware or firmware at manufacture. Thus smartcards cannot be duplicated without a comprehensive attack on the smartcard foundry itself, or by gaining access to design details of the semiconductor chip mask, information which is held extremely closely by the manufacturers and which is not useful to attackers unless they themselves can fabricate chips. Even if an attacker obtains the cardholder’s PIN, while they may be able to abuse the card until such time as it is revoked, they will, for all practical purposes, be unable to duplicate the card.
• Tamper-resistance – attempts to access a chip directly, bypassing the contacts, can be detected, made evident by security plastics design, and/or responded to actively by shutting down chip functions or ‘zero-ising’ data.
• Biometrics – templates for secure one to-one verification may be stored on the smartcard. Added security may come from implementing ‘match-on-card’, which obviates the need for biometric templates to be stored centrally. Match-on-card has several benefits including better resistance to replay attack, less reliance on network performance or availability, and a reduction in sensitive information being stored centrally where it might be attacked.
On the other hand, because biometric templates and algorithms are usually proprietary, interoperability between sensors, software and cards from different vendors is difficult to achieve, leading to difficult choices needing to be made around single vendor biometric solutions. A common compromise approach today is to only store raw biometric data – such as JPEG images of fingerprints or faces – on the smartcard, on the basis that a wider range of algorithms will be usable for match processing. Match-on-card is basically ruled out when raw data is stored on the chip as smartcard memory requirements are significantly increased.
• Identity management – smartcards can be configured as ‘containers’ for identifiers and digital credentials, as raw data, or for added security in the form of public key certificates. Such IDs might be held in free-read memory, or kept in access-controlled memory where PIN protection adds security and privacy (consent) mechanisms.
8.2 Potential security vulnerabilities
There is, of course, no such thing as perfect security. Like any other security component, smartcards have their own vulnerabilities. Moreover, smartcards are only one component of an overarching information system, the end-to-end security of which will depend on many other factors. In all cases, smartcard deployments should undertake threat and risk assessments specific to their local requirements, and/or other security reviews as appropriate. The major security vulnerabilities are:
• Direct probing by, for example, scanning electron microscope, bypassing the contacts can in principle be used to reveal memory contents. Codes might then be discovered or other secret firmware security functions reverse-engineered. A range of protective mechanisms are available, and are measured and certified under standards such as the United States Federal Information Processing Standards (FIPS) 140-2. These mechanisms should not be regarded as a definitive list.
• ‘Side channel’ attacks make use of inadvertent signals emitted by a system through the course of its operation to reveal critical information to an attacker. The term refers to the use of a communication medium other than the intended ones. Side channel attacks are the subject of intense academic and private sector research and development. Some of the better known side channel attacks on smartcard hardware, all of which have specific countermeasures known to the smartcard manufacturers,are:
real-time variations in power consumption which, if analysed carefully, can reveal about the security codes contained
inside; to effect a differential power analysis attack, surreptitious modifications might be made to a smartcard reader to retrieve the necessary power signal
- timing attacks – similar to differential power analysis, these involve looking at miniscule variations in the time taken to
- the ‘Belcore attack’ is a type of fault injection technique where irradiating a smartcard non-destructively can invoke
exceptional behaviours and thereby reveal card contents to a skilled analyst.
• Cryptanalysis is the practice of seeking fundamental weaknesses in publicly disclosed algorithms.
• Quantum computing is recognised as an in-principle threat to today’s number theoretical approaches to cryptography. Today’s factorisation-based encryption algorithms like RSA are based on the computational difficulty of working out the factors of large numbers; the only known approaches rest largely on ‘brute force’ or trial and error, which takes unfeasibly long periods of time with conventional computing technologies. Quantum computers represent a radically different architecture, which in theory can perform certain types of parallel operations (like factoring) almost instantaneously, which would render today’s cryptography obsolete. There is a possibility that quantum computing will progress to commercial availability at some point in the future, but this prospect affects all security systems, not just smartcards.
9 Operating systems
Almost all computers feature a built-in ‘executive’ program called the ‘operating system’, which controls resources like memory, input/output, instruction processing and security, and allows application software to access and use those resources. Specialised computer systems like smartcards require special operating systems to address issues such as small memory size, relatively low-speed interfaces, unusual hardware features, and security in the multi-application environment.
Two of the most widely used card operating systems in the smartcard industry are Javacard and MultOS5 (although there are many others with smaller market share or special niche market positions, including some open source ones). These are both proprietary but over time have gradually become more transparent. MultOS defines a platform for card and application life cycle management, including application loading, deleting and data updating. Javacard, the Global Platform specifications, also provides standards for an open smartcard infrastructure that enables service providers from many industries to deploy and manage multiple applications for their customers through a variety of devices6 .
Selection of an appropriate operating system can be critical to card success. Choosing the correct operating system increases the functionality of the card by supporting reconfiguration of applications after the card is issued. In many instances, an issuing organisation initially deploys a card with a single application; then, as card acceptance grows and market opportunities arise, the issuer can increase the functionality of the card by adding new applications. Applications can be added efficiently when an operating system supports secure dynamic loading and unloading of applications.
An open operating system allows any card deployment to migrate to more functionality as market and consumer acceptance increase.