Smart Cards: Technology for

Secure Management of
Information
By-
Saurabh pratap singh
Pccs college gr.noida

1
Machine readable plastic cards
What are smart cards
Security mechanisms
Applications
SCOSTA experience
Indian Driving License application

Agenda
2
Visual identity application
 Plain plastic card is enough
Magnetic strip (e.g. credit cards)
 Visual data also available in machine readable form
 No security of data

Electronic memory cards

 Machine readable data
 Some security (vendor specific)

Plastic Cards
3
Processor cards (and therefore memory too)
Credit card size
 With or without contacts.
Cards have an operating system too.
The OS provides
 A standard way of interchanging information
 An interpretation of the commands and data.

Cards must interface to a computer or terminal

through a standard card reader.

Smart Cards
4
Smart Cards devices
5

GND
VCC
VPP
Reset
I/O
Clock
Reserved
 What’s in a Card?

CLK RST
Vcc
RFU

GND

RFU
Vpp
I/O

6
 Typical Configurations
7

256 bytes to 4KB RAM.

8KB to 32KB ROM.
1KB to 32KB EEPROM.
Crypto-coprocessors (implementing 3DES, RSA etc.,
in hardware) are optional.
8-bit to 16-bit CPU. 8051 based designs are common.

The price of a mid-level chip when produced in bulk

is less than US$1.
 Smart Card Readers

 Computer based readers

Connect through USB or COM
(Serial) ports

 Dedicated terminals
Usually with a small screen,
keypad, printer, often also
have biometric devices such
as thumb print scanner.

8
 Terminal/PC Card Interaction
9

The terminal/PC sends commands to the card

(through the serial line).
The card executes the command and sends back the
reply.
The terminal/PC cannot directly access memory of
the card
 data in the card is protected from unauthorized access. This is
what makes the card smart.
 Communication mechanisms
10

 Communication between smart card and reader is standardized

 ISO 7816 standard
 Commands are initiated by the terminal
 Interpreted by the card OS
 Card state is updated
 Response is given by the card.
 Commands have the following structure

 Response from the card include 1..Le bytes followed by Response

CLA INS P1 P2 Lc 1..Lc Le
Code
 Security Mechanisms
11

Password
 Card holder’s protection
Cryptographic challenge Response
 Entity authentication
Biometric information
 Person’s identification
A combination of one or more
 Password Verification
12

Terminal asks the user to provide a password.

Password is sent to Card for verification.
Scheme can be used to permit user authentication.
 Not a person identification scheme
 Cryptographic verification
13

Terminal verify card (INTERNAL AUTH)

 Terminal sends a random number to card to be hashed or
encrypted using a key.
 Card provides the hash or cyphertext.
Terminal can know that the card is authentic.
Card needs to verify (EXTERNAL AUTH)
 Terminal asks for a challenge and sends the response to
card to verify
 Card thus know that terminal is authentic.
Primarily for the “Entity Authentication”
 Biometric techniques
14

Finger print identification.

 Features of finger prints can be kept on the card (even verified
on the card)
Photograph/IRIS pattern etc.
 Such information is to be verified by a person. The information
can be stored in the card securely.
 Data storage
15

Data is stored in smart cards in E2PROM

 Card OS provides a file structure mechanism

MF File types
Binary file (unstructured)
DF DF EF EF
Fixed size record file
DF EF Variable size record file

EF EF
 File Naming and Selection
16

 Each files has a 2 byte file ID and an optional 5-bit SFID (both
unique within a DF). DFs may optionally have (globally unique)
16 byte name.
 OS keeps tack of a current DF and a current EF.
 Current DF or EF can be changed using SELECT FILE command.
Target file specified as either:
 DF name
 File ID
 SFID
 Relative or absolute path (sequence of File IDs).
 Parent DF
 Basic File Related Commands
17

Commands for file creation, deletion etc., File size and

security attributes specified at creation time.
Commands for reading, writing, appending records,
updating etc.
 Commands work on the current EF.
 Execution only if security conditions are met.
Each file has a life cycle status indicator (LCSI), one of:
created, initialized, activated, deactivated, terminated.
 Access control on the files
18

Applications may specify the access controls

 A password (PIN) on the MF selection
 For example SIM password in mobiles
 Multiple passwords can be used and levels of security access
may be given
Applications may also use cryptographic
authentication
 An example scenario (institute ID card)
19
Read:
What happens Free
if the user forgets
Select: P2 Write:
hisSecurity upon
requirements:
password?
verification EF1 (personal data) verification by K1, K2
EF1:
Solution1: Add supervisor
Name: Rajat Moona or K3
PF/Roll: 2345 password
Should be modified only by
MF the DOSA/DOFA/Registrar
Solution2: Read:
AllowFree
EF2 (Address) Write:
Readable to Password
DOSA/DOFA/Registrar
all to modify
#320, CSE (off) EF3 Verification (P1)
EF2:
475, IIT (Res) Solution3: Allow both to happen
Card holder should be able to
modify
EF3 (password) EF4 (keys)
EF3 (password) K1 (DOSA’s key)
P1 (User password) Read: Never
P1 (User password) K2 (DOFA’s key)
P2 (sys password) Write: Once
K3 (Registrar’s key)

Read: Never
Write: Password
Verification (P1)
 An example scenario (institute ID card)
20

EF1 (personal data) Library manages its

