Robbing the bank using formal
methods
or
How to play with Lego during your PhD
Joeri de Ruiter
Digital Security, Radboud University Nijmegen
Overview
●
EMV
●
Is the specification secure?
●
●
Formalising the specs
Is the implementation secure?
●
Automated learning
–
–
Bank cards
Handheld readers
Smart cards
●
Processor and memory
●
Cryptographic co-processor
●
Pseudo random number generator
●
Multiple applications
●
Contact or contactless
●
Tamper resistant
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
3 / 60
Smart cards
●
VERIFY command
Terminal → Card: 00 20 00 80 08 24 12 34 FF FF FF FF FF
–
–
–
–
00 20 – VERIFY
00 80 – Plaintext PIN
08 – Length data
24 12 34 FF FF FF FF FF – Data
Card → Terminal: 90 00
–
Status word: PIN code correct
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
4 / 60
What is EMV?
Standard for payments using smart cards
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
5 / 60
What is EMV?
Developed and maintained
Owned by
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
6 / 60
What is EMV?
●
Initiated in 1993
●
Worldwide over 1,5 billion cards
●
Introduced in the UK in 1997
●
Required in Dutch shops since 2012
●
Specification over 700 pages
●
Variants for contactless and internet banking
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
7 / 60
Why EMV?
●
●
Prevent fraud
●
Skimming
●
Card-not-present fraud
Single Euro Payments Area
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
8 / 60
Key set-up
●
Card and issuer: symmetric key
●
●
Issuer: private/public keypair
●
●
Authenticate transactions to bank
Authenticate cards
Cards (optional): private/public keypair
●
Authenticate cards/transactions to terminal
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
9 / 60
EMV session
●
Initialisation
●
Select application
●
Read data
●
Card authentication
●
Cardholder verification
●
Transaction
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
10 / 60
Card authentication
●
Static Data Authentication (SDA)
●
Static data signed by issuer
READ RECORD
Sig((acc.nr., card nr., …), skBank)
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
11 / 60
Card authentication
●
Dynamic Data Authentication (DDA)
●
Public key cryptography used
●
Challenge/response mechanism
READ RECORD
Sig((acc.nr., …,pkCard), skBank)
INTERNAL AUTH, nonceT
Sig((nonceT, nonceK), skCard)
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
12 / 60
Card authentication
●
Combined Data Authentication (CDA)
●
Transaction data signed
READ RECORD
Sig((acc.nr., …,pkCard), skBank)
GENERATE AC, amount, nonceT, ...
Sig((amount, nonceT, …, AC), skCard)
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
13 / 60
Cardholder verification
●
None
●
Signature
●
PIN code
●
Offline
–
●
With or without encryption
Online
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
14 / 60
Transaction
●
Application Cryptograms
●
Transaction Certificate (TC)
●
Application Authentication Cryptogram (AAC)
●
Authorisation Request Cryptogram (ARQC)
●
MAC over transaction data
●
Online
●
●
Authentication bank
Offline
●
No contact bank
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
15 / 60
EMV-CAP
●
Based on EMV
●
Not public
●
Reverse engineered
●
Handheld readers
●
●
Rabobank (Random Reader)
●
ABN AMRO (e.dentifier)
Challenge-response
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
16 / 60
EMV-CAP
PIN
PIN
OK
challenge
GENERATE AC (challenge,...)
AC
bitfilter(AC)
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
17 / 60
Overview
●
EMV
●
Is the specification secure?
●
●
Formalising the specs
Is the implementation secure?
●
Automated learning
–
–
Bank cards
Handheld readers
Attacking smart cards
●
Direct access to memory not possible
●
Passive
●
●
●
Eavesdrop on communication
Active
●
Man-in-the-middle attack
●
Modification of communication
Side channels
●
Timing
●
Power consumption
●
Electromagnetic radiation
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
19 / 60
Attacking smart cards
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
20 / 60
Known weaknesses
●
Skimming
●
●
Data needed to reconstruct magnetic strip available
on chip
e.dentifiers ABN AMRO replaced in their offices
–
–
–
2008, 2009
1,5 million euro damages
Downloadcard
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
21 / 60
Known weaknesses
●
Clone SDA cards
●
Possible for offline transactions
●
Only static data authenticated
●
No support for asymmetric crypto on card
●
Yes-card
–
All PIN codes accepted
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
22 / 60
Known weaknesses
●
DDA man-in-the-middle attack
●
Possible for offline transactions
●
Terminal cannot authenticate transaction
●
Transaction seperate from card authentication
INTERNAL AUTH, nonceT
Sig((nonceT, nonceK), skCard)
GENERATE AC
AC
MitM
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
23 / 60
Known weaknesses
●
“Chip & PIN is broken” [Murdoch et al. 2010]
●
Possible for online and offline transactions
–
–
If card is not blocked
If transactions without PIN are allowed
●
Man-in-the-middle attack
●
All PIN codes accepted
●
Not possible in The Netherlands
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
24 / 60
Known weaknesses
Source: https://www.cl.cam.ac.uk/research/security/banking/nopin/
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
25 / 60
Known weaknesses
●
“Chip & PIN is definitely broken” [Barisani et al.
2011]
●
Rollback to plaintext PIN
●
Terminals in The Netherlands patched
●
Attack was still possible
–
Detected in backend
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
26 / 60
Complexity
●
Over 700 pages
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
27 / 60
Complexity
●
Many options and parameterisations
●
3 card authentication methods
–
●
5 cardholder verification methods
–
●
PIN / Handwritten signature / None
2 types of transactions
–
●
SDA / DDA / CDA
Online / offline
Parameterisation using Data Object Lists
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
28 / 60
Overview
●
EMV
●
Is the specification secure?
●
●
Formalising the specs
Is the implementation secure?
●
Automated learning
–
–
Bank cards
Handheld readers
Formal verification - ProVerif
●
Automated cryptographic protocol verifier
●
Active / passive attacker
●
Cryptography considered to be perfect
●
Unbounded number of sessions
●
Due to some approximations
●
False attacks possible
●
Claimed properties always hold
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
30 / 60
Formal verification - ProVerif
●
Input in applied pi-calculus
●
Queries
●
Secrecy
query attacker: M.
●
Authenticity
query ev:End ==> ev:Begin.
query evinj:End ==> evinj:Begin.
●
Attack reconstruction
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
31 / 60
F#
●
Formalisation in F#
●
Functional programming language
●
Developed by Microsoft Research
●
Executable code
●
Translated to applied pi-calculus using FS2PV
–
–
Subset of F# language
More flexibility
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
32 / 60
Formalisation
●
Card and terminal formalised
●
Options can be either unspecified or fixed
●
DOLs fixed for Dutch banking cards
●
370 lines of F# code
●
Over 2500 lines of applied pi-calculus
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
33 / 60
Formalisation
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
34 / 60
Security properties
●
Sanity checks
●
Secrecy of private keys
●
Highest supported authentication method used
●
Transaction authentication
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
35 / 60
Security properties
●
Card and terminal agree whether PIN is entered correctly
evinj:TerminalVerifyPIN(True)
==>
evinj:CardVerifyPIN(True)
●
Transaction are authentic
evinj:TerminalTransactionFinish(sda,dda,cda,pan,atc,True)
==>
evinj:CardTransactionFinish(sda,dda,cda,pan,atc,True)
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
36 / 60
Overview
●
EMV
●
Is the specification secure?
●
●
Formalising the specs
Is the implementation secure?
●
Automated learning
–
–
Bank cards
Handheld readers
From specification to
implementation
●
Specification analysed using formal methods
●
How do we know this is actually implemented?
●
Model based testing
●
Automated learning
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
38 / 60
Automated learning
●
LearnLib used
●
●
●
Implementation of
adapted L* algorithm
Deterministic Mealy
machine M =
(I,O,Q,q0,δ,λ)
Equivalence queries
approximated
●
Random traces
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
39 / 60
Automated learning
●
Custom test harness for EMV smartcards
●
In total 15 different commands
●
Input symbols: commands
●
Output symbols: status words (optionally with
cryptogram type)
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
40 / 60
Automated learning
●
Learned 33 models for 16 cards
●
Less than 20 minutes to construct final model
●
Models contained 4 to 8 states
●
●
Most cards did not follow state machine specified by
MasterCard
No security problems found
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
41 / 60
Results
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
42 / 60
Results
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
43 / 60
Results
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
44 / 60
Maestro cards
Rabobank Maestro
Volksbank Maestro
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
45 / 60
EMV-CAP
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
46 / 60
Using these diagrams
●
Reverse engineering
●
●
Fuzzing or model-based testing
●
●
Manual inspection of correctness and security
Use as basis for automated fuzz testing
Formal verification
●
Use as basis for model checking
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
47 / 60
Overview
●
EMV
●
Is the specification secure?
●
●
Formalising the specs
Is the implementation secure?
●
Automated learning
–
–
Bank cards
Handheld readers
e.dentifier2
●
●
●
Developed by Todos (now
Gemalto)
Can be used with or
without USB
With USB:
●
●
●
See-What-You-Sign
“the most secure
sign-what-you-see end
user device ever seen”
Good idea!
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
49 / 60
Automated reverse engineering
●
Using LearnLib
●
Two different versions of the device
●
Physical interaction needed
●
Programmable smart card
●
All PIN codes accepted
●
Responses fixed
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
50 / 60
Robot
●
Built using Lego
●
Controlled by Raspberry Pi
●
3 motors: OK, Cancel, digit
●
Power USB line
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
51 / 60
Robot
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
52 / 60
Robot
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
53 / 60
Results
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
54 / 60
Protocol
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
55 / 60
Protocol
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
56 / 60
Protocol
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
57 / 60
Protocol
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
58 / 60
Conclusions
●
●
Formal methods can be used to analyse
complex industry standards
Automated learning techniques
●
Useful in security analysis
●
Can find security vulnerabilities
●
Good excuse to play with Lego
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
59 / 60
Conclusions
●
●
Formal methods can be used to analyse
complex industry standards
Automated learning techniques
●
Useful in security analysis
●
Can find security vulnerabilities
●
Good excuse to play with Lego
Thanks for your attention!
Joeri de Ruiter - Digital Security, Radboud University Nijmegen
60 / 60