Smart Card Security

Final Project
Tel2820 – Cryptography
Dr. Prashant Krishnamurthy
 “Smart Cards” is an emerging technology in the United States that offers the seamless

interactions in everyday life that we have begun to expect from technologies such as USB and

Bluetooth. It offers a one-stop mentality for all your financial transactions and a utility

beyond the means people currently take for granted. Whether it is depositing your paycheck

with a swipe, buying groceries, or digitally signing the electronic purchase of your new car, a

heretofore unprecedented level of personal computing utility is at our fingertips. For all this

to occur however, these cards contain a potentially deep level of personal identification that

goes well beyond the current application technologies such as RFID. It is not surprising to

hear that many voices have already voiced concerns over the lack of security and privacy that

an RFID tag presents. Given the concerns shown over the lack of privacy inherent to RFID, it

is not difficult to see that there will be many outspoken opponents of the smart card

technology. With the current quality of security in said RFID devices, this is rightly so. The

potential damage that can be caused by an unscrupulous vendor, given unmitigated access to

an individual’s SSN, account numbers, credit card numbers, address, and other such personal

information is mind boggling and holistic in scope.

Securing this high-utility, high-risk, advance in ubiquitous technology represents a

significant challenge in many areas. Of particular concern in the security arena are two key

topics that must be explored to ensure safety and acceptance of this technology. First, there

must be mathematical cryptographic schemes to secure data from malicious hackers of an

ever-increasing sophistication level. There must be a non-repudiation of user identification to

prevent unauthorized purchases, and to determine who made an unauthorized purchase should

one occur. Finally, it is critical that there be access controls to determine who can see what

aspects of the smart card’s data as well as what functions they can call, lest they infer a
specific subset of data from a wider range of queries. Exploration of these complex arenas

will help us all have a greater understanding and a proper trust or fear of devices that carry

some of our most sensitive data.

As was stated already, highly secure cryptographic schemes must be present. To this

date, a variety of encryption schemes have shown their capability to securely transfer

sensitive data. A number of these are callable functions within a smart card’s processor, as

delineated by the NIST InterAgency Report on Governmental Smart Card Interoperability

Standards. These primarily come from the public/private key schema, and are such protocols

as RSA, DES, and AES. Hashing techniques are also used, both MDA5 and SHA-1. Padding

techniques are also available, usable at both the low and the high end values, using PKCS#1.

Within the RSA encryption scheme, several techniques are available. 512, 768, 1024,

and 2048 bit keys are creatable, using the Chinese remainder theorem, which states that two

simultaneous congruences n = n1 (mod m1) and n = n2 (mod m2) are only solvable when

n1 = n2 (mod gcd(m1,m2)). The solution is unique modulo lcm(m1,m2). DES keys are creatable

within a single or triple-strength algorithm. The DES key is used to generate cryptograms, 8

byte random numbers with a random key. DES is used for an 8 byte key, and DES_3 is used

for 16 byte keys. These cryptograms will be important later, but their creation is stated here

to show the ways in which DES is implemented. AES is a synchronous key encryption

protocol that has begun to surpass DES encryption as a standard of choice. Its applications

here are limited, with the strong and proven RSA encryption retaining ground, but it’s

inclusion into the smart card, shows a strong acceptance of it as a reliable source of

encryption. It makes use of Cipher-Block-Chaining and the Electronic CodeBook.

 The hashing techniques of MD5 and SHA-1 are generically implemented. They,

along with the keys, are more commonly padded. Padding is many times simply used to pad

the length of an AES key to be 16 octets, with padding optionally coming at the upper or

lower end. The PKCS #1 standard is used to pad MD5 and SHA-1 with 18 and 15 header

bytes respectively. These encryption schemes have thus far proved highly secure within our

normal computer networks. It is the case however that the relative openness of the data, it

being a wafer-thin piece of data in little protection, throws a unique light, no pun intended, on

the cryptography problem.

Researchers at the University of Cambridge in England have invalidated the security

systems in many smart card systems by developing a way of attacking and causing faults in

cards using common tools such as a photographer’s flash gun and a microscope. On a similar

vein of attacking the card on the hardware level, the Differential Power Attack (DPA)

“measures instantaneous power consumption of a device while it runs on a cryptographic

algorithm”(Messerges ). The power consumption charts, when sorted, can be used to

introduce a 1st order bias. This is due to the fact that there is a power consumption difference