own keys in EF3 under
EF2 (Address)
DF1
MF
EF3 (password) Institute manages its
EF4 (keys) keys and data under MF
Modifiable: By
DF1 (Lib) Thus library
admin staff.can
Read:
EF2 (Privilege info) develop applications
all
Max Duration: 20 days independent of the rest.
EF1 (Issue record)
Max Books: 10
Bk# dt issuedt retn Reserve Collection: Yes EF3: Keys
Bk# dt issuedt retn
K1: Issue staff key
K2: Admin staff key
Bk# dt issuedt retn Modifiable: By
Bk# dt issuedt retn issue staff. Read all
 How does it all work?
21

Card is inserted in the terminal

Card gets power. OS boots up. Sends
ATR (Answer to reset)
ATR negotiations take place to set
up data transfer speeds, capability
negotiations etc.

Terminal sends first command to Card responds with an error

select MF (because MF selection is only on
password presentation)
Terminal prompts the user to
provide password
Terminal sends password for Card verifies P2. Stores a status “P2
verification Verified”. Responds “OK”
Terminal sends command to select Card responds “OK”
MF again Card supplies personal data and responds
“OK”
Terminal sends command to read EF1
 Another Application Scenario
22

1. Authenticate user to bank

Terminal with officer card:
two card 1a. Get challenge from
readers banker card.
Banker’s card User’s card 1b. Obtain response for the
Application challenge from passport
software runs (IAUTH).
here 1c. Validate response with
officer card (EAUTH)
2. Authenticate officer card
to passport.
3. Transfer money to the
user’s card

The terminal itself does not store any keys, it’s the two cards that
really authenticate each other. The terminal just facilitates the
process.
 Status of smart card deployments
23
 Famous Gujarat Dairy card
 Primarily an ID card
 GSM cards (SIM cards for mobiles)
 Phone book etc. + authentication.
 Cards for “credit card” applications.
 By 2007 end all credit cards will be smart.
 EMV standard
 Card for e-purse applications
 Bank cards
 Card technology has advanced
 Contactless smart cards,
 32-bit processors and bigger memories
 JAVA cards
 SCOSTA Experience
24

Part of E-governance initiative of the Government.

Government decided to
 Create Smart driving licenses/registration certificate
 Backend system is already in place
Various smart card vendors in the country
 All with their own proprietary solutions
 In a national case, proprietary solution was not
acceptable.
NIC decides to ask IIT Kanpur to help.

SCOSTA: Smart Card OS for Transport Applications

 Goals of this Project
25

 To define a standard set of commands for smart cards for use in

Indian applications.
 To provide a reference implementation of this standard.
 Transport Applications (Driving License and Vehicle Registration
Certificate) were the pilot projects.
 Hence the OS standard is named SCOSTA.
 SCOSTA is defined by IIT Kanpur along with a technical
subcommittee of SCAFI (Smart Card Forum of India).
 The OS is not really restricted to the transport applications and
can be used in any ID application
 The SCOSTA Standard
26

Based on ISO 7816-4, -8, and -9.

Removes ambiguities in ISO 7816.
Has support for symmetric key cryptography (Triple
DES algorithm) and internal and external
authentication.
Encryption/decryption and crypto checksum
computation and verification using 3DES are also
supported.
 SCOSTA Implementation - Challenges
27

Portability – should be easy to port to different

processors.
Resource Constraints – very limited memory (32 KB
ROM, 512 byte RAM are typical). Usually 8 bit
processors are used.
Government processes
Vendors and their business interests.
 Challenges of the application
28

System must work nation wide

Cards are issued by the RTO
RTO officials may not be all that “clean”
Challans are done by police “on behalf of” RTO
 “Clean”??
Challans are settled by the Judiciary.
RTOs are administered by the STA
 But under the Union Ministry
 Solution
29

A robust key management scheme was needed.

Solution was based on
 Key derivations, usage counters etc.
 Solution
30

The entire system is based on few “nation wide”

generator keys.
Safely housed with the government.
Say the keys are k1, k2, k3, k4.
Keys are themselves never stored any where.
 Instead five out of seven card scheme is used.
 5 out of 7 scheme
31

Consider a polynomial
k1 + k2.x + k3.x2 + k4.x3 + k5.x4 = b
If b1, b2, b3, b4, b5 are known for x = 1, 2, 3.., the
system of equations can be solved and all k’s can be
found.
We use the SCOSTA cards to store (x1, b1), (x2, b2) etc.
At any point in time, five such pairs are needed.
For robustness, seven cards are generated and kept at
7 different locations.
 Operations
32

At RTOs, two RTO officers are required to create a

DL
 These two work in pair.
 Have a usage counter of key built in.
 RTO keys are generated and given in the RTO cards
STA can revalidate the usage counter.
STA keys are also generated.
 Operations
33

DL can be completely given by the RTO.

Some information is public readable on the DL.
Some information is once writable by the police
(challans) and readable by the police.
The same information is updatable by the judiciary.
(but can not be deleted)
Therefore the DLs must carry
 Police key, RTO keys and judiciary keys.
 A big security risk.
 Instead these keys for the DL are card specific.
 Police has a master key to generate DL specific police
key. Ditto with RTO and Judiciary.
NIC generates the cards (and therefore master keys)
for RTO, Police and Judiciary.

Operations
34
Prof. Deepak Gupta and Manindra Agrawal (CSE)
S. Ravinder and Kapileshwar Rao (MTech students
of CSE who worked on this project)
National Informatics Centre (NIC) Delhi
MCIT and MoST
References:
Smart Card Handbook
ISO7816 standards
www.parivahan.nic.in

Acknowledgements
35
Questions are invited

?
Thanking you