Smart Cards - OpenSecurityTraining.info

Smart Cards
Material last updated in 2007
Ronald van der Knijff
knijff at holmes dot nl
1
29-Sep-14
1
All materials is licensed under a Creative
Commons “Share Alike” license.
•  http://creativecommons.org/licenses/by-sa/3.0/
2
Attribution condition: You must indicate that derivative work
"Is derived from Ronald van der Knijff's 'Smart Cards' class, available at http://OpenSecurityTraining.info/SmartCards.html"
29-Sep-14
2
Smart Cards
Ronald van der Knijff :
•  HTS (secondary technical school) electrical
engineering::telecom
1987-1991
•  Defense: Signals
1992-1993
•  University: Computerization
1993-1996
•  Netherlands Forensic Institute
1996•  Section Digital Technology
•  Specialization Embedded Systems
–  digital evidence
–  fraud
–  government expertise
3
29-Sep-14
3
Program
•  Smart Cards
•  Physical and electrical characteristics
•  Operating Systems
•  Physical Attacks
•  Security Mechanisms
•  Security Evaluation
•  Logical Attacks
4
29-Sep-14
4
Study Targets
• 
• 
• 
• 
• 
• 
• 
Why using a smart card
What’s a smart card and what’s not
How’s a smart card structured
What kind of interface equipment is available
Working of a smart card OS
Key developments
Physical attacks
5
29-Sep-14
5
Study Targets
•  Purpose and operation of security mechanisms
•  hardware authentication
•  individual authentication
•  identification
•  verification
•  data authentication
•  one-way hashing
•  MAC’s
•  signing
•  certificates
6
29-Sep-14
6
Study Targets
•  Purpose and operation of security mechanisms
•  authorization
•  confidentiality
•  symmetric versus asymmetric
•  Attacks
•  Why and how security evaluation
•  Why and how risk analysis
7
29-Sep-14
7
Literature
• 
Smart Card Handbook - W. Rankl & W. Effing
• 
RFID Handbook: Radio-Frequency Identification Fundamentals
and Applications - Klaus Finkenzeller
"Fundamentals and Applications in Contactless Smart Cards and
Identification"
(2nd English edition, April 2003)
• 
Smart Cards: The Developer's Toolkit Timothy M. Jurgensen, Scott B. Guthery
old version: unix.be.eu.org/docs/smart-card-developer-kit
8
29-Sep-14
8
Literature
•  Smart Card Security and Applications - Mike Hendry
•  Smart Cards : A Guide to Building and Managing
Smart Card Applications - J. Thomas Monk, Henry N.
Dreifus
•  Java Card™ Technology for Smart Cards:
Architecture and Programmer's Guide - Zhiqun
Chen
•  Smart Card Application Development Using Java Uwe Hansmann, Martin S. Nicklous, Thomas
9
Schaeck, Frank Seliger
29-Sep-14
9
Why smart cards?
Information society à Information represents value
Digital representation of information à Easy storage,
transportation, manipulation and reproduction
Most information systems are open and free accessible
à Not always desirable (passwords, credit card
data, personal data ...)
Guarantee of confidentiality and integrity
demands a closed, inaccessible (mini)system
10
29-Sep-14
10
Why smart cards?
Information society àServices become location and time
independent
Services require verification of (pseudo) identities
On-line communication à Expensive and
vulnerable(because of central storage and processing)
à Off-line with local distributed storage seems
attractive alternative
Central storage of personal information raises privacy
concerns à With local storage the user protects his/
her privacy
Smart card is a portable, protected mini-archive
11
29-Sep-14
11
What’s a smart card
8-bits
µProc
Smart
ASIC
Chip
Contact
Contactless
CISC
RISC
Co-Proc
16-bits
32-bits
Wired-Logic
Protected
Imprinted
Memory
Unprotected
Embossed
Cards
Magstripe
Wiegand
1D
Barcode
Optical
2D
Low-Density
WORM
High-Density
12
29-Sep-14
12
What’s a smart card
8-bits
µProc
Smart
ASIC
Chip
Contact
Contactless
CISC
RISC
Co-Proc
16-bits
32-bits
Wired-Logic
Protected
Imprinted
Memory
Unprotected
Embossed
Cards
Magstripe
Wiegand
1D
Barcode
Optical
2D
Low-Density
WORM
High-Density
13
29-Sep-14
13
(Smart) Card dimensions
16.4 mm
ID-000
3FF
6.25 mm
54 mm
25 mm
ID-1
85.6 mm
C1=Vcc
C5=GND
C2=RST
C6=Vpp
C3=CLK
C7=I/O
C4=RFU
C8=RFU
14
29-Sep-14
14
Production (single layer body)
wafer manufacturing
card printing
Wafer with marked correct chips
(Chip maximal 25 mm2 )
Printed foils
module arrangement
card punching
Card with visual characteristics
module cavity milling
flexible film with contacts
attached to the chips
and covered with protected material
Card with cutted hole for
for IC module
embedding &
pre-personalisation
Functional chip card
personalisation
Personalised
chip card
15
issue
29-Sep-14
15
Smart card chip
ROM
RAM
EEPROM
CPU
Memory Management
Test &
Security
CoProc
RNG
Clock/
Charge
Pump
I/O
16
29-Sep-14
16
CPU (Central Processing Unit)
•  8-bit CISC / RISC
•  6805 / 8051 / Z80 / H8 / AVR
•  16-bit CICS / RISC
•  8051XA / H8 / ARM
•  32-bit RISC
•  ARM / MIPS
•  Need for more processing power (virtual
machines, cryptography)
17
29-Sep-14
17
ROM (Read Only Memory)
• 
• 
• 
• 
• 
• 
Permanent storage
“Filled” during production (mask)
Contains static part OS + test & security
Capacity 8- 512 KB
Optical readable after removal of top layers
Flash is coming up for prototyping, small
quantities and as ROM/EEPROM
replacement
18
29-Sep-14
18
EEPROM (Electrically Erasable ROM)
•  Non volatile, re-writable memory
•  Write=Erase + Program
• 
• 
• 
• 
• 
non-atomic
slow
requires high programming voltage (≈15 Volt)
limited (10.000 - 100.000 times)
data retention (10 - 100 years)
•  Contains file system and dynamic part of OS
•  Capacity 1- 512 KB and increasing (1 MB FLASH
from Sharp)
•  Readable via micro-probing, SEM en FIB
•  FRAM in future?
19
29-Sep-14
19
RAM (Random Access Memory)
•  Volatile re-writable memory (SRAM)
•  For storage of temporary data
•  stack
•  heap
•  I/O buffer
•  Capacity 128- 16384 Bytes and increasing
•  Volatile but still small permanent storage
characteristics
20
29-Sep-14
20
I/O (Input/Output)
•  Contact Interface
C1=Vcc
C5=GND
C2=RST
C6=Vpp
C3=CLK
C7=I/O
C4=RFU
C8=RFU
»  Vcc = 5 Volt (3 Volt)
»  Vpp not used anymore
»  CLK (3.5712, 4.9152, 10 MHz.)
»  UART voor I/O
•  Contactless Interface (125 kHz & 13.56 MHz)
•  Close coupled, a few millimeters
•  Proximity, less than 10 centimeter
•  Vicinity, more than 10 centimeter
21
29-Sep-14
21
Contactless Interface
•  Power from CAD
•  Modulation:
•  CAD àCard : AM, FM, PM
•  Card à CAD: AM
•  Anti collision
22
29-Sep-14
22
CoProcessor
•  Some cryptographic algorithms cannot be
implemented fast enough on smart cards CPU’s
•  Coprocessor is a specially developed arithmetic unit
(with own RAM) for computations relating to
cryptographic algorithms
•  Symmetric algorithms: DES computation unit (takes roughly the
same chip space as ROM program code)
•  Asymmetric algorithms: Exponentiation and modulo arithmetic on
large numbers
•  Low level calling: CPU prepares input data, Escapes
to CoProc and processes output data
•  High level calling: CryptoAPI
23
29-Sep-14
23
CoProcessor
24
29-Sep-14
24
CoProcessor
25
29-Sep-14
25
CoProcessor
CryptoBytes RSA Volume 4, Number 1
http://www.rsasecurity.com/rsalabs/cryptobytes
26
29-Sep-14
26
CoProcessor
CryptoBytes RSA Volume 4, Number 1
http://www.rsasecurity.com/rsalabs/cryptobytes
27
29-Sep-14
27
MMU (Memory Managing Unit)
•  Important for non-verified (post-issuance)
executable code
•  Each data object has attributes specifying the
physical address space
•  Hardware registers check if the object stays in
the specified address area
•  Exchange of data between applications only
via OS routines with authorization
mechanisms
28
29-Sep-14
28
Test & Security
•  (Self)test hardware and software
• 
• 
• 
• 
• 
ROM checksum
EEPROM static data checksum
RAM dump
EEPROM read/write functions
Most test hardware and software made useless before
personalization
–  fuse blowing not sufficient!
–  hidden instructions will be found!
29
29-Sep-14
29
Test & Security
•  Smart Card is a tamper resistant device (gradation: evident,
resistant, responsive, more in ISd2)
•  Penetration:
•  Protective epoxy cover
•  Top-layer sensor mesh
•  Layout scrambling
•  Monitoring:
• 
• 
• 
• 
• 
• 
Supply voltage
Clock frequency and slope
Temperature
Amount of light
Condition of protective layers
Leakage prevention
•  Control only possible with attached power supply!
Markus Kuhn: http://www.cl.cam.ac.uk/~mgk25/
30
29-Sep-14
30
Clock Circuit & Charge Pump
• 
• 
• 
• 
External clock signal
Internal clock multiplication possible
I/O clock divisor of external clock
Charge pump generates EEPROM
programming voltage
Charge
+
+
-
-
Vcc
•  via external clock and capacitors
•  via local oscillator and capacitors
Discharge
+
2*Vcc
+
-
•  Autonomous internal clock is more secure
31
29-Sep-14
31
RNG (Random Number Generator)
•  Needed for cryptographic procedures:
Card-Key
•  Key generation
•  Authentication
•  Freshness
DES
•  PRNG (Pseudo RNG)
RND
RNDn=F(Card-Key, RNDn-1)
Cyclic EEPROM File
•  uses an algorithm with input, internal state and output
which are “as unpredictable as possible”
•  knowledge of internal algorithm state and/or input might
make the output predictable
32
29-Sep-14
32
RNG (Random Number Generator)
•  TRNG (True RNG)
•  uses physical processes (frequency instability of an
oscillator, semiconductor noise, particle-decay ...)
•  unpredictable output
•  influence of physical process must not affect the
unpredictability
CLK
Noise
Source 1
BandPass
Filter
Sample &
Hold
Noise
Source 2
100101...
Vref
Amaury Neve, Dennis Flandre and Hean-Jacques Quisquater
33
29-Sep-14
33
RNG – Testing Random Numbers
Five basic tests (not more than failure to reject hypothesis):
1.  Frequency test (monobit test)
X1 =
(n0 − n1 )2
Χ 2 | DoF (1) ∧ n > 11
n
2.  Serial test (two-bit test)
X2 =
4
2
2
2
n00
+ n01
+ n102 + n112 − n02 + n12 + 1
n −1
n
(
) (
)
Χ 2 | DoF (2) ∧ n > 21
3.  Poker test (k non-overlapping parts of length m)
2m
X3 =
k
m
⎛ 2 2 ⎞
⎜ ∑ ni ⎟ − k
⎜ i =1 ⎟
⎝
⎠
Χ 2 | DoF (2 m − 1)
4.  Runs test (Gap/Block)
k
(Bi − ei )2
i =1
ei
X4 = ∑
k
+∑
i =1
(Gi − ei )2
ei
Χ 2 | DoF (2k − 2)
5.  Autocorrelation test
n − d ⎞
n − d −1
⎛
X 5 = 2⎜ A(d ) −
⎟ / n − d , with : A(d ) = ∑i =0 si ⊕si + d , and : 1 ≤ d ≤ n / 2
2 ⎠
⎝
Menezes, van Oorschot, Vanstone - Handbook of Applied Cryptography
N (0,1) | n − d ≥ 10
34
29-Sep-14
34
RNG – Testing Random Numbers
FIPS 140-1: Single bit stream of 20,000 consecutive bits must pass following tests:
1.  Monobit Test – 9,654 < X < 10,346 (X = the number of ones)
2.  Poker Test –
1.  Divide the 20,000 bit stream into 5,000 contiguous 4 bit segments. Count
and store the number of occurrences of each of the 16 possible 4 bit
values. Denote f(i) as the number of each 4 bit value i
2. Evaluate the following:
X = (16/5000) * [SUM of f(i)^2, for i = 0 to 15] – 5000
3. The test is passed if 1.03 < X < 57.4.
3.  Run Test – Length of Run Required Interval
1
2
3
4
5
6+
4. 
2,267 - 2,733
1,079 - 1,421
502 - 748
223 - 402
90 - 223
90 - 223
Long Run Test – No Runs > 33
35
29-Sep-14
35
RNG – Testing Random Numbers
36
29-Sep-14
36
RNG – Testing Random Numbers
37
29-Sep-14
37
38
29-Sep-14
38
Card Accepting Devices (CAD/IFD)
Dumb - PC signal conversion and clock gen.
(Litronic 210, Dumbmouse, Dr Chip ...)
µProc - remote controlled microprocessor
(Gemplus GemPC 410 , Towitoko Chipdrive ...)
Keypad - PIN’s stay local
(ORGA ICCR, ThuisChipper ...)
Embedded - Part of other electronic device
(POS-SAM, GSM-SIM ...)
Wallets, Balance checkers …
USB-slots
39
29-Sep-14
39
Card Accepting Devices – FINREAD
www.finread.com
•  Specifications for secure:
• 
• 
• 
CAD architecture
downloading and management of CAD applets
data exchange between CAD and Smart Card
•  Interoperability of secure transactions on open networks by:
•  common format for the downloading of applications,
•  common set of APIs between the card reader system software and the card reader
downloaded applications
•  Achieve a high security level through the definition of security
requirements
•  2003: Ingenico, Omnikey and SCM MicroSystems
first approved FINREAD readers
40
29-Sep-14
40
Card Operating Systems
Smart card OS tasks:
• 
• 
• 
• 
• 
• 
life-cycle management
instruction processing
data management
data transmission
(hardware) error handling
control of co-processor
41
29-Sep-14
41
Life-cycle management
Security not stronger than weakest linkà
authorization depends on life cycle phase:
Test
•  full access to all memories
•  unique read-only serial number in EEPROM
•  termination through writing EEPROM + (fuse blowing)
+ (hardware removal)
42
29-Sep-14
42
Life-cycle management
Completion
•  key needed
•  writing of EEPROM OS jump table + fixes
•  file system initialization with root + serial number +
transport key
Pre-personalization
• 
• 
• 
• 
transport key needed
placing of file structure
writing of static data (PIN’s, keys, application code)
finishing by invalidation of transport key
43
29-Sep-14
43
Life-cycle management
Personalization
•  writing of personal data
•  files contain authorization attributes
Usage
•  Security via file access control data
End
•  All card functionality is made inaccessible in a an irreversible way
Real-life Card Life Cycle model: GlobalPlatform Card Specifications:
OP_READY, INITIALIZED, SECURED, CARD_LOCKED,
TERMINATED)
44
29-Sep-14
44
Instruction processing
•  CAD master, smart card slave
•  Instructions coded in APDU (OSI 7)
•  command APDU:
Header
CLA INS P1 P2
Body
[Lc] [<Data>] [Le]
•  response APDU:
Body
Trailer
[Data]
SW1 SW2
45
29-Sep-14
45
Instruction processing
Instruction
EXTERNAL AUTHENTICATE
INTERNAL AUTHENTICATE
ASK RANDOM
GIVE RANDOM
SELECT FILE
GET RESPONSE
VERIFY CHV
CHANGE CHV
DISABLE CHV
ENABLE CHV
UNBLOCK CHV
READ BINARY
READ BINARY STAMPED
READ RECORD
READ RECORD STAMPED
SEEK
WRITE BINARY
UPDATE BINARY
UPDATE RECORD
APPEND RECORD
INCREASE
Function
INS
Card authenticates CAD
82
CAD authenticates card
88
Receive random number from card
84
Send random number to card
86
Select card file
A4
Receive response from card
C0
Verify PIN
20
Change PIN
24
Switch-Off PIN
26
Switch-On PIN
28
Unblock PIN with PUK
2C
Read from transparant EF
B0
Read from cryptographic secured transparant EF
B4
Read from lineair or cyclic EF
B2
Read from cryptographic secured lineair or cyclic EF
B6
Search in lineair/cyclic EF
A2
Write to transparant EF (secure->non-secure)
D0
Overwrite data in transparant EF (erase+write)
D6
Write to record of lineair/cyclic EF
DC
Inser record to end of lineair fixed EF or overwrite less recent record of cyclic EF E2
Increase value of file counter
32
Standard
ISO 7816-4
ISO 7816-4
EN 726-3
EN 726-3
ISO 7816-4
ISO 7816-4
EN 726-3
EN 726-3
EN 726-3
EN 726-3
EN 726-3
ISO 7816-4
EN 726-3
ISO 7816-4
EN 726-3
EN 726-3
ISO 7816-4
ISO 7816-4
ISO 7816-4
ISO 7816-4
EN 726-3
INCREASE STAMPED
DECREASE
DEREASE STAMPED
ENVELOPE
ERASE BINARY
EXECUTE
CREATE FILE
DELETE FILE
INVALIDATE
REHBILITATE
Increase value of file counter in cryptographic secure way
Decrease value of file counter
Decrease value of file counter in cryptographic secure way
Embed instruction with cryptographic protection
Erase (part) of transparant EF
Execute a file
Create a new file
Delete file
Reversibly block a file
Unblock a file
EN 726-3
EN 726-3
EN 726-3
ISO 7816-4
ISO 7816-4
EN 726-3
EN 726-3
EN 726-3
EN 726-3
29-Sep-14
EN 726-3
46
36
30
24
C2
0E
AE
E0
E4
04
44
46
Instruction processing
Code Interpreter
File Manager
State Machine
Memory Manager
Instruction Interpreter
Response Manager
Secure Messaging Manager
I/O Manager
I/O Interface
ROM, RAM, EEPROM
47
29-Sep-14
47
Data Management
•  File system:
•  Master File (root)
•  Directory Files
•  Elementary Files
•  transparant
•  linear fixed
•  linear
variable
•  cyclic
•  purse
•  executable
•  …
MF
EF
EF
EF
DF
DF
EF
Transparant
EF
Linear fixed
DF
EF
DF
EF
EF
Linear variable
Cyclic fixed
48
29-Sep-14
48
Data Management
•  File consists of:
•  Header (ID, type, size, access conditions, status)
•  Data
49
29-Sep-14
49
50
29-Sep-14
50
Data Management
•  ASN.1 BER - TLV coding
• 
• 
• 
• 
T
L
V
T
L
Abstract Syntax Notation One
Basic Encoding Rules
Tag Length Value
ISO 7816-6 annex contains general TLV definitions
V
T
L
V
T
L
V
T
L
'85' '06' "Ronald" '86' '07' "van der" '87' '06' "Knijff" '88' '10' "Volmerlaan" '89' '02'
'87' '06' "Knijff" '86' '07' "van der" '85' '06' "Ronald" '90' '06'
"3024AE"
V
"17"
T
L
'90' '06'
V
T
"3024AE"
L
V
'91' '11' "Rijswijk ZH"
'91' '11' "Rijswijk ZH" '88' '10' "Volmerlaan" '89' '02'
"17"
Advantage:
•  self-describing
•  extendable/backwards compatible
Disadvantage:
•  T and L need storage space
51
29-Sep-14
51
ASN.1 BER TLV coding
52
29-Sep-14
52
Data transmission
•  Serial asynchronous master slave
•  CLK 3.5712 MHz. or 4.9152 MHz.
•  Booting (transmission speed I/O=CLK/372):
GND
Vcc
C1=Vcc
C5=GND
C2=RST
C6=Vpp
C3=CLK
C7=I/O
C4=RFU
C8=RFU
CLK
RST
I/O
Answer To Reset
•  After PTS communication through via negotiated
protocol
53
29-Sep-14
53
Data Transmission T=0 protocol
•  Byte oriented
•  TPDU (Transmission Protocol Data Unit) ≈
APDU
• 
• 
• 
• 
CAD transmits CLA, INS, P1, P2, P3
Card transmits procedure byte ACK
Following communication depends on Command
Communications end with status bytes SW1, SW2
•  Transmission errors detected via parity bit and
corrected via second time transmission
•  Poor separation application and data link layer
54
29-Sep-14
54
Data Transmission T=1 protocol
•  Block oriented
Prologue
NAD
PCB
LEN
1 Byte 1 Byte 1Byte
Information
Epilogue
APDU
EDC
0 - 254 Bytes
1-2 Bytes
•  Block types:
•  I - application data
•  R - receive confirmation
•  S - protocol control data
•  Transmission errors detected with EDC: LRC
(XOR byte) or CRC (x16+x12+x5+1), correction
via S-block + PCB
55
29-Sep-14
55
Hardware Error Handling
•  EEPROM most error prone component à Write=Erase
{1} + Program {0,1}
•  EEPROM secure state: minimum energy state (0)
•  Prevention and Control mechanisms
•  Map one logical EEPROM address to more physical addresses and
alternate write actions
•  Implement one logical EEPROM address with several physical
addresses and use majority voting
buffer
anti•  EDC’s and ECC’s
tearing
flag
•  anti tearing against sudden card removal
1.
2. Buffer valid
•  buffer + anti-tearing flag
new data
existing data
4. Buffer invalid
3.
•  cyclic files
Transparant
EF
56
29-Sep-14
56
Developments - Architectures
•  Major smart card chip suppliers:
•  Infineon, STMicroelectronics, Hitachi, Philips, Atmel,
Samsung, NEC
•  smaller structures (<0.18 µm) àmore
functionality on 25 mm2
•  larger memories
•  co-processors (3DES, AES, RSA)
•  security (sensors, TRNG, MMU …)
57
29-Sep-14
57
Developments - Architectures
• 
• 
• 
• 
16- and 32 bits architectures
RISC (ARM & MIPS)
Virtual Machine Optimizations
Dual interface cards (e.g. MIFARE Pro)
•  contact interface
•  contactless interface
•  both connected to the same chip/OS/memory
58
29-Sep-14
58
Developments - Card OS’es
•  Major smart card card/OS suppliers:
• 
• 
• 
• 
• 
• 
Axalto (SchlumbergerSema=Schlumberger + Bull CP8)
Gemplus
Giesecke & Devrient
Oberthur
Orga
Sagem
•  Older COS generations:
• 
• 
• 
• 
too much and all different
CAD applications depend on card OS
low-level on-card application development
limited expansion possibilities during usage
59
29-Sep-14
59
www.gemplus.com/smart/r_d/publications/pdf/DGGJ03os.pdf
60
29-Sep-14
60
Developments - Card OS’es
Solutions:
•  Join best aspects into one standard Card OS API
•  New systems
•  Java Card
•  MULTOS
•  BasicCard
•  Windows for Smart Cards/Smartcard.NET
Virtual Machine principle:
•  abstract machine on top of OS
•  interpretation of hardware independent byte code
61
29-Sep-14
61
Developments - MULTOS
•  Low level kernel with VM on top
•  VM interprets MEL (MULTOS Executable
Language)
•  Multi-Functional
•  designed for ITSEC E6-High
62
29-Sep-14
62
Developments - MULTOS
• 
• 
• 
• 
Licenses needed from MAOSCO
Applications certified by CA
Crypted application loading with certificate
Application controls interaction with other
applications
•  Implementations on Hitachi 3112/3113,
Infineon SLE66CX160S, Motorola ...
•  Used for MONDEX purse and EMV
63
29-Sep-14
63
Developments - MULTOS licensees
MAOSCO
MULTOS
Application
licence
Application
development
tools
Implementation
license
MULTOS
MULTOS
Implementation
Implementor
licence
Toolkit providers
Certification services
Application
developers
Card
issuers
Applications
Cards
Silicon
providers
Certification
Authority
MULTOS
Silicon
Card fabricator
Products
and
services
CONSUMERS
64
29-Sep-14
64
Developments - MULTOS
C
PC simulator
and
debugging tools
Other
Compiler
MEL
VM
OS
Hardware
Applications
Platform
65
29-Sep-14
65
Developments - Java Card
•  Java without:
•  Dynamic class loading
•  Security manager
•  Threads and synchronization
•  Object cloning
•  Finalization
purse
applet
Applets
authentication
applet
loyalty applet
Java Card Runtime Environment (JCRE)
framework
classes (APIs)
industry-specific
extensions
installer
system classes
applet
management
transaction
management
I/O network
communication
Java Card virtual machine
(byte code interpreter)
other services
native methods
•  Large primitive data types (32- en 64 bit, Unicode)
•  Minimal architecture:
•  8-bit core
•  16 KB ROM, 256 Bytes RAM, 8 KB EEPROM
66
29-Sep-14
66
Developments - Java Card
• 
• 
• 
• 
• 
• 
• 
JCRE active until card-end-of life (no signals =long clock cycle)
Applet active from registration until removal
transient RAM objects for speed
Each Applet unique AID (ISO 7816-5)
JCRE controls security policy (applet firewalls/context switching)
Objects owned by creator Applet
Applet can share attributes and methods with specific applets or
all applets
off-card VM
class
files
converter
CAP
file
on-card VM
interpreter
67
29-Sep-14
67
Developments - Java Card
•  Applet development with common
class
Java Tools
files
•  Compiler generates class file
runtime environment
•  Java Card converter checks and
converter
on-card
optimizes byte code
installer
•  Converter/Loader for each Java Card
interpreter
CAP
file
implementation
smart card
•  Global Platform standard for secure
off-card
applet addition, management and
installer
removal
•  Security definable with Java Card
CAD
Protection Profile
PC/workstation
java.sun.com/products/javacard/
JCSPPC-1.0b.pdf
•  A lot of implementations available
http://securingjava.com/chapter-eight/
(especially for GSM SIM
68
http://java.sun.com/products/javacard/JavaCardSecurityWhitePaper.pdf
development)
http://java.sun.com/docs/books/javacard/
29-Sep-14
68
Developments - Open Card Framework (OCF)
•  Standard framework for inter-operable smart cards
solutions across different hardware and software
platforms
•  Two major function categories:
•  Application and Service Developers:
•  Card and Terminal Providers:
•  Architecture + set of API’s
•  Java based
•  Runs on any Java enabled platform
69
29-Sep-14
69
Developments - Open Card Framework (OCF)
www.opencard.org
www.gemplus.com/techno/opencard/
70
29-Sep-14
70
Developments – Windows for Smart Cards
Microsoft Card OS:
• 
• 
• 
• 
8-bits, 8 KB ROM
multi-application
applications loading in user phase
Windows developer environments
•  Visual Basic
•  Developer Studio
•  May 2001 end of WfSC:
•  Current versions: 1.1 GSM & 2.0 Banking
•  Developer team discontinued
•  Source licensed and/or further developed by:
Interpreted Commands
& Applications
Host
Applications
using the API
Proxy
Virtual Machine
On-Card API
Authentication & Authorization
I/O
Cryptography
File System
–  SCI (SCI-OS, s-Choice)
–  Sagem (W-OS)
•  November 2002: Hive Minded announces Smartcard.NET
•  ECMA/ISO standard .NET platform for smart cards
•  Uses Microsoft Visual Studio .NET development tools
•  End 2004: licensed to Axalto to be used by Microsoft employees
71
29-Sep-14
71
Developments - PC/SC
Interoperability Specification for ICC’s and
Personal Computer Systems:
72
29-Sep-14
72
Developments - PC/SC
•  Separation between applications, CAD’s and
smart cards
•  SCSP on card , service or domain basis
•  Availability:
• 
• 
• 
• 
Windows 95 and NT 4.0 as add-on
Windows 98 on CD
W2K/XP standard
Unix M.U.S.C.L.E (www.linuxnet.com)
•  Used for W2K/XP with Crypto API, BIO API
and Kerberos for GINA
73
29-Sep-14
73
W2K/XP PC/SC client authentication (SSL/TLS)
• 
Secure Channel between
Internet Explorer and Internet
Information Server
Secure channel
Internet Explorer
• 
• 
Keys and certificates managed
by CryptoAPI, stored in smart
card
Smart Card CSP retrieves
certificate and protocol signature
from card
Crypto API
SmartCard
CSP
Reader
driver
Reader
ICC
74
29-Sep-14
74
W2K/XP PC/SC interactive logon
Winlogon
GINA
2. GINA prompts user for
PIN for auth then gets
X.509v3 cert from card
LSA
TGT
CryptoAPI
Base Smart
Card Components
Driver
Kerberos
Package
3. GINA sends credentials
to Kerberos package
through the LSA
4. Kerberos returns a double
encrypted TGT based on
cert & user object properties
in DS
Directory
KDC
1. User inserts smart
card into reader
Windows NT Domain Ctrl
Final report smartcard PKI experiment TU/e:
75
http://www.gigaport.nl/netwerk/access/ta/pki/tue/eindrapportage-tue.pdf
29-Sep-14
75
W2K/XP PC/SC remote logon
• 
• 
• 
RAS (Remote Access Service) supports EAP
(Extensible Authentication Protocol)
EAP provides standard mechanism for PPP
additions
Built-in EAP smart card module for strong
authentication of remote users towards:
1.  RAS server
2.  Domain (EAP/TLS like client authentication)
• 
Also used for VPN connection authentication and
data encryption (PPTP and L2TP/IPSec)
76
29-Sep-14
76
Trusted Computing Group
www.trustedcomputinggroup.org
•  Mission: Standardize, license and promote new hard- and software to
protect PC’s, PDA’s, mobile phones and other devices from hackers,
viruses and other security threats
•  Promoters: AMD, Hewlett-Packard, IBM, Intel, Microsoft and Sony
•  Some of the TCG standards are incorporated in Microsoft’s NextGeneration Secure Computing Base (NGSCB):
•  new security technology for MS Windows OS
•  SSC (Security Support Component) is a TCG TPM (Trusted
Platform Module) implementation
•  Not designed for but very usable for Digital Right Management (DRM)
Card Technology August 2003
www.cardtechnology.com
77
29-Sep-14
77
Developments - Standards
•  ISO International Standards Organization, 7816
(http://www.iso.ch/)
•  ETSI European Telecommunications Standards Institute, SIM (
http://www.etsi.org/getastandard/home.htm)
•  EMV Europay, Mastercard, and VISA, debit and credit cards
(http://www.emvco.com/)
•  Global Platform standards for smart card infrastructure
(www.globalplatform.org)
•  PKCS #11 & #15 RSA Public-Key Cryptography Standards (
http://www.rsasecurity.com/rsalabs/pkcs/)
78
29-Sep-14
78
Physical Attacks
• 
• 
• 
• 
• 
• 
Visual Inspection
Micro Probing
Electron Beam
Focused Ion Beam
Scanning
Signal Distortion
79
29-Sep-14
79
Physical Attacks - Visual Inspection
•  Chip module protected on front with protective
coating (epoxy)
•  Removable with chemicals
•  OS ROM code in general not visible from the top
layer à removing top layers with wet/dry etching
•  ROM content can be re-constructed with image
processing
•  Interesting technique: backside inspection
•  optical microscope: magnification ≈ 1500; SEM ≈
100000
80
29-Sep-14
80
The Chip
81
29-Sep-14
81
ROM mask
0 1 10 10 00
82
29-Sep-14
82
Physical Attacks - Micro Probing
Needles ≈ 1 µm placed on internal chip
structures:
• 
• 
• 
• 
• 
• 
• 
connect and/or disconnect tracks (MONDEX fuse)
combination with laser cutter
local signal detection and injection
EEPROM could be read in this way
make observations during normal operations
labor-intensive work
becomes less practical with smaller structures
83
29-Sep-14
83
Micro
Probing
84
29-Sep-14
84
Physical Attacks - E-Beam
Scanning Electron Microscope for:
•  magnification to 100000
Voltage Contrast:
•  EEPROM Read-out (data destructive)
•  visualize local voltage levels
85
29-Sep-14
85
Physical Attacks - Focused Ion Beam
• 
• 
• 
• 
Like SEM but with charged ions
cutting and removal of material
adding conductive material
adding probing pads
86
29-Sep-14
86
Physical Attacks -Scanning
Magnetic Scanning with Eddy Currents:
Laser Scanning:
www.cl.cam.ac.uk/~sps32/ ww.cl.cam.ac.uk/~rja14/
87
29-Sep-14
87
Physical Attacks - Signal Distortion
deformation of signals to force chip in other state:
•  decrease Vcc to block EEPROM write (PIN attack)
•  distort CLK to cause a program counter jump (read
EEPROM)
•  logical level attacks
•  increase/decrease temperature
•  light
•  radiation
Markus Kuhn: http://www.cl.cam.ac.uk/~mgk25/
88
29-Sep-14
88
Purpose of security
Protect information against:
•  unallowed disclosure
•  alteration
•  unavailability
With security functions
•  confidentiality
•  integrity
•  availability
Realization of security functions with, mostly on
cryptography, based mechanisms
89
29-Sep-14
89
Authentication
Ascertain authenticity of
•  hardware
•  individuals
•  data
Smart Card hardware authentication:
•  internal - CAD ascertains authenticity of card (application)
•  external - card ascertains authenticity of CAD
•  mutual
OS functions: GIVE/ASK RANDOM, GET CHALLENGE,
INTERNAL/EXTERNAL AUTHENTICATE
A Survey of Authentication Protocol Literature - John Clark and
Jeremy Jacob:
www-users.cs.york.ac.uk/~jac/papers/drareviewps.ps
90
29-Sep-14
90
Internal Authentication
(challenge response)
Smart Card with Ks:
CAD with Kc:
Rc
transmits Rc
enciphered under Ks
transmits random nr. Rc
EKs(Rc)
Symmetric cryptography:
Asymmetric cryptography:
private key
OK iff DKc(EKs(Rc)) = Rc
Ks=Kc=secret key
Ks=smart card
Kc=smart card public key
91
29-Sep-14
91
Replay Attack
Asymmetric, static internal authentication without smart
card cryptographic processor:
•  during personalization a hash is calculated over static smart card
data, signed with a private smart card (issuer) key and stored in
the smart card
•  at each internal authentication:
•  CAD asks public key certificate from smart card together with the
static smart card data and the signed hash
•  CAD verifies public key,calculates the hash and compares this with
the checked smart card hash
After first authentication sniffed data can be used for
authentication without smart card
Static data authentication can only guarantee that the
data comes from the private key owner
92
29-Sep-14
92
Mutual authentication
Smart Card with Ks:
CAD with Kc:
Rc
transmits concatenation of
Rc and random nr. Rs
enciphered under Ks
transmits random nr. Rc
EKs(Rc+Rs)
deciphers EKs(Rc+Rs):
DKc(EKs(Rc+Rs))=Rc+Rs;
checks Rc and transmits EKc(Rs+Rc)
deciphers EKc(Rs+Rc):
EKc(Rs+Rc)
DKs(EKc(Rs+Rc))=Rs+Rc;
checks Rc and Rs
93
29-Sep-14
93
Reflection Attack
Smart Card with Ks:
CAD with Kc:
Rc
Rs, EKs(Rc)
Rs
checks:
DKc(EKs(Rc))=Rc
Rs’, EKs(Rs)
checks:
DKs(EKc(Rs))=Rs
EKc(Rs)
sym. crypto:
Ks=Kc !
CAD has been
authenticated without the
use of Kc !
94
29-Sep-14
94
GSM SIM internal authentication
SIM with Ki16
TIMSI8
HPLMN Ki16
RND16
A3A8Ki16 (RND16)=(SRES4, Kc8)
SRES4
Checks:
SRES4=A3Ki16(RND16)
Kc8=A8Ki16(RND16)
95
29-Sep-14
95
GSM SIM internal authentication
ETSI GSM standard specifies A3A8 input & output, not
the implementation. MOU example: COMP128
April 1998: COMP128 published and appears to be
cripple → Ki can be recovered which makes card
cloning possible
Software on the internet in weeks including SIM
simulation software
Non COMP128: Libertel, KPN, Deutsche Telekom, EPlus, Vodafone ….
Current fixes:
•  COMP128-2/3
•  Counter limits number of internal authentications
96
29-Sep-14
96
COMP128
•  Based on FFT structure
•  Lack of diffusion → Output bytes i, i+8, i+16 and i+24
internal round 2 depend only on input bytes i, i+8 of
the challenge RND
•  Rounds not bijective → different inputs with same
outputs, collisions, can be found as 2 different RND’s
with identical (SRES, Kc)
•  For each collision pair i 2 Ki bytes i, i+8 can be
found by a 2-R attack
•  Marc Briceno, David Wagner, Ian Goldberg,
http://www.scard.org/gsm/
97
29-Sep-14
97
COMP128 SIM attack
// find collisions (≈8 hours for 1 SIM)
for (i=0;i<8;i++)
for RND[i,i+8]=0; RND[i,i+8]≤0xffff)
{
(RND,SRES,Kc)Table[i].Add(SIM.RunGSM(RND));
if ((RND,SRES,Kc)Table[i].FindCollision())
{collisionmap[i]=(RND, RND’); break}
}
// 2-R brute force attack on Ki
for (i=0;i<8;i++)
for Ki[i,i+8]=0; Ki[i,i+8]≤0xffff)
if (A3A8(ki,collisionmap[i,0])==A3A8(ki,collisionmap[i,1]))
/* found Ki[i,i+8] */
break;
98
29-Sep-14
98
Authentication of Individuals
Determine who someone really is:
•  identification
•  verification
: one-to-many
: one-to-one
With:
•  something someone possesses (token=smart card)
•  something someone knows (PIN, password)
•  personal characteristics (finger-print)
OS functions: VERIFY/CHANGE/UNBLOCK/
DISABLE/ENABLE CHV
99
29-Sep-14
99
Smart Card PIN verification
•  [4 digits] PIN stored in smart card with:
•  <PINmax> [3] maximum number of consecutive false verifications
•  <PINcur> present number of consecutive false verifications
•  Authentication impossible iff: <PINcur> ≥ <PINmax>
•  New PIN with [8 digits] PUK:
•  authentication permanently impossible iff <PUKcur> ≥ <PUKmax> [10]
•  4-digit PIN → 10.000 possibilities
•  Prevention of EEPROM write operations to <PINcur>, <PUKcur> makes
brute-force possible → write <P??cur>=<P??cur>+1 before verification !
•  Use of 1 PIN for hybrid cards (magstripe/chip) → sniffed PIN during chip
usage makes magstripe cloning possible
•  Digit guessing → verification implementation must be time invariant
100
29-Sep-14
100
PIN verification
•  PIN sometimes not random but result of cryptographic
operation with card data and secret key.
•  Use of hexadecimal representation during PIN
generation causes non uniform distribution →
increasing guess probability
101
29-Sep-14
101
(Old fashioned) PIN verification
1000 ≤ PIN ≤ 9999
P(PIN correct in 3
attempts)
uniform
= 1/3000
ec-PIN
≈ 1/150
ec-PIN+O1…O3 ≤ 1/105
Probability Theory for Pickpockets -- ec-PIN Guessing,
Markus G. Kuhn
102
29-Sep-14
102
PIN verification
September 22, 1998
German Court Ruling Another Blow to
U.S. Encryption Standard
By Mary Lisbeth D'Amico
MUNICH – A German district court has ordered a bank in
Frankfurt to repay a customer 4,543 marks (US$2,699) for
money withdrawn from her bank account after her bank card was
stolen.
The decision, made public Monday, again points to the holes in
the 56-bit encryption technology used in Eurocheque cards,
called EC Cards, according to the Chaos Computer Club, a
German hackers group.
Calling the encryption technology for the EC bank cards "out-ofdate and not safe enough," a Frankfurt District Court held the
bank responsible for the amount stolen from the 72-year old
plaintiff in February 1997. Neither the bank's name or that of the
plaintiff were revealed……...
http://www.cnn.com/TECH/computing/9809/23/germancrypt.idg/
103
29-Sep-14
103
Data authentication
Ascertain data integrity with:
One-way hash function H:
•  input arbitrary amount of data D, output h with fixed
length so that:
•  given D, calculation of h is easy
•  given h, difficult to find D with H(D)=h
•  given D, difficult to find D’ with D’≠D and
H(D)=H(D’)
•  Common hash functions: SHA-1 and MD5
•  Hashing for data integrity requires protection of the
hash
104
29-Sep-14
104
Data authentication
Message Authentication Code (MAC):
•  symmetric enciphered hash added to the authenticated data
(e.g. DES in CBC mode or RFC2104 HMAC)
•  hash is protected (if key is protected)
•  source known, key shared
Digital Signing
•  asymmetric, with private key, enciphered hash added to the
authenticated data
•  hash is protected (if key is protected)
•  source known, key not shared
•  DSS NIST standard
105
29-Sep-14
105
Data authentication
Certificates:
• 
• 
• 
• 
• 
Document signed by a Certificate Authority (CA)
Identity verifiable by everyone who trust CA
guaranties authenticity of document and source
popular for public key exchange
standards: X.509, PKCS
Prevention of replay attacks through addition of
unpredictable (random) data to data being
authenticated by checking party.
106
29-Sep-14
106
Data authentication - Protected Read
Smart Card with Ks:
CAD with Kc:
generates random nr. Rc
ReadProtected(file,offset, length, Rc)
reads Data,
calculates MACKs(Rc, Data)
Data + MAC
Calculates MAC’Kc(Rc, Data)
OK iff MAC’=MAC
107
29-Sep-14
107
Data authentication - Protected Write
Smart Card with Ks:
CAD with Kc:
generates random nr. Rc
Rc
calculates MACKc(Rc, Data)
WriteProtected(file,offset, Data, MAC)
calculates MAC’Ks(Rc, Data)
Writes iff MAC’=MAC
more on cryptographic protocols in
ISd2
108
29-Sep-14
108
Authorization
ALWAYS
CHV1
CHV2
AUT
PRO
CHV1 & AUT
CHV2 & AUT
CHV1 & PRO
CHV2 & PRO
CRYPT1
CRYPT2
NEVER
Smart Card security context: situation after
authentication of smart card, CAD, and user
Authorization mechanisms determine which actions are
permitted in the current security context
Access Control List (ACL) in file header:
Operation always allowed
Operation allowed after succesfull Card Holder Verification with PIN 1
Operation allowed after succesfull Card Holder Verification with PIN 1
For this operation the card (application) must be authenticated succesfully
For this object a Message Authentication Code must be calculated
Communication is encrypted with key 1
Communication is encrypted with key 2
Operation is never allowed
109
29-Sep-14
109
Authorization
Drawbacks:
• 
• 
• 
• 
• 
• 
support for security contexts
support of combinations
fixed on files instead of objects
parameter support
bad extendibility (bit coded)
storage space proportional to #files
Possible solutions:
Access Control Object (ACO)
Windows for Smart Card ACL approach
110
29-Sep-14
110
ACO
Doctor
(Security Env #1)
Assistant
(Security Env #2)
Pharmacist
(Security Env #3)
Patient
(Security Env #4)
EF_PATIENT
EXTAUT (AUT#1)
EF_DIAGNOSIS
EXTAUT (AUT#1)
EF_MEDICINE
EXTAUT
(AUT#1)
READ
(PRO#2)
EXTAUT
(AUT#2)
READ
UPDATE
APPEND
EXTAUT
(PRO#2)
(PIN#1,PRO#3)
(PRO#3)
(AUT#2)
READ
UPDATE
APPEND
EXTAUT
(PRO#2)
(PIN#1, PRO#3)
(PRO#3)
(AUT#2)
READ
UPDATE
EXTAUT
(PRO#2)
(PRO#4)
(AUT#3)
READ
(PRO#2)
READ
(PRO#2)
EXTAUT
(AUT#3)
READ
(PRO#5)
READ
(PIN#2)
-
READ
(PRO#5)
CONF_MED (PRO#5)
READ
(PIN#2)
READ
(PIN#2)
Proprietary condition: only permitted iff CONF_MED has not been executed
The Security Functions of Access Control Objects in Smart Cards – Helmut
Scherzer, IBM Germany, in Proceedings of CardTech/Securtech Orlando May
1997.
111
29-Sep-14
111
ACO
ACID=01
01: READ
EXT AUT (#1..#3)
ACO graph:
ACID
house nr.
SCD
ACP
ACID=02
ACID=03
ACID=04
81: CONFIRM_MEDIC
P RO #5
01: NEVER
81: P RO #2
02: UP DAT E
EXT AUT (#1..#3)
ACID=05
ACID=06
ACID=07
01: P IN #2
81: PRO #4
82: P RO #3, P rop#1
P IN #1
03: AP P END
EXT AUT (#1..#3)
P IN #1, P RO #3
File header info:
FILE_ID
EF_PATIENT
EF_DIAGNOSIS
EF_MEDICINE
T
86
86
86
L
8
8
8
V
01
07
07
( ACID || Security Env.)
01 06 02 02 03 05 04
01 01 02 03 03 05 04
01 01 02 02 03 05 04
The Security Functions of Access Control Objects in Smart Cards – Helmut
Scherzer, IBM Germany, in Proceedings of CardTech/Securtech Orlando May
1997.
112
29-Sep-14
112
ACO
Algorithm:
•  Given object ACID + security context + command;
•  Search command in ACO with ACID. Command not found → go to
parent ACO and repeat search until root . Command not found →
condition of command: NEVER.
Command found → remember “house number” from ACO in which
command was found.
•  Go back to first ACO and search upwards to “house number”. Here’s the
object access condition. For “house numbers” > 0x80 the most
significant bit has to be removed first. If it matches the condition counts
but the search continues via parent ACO.
The Security Functions of Access Control Objects in Smart Cards – Helmut
Scherzer, IBM Germany, in Proceedings of CardTech/Securtech Orlando May
1997.
113
29-Sep-14
113
ACO example
UPDATE Authorization of
EF_DIAGNOSIS by a Doctor:
EF_DIAGNOSIS
86 8 07 01 01 02 03 03 05 04
ACID=07
ACID=01
EXTAUT(#1..#3)
01: READ
EXT AUT (#1..#3)
ACID=02
ACID=03
ACID=04
81: CONFIRM_MEDIC
P RO #5
01: NEVER
81: P RO #2
02: UP DAT E
EXT AUT (#1..#3)
ACID=05
ACID=06
ACID=07
01: P IN #2
81: PRO #4
82: P RO #3, P rop#1
P IN #1
03: AP P END
EXT AUT (#1..#3)
P IN #1, P RO #3
PRO#3, Prop#1,
PIN#1
114
29-Sep-14
114
Windows for Smart Cards (WfSC) ACL’s
•  Known Principals (KP) for Authentication
•  issuer, owner, CAD, application …
•  each KP has a reference to an authentication protocol
•  PIN, challenge-response, applet …
•  Group is a collection of KP’s
•  Group authenticated iff at least 1 KP is authenticated
•  Group de-authenticated iff all KP’s are de-authenticated
•  Access Control List (ACL):
•  list with actions and Boolean KP expressions
•  action is permitted iff expression is valid (KP is
authenticated)
115
29-Sep-14
115
Windows for Smart Cards ACL’s
•  Each file, including each ACL file, on the card
requires an ACL file that determines access
rules
•  File structure after card initialization
(bootstrap):
/
/s
/s/k
/s/k/index
/s/k/anonymous
/s/a
/s/a/anonymous
/s/a/default
/s/a/kpdir
/s/a/sys
(directory)
(directory)
(directory)
(file)
(file)
(directory)
(file)
(file)
(file)
(file)
ACL
ACL
ACL
ACL
ACL
ACL
ACL
ACL
ACL
ACL
default
default
kpdir
sys
anonymous
default
anonymous
anonymous
anonymous
anonymous
116
29-Sep-14
116
GSM <-> WfSC mapping
ETSI GSM
Authentication
ALWAYS
CHV1
CHV2
ADM1… ADM10
ADM
NEVER
Authorization
READ
UPDATE
INVALIDATE
REHABILITATE
INCREASE
WfSC GSM
KP ANONYMOUS
KP CHV1 + KP PUK1
KP CHV2 + KP PUK2
KP ADM1 … KP ADM10
KP Group ADM with KP ADM1…ADM10
No ACL entry (or KP index )
READ
WRITE
custom INVALIDATE
custom REHABILITATE
custom INCREASE
117
29-Sep-14
117
Confidentiality
Symmetric:
•  DES
•  3DES
•  AES
Asymmetric
•  RSA
•  Elliptic curves
Choice of algorithm: proven technology,
scalability, key management, cost, privacy …
more on cryptographic algorithms in
ISd2
118
29-Sep-14
118
Symmetric systems (DES)
• 
• 
• 
• 
Civil use since 70’s
Bit manipulations → hardware efficient
No real scalability (not key-upgradable)
Key management → both sides need secure device
(SAM)
•  Generic attack: exhaustive key-search
•  #keys=256≈ 7.2*1016
•  distributed computing via internet: key within weeks: http://distributed.net/
•  dedicated hardware: key within 1 day
http://www.eff.org/descracker/
•  Triple-DES → #keys = 2112 ≈ 5.2*1033
exhaustive key-search not realistic
119
29-Sep-14
119
DES implementation attacks - DPA
(http://www.cryptography.com/)
120
29-Sep-14
120
DES implementation attacks - DPA
input ( Rx 32 bits)
E
48 bits
S1
S2
subkey (Kx 48 bits)
S3
S4
S5
S6
S7
S8
P
output ( Rx 32 bits)
(http://www.cryptography.com/)
121
29-Sep-14
121
DES implementation attacks - DPA
Variables
•  key length
: l=56
•  sub-key length
: s=6
•  #S-BOXES
: b=8
•  #characters
: c=2
•  average #test keys
:t
Goal
•  Reduction from exhaustive key search (t=0.5 x cl = 255=
36028797018963968) towards exhaustive sub-key search
(t= 2 x b x cs = 1024)
•  Other advantage: only plain OR crypto text needed
122
29-Sep-14
122
DES implementation attacks - DPA
•  Collection phase: execute DES with n random inputs
measuring the Power P :
P i, t : i = input, t = time ∈ [0…T]
•  Differential Key Search: For each possible sub-key s
divide P into two summed traces: P0 and P1 based on a
selection function D which is dependent on i, s and
something of the sub-key which is correlated to the actual
current (e.g. S-BOX leftmost output bit)
•  incorrect sub-key⇒D uncorrelated to actual Power consumption ⇒
random partitioning ⇒ P1 - P0 ≈ 0
•  correct sub-key⇒D correlated to actual Power traces ⇒ P1 - P0 ≠ 0
•  Round 1 reveals 48 key-bits, other 6 bits can be found
with same technique on round 2
123
29-Sep-14
123
DES implementation attacks - DFA
Differential Fault Analysis (DFA): (Bellcore, Biham, Shamir ...)
message m, n bits key k, cipher text c, cf=encryption of m with all_zero_key kf
// break-down stage
i=0; ci=E(m);i++;
while (E(m)!=cf)
{
use physical stress to force single 1
if (new value E(m))
{ci=E(m);i++}
} // built-up stage
k=kf;i=f;
while (i)
{
while (Ek(m)!=ci)
try other k with single 0
i--;
→
→
0 key bit change;
1 bit change
}
124
29-Sep-14
124
DES implementation attacks - DFA
Differential Fault Analysis (DFA): (TNO EIB)
Do same encryption twice, first without any faults, second with
faults that corrupt the outcome of the 15th round:
R16=F(R15,K16) ⊕ L15
R’16=F(R’15,K16) ⊕ L15
-------------------------------------------- ⊕
R16 ⊕ R’16 = F(R15,K16) ⊕ F(R’15,K16) ⇐ only K16 Unknown !
= S(E(R15) ⊕ K16) ⊕ S(E(R’15) ⊕ K16)
K16 can be brute-forced individually for each S-BOX i where
(R16 ⊕ R’16 )i ≠ 0 ⇒ 26=64 candidates for all such S-BOX’es
125
29-Sep-14
125
DES implementation attacks
Differential Fault Analysis (DFA):
•  single bit changes not easy
•  execution errors more likely (clock glitching)
Differential Power Analysis (DPA):
•  leakage of run-time OS (crypto algorithm) information
via smart card power consumption
•  not only a DES threat
•  Counter measures:
•  hardware leakage reduction (filters, noise generators …)
•  software adaptations (loop balancing, retry counters …)
more on side channel analysis in ISd2
126
29-Sep-14
126
Asymmetric systems
•  Concept from 1976, in use during last decades
•  Algebraic structures → less hardware efficient
•  discrete logarithm
•  factoring
•  elliptical curves (efficient in processing power and key-length)
•  Scalable (key-upgradable)
•  Key management → secure device for private key,
certificate for public key
•  Cryptographic coprocessor needed + key EEPROM
→ more expensive
•  Key generation takes time !
127
29-Sep-14
127
RSA - Implementation Attacks
s = x y mod n via binary square & multiply:
s = 1;
while (y)
{
if (y&1)
s=(s*x) mod n;
y>>=1;
x=(x*x) mod n;
}
return (s);
Only multiply iff corresponding key-bit is 1 !
Time measurement
: Timing Attack
Crypto Processor (On/Off)
: (D)PA Attack
Paul Kocher (http://www.cryptography.com/)
128
29-Sep-14
128
Smart Card Symmetric Key Hierarchy
Derivation
Data #1
Master Key
1*generation
Encrypt
Derivation
Data #2
Main Key
1*function
Encrypt
Derivation
Data #3
Derived Key
1*card
Encrypt
Session Key
1*session
129
29-Sep-14
129
Source: Litronic
130
29-Sep-14
130
Privacy
identity known - identity card during postal parcel pick up
pseudo-anonymous ATM transaction at shopping mall
anonymous - phone call with pre-paid GSM subscription
unlinkable - successive phone calls from phone booth
with the same pre-paid phone card
unobservable - freedom network??
131
29-Sep-14
131
Security Evaluation
•  Certainty about system correctness and
system sensitiveness
•  Security objectives determine the scope of
evaluation expressed in evaluated assurance
level
•  Makes comparison possible
•  Criteria: Agreements about the evaluation
process
•  formal requirements + number of tests
more on evaluation in ISd2
132
29-Sep-14
132
IT Security Criteria
•  Trusted Computer Security Evaluation Criteria
(TCSEC) = Orange Book
•  Information Technology Security Evaluation
Criteria (ITSEC)
•  IT Security Evaluation Manual (ITSEM) - methods for
the execution of ITSEC evaluations
•  Common Criteria for Information Technology
Security Evaluation (CC)
•  Version 2.1 ISO/IEC 15408
133
29-Sep-14
133
Common Criteria for Information Technology
Security Evaluation
•  8 Evaluation Assurance Levels (EAL’s)
•  EAL0 - insufficient certainty
…
•  EAL7 (implementation) ⇒ (formal specification)
•  Strength Of Function (SOF) classification:
•  SOF-basic smart outsider; intelligent; not enough system knowhow; no advanced equipment
•  SOF-medium educated insider; experience and advanced
equipment
•  SOF-high financed organization; hire specialists and equipment
134
29-Sep-14
134
Smart Card Protection Profiles
•  Protection Profiles: Definition of security
requirements for a product group,
independent of implementation
•  Smart Card PP:
ID
PP/0303
PP/0010
PP/0002
PP/9911
PP/9909
PP/9903
PP/9810
• Type
description of TOE and position in smart card life-cycle
Version Status EAL SOF
1.0b
ard P rotection P
rofile • J ava C
description
of assets
to be protected + threats to
withstand
3.0
E+V
4 High
S C S UG S mart C ard P rotection P rofile 2.0
C
4 High
ard IC with Multi-­‐Application S
ecure P
• S mart C
formulation
of security goals TOE
and latform environment
2.0
C
4 High
T rans actional S C R eader
• S mart C
definition
of functional
TOE requirements
in order
2.0 to meet
C security
4 High
ard Integrated C
ircuit with E
mbedded S oftware objectives
1.2
C
4 High
Inters
ector E lectronic P urs e and P urchas e Device 1.2
C
4 High
T rans portation ticketing contact & contactles s
• S martcard E
definition mbedded S
of requirements
which must be satisfied
in order
1.2 by TOE
C
4 High
oftware P rotection P rofile to guarantee the level of security
http://niap.nist.gov/cc-scheme
135
29-Sep-14
135
Risk Analysis
•  Social risks of smart cards
•  Risk=Probability*Effect
•  negligible: 1 card holder
•  small: 1 card issuer (loss of money and reputation)
•  large: go beyond the card issuer (system compromised)
•  Risk classes on behalf of prevention
•  impersonal smart cards (pre-paid SIM )
•  smart cards with (pseudo)-identity (chipknip)
•  smart cards with third-party identity function (W-document)
136
29-Sep-14
136
Prevention Measures
www.minjust.nl/c_actual/rapport/smartnl.htm
137
29-Sep-14
137
Design Hints
•  Maximize reuse
• 
• 
• 
• 
• 
standards
algorithms
API’s
risk analysis
incidents
•  Use an evaluation method
•  Common Criteria …
•  Peer review
•  Security by Obscurity can only work as a delay factor
•  Take system failure as a starting point of security
•  how is it detectable
•  how can the damage be restricted
•  how can the failure be corrected
138
29-Sep-14
138