SMART CARD CONTENT SECURITY
`
`Defining “tamperproof” for portable smart media
`
`AUTHOR: Stefano Zanero ( s.zanero@computer.org )
`Dipartimento di Elettronica e Informazione
`Politecnico di Milano
`
`Version 1.0
`
`This work is copyrighted by the author: however, you are free to use it and redistribute it, provided that due credit is
`given. Partial or integral reproduction of this work can not be sold, or used as part of any website, magazine or book
`which is not released freely, without the permission of the author. Portions of this work are based on related and
`previous scientific works, in which case due credit is given at the bottom of the text. Please send any corrections to the
`address of the author – thank you.
`ABSTRACT
`
`Smart Cards are often touted as “secure” portable storage devices. A complete, high-level design
`metodology has been proposed for embedded information systems based on smart card devices.
`However, this metodology takes as granted that informations stored on the card will be really
`securely stored, and access control will be correctly maintained. Unfortunately, standards and
`specifications, created by hardware and software vendors for both the card hardware and the micro
`operating system which runs it have been repeatedly proven not as secure as they are commonly
`supposed to be.
`
`In this paper we try to analyze the faults in existing standards and implementations of content
`security for smart card embedded information systems, and we try to suggest possible ways (both
`hardware and software) to prevent security leaks. This paper does not provide breaking news, but
`rather tries to sum up the known techniquest to attack smart card devices.
`
`1 SMART CARD CONCEPTS
`
`1.1 CARD TYPES. WHAT IS SMART ?
`
`The International Organization for Standardization (ISO) standard 78101 "Identification Cards –
`Physical Characteristics" defines physical properties such as flexibility, temperature resistance, and
`dimensions for three different card formats (ID-1, ID-2, and ID-3).
`
`There are different types of ID-1 format cards, each specified by a different substandard2:
`
`Embossed cards: embossing allows for textual information or designs on the card to be transferred
`to paper by using a simple and inexpensive device. ISO 78113 specifies the embossed marks,
`covering their form, size, embossing height, and positioning. Transfer of information via embossing
`may seem primitive, but the simplicity of the system has made worldwide proliferation possible.
`
`Magnetic Stripe: the primary advantage that magnetic stripe technology offers over embossing is
`a reduction in the flood of paper documents. Parts 2, 4, and 5 of ISO 7811 specify the properties of
`the magnetic stripe, coding techniques, and positioning. The stripe’s storage capacity is about 1000
`bits and anyone with the appropriate read/write device can view or alter the data.
`
`PROTECTIVE ORDER MATERIAL
`
`IRIS
`EXHIBIT 2021 PAGE 1
`DOJ v. IRIS
`IPR 2016-00497
`
`

`

`Integrated Circuit cards (smart cards): these are the newest and most clever additions to the ID-1
`family, and they also follow the details laid down in the ISO 78164 series. These types of cards
`allow far greater orders of magnitude in terms of data storage – cards with over 20 Kbytes of
`memory are currently available. Also, and perhaps most important, the stored data can be protected
`against unauthorized access and tampering. Memory functions such as reading, writing, and erasing
`can be linked to specific conditions, controlled by both hardware and software. Another advantage
`of smartcards over magnetic stripe cards is that they are more reliable and have longer expected
`lifetimes.
`
`Memory Cards: though often also referred to as smartcards, memory cards are typically much less
`expensive and much less functional than microprocessor cards. They contain EEPROM and ROM
`memory, as well as some address and security logic. In the simplest designs, logic exists to prevent
`writing and erasing of the data. More complex designs allow for memory read access to be
`restricted. Since they cannot directly manipulate data they are dependent on the card reader (also
`known as the card-accepting device) for their processing and are suitable for uses where the card
`performs a fixed operation. Typical memory card applications are pre-paid telephone cards and
`health insurance cards.
`
`Contactless Smartcards: though the reliability of smartcard contacts has improved to very
`acceptable levels over the years, contacts are one of the most frequent failure points any
`electromechanical system due to dirt, wear, etc. The contactless card solves this problem and also
`provides the issuer an interesting range of new possibilities during use. Cards need no longer be
`inserted into a reader, which could improve end user acceptance. No chip contacts are visible on the
`surface of the card so that card graphics can express more freedom. Still, despite these benefits,
`contactless cards have not yet seen wide acceptance. The cost is higher and not enough experience
`has been gained to make the technology reliable. Nevertheless, this elegant solution will likely have
`its day in the sun at some time in the future.
`
`Optical Memory Cards: ISO/IEC standards 116935 and 116946 define standards for optical
`memory cards. These cards look like a card with a piece of a CD glued on top - which is basically
`what they are. They can carry many megabytes of data, but can only be written once and never
`erased with today’s technology. Today, these cards have no processor in them (although this is
`coming in the near future). While the cards are comparable in price to chip cards, the card read and
`write devices use non-standard protocols and are still very expensive. However such cards may find
`use in applications such as health care where large amounts of data must be stored.
`
`Maximum memory
`capacity (nominal)
`
`Type of on-
`board CPU
`
` Card cost
`
`Cost of reader,
`software, connections
`
`Magnetic-stripe
`cards
`Integrated circuit
`memory cards
`Integrated circuit
`processor cards
`(“Smart cards”)
`Optical Memory
`Cards
`
`140 bytes
`
`1 Kbyte
`
`8 Kbytes
`
`2.8 - 4.9 Mbyte
`
`1.2 SMART CARD BASICS
`
`None
`
`None
`
`8-bit CPU
`(16 o 32 bit in
`the near future)
`None
`
`$0.20 - $0.75
`
`$750
`
`$1 - $2.50
`
`$500
`
`$7-$15
`
`$500
`
`$7 - $12
`
`$3,500 - $4,000
`
`PROTECTIVE ORDER MATERIAL
`
`IRIS
`EXHIBIT 2021 PAGE 2
`DOJ v. IRIS
`IPR 2016-00497
`
`

`

`Integrated Circuit Cards have conventionally come to be known as "Smart cards". A smart card is a
`card that is embedded with either a microprocessor and a memory chip or only a memory chip with
`non-programmable logic. As we will see, this simple and somehow strange structure offers a bunch
`of functionalities difficult to obtain otherwise.
`
`The microprocessor card can add, delete, and otherwise manipulate information on the card, while a
`memory-chip card (for example, pre-paid phone cards) can only undertake a pre-defined operation.
`
`Smart cards, unlike magnetic stripe cards, can carry all necessary functions and information on the
`card. Therefore, they do not require access to remote databases at the time of the transaction.
`
`A typical smartcard consists of an 8-bit microprocessor running at approximately 5 MHz with
`ROM, EEPROM and RAM, together with serial input and output, all in a single chip that is
`mounted on a plastic carrier. The operating system is typically stored in ROM, the CPU uses RAM
`as its working memory, and most of the data is stored in EEPROM.
`
`A rule of thumb for smartcard silicon is that RAM requires four times as much space as EEPROM,
`which in turn requires four times as much space as ROM. There are various smart card chipset. The
`most common chipsets mount 32 kbytes of ROM, and either 32 kbytes of EEPROM with 1 Kbyte
`RAM or 16 Kbytes of EEPROM with 2 Kbytes of RAM. This gives them the equivalent processing
`power of the original IBM-XT computer, albeit with slightly less memory capacity.
`
`In addition, most smart cards embed a cryptographic coprocessor. Because the common asymmetric
`cryptographic algorithms of the day (such as RSA) require very large integer math calculations, an
`8 bit microprocessor with very little RAM can take on the order of several minutes to perform a
`1024 bit private key operation. However, if a cryptographic coprocessor is added to the architecture,
`the time required for this same operation is reduced to around a few hundred microseconds. The
`coprocessors include additional arithmetic units developed specifically for large integer math and
`fast exponentiation. There is a drawback, however, and it is the cost. The addition of a
`cryptographic coprocessor can increase the cost of today’s smartcards by 50% to 100%. These cost
`increases will likely diminish as coprocessors become more widespread.
`
`Smart cards are passive devices, which means that to function a smart card needs to be inserted into
`a reader connected to a computer, or an integrated smart terminal. These devices are usually known
`as CAD (Card Acceptance Device), and come in many kind of shapes: readers integrated into a
`vending machine, handheld battery-operated readers with a small LCD screen, readers integrated
`into a GSM mobile phone, or attached to a personal computer by a variety of interfaces.
`Mechanically, readers have various options including: whether the user must insert/remove the card
`versus automated insertion/ejection mechanism, sliding contacts versus landing contacts, and
`provisions for displays and keystroke entry. Electrically, the reader must conform to the ISO/IEC
`7816-34 standard.
`
`The CAD offers power for the smartcard chip, and an interface for communication, which is
`bidirectional and half-duplex (one-way at a time). The serial I/O interface usually consists of a
`single register, through which the data is transferred in a half duplex manner, bit by bit. Though the
`chip can be thought of as a tiny computer, the external terminal must supply the voltage, ground,
`and clock. It could also be important to remember that, though commonly referred to as “smartcard
`readers”, all smartcard enabled terminals, by definition, have the ability to read and write as long as
`the smartcard supports it and the proper access conditions have been fulfilled
`
`PROTECTIVE ORDER MATERIAL
`
`IRIS
`EXHIBIT 2021 PAGE 3
`DOJ v. IRIS
`IPR 2016-00497
`
`

`

`There are standards for data transfer format, CAD specifications, and chipset interface
`specifications. You may refer to ISO 78164 standard (based on ID-1 type cards, as specified by
`ISO7810 standard), which has originated ETSI, EMV and Open Card7 standards. These standards
`have been widely adopted, leading to interoperability of various cards and products.
`
`A smart card works in a black-box model: the CAD gives the card an input, this input is processed
`by the card chipset, and then an output is sent back to the CAD. The CAD itself cannot access
`directly the smart card EEPROM, RAM or ROM memories.
`
`Since data cannot be retrieved directly via the CAD, smart cards have been proposed as portable
`and secure data storage devices. In addition, their computing capabilities (expecially if integrated by
`the cryptogaphic co-processor) make them expecially suitable as private key storage devices for
`asymetric algorithms, since in this way private keys can be generated and stored on board the card,
`and never leave it. Encription and decription of data are performed on request by the card chipset
`itself. In this way, the user’s private key is kept secure and can not be eavesdropped. Thus, chip
`cards have been the main platform for holding a secure digital identity.
`
`1.3 PHYSICAL AND ELECTRICAL PROPERTIES
`
`As we already said, the physical size and shape of a smartcard is described in ISO 78101 and
`designated as ID-1. The dimensions are 85.6 mm by 54 mm, with a corner radius of 3.18 mm and a
`thickness of 0.76mm. ISO 78101 was created in 1985, so it did not address chip placement but
`instead addressed embossing, magnetic stripes, and so on. Smartcard chip placement is defined in
`ISO 7816-24, which is dated 1988. See figure for details:
`
`Card robustness requirements are specified in ISO 78101, 78138, and 78164 part 1. These
`specifications address such things as UV radiation, X-ray radiation, the card’s surface profile,
`mechanical robustness of card and contacts, electromagnetic susceptibility, electromagnetic
`discharges, and temperature resistance. ISO/IEC 103739 specifies the test methods for many of
`these requirements.
`
`The electrical specifications for smartcards are defined in ISO/IEC 7816 parts 2 and 3, and GSM
`11.1110. Most smartcards have eight contact fields on the front face, however, two of these are
`reserved for future use so some manufacturers produce cards with only six contact fields, which
`slightly reduces production costs.
`
`PROTECTIVE ORDER MATERIAL
`
`IRIS
`EXHIBIT 2021 PAGE 4
`DOJ v. IRIS
`IPR 2016-00497
`
`

`

`Electrical contacts are typically numbered C1 through C8 from top left to bottom right, as shown
`here both for 6 and 8 contact shapes:
`
`In the table we list for each contact a standard abbreviation and a short function description:
`
`POSITION ABBREV. FUNCTION
`C1
`Vcc
`Supply Voltage
`
`C2
`C3
`
`C4
`
`C5
`C6
`
`C7
`C8
`
`RST
`CLK
`
`RFU
`
`GND
`Vpp
`
`I/O
`RFU
`
`Reset
`Clock Frequency
`
`Reserved for future use
`
`Ground
`External programming voltage
`
`Serial input/output communications
`Reserved for future use
`
`The Vpp contact was used several years ago to supply voltage to EEPROMs for programming and
`erasing. However, with the advent of charge pumps that exist on the chip, the Vpp contact is rarely
`used today (see below for security implications of this change). The Vcc supply voltage is specified
`at 5 volts ± 10%. There is an industry push for smartcard standards to support 3 volt technology
`because all mobile phone components are available in a 3 volt configuration, and smartcards are the
`only remaining component which require a mobile phone to have a charge converter. It is
`theoretically possible to develop 3-volt smartcards, but interoperability with current 5-volt systems
`would be a problem. Nonetheless, a wider voltage range handling 3 to 5 volts will probably become
`mandatory in the near future.
`
`1.4 DATA TRANSMISSIONS
`
`All communications to and from the smartcard are carried out over the C7 contact. Thus, only one
`party can communicate at a time, whether it is the card or the terminal. This is termed "half-
`duplex". Communication is always initiated by the terminal, which implies a type of client/server
`relationship between card and terminal.
`
`After a card is inserted into a terminal, it is powered up by the terminal, executes a power-on-reset,
`and sends an Answer to Reset (ATR) to the terminal. The ATR is parsed, various parameters are
`extracted, and the terminal then submits the initial instruction to the card. The card generates a reply
`IRIS
`EXHIBIT 2021 PAGE 5
`DOJ v. IRIS
`IPR 2016-00497
`
`PROTECTIVE ORDER MATERIAL
`
`

`

`and sends it back to the terminal. The client/server relationship continues in this manner until
`processing is completed and the card is removed from the terminal.
`
`The physical transmission layer is defined in ISO/IEC 7816-3. It defines the voltage level specifics
`which end up translating into the "0" and "1" bits.
`
`Logically, there are several different protocols for exchanging information in the client/server
`relationship. They are designated "T=" plus a number, as summarized here:
`
`DESCRIPTION
`PROTOCOL
`Asynchronous, half-duplex, byte oriented, see ISO/IEC 7816-3
`T = 0
`Asynchronous, half-duplex, block oriented, see ISO/IEC 7816-3, Adm.1
`T = 1
`Asynchronous, full-duplex, block oriented, see ISO/IEC 10536-4
`T = 2
`Full duplex, not yet covered
`T = 3
`Asynchronous, half-duplex, byte oriented, (expansion of T = 0)
`T = 4
`T = 5 TO T = 13 Reserved for future use
`T = 14
`For national functions, no ISO standard
`T = 15
`Reserved for future use
`
`The two protocols most commonly seen are T=0 and T=1, T=0 being the most popular. A brief
`overview of the T=0 protocol is given below. The references contain more detailed information and
`descriptions of all the protocols.
`
`In the T=0 protocol, the terminal initiates communications by sending a 5 byte instruction header
`which includes a class byte (CLA), an instruction byte (INS), and three parameter bytes (P1, P2,
`and P3). This is followed optionally by a data section.
`
`Most commands are either incoming or outgoing from the card’s perspective and the P3 byte
`specifies the length of the data that will be incoming or outgoing. Error checking is handled
`exclusively by a parity bit appended to each transmitted byte. If the card correctly receives the 5
`bytes, it will return a one-byte acknowledgment equivalent to the received INS byte.
`
`If the terminal is sending more data (incoming command) it will send the number of bytes it
`specified in P3. Now the card has received the complete instruction and can process it and generate
`a response. All commands have a two-byte response code, SW1 and SW2, which reports success or
`an error condition. If a successful command must return additional bytes, the number of bytes is
`specified in the SW2 byte.
`
`In this case, the GET RESPONSE command is used, which is itself a 5-byte instruction conforming
`to the protocol. In the GET RESPONSE instruction, P3 will be equal to the number of bytes
`specified in the previous SW2 byte. GET RESPONSE is an outgoing command from the card’s
`
`PROTECTIVE ORDER MATERIAL
`
`IRIS
`EXHIBIT 2021 PAGE 6
`DOJ v. IRIS
`IPR 2016-00497
`
`

`

`point of view. The terminal and card communicate in this manner, using incoming or outgoing
`commands, until processing is complete.
`
`1.5 SMART CARD OPERATING SYSTEMS
`
`There’s a wide variety of operating systems designed for smart cards. They suffer most limitations
`common for embedded operating systems, in particular for size and performance. The size is
`typically between 3 and 24 Kbytes. The lower limit is that used by specialized applications and the
`upper limit by multi-application operating systems.
`
`Though typically only a few thousand bytes of program code, the operating system for the
`smartcard microprocessor must handle such tasks as:
`
`?? Data transmission over the bi-directional, serial terminal interface
`?? Loading, operating, and management of applications
`?? Execution control and Instruction processing
`?? Protected access to data
`?? Memory Management
`?? File Management
`?? Management and Execution of cryptographic algorithms
`
`Just like embedded operating systems, they do not need user interfaces or the ability to access
`external peripherals or storage media.
`
`There are four international standards that define typical smartcard instruction sets. More than 50
`instructions and their corresponding execution parameters are defined. Though found in four
`separate standards, the instructions are largely compatible. The specifications are GSM 11.11
`(prETS 300608), EN 726-311, ISO/IEC 7816-4, and the preliminary CEN standard prEN 154612.
`
`Instructions can be classified by function as follows:
`?? File selection
`?? File reading and writing
`?? File searching
`?? File operations
`?? Identification
`?? Authentication
`?? Cryptographic functions
`?? File management
`?? Instructions for electronic purses or credit cards
`?? Operating system completion
`?? Hardware testing
`?? Special instructions for specific applications
`?? Transmission protocol support
`
`Because smartcard memory space is so severely limited, not all standardized instructions and file
`structures can be generally implemented in all smartcard operating systems. For this reason, so-
`called "Profiles" have been introduced in ISO 7816-4 and EN 726-3. A profile defines the minimum
`requirements for data structures and commands.
`
`For example, Profile O in ISO 7816-4 defines the following minimums:
`
`PROTECTIVE ORDER MATERIAL
`
`IRIS
`EXHIBIT 2021 PAGE 7
`DOJ v. IRIS
`IPR 2016-00497
`
`

`

`Data Structures:
`
`Transparent
`
`Linear Fixed
`
`Linear Variable
`
`Cyclic
`
`READ BINARY, UPDATE BINARY, no implicit selection and
`maximum length up to 256 bytes
`
`READ RECORD, UPDATE RECORD, without automatic
`selection
`
`APPEND RECORD
`
`Commands:
`
`SELECT FILE
`
`VERIFY
`
`INTERNAL AUTHENTICATE
`
`EXTERNAL AUTHENTICATE
`
`GET CHALLENGE
`
`1.5.1 JAVA CARDS
`
`One of the most common smart card operating environments (adopted by over the 95% of
`manufacturers) is Java. Java-enabled smart cards are called Java Cards13. A complete discussion of
`the Java Card architecture is far beyond the scopes of this work. However, we will discuss it briefly
`to give an example of how a smart card OS could implement access to card databanks and access
`controls.
`
`Just as in the Java operating environment for computer systems, the JavaCard API enables a “Write
`Once, Run Anywhere” approach, by wrapping proprietary, vendor-dependant API and system calls
`into a common framework.
`
`The Java programming language and the Java Card API allow development using modern object-
`oriented programming, instead of assembly language or the C programming language. Using OOP
`has obvious benefits for security, allowing the developer to encapsulate sensitive data and
`algorithms within objects, which have provable behaviour and are easier to test; this is obviously in
`addition to traditional benefits for time-to-market and maintainability.
`
`In addition, the Java community has developed a wide and strong base of knowledge on the security
`and safety issue, which can be leveraged when developing smart-card applications.
`
`As an additional security benefit the Java Card platform provides a secure execution environment
`with a “firewall” (beware: not in the traditional meaning) between different applications in the same
`card. This allows different applications on the same card to function separately and independently
`from each other as if they were on separate cards. We will see that this is a benefit against software-
`based attack.
`
`PROTECTIVE ORDER MATERIAL
`
`IRIS
`EXHIBIT 2021 PAGE 8
`DOJ v. IRIS
`IPR 2016-00497
`
`

`

`In the last five years, products incorporating the Java Card platform have passed real-world security
`evaluations for major industries around the world. The Java Card platform is the leading platform
`for multi-application cards in mobile telephony. It is also the only platform that has passed security
`evaluations for issuance by all major financial payment associations. In addition, it has passed
`security assessments by leading government authorities, including the US Department of Defense
`and the US National Security Agency. Java Card platforms have achieved compliance with FIPS
`140-1.
`
`1.6 CRYPTOGRAPHIC CAPABILITIES
`
`Current state of the art smartcards have sufficient cryptographic capabilities to support popular
`security applications and protocols. In spite of the increased cost, the benefits to computer and
`network security of including the cryptographic coprocessor are great, for it allows the private key
`never to leave the smartcard. As we’ll see in the following sections, this becomes a critical factor
`for operations such as digital signatures, authentication, and non-repudiation. Eventually, though,
`the need for a cryptographic coprocessor and its associated cost will likely go away. The basic
`processors could become powerful enough to perform the math-intensive operations, or other
`algorithms such as those based on elliptic curve technology could become popular. Elliptic curve
`algorithms provide strong security without the need for large integer math, but haven’t yet found
`their way into widespread use.
`
`However, we will better describe common capabilities found in the crypto-enabled smartcards from
`leading vendors.
`
`RSA signatures and verifications are supported with a choice of 512, 768, or 1024 bit keylengths.
`The algorithms typically use the Chinese Remainder Theorem (CRT) in order to speed up the
`processing. Even at the 1024 bit keylength, the time needed to perform a signature is typically under
`one second. Usually the EEPROM file that contains the private key is designed such that the
`sensitive key material never leaves the chip. Even the card holder can’t access the key material in
`this case. The usage of the private key is protected by the user’s PIN, so that possession of the card
`does not imply the ability to sign with the card. RSA’s PKCS#1 padding is implemented by some
`cards.
`
`Though smartcards have the ability to generate RSA keypairs, this can be very slow. Typical times
`needed for a 1024 bit RSA keypair range from 8 seconds to 3 minutes. The larger times violate the
`ISO specifications for communications timeout so specialized hardware or software is sometimes
`necessary. Also, the quality of the keypairs may not be extremely high. The lack of computing
`power implies a relatively weak random number source as well as relatively weak algorithms for
`selecting large prime numbers.
`
`The Digital Signature Algorithm (DSA) is less widely implemented than RSA. When it is
`implemented, it is typically found only at the 512 bit key length.
`
`DES and triple DES are commonly found in the leading smartcards. They usually have the option to
`be used in a Message Authentication Code (MAC) function. However, because the serial interface
`of a smartcard has a low bandwidth, bulk symmetric encryption is very slow.
`
`Electronic purse functionalities are often present, but they are typically based on symmetric key
`technologies such as DES and triple DES. Thus, a shared secret key enforces the security of many
`of these schemes. Hashing algorithms commonly found include SHA-1 and MD-5; but again the
`low bandwidth serial connection hinders effective use of bulk hashing on the card.
`
`PROTECTIVE ORDER MATERIAL
`
`IRIS
`EXHIBIT 2021 PAGE 9
`DOJ v. IRIS
`IPR 2016-00497
`
`

`

`Random number generation (RNG) varies among card vendors. Some implement a pseudo RNG
`where each card has a unique seed. In this case, random numbers cycle through, dependent on the
`algorithm and the seed. Some cards have a true, hardware based RNG using some physical aspect of
`the silicon. It’s best to check with the vendor for details of the RNG if it will be used in a
`cryptographically sensitive context.
`
`As with any technology, there are legal issues to keep in mind when dealing with smartcards.
`Commonly, a smartcard has the ability to perform certain licensed algorithms, such as the RSA
`asymmetric cipher. Usually any license fees associated with the algorithm are bundled into the cost
`of the smartcard.
`
`1.7 SECURITY FEATURES
`
`We already saw that one of the basics concepts on which smart card security architecture relays is
`that it should be really difficult to extract informations about card operating and file systems from
`the device without controls by both the chip and the card OS. To do so, various methods of
`hardware security monitoring are enabled on leading smartcards.
`
`A one-time, irreversible fuse typically disables any test code built into the EEPROM. In order to
`avoid card cloning an unalterable serial number is often burned into the memory. The cards are
`designed to reset themselves to a power-on state if they detect fluctuations in voltage, temperature,
`or clock frequency. Reading or Writing of the ROM is usually disabled. However, since every
`vendor has its own, usually proprietary, schemes for these measures, it’s always good to inquire
`and/or request reports from independent testing laboratories.
`
`Communications protocols on smartcards at the command level can also have a security protocol
`built in. These are typically based on symmetric key technology and allow the smartcard itself to
`authenticate the read/write terminal or vice versa. However, the cryptograms and algorithms for
`these protocols are usually specific to a given application and terminal set.
`
`Smartcards support the ability to configure multiple PINs that can have different purposes.
`Applications can configure one PIN to be a "Security Officer" PIN, which can unblock the User
`PIN, after a set number of bad PIN attempts, or re-initialize the card. Other PINs can be configured
`to control access to sensitive files or purse functions.
`2 SMART CARD USAGE
`
`2.1 EXAMPLES OF SMART CARD USAGE
`
`Since data stored on a smart card cannot be retrieved directly via the CAD, smart cards have been
`proposed as portable and secure data storage devices. In addition, their computing capabilities
`(expecially if integrated by the cryptographic co-processor) make them expecially suitable as
`private key storage devices for asymmetric algorithms, since in this way private keys can be
`generated and stored on board the card, and never leave it. Encryption and decryption of data are
`performed on request by the card chipset itself. In this way, the user’s private key is kept secure and
`can not be eavesdropped. Thus, chip cards have been the main platform for holding a secure digital
`identity.
`
`Smart Cards are now everywhere: in GSM phones (the SIM, Subscriber Identity Module, is a smart
`card), in new generation credit cards, in pay-TV and digital satellite decoders, and as a personal
`
`PROTECTIVE ORDER MATERIAL
`
`IRIS
`EXHIBIT 2021 PAGE 10
`DOJ v. IRIS
`IPR 2016-00497
`
`

`

`data holder in the next-generation of ID card projects. They are also used for credit cards and
`prepaid phone cards. Combining their two main functions of being a secure data container and a
`crypto-enabled device, cards can:
`
`?? securely hold money ("stored value cards") or money equivalents
`?? provide secure access to a network, secure identification, law-strong digital signature
`?? secure cellular phones from fraud
`?? allow set-top boxes on televisions to remain secure from piracy
`
`Even though smartcards provide many obvious benefits to computer security, they still haven’t
`caught on with great popularity in countries like the United States. This is not only because of the
`prevalence, infrastructure, and acceptability of magnetic stripe cards, but also because of a few
`problems associated with smartcards.
`
`Lack of infrastructure for smartcard reader/writers is often cited as a complaint. The major
`computer manufactures haven’t until very recently given much thought to offering a smartcard
`reader as a standard component. Many companies don’t want to absorb the cost of outfitting
`computers with smartcard readers until the economies of scale drive down their cost. In the
`meantime, many vendors provide bundled solutions to outfit any personal computer with smartcard
`capabilities.
`
`Lack of widely adopted smartcard standards is often cited as a complaint. The number of smartcard
`related standards is high and many of them address only a certain vertical market or only a certain
`layer of communications. This problem is lessening recently as web browsers and other mainstream
`applications are including smartcards as an option. Applications like these are helping to speed up
`the evolution of standards.
`
`2.2 SMART CARD AS SECURITY TOKENS
`
`2.2.1 USING SMART CARD AS CRYPTO DEVICES
`
`Smart Cards are extraordinarily useful as crypto devices. A primary reason for this is that they have
`the quite unique ability of being capable of generating and protecting a private signing key which
`can never leave the card. In this way it is really difficult for outsiders to gain knowledge of the
`private key, something which could otherwise happen for example through a compromise of the
`host computer system. This has obvious and immediate advantages on protocols and applications
`oriented to authentication, authorization, privacy, integrity, and non-repudiation, for example PKI,
`Public Key Infrastructure, systems. These systems offer the services listed above by the means of a
`public/private key asymmetric algorithm. Now, placing the private certificate on a smartcard, which
`it never leaves, the crucial secret for the system is never in a situation where it is easily
`compromised. Moreover, if a private key is stored in a browser storage file on a hard drive, it is
`typically protected by a password. This file can be "dictionary attacked" where commonly used
`passwords are attempted in a brute force manner until knowledge of the private key is obtained. On
`the other hand, a smartcard will typically lock itself up after some low number of consecutive bad
`PIN attempts, for example 10. Thus, the dictionary attack is no longer a feasible way to access the
`private key if it has been securely stored on a smartcard.
`
`In addition, wherever multiple disjointed systems often have their security based on different
`technologies, smartcards can bring these together by storing multiple certificates and passwords on
`the same card. One of t