between a 1 volt and a 0 volt, it is in fact the defining difference between them.

For example, we have a cryptographic scheme which at one point generates the

following computation:

Alg1(PTI) {
Vulnerable computation -> Result = PTI SecretKey
…
return CTO
}

Now, we can examine the signals for the presence of particular patterns noted below.
 Using these computational algorithms, we can average the signals, and subtract to

determine a bias between S1 and S0.

 Now that this simple to compute and generate Signal is complete, it gives us a clear

red flag to the bit-stream sent when the algorithm was used. This bit-stream can then be re-

encoded to give us the key. With that key, we have unmitigated access to the smart card and

can wreak essentially whatever havoc we wish.

So, where does this distressing news leave us? What can alleviate the destruction of

carefully and brilliantly crafted computational algorithms? A few options are set forth, with a

varying degree of confidence and from various angles. There are noise generators using

power randomization, active power filters through a hardware change, desynchronization

through time lapse, and finally masking through a mathematical computation. Some of these

deserve more attention than others.

The noise generators were fairly well deprecated from the start, but nevertheless must

be an explored option. In this schema, noise in introduced to the algorithm. This is both

simple and effective, but mitigating factors prevent it from becoming widespread. It is not

energy efficient, since it is pumping additional power. As a side effect, it is more expensive

to implement. Also, though the signal is distorted it is still ‘hidden’ there in a raw form. It

may also be tampered with. On the other side of the fence, we can minimize the signal to

almost nothing using an active power filter. This too is simple and effective, but also requires

a hardware change and is susceptible to physical tampering. Additionally, these filters either

can’t be made large enough (passive filter), or the active filter won’t be able to keep up with

power supply changes.

Desynchronization is easy and cheap, and increases the difficulty of attack. It

modified the electrical bit stream in the following way, where the green arrow represents the

key to remain hidden.

 However, since the signal is generated using the following formula:

It is susceptible to signal processing analysis. Note that the duplication increases

the difficulty of the analysis, but does not throw it for a grand new loop.

Finally we have another great contender for a protocol to mitigate the danger of a

differential power analysis, this is the concept of masking. In masking you turn a single bit

array into a pair of arrays to which a code must be applied to break it back into a single bit

array. It looks much like this:

When we look at the old, un-secure algorithm:

Alg1(PTI) {
Vulnerable computation -> Result = PTI SecretKey
…
return CTO
}

We want to change it to the following:

Alg2(PTI) {
RandomMask = Rand();
mPTI = PTI RandomMask;
Result = mPTI xor SecretKey;
….
More masked options…
…
unmask and return CTO
}

The flaw here is that the algorithm is susceptible where a 2nd order attack is engaged.

In a 2nd order attack you must find correlated peaks, then you must identify inversely
correlated peaks. This is similar to the signal analysis done in a first order DPA attack.

Finally, you must determine which sets are correlated and which are uncorrelated in the

presence of noise. The calculation for this is such:

This is the optimal decision problem for a 2nd order attack.

As we can see, masking generates a significantly more complex problem for a

malicious hacker to solve. In a first order attack, “fewer than 50 power signals are needed” to

crack the data. In a second order attack, this number rises to 2N2. Finally, use of a masking

technique requires the attacker to know what time component of the signal to identify, which

may or may not be a significant deterrent.

So, are AES and RSA encryptions the standards of choice? While they are both very

powerful encryption schemes, they are both vulnerable to DPA and other physical attacks.

Yet it has yet to be seen that there is a encryption scheme that can, on its own, defend against

these types of attacks. Masking presents us with a glimmer of hope for successful encryption

of signals, but this discipline is still relatively young. Until the encryption of signals advances

to the point that they cannot be forcefully decrypted in a time span less than the usefulness of

the data, smart cards represent a significant security risk that cannot be ignored.

Now that all of you are scared about the security of the smart cards, let us look at

another aspect of smart card security that could use some deeper thought and analysis.

Access control models are methods and control structures that determine who can access what

data and functions within the smart card architecture. Access control models have been

making great strides in the last 8-10 years, especially with the introduction of the high-utility

Role-Based access control model. So how are they implemented in smart cards?
 To understand the Access Control rules, you must understand the architecture of a

smart card. Interoperability is designated at two levels by the Government Smart Card –

Interoperability Standard (GSC-IS), the service call level and the command level. The service

level is more basic and is primarily concerned with functions that obtain various services from

the card, primarily dealing with cryptographic identification and creation of a secure

transmission medium. The API for this medium is called the BSI, or Basic Services Interface.

The BSI is implemented by the Service Provider Module (SPM). SPM is a hardware and

software interface, while the software service alone is called the Service Provider Module

(SPS). At the command level, the specified API is the Virtual Card Edge Interface (VCEI).

This level is concerned with the Application Protocol Data Units (APDU) sent to receive

required services. These APDUs are defined within IS 7816-4 (ISO4) and 7816-8 (ISO 8)

Service Provider Software (SPS) reformats BSI-level authentication structures into APDUs

for the VCEI, and vice versa. At this time it should be noted that certain data sets, called Data

Models, are a required standard format to ensure the interoperability provided by the BSI and

VCEI. Categories of these data models are called containers. For example, “One of these

containers, the Card Capability Container (CCC), describes the differences between a smart

card’s native APDU set and the standard APDU set defined by the VCEI. An SPS retrieves a

smart card’s CCC and uses it to perform the translation between the VCEI and the card’s

native APDU set. The GSC-IS accommodates any smart card whose APDU set can be

mapped to the VCEI via a CCC Definition”(NIST, 21). At this time, a graphic of the smart

card layout will show you how the layers are stacked.
 Within the BSI, three logical modules are instantiated by NIST to define what services

they provide. Different modules are used to sort and define the different user groups, and

three modules are instantiated by the NIST standards. They are the Utility Service Provider,

Generic Container Service Provider, and the Cryptographic Provider. The utility service

provider is responsible for creating and terminating logical connections, retrieving a list of

available card readers, and other such tasks. The generic container service provide an

abstraction of storage services, it presents applications with simple protocols to establish

containers of data elements in tag/length/value format. The cryptographic provider provides

core requirements for cryptography such as random number generation, authentication, and

digital signature creation.

 The VCEI defines default interoperable APDU level commands for the two types of

smart cards. These are virtual machines and file systems. The “file system” cards are the

original, and conform to ISO 7816-4, dealing with communications standards. They are hard

coded at time of manufacture, and cannot be changed later. Virtual machines commonly use a

special java virtual machine specification, though other environments are theoretically

supported. Executable can be integrated with the environment, and programmatically change

its function. These changes allow it to theoretically support any protocol, not the least of

which include the ISO communications standards. The VCEI must contain two things: a card

edge definition for file system cards and a card edge definition for virtual machine cards to

include the following three pieces: a generic container provider, a symmetric key

cryptographic provider, and a public key infrastructure cryptographic service provider.

Now that this has been defined, we can look more deeply at the access control model.

The modules we mentioned earlier of utility service, generic services, and cryptographic

services play a large role here. A smart cards services and containers provided by SPM are

subject to Access Control Rules (ACRs), which are defined when a smart card is initialized.

There are three general authentication mechanisms that the ACRs are based upon: Pin

Verification, External Authentication, and Secure Messaging, which you can see in the list of

rules.

Here is a list of the available access control rules:

Always: The corresponding service can be provided without restrictions.

Never: The corresponding service can never be provided.
External Authenticate: The corresponding service can be provided only after a GET
CHALLENGE and subsequent EXTERNAL AUTHENTICATE APDUs.
PIN Protected: The corresponding service is provided if and only if the verification code of the
PIN associated with the service has been provided in the current card session.
PIN Always: The corresponding service can be provided only if its associated PIN code has
been verified immediately before each unique service request.
External Authenticate or PIN: Either one of the two controls gives access to the service. This
allows for a cardholder validation when a PIN pad is available and for an external authentication
when no PIN pad is available. Or, this provides an authentication method when the application
cannot be trusted to perform an external authentication and to protect the external authentication
key.
External Authenticate then PIN: The two methods must be chained successfully before access
to the service is granted. This allows the authentication of both the client application and the
user.
External Authenticate and PIN: The two methods must be chained successfully before access
to the service is granted. Order of the methods is not important.
PIN then External Authenticate: The PIN presentation is followed by an External
Authentication.
Secure Channel (GP): The corresponding service can be provided only through a Secure
Channel managed by a Global Platform [GLOB] Secure Messaging layer.
Update Once: A target object can only be updated once during its lifetime.
Secure Channel (ISO): The corresponding service can be provided through a Secure Channel
managed by an ISO [ISO4],[ISO8] Secure Messaging layer.

These BSI level ACR’s are logical compositions of primitive access methods, with

associated hexadecimal values. The standard BSI service in this instance specifies 23 services

that are required, grouped across the 3 modules and they contain some of the following

functions:

Utility Provider Module

gscBsiAcquireContext,
gscBsiUtilConnect(),gscBsiUtilDisconnect(),gscBsiBegin/EndTransaction(),gscBsiGetVersio
n(),gscBsiGetProperties()
Generic Container Provider
DataCreate(), DataDelete(), ReadValue(), UpdateValue(),
Cryptographic Provider
gscBsiGetChallenge(), gscBsiSkiInternalAuthenticate(), gscBsiPkiCompute(),
gscBsiPkiGetCertificate()

These functions support various ACR’s. In addition, any function call that maps directly to a

card level function can return BSI_NO_CARDSERVICE or BSI_NO_SPSSERVICE. The

previously mentioned DES cryptograms are useful at this stage, as BSI transmits and receives

binary data, such as cryptograms. These functions provide a variety of operational

opportunities. As an example, the pin verification authentication models looks like this: A

logical connection is created using gscbciUtilConnect(). Then it would retrieve the ACRs

required for a specific service, using gscBsiGcGetContainerProperties() or

gscBsiGetCryptoProperties(). You would then acquire context with

gscBciUtilAcquireContext() using the ACRs required by the service’s security context. After

the verification is complete, a gscBsiUtil. So we can see here that there is a significant

framework of access control models and methods within the smart cards that allows for a

varying degree of security and authentication. There is a potential oversight however, which

may be highly unfortunate.

Service Provider Software (SPS) reformats BSI-level authentication structures into

Application Protocol Data Units for the Virtual Card Edge Interface, and vice versa. Thus,

they are an isolated medium of communication between the card and the reader. There is no

SPS authentication, and the SPS is not responsible for enforcing the ACRs. What this

essentially means is that the SPS is always a trusted authority for the transmission of

communication. It should be trivial to note at this point that this can be classified as a very

bad thing. The potential for misuse and abuse is rampant, since the software can basically

interpret the data any way it wishes to and capable of doing. Additionally, this can be

extremely transparent to the user since it would raise no flags at the time of execution. That

said, I think we are in a very bad place when it comes to non-repudiation.

When the user can neither confirm nor deny whether he or she authorized a particular

transaction, non-repudiation is thrown out the window. With a power attack analysis at time

of execution, or an attack on a physical card that has been stolen as the researchers at

Cambridge have proven, there are several ways in which a user can lose unique access to their
encryption schemes. Additionally, other sensitive and identifying data is still at risk. I

believe it is safe to say at this time that non-repudiation is an unachievable goal with the

standards currently in place.

With many actors at work in the field, and with so many commercial, it is not

unreasonable to believe that smart card technology can be a viable option in the next five to

seven years. However, several barriers stand in the way. The easily broken transmission

encryption schemes make the theft of a card a significant risk. The relatively poor solid state

data protection also makes theft a significant risk, and opens up wide avenues of abuse. The

lack of authentication in the SPS allows malicious alteration of otherwise secure transactions.

These forces together make smart card security a dim proposition at this time, yet there is a

great hope for future success in this market.

Works Cited

Smart Card Security. 25 Sept. 2004. Gamma Secure Systems. 20uly. 2005
<http://www.gammassl.co.uk/topics/smart%20cards/>.

NIST Smart Card Standards and Research. 16 July 2003. US Commerce Department’s
Technology Administration. 22 July. 2005 <http://smartcard.nist.gov/>

Smart Card Overview of Smartcards, integrated circuit cards, Chipcards and Memory Cards.
20 July 2005. Jacquinot Consulting Inc.. 21 July. 2005 <http://www.cardwerk.com/>

Corman, Patrick and Burke, Caron. Cryptography Resarch Patents for Smart Cards. 19 Apr.
2004. Cryptography Research Inc.. 22 July. 2005
<http://www.google.com/search?q=cache:dJb41PwnchAJ:www.cryptography.com/
company/prel/20040419-DPA-Patent.pdf+%22smart+cards%22+cryptography&hl=en>

Messerges, Thomas, PhD. Power Analysis Attack Countermeasures and their Weaknesses. 12
Oct. 2000. Motorola. 20 July. 2005
<http://www.iccip.csl.uiuc.edu/conf/ceps/2000/messerges.pdf>