Online Banking

Transcription

Online Banking

Wilhelm Schickard Institute of Computer Science
Theoretical Computer Science
Online Banking
TAN Generation via Smartphone
Supervisors:
Dr. Borchert
Prof. Reinhardt
Author:
Robert Finze
September 25, 2013
CONTENTS
1
introduction
1
1.1 Structure
1
2 tan methods used for online banking
2.1 Mobile Banking
3
2.2 How are TANs generated
5
2.2.1 TAN / iTAN List
5
2.2.2 mTAN
7
2.2.3 crontoSign
8
2.2.4 chipTAN
10
2.2.5 NFC-TAN
12
3 nfc smartphones and nfc chip cards
4 standards, norms and specifications
4.1 ISO/IEC 7816
20
4.2 ISO/IEC 7816-2
20
4.3 ISO/IEC 7816-3
21
4.3.1 Protocol T=0
21
4.3.2 Protocol T=1
22
4.3.3 ATR
23
4.4 ISO/IEC 7816-4
24
4.4.1 Command APDU
24
4.4.2 Response APDU
25
4.5 ISO/IEC 14443
25
4.5.1 ISO/IEC 14443-3
26
4.5.2 ISO/IEC 14443-4
27
4.6 ISO/IEC 18092
28
4.7 HHD
28
4.7.1 Startcodes
29
4.8 EMV
30
5 the birth of a tan
31
5.1 Test Environment
31
5.2 Sniffing a TAN generation
33
6 implementing a prototype
41
6.1 Environment
41
6.2 Structure
42
6.2.1 Proxy Server
45
6.2.2 Mobile Application
46
6.2.3 Helping Hands
51
6.3 Extension: Mobile Banking
52
7 is it safe?
53
7.1 Attacks on NFC-TAN
54
7.1.1 Malware on PC
55
7.1.2 Malware on Phone
56
7.1.3 Theft
57
7.1.4 Communication Interfaces
57
3
15
19
i
Contents
Social Engineering
58
GSM Security
59
Keeping Secrets Secret
59
Common Attacks Explained
60
7.5.1 Man-in-the-Middle
60
7.5.2 Man-in-the-Browser
61
7.5.3 Re-, Preplay
61
7.5.4 Relay Attack
61
conclusion
63
7.2
7.3
7.4
7.5
8
ii
LIST OF FIGURES
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13
Figure 14
Figure 15
Figure 16
Figure 17
Figure 18
Figure 19
Figure 20
Figure 22
Figure 21
Figure 23
Figure 24
Figure 25
Figure 26
Figure 27
Figure 28
Figure 29
Figure 30
Figure 31
Figure 32
Figure 33
Mobile Banking TAN Methods
4
Online Banking TAN Methods
6
Protocol with TAN Lists
6
mTAN Protocol
7
photoTAN reader and crontoSign application
8
crontoSign Protocol
9
chipTAN comfort TAN generator
10
chipTAN Protocol
11
Flickercode
11
Parts of NFC-TAN
13
protocol of tan generation
14
Original NFC-TAN
15
NFC-TAN without NFC smartphone
17
NFC-TAN with Proxy
17
Contacts of a chip card
20
T=0 block structure
21
T=1 block structure
22
Structure of a complete command APDU
24
Structure of a response APDU
25
Structure of a block according to ISO/IEC 14443-4
27
Wired TAN Generator
31
Devices used to sniff communication between card and TAN
generator
32
Smartcard readers. Left ReinerSCT cyberJack RFID komfort
and right gemalto PC USB-SL
42
Parts of NFC-TAN
43
NFC-TAN Proxy Summary
43
protocol of tan generation with proxy
44
Proxy Server Summary
46
Mobile Application Classes
48
Abstract Transaction Init Classes
48
QR Codes
49
Abstract TAN Generator Classes
49
Abstract card reader classes
50
Process of creating a TAN
51
iii
LISTINGS
5.1
5.2
BusPirate UART Paramerters . . . . . . . . . . . . . . . . . . . . . . .
Transaction Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
33
6.1
6.2
6.3
Assigning a URI to a Java Method . . . . . . . . . . . . . . . . . . . .
ITerminal Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Public interface of TransactionObject . . . . . . . . . . . . . . . . . . .
45
46
47
1
2
3
4
5
6
ITerminalProtocol . . . .
BankAccountProtocol . .
Transaction Interface . .
URLConnectionHandler
SmartcardTerminal . . .
Data Type APDU . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
a
a
a
a
b
c
v
ACRONYMS
AFL Application File Locator
AID Application IDentifier
AIP
Application Interchange Profile
APDU Application Protocol Data Unit
ASCII American Standard Code for Information Interchange
ATC Application Transaction Counter
ATM Asynchronous Transfer Mode
ATR Answer To Reset
ATS Answer To Select
BCD Binary Coded Decimal
BKA BundesKriminalAmt (Federal Criminal Police Office)
BSI
Bundesamt für Sicherheit in der Informationstechnik (Federal Office for
Information Security)
CICC Close Coupling Integrated Chip Card
CID Card IDentifier
CRC Cyclic Redundancy Code
DK
Deutsche Kreditwirtschaft (German Banking Industry Committee)
EC
Electronic Cash
EDC Error Detection Code
EEPROM Electrically Erasable Programmable Read-Only Memory
EMV Europay, Mastercard, Visa
EPROM Erasable Programmable Read-Only Memory
FinTS Financial Transaction Services
GSM Global System for Mobile communications or Groupe Spécial Mobile
HHD Hand Held Device
ICC
Integrated Circuit Card
IEC
International Electrotechnical Commission
IFSC Information Field Size for the Card
vii
Listings
IFSD Information Field Size for the Device
iOS
iPhone Operating System
iTAN indexed TransAction Number
ISO
International Organization of Standardization
JTC Joint Technical Committee
LRC Longitudinal Redundancy Check
MitB Man-In-The-Browser
MitM Man-In-The-Middle
mTAN mobile TransAction Number
NAD Node ADress
NDA Non Disclosure Agreement
NFC Near Field Communication
nPA neuer PersonalAusweis (new German Personal ID)
nonce number used once
OSI
Open Systems Interconnection
PC
Personal Computer
PCB Protocol Control Byte
PCD Proximity Coupling Device
PICC Proximity Integrated Circuit Card
PIX
Proprietary application Identifier eXtension
PIN Personal Identification Number
QR-code Quick Response code
RF
Radio Frequency
RID Registered IDentifier
SC
Sub Committee
SDK Software Development Kit
SECCOS Secure Chip Card Operating System
SIM Subscriber Identity Module
SSL
Secure Sockets Layer
SWP Single Wire Protocol
TAN Transaction Authentication Number or TransAction Number
viii
Listings
UI
User Interface
USB Universal Serial Bus
VICC Vicinity Integrated Circuit Card
ZKA Zentraler KreditAuschuss (Central Credit Committee)
ix
1
INTRODUCTION
This work belongs to a series of other projects1 which all concern themselves with
online banking and methods of generating TANs.
Goal of this project is to create an implementation of NFC-TAN2 for iOS3 devices
thus enabling users to do online banking with their iOS device and a NFC debit
card in a secure and easy way.
In the process of reaching this goal necessary information about online banking,
TAN methods, standards and protocols are gathered and introduced giving an
understanding of details involved in successfully placing an online transaction.
Main challenges were iOS currently not providing NFC support and NFC debit
cards only providing limited access. When developing ideas to overcome these
challenges, other projects were found which in the end each contributed parts to
a very flexible solution. This solution consists of simulating not available features.
NFC debit cards were substituted with [Sat12]’s eKaayDebitCards and NFC was
added to iOS with a proxy solution to which [Gün11] provided a some groundwork. Having this already flexible concept, [Ccc]’s experiment was repeated and
included in this project to extend its application.
Online banking is a field with high security requirements and TAN methods
exist solely to prevent fraud and abuse in online banking scenarios. Different
attacks and defences will be discussed to show not only how TANs add security
but also how TAN methods itself can be target of an attack.
1.1
structure
Following chapters will provide necessary information needed to understand technologies and methods used in this project. Starting with a description of what
TANs are and how they are used, we then discuss some current methods to create
TANs in chapter 2 including a new approach — NFC-TAN. Chapter 3 describes
some difficulties encountered in this project like NFC currently not being supported on iOS devices. Some possible solutions are introduced and one of these
solutions will be implemented in chapter 6. Chapter 4 gives an introduction to
standards and specifications associated with used technologies which are mainly
chip cards and NFC. Also some specifications about banking protocols are mentioned.
1 Especially [Sat12] and [Gün11]
2 See http://nfc-tan.com, [BG13] and section 2.2.5
3 iOS – iPhone Operating system
1
1 introduction
A currently widely used TAN method is chipTAN. When implementing this
method, a central question is how exactly are these TANs generated. Details on
this will be given in chapter 5 which is based on previous work of [Ccc]. With their
help it was possible to repeat their experiment and create a software implementation with the results.
The concept and some details of the implementation will be described in chapter 6
At the end chapter 7 takes a look at security issues of TANs used in online banking. By discussing possible attacks on NFC-TAN and other systems it is explained
how they could be anticipated. If some attacks are still possible suggestions to
solutions are given. Additionally a short introduction to some standard attack
scenarios are given.
2
2
TA N M E T H O D S U S E D F O R O N L I N E B A N K I N G
Online banking – or electronic banking – describes “the process or business of
using the internet to organise, examine, and make changes to bank accounts, investments, etc”1 . So instead of having to go to a bank during their opening hours,
people can do their banking whenever they have time. The obvious advantages
of online banking has led many people to do most of their every-day banking
online2 .
Even before online banking the idea of a TAN, additionally to the PIN was
developed3 . A TAN is an one-time password which is used to authorise a specific transaction. For each transaction a new TAN is used and only with that the
transaction will be carried out.
Today people doing online banking are most likely familiar with the concept of
a TAN since every time a transaction is submitted a TAN is needed to authorise
that transaction. Early TAN methods didn’t completely prevent fraud so banks
have been working on new methods to counter attacks which then attackers again
adopted to.
For online banking people can choose to either install an application which runs
on their PC and communicates with their bank or use the bank’s website. The first
approach is done in Germany via the FinTS4 protocol and functions differently
from the web-based method. In this work only the web-based online banking will
discussed, keeping in mind that the arguments here might not apply to standalone
applications for online banking.
2.1
mobile banking
Mobile banking is the next iteration after online banking. Smartphones are becoming more and more a part of our everyday life and with them we are getting used
to always being online. People may want to check their account balance before
deciding to buy goods or want to transfer money while sitting in a cafe. In its
features and security issues mobile banking can be compared to online banking
with a PC because that’s basically what smartphones are.
All people need for mobile banking is a device with internet access. Banks
usually provide an application which makes common services easier to use but for
most tasks a web browser is sufficient. Having only one device all security risks
that apply to online banking on a PC also apply to mobile banking. One might
1
2
3
4
[Pre]
[Got12]
[Bora]
Financial Transaction Services, formerly known as HBCI – Homebanking Computer Interface
3
argue that applications on smartphones are sandboxed5 and therefore more secure
than common applications on PCs but this argument is deceiving6 . Although
people seem to be aware of the potential risks of mobile banking7 , nonetheless
it might likely be very common in a few years. Especially in emerging markets
mobile banking provides access to banking services for people who otherwise
might be excluded from banking services at all8 .
Again the question arises which TAN method to choose. Figure 1 shows a
summary of the most common TAN methods used in mobile banking ordered to
security and usability.
Security
secure
ChipTAN
little risk
medium risk
NFC-TAN
iTAN
SIM-TAN
PushTAN
App-TAN
high risk
insecure
SMS-TAN
very insecure
PIN only
available today
requirements fullfiled
requirements not yet fullfiled
Usability
Figure 1: Mobile Banking TAN Methods9
Although SMS-TAN (or mTAN) has a rather good usability it is very insecure
when using mobile banking. A main feature of mTAN is the two-channel authentication when doing online banking. Since mTAN uses only a mobile device there
is no second channel. This led some banks prohibiting mTAN when doing mobile
banking. Other methods like App-TAN or SIM-TAN where the TAN is created
using a secret key stored within the memory of the application or the SIM card
provide a high usability. They are however object to other attacks. Since the TAN
is generated on the phone without external accessories, users might not notice if
malware creates TANs in the background, sends them to an attacker or uses them
to authorise transactions. While it is hard to extract the secret from a SIM card,
it is easier breaking the sandbox and accessing the private memory of an application. Attackers then can copy the secret and create TANs whenever they choose
to10 . iTANs provide a good level of security if the iTAN list is stored securely.
5 Sandboxing is a technique of restricting access to certain resources only to specific applications.
These access conditions are usually managed by the operating system.
6 See [Au+11] and [SJH11]
7 see [Zho12]
8 See [Alo+13] and [She12]
9 Figure adopted from Dr. B. Borchert, University of Tübingen, 2013
10 More on malware on smartphone in section 7.1.2 on page 56
4
But handling these lists has serious usability implications. ChipTAN offers a good
level of security because it offers a two-channel authentication also when doing
mobile banking. Though users have to carry around an additional device. Here
NFC-TAN tries to close the bridge between security and usability. People do not
need to carry an extra device and malware can not steal the secret to create TANs
since it is not stored on the phone. This method however might be subject to malware and phishing11 attacks, e.g. Man-in-the-Browser, where different transaction
data is shown on the screen than is sent to the bank.
2.2
how are tans generated
Several methods were established to distribute or create TANs. Each tried to fix
issues with previous methods and after an adoption period to each method new attacks have been found. In the following some current methods will be introduced.
A short summary of further methods can be found at [Borb].
Figure 2 tries to order those methods in two categories: security and usability.
While using only a PIN is very easy to use it is also very insecure. iTANs lists are
relatively unmanageable but provide better security than no TAN. The photoTAN
method provides good usability but has security issues if the smartphone gets
infected with malware. A better way would be to use the SIM card as secure
storage. SIM cards are managed by network providers so it is less easy to set up
because two companies are involved and there will be organisational overhead.
Mobile TANs are also prone to malware on smartphones but are relatively easy to
set up. ChipTAN is considered a very secure method because debit cards provide
a secure storage and TAN generators are hard to compromise. Although in order
to use chipTAN users do need to carry an extra device around. NFC-TAN provides
a good usability by using a smartphone for authentication together with a debit
card as secure storage.
2.2.1 TAN / iTAN List
When online banking was introduced probably most banks used simple lists of
pre-generated TANs which were sent to customers in a letter. With each transaction customers choose any TAN from that list for authorisation. The bank then
checks if that TAN was a number from the list sent to the customer and could acknowledge or deny that transaction. An outline of this simple procedure is shown
in fig. 3.
With an increasing number of phishing attacks13 where customers were tricked
in giving out TANs to adversaries banks soon introduced indexed TANs – iTANs.
With iTANs the bank demands a specific number from that list for a specific transaction. This makes an attack harder since the attacker does not know in advance
which iTAN will be required. Thus phishing attacks where stolen TANs are used
to authorise transactions are made more difficult. The introduction of this system
initially had a significant effect on cybercrime statistics. In Germany the number
of phishing cases dropped about 57%14 when this system was introduced. How11
12
13
14
See section 7.2
Figure adopted from Dr. B. Borchert, University of Tübingen, 2013
See section 7.2 on page 58
From 4164 in 2007 down to 1778 in 2008.
5
Security
secure
ChipTAN
little risk
NFC-TAN
medium risk
PhotoTAN a)
high risk
PhotoTAN b)
mTAN
iTAN
insecure
PIN only
Usability
a) credential on SIM card
b) credential in application memory
Figure 2: Comparison of TAN methods for online banking12
PC
Bank
TAN List
1
2
3
4
5
Figure 3: 1 create transaction; 2 request TAN; 3 customer chooses a TAN
from list; 4 send TAN to bank; 4 transaction successful
6
ever after this initial drop attackers adopted rather quickly and the number of
cases and total amount of money stolen rose again15 . This shows that also with
iTANs customers are not safe from attacks like Man-in-the-Middle16 . A weakness
of both systems is that when letters with those lists are stolen. An attacker is then
able to authorise as many transactions as are TANs on that list.
With the advent of mobile computers and people wanting to do online banking
away from home, TAN lists became very unhandy because they always had to be
carried around. This also made them easier to get stolen. For some years now
working attacks have shown17 that iTAN lists can be considered to be insecure.
2.2.2 mTAN
Because of growing security problems with TAN lists and their poor usability,
banks introduced mobileTAN (mTAN) or smsTAN. Most people today have access
to mobile phones18 so it is possible to send TANs to customer’s mobiles when a
transaction is made. Figure 4 shows the basic steps for placing a transaction. The
main difference to fig. 3 is the source of the TAN. Here the TAN is sent to the
customer just after a transaction had been created and only the currently needed
TAN is created.
PC
Bank
Mobile Phone
1
2
3
4
5
6
Figure 4: 1 create transaction; 2 request TAN; 3 bank sends a SMS to phone;
4 enter TAN in online banking form; 5 send TAN to bank; 6 transaction successful
This was believed to be more secure because no paper lists could be stolen and
also pre-generated TANs for future use don’t exist. Statistics by the BKA19 show
that after mTAN had been widely adopted a decline in phishing attacks in online
banking of about 40% was noticed20 . TANs could not easily get stolen because
customers did not have any laying around. Only the currently needed TAN is
send to the customer.
Man-in-the-Middle attacks where the computer had been compromised and
showed false transaction data were countered by sending not only the TAN to
15
16
17
18
19
20
See [BKA11]
Man in the Middle attacks are described in section 7.5.1 on page 60
See [SH] and [Red]
[Rob]
BundesKriminalAmt (Federal Criminal Police Office)
See [BKA12]
7
the customer but also the recipient and amount. Customers were then able to
verify the transaction data before entering the TAN. If a mobile phone gets stolen
similar attacks are possible as were with stolen TAN lists. People tend to pay more
attention to their mobile than to a sheet of paper so a stolen mobile gets locked
fairly quickly by the owner and no TANs can be received anymore.
With mTANs attackers are provided new attack vectors. Possible attack targets
are SIM cards, mobile phones or the communication channel which is very often
GSM. Some examples on how these attacks could work are outlined section 7.1.2
and section 7.3.
2.2.3 crontoSign
In search for new and more secure methods to authorise online transactions, a
team of the University of Cambridge developed a new protocol to generate transaction numbers — called crontoSign21 . Goal was to develop a method that is easy
to use and yet not frail to a Man-in-the-Browser attack22 . Developed in cooperation
with the German Commerzbank crontoSign has recently been sold to a company
specialising in authentication products23 . This shows that interest in secure TANs
is still high. Commerzbank renamed crontoSign to photoTAN24 .
Figure 5: photoTAN reader and crontoSign application
The idea behind photoTAN is that a different device is used to generate a TAN
than is used to create transactions. TANs are created by the customer alone and are
only send to the bank as an authorisation code. Banks do not need to send TANs to
customers which removes the risk of stolen or captured TANs. One advantage of
crontoSign is that a smartphone is used to generate TANs. Smartphones are widely
adopted and users usually always have their smartphones at hand. Also do they
provide powerful hardware which makes it easy to run more difficult algorithms.
The fact that people often have their phone at hand means that in fact no additional
device for online banking is needed. People not having a smartphone can use a
21 See http://www.cronto.com/ and
http://www.cam.ac.uk/research/news/new-system-to-combat-online-banking-fraud
22 Man in the Browser attacks are described in section 7.5.2 on page 61
23 http://www.businessweekly.co.uk/hi-tech/15425-cambridge-university-spin-out-soldfor-22m/
24 http://www.cronto.com/commerzbank-and-cronto-launch-phototan-for-secure-onlinebanking-transactions.htm/
8
special device25 which runs the smartphone application — however mitigating
the advantage of not needing another device to carry around. Using two separate
devices to create a TAN is called a two-channel-authentication.
To generate a TAN the bank shows the customer an image in which transaction
data is encoded. A smartphone with a crontoSign application then decodes this
image and displays data for customers to verify it. Together with the transaction
data a TAN is generated and displayed. If everything seems to be correct customers enter the TAN in the online banking website and authorise the transaction.
This process is outlined in fig. 6. If data had been altered by malware on the
computer customers are able to notice this because the modified transaction data
would be shown on the phone’s display.
PC
Bank
Mobile Phone
1
2
3
4
5
6
Figure 6: 1 create transaction; 2 display picture-code; 3 scan code; 4 display
TAN and transaction data; 5 enter TAN; 6 transaction successful
Another way of implementing crontoSign has been described in [BG13]. There
banks create a TAN when customers initially create a transaction. This TAN together with the transaction data is encrypted with a secret key which is stored on
the customers smartphone. The encrypted data is shown on the website encoded
in an image. An application on the smartphone then decodes and decrypts this
image and displays all containing data, which includes the TAN.
Either way malware on the smartphone poses a threat because the secret key
is always stored in application memory on the phone. Malware which is able to
access that data can also use or copy the secret key. SpyEye has shown that smartphones are prone to malware attacks26 . Once infected with malware phishing or
Man-in-the-Middle attacks are also possible on the smartphone27 .
25 Figure 5 shows the hardware reader and smartphone application.
26 see [Hey]
27 See chapter 7 for more about attacks on smartphones.
9
2.2.4 chipTAN
A different approach to counter problems with iTAN letters was made with the
chipTAN method which has been introduced shortly before crontoSign28 . It is also
a two-channel authentication method with an additional device – called TAN generator or HHD29 shown in fig. 7. The difference is that the key used to generate
a TAN is not stored in the device itself but instead the customer’s debit card30 is
used as secure storage.
As before the user fill out a transaction form at their online banking website. After that a number – called
startcode31 is displayed which then
has to be entered in the TAN generator. This startcode contains some
information about the type of the
transaction and a random number –
Together with the startnonce32 .
code the user enters the transaction
data, e.g the amount and recipient
into the TAN generator. With this
information and a debit card the device can generate a TAN which is displayed.
A summary of the protocol is shown
in fig. 8 and will be described in detail
in chapter 5. All details of this process
are described in the SECCOS Specifications33 which are available from the
Bank Verlag34 for a fee35 .
Figure 7: chipTAN comfort
TAN generator
Because the exact specification of
this protocol are not publicly available,
some groups started to look at the communication between reader and cards and
attempted to reverse engineer this protocol with some insightful results. These
groups were namely [Ccc], [Fix06], [BF07] and [Zue]. Some of their results are
used in chapter 5.
28 ChipTAN has been introduced around 2006 even though many features like the optical interface have been introduced until 2010. CrontoSign started development in 2008 – http://www.
chipcardmaster.de/smarttanchiptan.htm
29 HandHeld Device
30 EC - electronic cash - is a debit card system by the Deutsche Kreditwirtschaft (DK) which uses
ISO/IEC 7814 smartcards.
31 Startcodes are further explained in section 4.7.1
32 Number used Once - a random number which is only used once.
33 Schnittstellenspezifikationen der ZKA-Chipkarte
34 http://www.bank-verlag.de/
35 This is not a licence fee but the fee for the login to the download page.
10
PC
Bank
TAN Generator
Card
1
2
3
4
5
6
7
8
9
10
Figure 8: 1 create transaction; 2 display flicker- or startcode; 3 scan/enter
code; 4 send transaction data to card; 5 return cryptogram; 6 calculate TAN from cryptogram; 7 final TAN; 9 enter TAN into online
banking website; 9 sent data to bank; 10 transaction successful
bit 4 / 8
bit 3 / 7
bit 2 / 6
bit 1 / 5
clock
To further improve usability a different way of getting transaction data into the
TAN generator was developed called Flickercode36 . After filling out a transaction
form on the website an image is shown which contains five stripes that switch
between black and white as seen in fig. 9. Flickercodes are described in detail
in [Sch09] and [Fli]. The TAN generator is modified to read this Flickercode and
so data can be transferred from the computer to the TAN generator without having
to enter them manually. Transaction data is shown in the display of the device and
can be verified by the customer. If it is correct a TAN is calculated and displayed.
Because rapidly flickering images can cause problems with people with epilepsy
the manual method of entering data is alternatively provided.
Figure 9: Flickercode image: first bar gives clock signal, then every clock four bit
are transmitted. With that in two clock cycles one byte can be sent.
Attacks on chipTAN seemed not possible since the secret needed to create a TAN
is stored securely on a chip card. An attacker would need not only credentials to
36 The corresponding TAN methods are called chipTAN comfort or sm@rtTAN
11
the victim’s online banking website but also access to the debit card. Some known
attacks do not attack the smartcard or TAN generator but rather exploit the size
of the small display of the generator and with that the limitations and decisions
what data to show to customers37 . These are typically Man-in-the-Middle or Manin-the-Browser attacks which are described in section 7.5.1 on page 60.
2.2.5 NFC-TAN
NFC-TAN is a new way of approaching challenges with current TAN systems and
was developed by [BG]. The idea is to use NFC debit cards and a NFC smartphone
to generate TANs for online banking and so providing a method with good security and good usability. Since smartphones with NFC capabilities are getting more
common38 and NFC debit cards are already being rolled out39 these requirements
should be met in the near future40 .
Figure 10 on page 13 shows all parties involved in creating a TAN which are
similar to chipTAN41 . After logging in to the banks website information about
a transaction needs to be transferred from a PC to a smartphone. This is either
done manually be the user or by scanning a QR-Code. The phone then communicates with a NFC smartcard to calculate the corresponding TAN which will be
displayed on the phones display together with all transaction data for verification.
If all checks out to be correct the user enters the TAN in the banks website and
authenticates the transaction.
A more detailed view of the NFC-TAN protocol is shown in fig. 11. To illustrate
this a use case is used. To successfully complete a transaction a customer – Clara
needs to log in into her online banking account 1 . The bank server checks her
credentials and then provides access to the online banking forms 2 . She then
puts in the information to the transaction she wants to make 3 and receives a
startcode42 4 . This startcode can be coded, for example in a Flickercode43 , in a
QR-Code44 or just be given as plain number. Then she uses the NFC-TAN application on her smartphone 5 and enters the startcode and transaction data45 in
the NFC-TAN application on her smartphone. Now Clara needs to hold her NFC
debit card close to the phone. The phone starts sending the startcode and all transaction data to the card via NFC in several steps 6 and at the end receives a byte
string – called application cryptogram 7 . On this cryptogram some operations
are performed 8 and with that in a last step 9 a TAN is calculated46 . This TAN
is shown on the phone’s display together with the original transaction data to let
37
38
39
40
41
42
43
44
45
46
See [Pen09]
[iSu]
[Han]
Although these NFC debit cards do not yet provide the same applications, e.g. the TAN application
over the NFC interface than over the contact-based interface.
For chipTAN see section 2.2.4
Details of the startcode are explained in section 4.7.1 on page 29.
See section 2.2.4 on page 10
[ČBA12] would be one example coding.
Which data exactly is needed depends on the type of transaction and is indicated by the startcode.
For simple wire transfers only the recipients account number and the amount is needed.
We want to note here that steps 6 and 7 are simplified here for the purpose of giving a more
compact summary. These steps consist of 10 separate communication steps which will be discussed
in detail in chapter 5 on page 31
12
a
Recp 12437
Recp
12437
123.45
Am 123.45
Am
Txt Rent
Rent
Txt
TAN
Bank
PC
b
d
Recp 12437
Am 123.45
Txt Rent
TAN
NFC Card
c
Smartphone
Figure 10: a login to online banking; b scan QR code with smartphone; c use
NFC card to generate TAN; d enter TAN in online banking website
13
Clara verify if this is the transaction she intended to do. If everything is correct
she then enters the TAN in the web browser on her PC 10 which then sends it to
the bank server as an authorisation for the transaction 11 . On the bank side the
same TAN had been calculated47 and is compared to the TAN received from Clara.
If it checks to be the same the transaction is acknowledged 12 . One modification
of this process would be to let the phone sent the TAN directly to the bank after
Clara checked if the transaction data is correct. This way Clara doesn’t need to
enter the TAN manually in the online banking form. More on NFC-TAN can be
found in [Sat12, chap. 4] and [BG13].
PC
Bank
Phone
Card
1
2
3
4
5
6
7
8
9
10
11
12
Figure 11: 1 login at bank; 2 success; 3 create transaction; 4 startcode; 5
startcode + transaction data; 6 startcode + transaction data; 7 application cryptogram; 8 generate TAN; 9 TAN; 10 TAN; 11 TAN;
12 transaction successful
Compared to mTAN or photoTAN more security is gained by separating the
device which generates TANs from the device which stores the secret key used
to generate them. In this way it is similar to chipTAN but with added usability
because customers do not need to carry around another device.
47 This is possible since the bank also possesses the secret stored on the debit card. In reality several
TANs are generated on the bank side because the cards TAN depends on an internal counter. Details
will be shown in section 5.2
14
3
N F C S M A RT P H O N E S A N D N F C C H I P C A R D S
NFC is a technology which is mainly developed by the NFC-Forum1 founded
in 2004. Although first specifications have been available since 2006 it took a
relatively long time until enough NFC devices were available to make an impact
on the market. In the last years many new smartphones were introduced which
have built-in NFC capabilities and this trend seems to continue2 . Except Apple,
all major smartphone manufactures and operating systems support NFC. Android
seems to have a leading role here with the most NFC devices3 .
One core technology of this project is NFC4 . And to reach the goal of implementing the NFC-TAN method introduced in section 2.2.5 hardware which supports NFC is needed. Namely a chip card which is accessible via NFC and a
smartphone which is NFC capable — creating a simple setup as shown in fig. 12.
NFC Smartphone
NFC Debitcard
Figure 12: Original NFC-TAN with NFC smartphone and NFC debit card
When developing for smartphones it usually starts with the question which
platform to develop for. Android or iOS are the obvious choices sine they have the
biggest market share5 . Android the operating system (OS) of choice in a previous
work about NFC-TAN done by [Sat12]. In this project iOS is chosen to show that
NFC-TAN does not depend on Android but can be ported to any smartphone OS.
This choice however brought some challenges that needed to be solved.
In order to use NFC-TAN we were faced with two challenges. One issue is the
fact that current debit cards do not support the generation of a TAN via the NFC
interface6 . And a second one is that iOS currently doesn’t feature NFC natively.
1 http://www.nfc-forum.org
2 http://blogs.synopsys.com/theeyeshaveit/2012/03/26/non-volatile-memory-technologyfor-nfc-enabled-smartphones/
3 http://en.wikipedia.org/wiki/List_of_NFC-enabled_mobile_devices
4 Near Field Communication
5 http://www.statista.com/topics/876/android/chart/1366/smartphone-os-market-share/
6 Currently only the digital wallet application is supported.
15
3 nfc smartphones and nfc chip cards
The first point is more an organisational than a technical one. Debit cards currently issued already feature an NFC interface and also support the TAN application via a contact based interface. Having this it is only a matter of access rights
to also make the TAN application accessible via NFC. No hardware changes are
necessary and software changes are minimal. Because those software changes
can only be done by the banks who issue those card an alternative was needed.
[Sat12] developed a java card called eKaayDebitCard which implements the TAN
application according to the same specifications as regular debit cards as closely
as possible and also providing a NFC interface. Using these eKaayDebitCards it
is possible to simulate how the entire system would behave if a regular NFC debit
card from a bank were available. Figure 12 on page 15 still applies but now the
NFC debit card is exchanged with a eKaayDebitCard.
The second issue – iOS not supporting NFC – has several possible solutions. A
way to connect an iOS device to a NFC card is needed.
One approach would be to use 3rd party accessories to provide NFC to iOS.
However while researching for suitable adaptors trouble was encountered with
either the availability or with the provided feature set. One adaptor7 seems to
provide all necessary functionality. Unfortunately it was not possible to find a reseller which sells the adaptor with SDK. Efforts trying to contact the manufacturer
directly were not successful. Emails weren’t answered and neither were calls.
Another solution tried was a crowd-funding project called FloJack by Flomio8 .
At first it looked promising because the SDK was already publicly available and
shipment was supposed to start in April 2013. Problems in production delayed the
shipment until late fall 2013 so that until now only a couple have been shipped.
Reviewing the SDK revealed that the current FloJack firmware does not support
all NFC features and especially not communication with ISO/IEC 7816-4 APDUs9
which is necessary for this project.
A third way would be to use a card reader which connects via bluetooth to the
smartphone. Such a NFC reader has recently been announced as a developer device from ReinerSCT10 . Unfortunately it has only become available in late August
so there was no time to evaluate this solution. Figure 13 on page 17 shows how
the original idea of NFC-TAN would change when the smartphone doesn’t support NFC. Either a NFC hardware adaptor needs to be used to connect to a NFC
debit card or a card reader which can be connected wirelessly to the smartphone.
Application software on the smartphone using NFC needs to be designed then to
use this simulated NFC reader instead of a native reader.
Having no direct approach to use NFC on iOS an indirect way to connect to
a card reader was needed and for that a proxy pattern11 was chosen. The proxy
server is connected to a physical card reader and provides a web interface. When
a client send data to the web interface the proxy forwards all data to the card
reader. The mobile client can then communicate with a card as if it were locally
connected. An application on the smartphone can send and receive data via WiFi
7
8
9
10
11
iCarte http://www.icarte.ca
http://flomio.com/flojack/
At least not directly.
http://www.reiner-sct.com/produkte/chipkartenleser/cyberjack_wave.html
See [Gam09]
16
Smartphone
NFC Debitcard
Smartphone
Bluetooth Cardreader
Figure 13: When smartphone doesn’t support NFC other ways of connecting to the
NFC debit card have to be found; here bluetooth or hardware dongles.
to the card reader. More details about design and implementation of this proxy
are found in chapter 6 on page 41.
In fig. 14 we see how this double simulation looks like. On one side a NFC debit
card is simulated using by a eKaayDebitCard and on the other side a local NFC
reader is simulated by using our proxy server approach.
Smartphone
Proxy
USB Cardreader
Figure 14: NFC-TAN when both smartphone and debit card are not NFC capable.
A proxy is used to connect phone to card.
This proxy provides the possibility to connect any card to the phone – NFC or
contact based smartcards. To show the flexibility of this approach besides NFCTAN another TAN method is implemented chipTAN. This is useful because regular debit cards can be used additionally to the also supported eKaayDebitCards.
Although contact based readers for smartphones exist12 , these companies only
sell a service and not hardware which means that it is not possible to get access to
the API of the hardware card readers.
12 https://www.izettle.com or
https://sumup.de/
17
4
S TA N D A R D S , N O R M S A N D S P E C I F I C AT I O N S
Different technologies are used in this project and with that we come in contact
with even more standards, norms and specifications describing and defining those
technologies. This chapter will introduce some of them and point out why and
how they are important for this project. We won’t however go into the details of
differences between these three terms1 and just take them as something that needs
to be fulfilled in order to create a working application. All three terms will here
be used interchangeably and without semantic difference.
To list all involved standards and describe them thoroughly would be out of
scope and could possibly distract from the goal of giving information needed for
the following chapters. Though all necessary standards will be mentioned and
relations between them shown. Because some standards are not publicly or freely
available, references about those standards are used. Most information is taken
from [RE08] who provides a complete introduction chip cards in general and also
to standards in particular. CardWerk Technologies2 provide comments about parts
of ISO/IEC 7816 which are helpful. Being a bit older [Eve92] still applies and
gives information about chip cards and standards used here. Although here note
covered, one might find useful details about otherwise non accessible information
in the GSM specifications3 because chip cards used for debit cards and SIM cards
used in mobile phones are very much alike.
These standards can be categorised in two different fields: one describing chip
cards and the infrastructure around them and the other being standards from the
banking sector describing procedures and business processes. ISO/IEC standard
family 7816 and here especially parts three and four describe how we can access
contact cards and how data is organised on them. ISO/IEC 14443 does similar
things for contact-less – or more precisely proximity coupled cards. NFC uses
these standards and further refines its usage in ISO/IEC 18092 and some specifications by the NFC forum4 . The physical implementation of data transfers either
in contact or contact-less cards are left out. They are not essentially necessary for
implementation or to understand how it functions. A good introduction to the
physical layer of contact-based cards can be found in [RE08, chap. 3-5] and for
contact-less cards in [Fin08] and also [RE08, chap. 10]. From the banking sector we
are mainly concerned with specifications by the German Banking Industry5 . Devices used for chipTAN their protocols and commands are specified in the HHD6
specifications.
1
2
3
4
5
6
This is done in [Fin08, p.11]
http://www.cardwerk.com
See [ETSI]
http://www.nfc-forum.org
http://www.hbci-zka.de/
HandHeld Device
19
4.1
iso/iec 7816
This series of standards describes the main characteristics of contact based chip
cards and is build on [ISO/IEC 7810] in which identification (ID) cards are covered. [ISO/IEC 7810] defines physical dimensions of most of our every day plastic
cards, from SIM cards to credit cards and more. The most common form factor
is the ID − 17 format which is also the format of the cards used here. ISO/IEC
7816 part 1 and 2 describe the physical properties of chip cards and where the
electrical contacts are placed. Those standards are mainly of interest for chip
cards manufacturers or hardware experiments with chip cards. More relevant for
the development of this application are parts 3 and 4 where transmission protocols, data organisation and commands to and responses from cards are described.
[ISO/IEC 7816-8] defines some commands for security operations additionally to
part 4. Other parts are of less significance for this project because features described there are not or not yet used for online banking.
4.2
iso/iec 7816-2
This part “specifies the dimensions and locations for each of the contacts”8 on a
chip card. In the experiment in chapter 5 this is used to correctly connect the
probes to the contacts. Eight contacts are specified (C1 - C8) and shown in fig. 15.
Figure 15: Contacts of a chip card
C4 and C8 are called auxiliary contacts and were reserved for future use. Today
that future has come and they are used for either connecting an USB interface, an
antenna for contact-less systems or other applications. If manufacturing costs need
to be cut chips with only six contacts can be produced and still comply to ISO/IEC
7816. Early chip cards had an EEPROM9 chip which could be reprogrammed.
Today’s chips don’t have this EEPROM chip and so this contact is open for other
7 ID-1 defines dimensions of 85.60 × 53.98 × 0.76mm.
8 [ISO/IEC 7816-2, abstract]
9 Electrically Erasable Programmable Read-Only Memory
20
4.3 ISO/IEC 7816-3
use. On NFC cards this contact can be used to connect an NFC controller via
SWP10 . Table 1 lists each contact with its short name and the function it has11 .
Contact
C1
C2
C3
C4
C5
C6
Name
Vcc
RST
CLK
AUX1
GND
Vpp
C7
C8
I/O
AUX2
Function
Provides power to the chip.
Reset line - used to request reset sequence.
Clock signal for the chips processor.
Auxiliary contact 1.
Ground line.
Provides power to program a chips EEPROM. Today used for other
purposes like SWP.
Data channel for half-duplex communication
Auxiliary contact 2.
Table 1: Name and functions of contacts of a chip according to ISO/IEC 7816-2
4.3
iso/iec 7816-3
ISO/IEC 7816-3 describes the electrical interface and transmission protocols of
chip cards. It defines which voltages and currents are to be used and what data
is transmitted over the electrical contacts defined in part 2. Chip cards according
to ISO/IEC 7816 can transmit data with different protocols. Currently there are
15 different protocols standardised although T=0 and T=1 are primarily used12 .
Communication is also possible with protocols not defined in this standard like
USB13 or SWP14 but those are not yet widely adopted.
4.3.1 Protocol T=0
T=0 is a byte-oriented protocol which means that every operation it does is done
on bytes. If during a transmission an error occurs the last byte has to be retransmitted. To recognise transmission errors a parity bit is send after each data byte. Each
command according to T=0 has class, instruction and parameter bytes followed by
optional data bytes as shown in fig. 16. This makes this protocol fast and efficient
because commands are only as long as necessary. Difficulties can arise when handling encrypted data. Even if data bytes are encrypted the header bytes – class,
instruction, parameters and especially length value have to be unencrypted. One
example where this protocol is used are GSM SIM cards. A thorough introduction to T=0 gives [RE08, chap. 9.3.1] and further standards describing T=0 are TS
51.011, TS 102221, EMV 15 .
CLA INS
P1
P2
P3
Data
Figure 16: Structure of a block according to T=0
10
11
12
13
14
15
Single Wire Protocol see [RE08, chap. 9.6]
See [RE08, chap. 4.1] and [Car]
See [RE08, p. 276]
Universal Serial Bus – see [RE08, chap. 9.4]
Single Wire Protocol – see [RE08, chap. 9.5]
See [EMV; ETSI]
21
4.3.2 Protocol T=1
In contrast to T=0 is T=1 a block oriented protocol which allows a strict separation of data link and transport layer of the ISO/OSI model16 . This in turn enables
an easier implementation of secure messaging techniques because the application
layer does not need to consider requirements of the transport layer. Another advantage of this protocol is that it has the ability to chain blocks together to send
data which would otherwise not fit into a single block. A disadvantage is that for
the added features more memory is needed on the card and since more protocol
data is transmitted this protocol is slower than T=0.
Each block has a defined structure consisting of three parts – a prologue, an
optional information field and an epilogue. The prologue contains a node address
byte (NAD), a protocol control byte (PCB) and a length byte (LEN). The following
information field containing an APDU is optional for this protocol. At the end an
error detection byte (EDC) is added. Figure 17 shows the structure of a full T=1
block.
NAD PCB LEN
APDU
EDC
Figure 17: Structure of a block according to T=1
In our case the NAD byte is unused and always 0. The PCB specifies which
type a block has. In T=1 three types are defined: information – I blocks, ready
receive – R blocks and supervise – S blocks as are described in [Eve92, part 6]
and [RE08, chap. 9.3.2] with information blocks being the most common. They are
used to send and receive data, R blocks are used as an acknowledge message when
block chaining is used and S blocks set protocol control parameters or handle error
conditions. The last field in the prologue is the LEN byte which states the length
of the information field in number of bytes. If no information is being transmitted
LEN is considered 0. Since LEN is only one byte the maximum length of the
information field is 254 bytes17 . Because of the block chaining mode, however
there is no limitation on how much data can be sent.
If present the information field usually contains an APDU which will be introduced later but any information type can be transported. The length of the
information field is variable and is indicated in the information field size (IFS).
Card and reading device each have their own IFS which means they accept different information field lengths. For the device this is called IFSD (IFS Device) and
respectively IFSC (IFS Card) for the card. Both are defaulted to 32 byte and limited
to 254 byte.
The IFSC can be changed to a different value during start up when the card sends
an ATR18 . If the IFSD needs to be changed an S block with the corresponding flags
set in the PCB byte can be send to the card. In the this case the information field
contains the length of future information fields in I blocks.
The epilogue field contains error detection information about all previous bytes.
Two error detection algorithms are allowed: longitudinal redundancy check (LRC)
16 ISO/IEC standard 7498-1:1994
17 The value FF16 (25510 ) is reserved for future use.
18 See section 4.3.3
22
4.3 ISO/IEC 7816-3
and cyclic redundancy check (CRC)19 . When using LRC the XOR20 sum over all
previous bytes is computed and used as EDC. Because this is very fast and sufficient accurate for contact-based communication, it is the standard method used
for error detection. When using CRC more errors can be detected but two bytes
for EDC have to be used which increases the protocol overhead.
4.3.3 ATR
ATR is an abbreviation for Answer To Reset. When a card is inserted into a reading
device one of the first things the reader sends to the card is a signal on the reset
line C2. “A card reset is initiated by the interface device, whereupon the card shall
respond with an Answer to Reset[...]”21 . This ATR contains information about the
capabilities of the card and which communication parameters it supports as well
as some proprietary data. Since an ATR contains information about transfer protocols and parameters, it needs to be ensured that all readers are able to correctly
receive and interpret an ATR.
An ATR consists of five parts22 : initial character (TS), format character (TO), interface characters (TAi , TBi , TCi , TDi ), historical characters and a check character.
TS is used to determine what coding is used and provides a way to determine
the transmission rate. After the TS a format character (TO) is sent. It provides information about and links to following bytes and specifies how to interpret them.
For instance, it states the number of historical bytes. TS and TO are mandatory to
be sent, interface characters however not. They describe transmission parameter
and available protocols of the card like voltages and timings. It is optional to sent
them because for every parameter default values exist which will be used otherwise. Not sending the interface characters can speed up the initialisation process
of the card since less bytes have to be transmitted. The exact meanings of those
values can be looked up in [RE08, chap. 8.1] and [Eve92, part 4]. [Rou] provides a
tool which parses ATRs, decodes the data contained and visually processes them
for easier viewing. Some special values in the experiment in chapter 5 on page 31
are TA3 which describes the cards information field size (IFSC) and TD2 which
specifies T=1 as transmission protocol. More examples can be found in [RE08,
chap. 8.1.6]. Historical characters (Ti, TK) are optional as well. Their contents are
not specified in ISO/IEC 7816-3 but were later added to part 4 of the standard.
Amongst others are they providing information about the cards features, operating system or serial numbers. At the end a check character (TCK) may be sent
depending on the transmission protocol used. With T=1 a XOR checksum is calculated and used as TCK. If T=0 is used this is not needed because every byte
already has a checksum according to the protocol definition.
19
20
21
22
For more on coding theory see [Hau10] or [RE08, chap. 6.5.2]
logical eXclusive OR
ISO7816 3.2.b according to [Car]
An example of an ATR is give in chapter 5
23
4.4
iso/iec 7816-4
This part of the standard family describes commands to and responses from cards,
how data can be retrieved from cards, a structure of the earlier mentioned historical bytes in the ATR, structure, identification of and access to files and applications
on cards, a security architecture for files and data including secure messaging and
other details about how data is stored on and can securely be accessed from the
card23 .
Most relevant for this project is the part of ISO/ICE 7816-4 where commands
and response objects are defined. These application protocol data units – APDUs
are used to send commands to cards and return responses. Two different types
can be distinguished: command APDUs (cAPDU) send from the reader to the card
and response APDUs (rAPDU) which are sent from card to the reader.
4.4.1 Command APDU
Command APDUs are fully described in [ISO/IEC 7816-4] and are composed of a
fixed-sized mandatory header and a variable-sized optional body. The four bytes
of the header are a class instruction byte (CLA), an instruction byte (INS) and two
parameter bytes (P1, P2). A complete body field consists of one length byte Lc
which states the number of following data bytes, data bytes and another length
byte Le which says how many data bytes are expected in the response. A cAPDU
with all fields is shown in fig. 18.
CLA INS
P1
P2
Lc
Data
Le
Figure 18: Structure of a complete command APDU
CLA
The CLA indicates to which standard this command belongs to. APDUs are used
not only for ISO/IEC 7816-3 protocols but for various others. Some examples are
A0 indicates a GSM command, 8X a proprietary or a secure messaging command,
D0 to FE proprietary, and 0X, B0 to CF ISO/IEC 7816-4 commands. A more complete list is found in [ISO/IEC 7816-4]
INS
This byte specifies the actual command which is going to be executed by the card.
According to [ISO/IEC 7816-4] commands 00 to 7F are defined in ISO/IEC 7816-4,
the remaining are to be defined by JTC 1 SC 1724
P1, P2
These bytes provide parameters for the command. If no parameters are used they
are set to 00.
23 See [ISO/IEC 7816-4, scope]
24 Joint Technical Committee of the ISO and IEC, Subcomittee 17 – Cards and personal identification.
24
4.5 ISO/IEC 14443
Lc
If data is transmitted Lc indicates how many data bytes the data field contains.
It is usually one byte long, although the standard provides the possibility to use
three byte long Lc fields. In this case the first byte is used as an escape sequence.
Data
After the Lc field follow the data bytes. On this layer no information about the
contents is either needed or known.
Le
Le describes how many data bytes are expected in the response from the card. This
again is optional and can be omitted if no data is expected. 0x00 indicates that
the maximum allowed is expected. Le is usually one byte long but also three byte
Le fields are allowed. The first byte then is escaped leaving two bytes for length
information similar to the Lc field.
Since parts of a cAPDU are optional, ISO/IEC 7816-4 states four different cases
of a cAPDU. Case one consists of just the header with no body. Case two has,
additionally to the header a Le field. Case three contains a data field and a Lc field
to specify the length of the data. Case four has all available fields and is shown
in fig. 18. This information can be found in [RE08, chap. 8.3.1] in more detail.
4.4.2 Response APDU
Each cAPDU sent to a card is answered with a response APDU. The structure is
simpler and shown in fig. 19.
Data
SW1 SW2
Figure 19: Structure of a response APDU
If the command produced response data this is sent back with the first bytes
of the rAPDU. If an error occurs during the execution of the command no data is
transmitted. Status words SW1 and SW2 – also called return code give information
about the result of the execution. All return codes are listed in [ISO/IEC 7816-4]
although some are reserved to be used proprietary. Return code 9000 or 61XX
indicate a successful execution, others specify if and what kind of error occurred.
This again is also described in [RE08, chap. 8.3.2].
4.5
iso/iec 14443
So far we covered standards for contact-based systems. ISO and IEC provide standards for contact-less systems which are divided into three groups based on their
range of coverage. ISO/IEC 10536 describes close coupling cards (CICC) with coverage of 1 cm while ISO/IEC 15693 describes vicinity coupling cards (VICC) with
a range of about 1 m. ISO/IEC 14443 is the basis for NFC and describes proximity
coupling cards (PICC) with a specified range of about 10 cm. Throughout this
25
standard the reading device is called PCD – Proximity Coupling Device. The card
is usually referred to as PICC – Proximity Integrated Circuit Card.
Physical characteristics are covered in part 1. The signal interface and properties
of the radio frequency field are described in part 2. Because members of the
working group writing this standard could not consent on one protocol used, two
types have been taken into the standard – Typ A and Typ B which are different
in their anti-collison methods and the codings they use. Part 3 covers detection,
initialisation and anti-collision methods, information structures similar to an ATR
of contact cards as well as other communication parameters. Part 4 describes a
half-duplex transmission protocol which is designed for contact-less environments.
This standard is not available for free so we took our information from a publicly
available draft [Wg8] of the working group 8 and from [RE08, chap. 10.9]. A short
introduction of this standard family can be found in [Plö08].
4.5.1 ISO/IEC 14443-3
Part three of ISO/IEC 14443 describes procedures of the initialisation of cards and
anti-collision methods. Although the standard defines two different types of cards
the basic principles are similar. Here the similarities rather the differences are
emphasised.
Contact-less cards deal with more difficulties and have to consider different
scenarios than contact-based cards. Some of the added complexity deals with the
fact that multiple cards could be in the readers area of operation thus effective
anti-collision methods have to be used. Another scenario to consider is how to
behave if one card connects to the reading device while another is already active25 .
Also multiple cards with multiple applications can be active at the same time.
What adds to the diversity is the fact that two different types of PICCs – Typ A
and Typ B need to be supported by PCDs. To support all this and provide a stable
environment for communication anti-collision and card identification methods are
described in this part of the standard.
The basic idea is that each PICC can be in a different state. Once a card comes
into the area of operation of a PCD, the cards processor is provided with power
and boots up. Right after that it enters an IDLE state where it only listens to certain
wake-up commands in order not to interfere with ongoing communication to other
cards. After it receives a wake-up command it enters a READY state and sends
some information about its capabilities to the PCD. Then an anti-collision process
starts after which the PCD send a select commands with the cards id (CID) and
the PICC enters and ACTIVE state in which communication is possible with the
protocol described in ISO/IEC 14443-4. After communication is done the PCD sets
the PICC into a HALT state which is similar to IDLE in that the PICC only listens
to certain wake-up commands. Details of this processes and differences between
types A and B are found in [RE08, chap. 10.9], [ISO/IEC 14443-3] and [Fin08]
25 The active state will be introduced shortly.
26
4.5 ISO/IEC 14443
4.5.2 ISO/IEC 14443-4
Once a PICC is initialised communication can begin. The communication protocol used is described in the fourth part of ISO/IEC 14443 which is similar to
ISO/IEC 7816-3 T=1 but optimised to the needs of a contact-less envrironment.
Both are asynchronous block protocols and are able of transporting ISO/IEC 78164 APDUs. Those similarities make it easier to develop dual interface cards which
support a contact-based and a contact-less interface to the same operating system
underneath. The communication protocol begins after a PICC is selected with a
SELECT command. PICCs of Typ A need to go through an activation sequence
where communication parameters are exchanged while Typ B PICCs can enter the
ACTIVE state directly. During the activation of Typ A an ATS26 is sent to the
PCD where the PICC states which protocol parameters it supports. The PCD and
PICC can then adjust these parameters – like bit rates and frame sizes to optimal
settings.
For this protocol the basic structure of a block has been take form the T=1
protocol as shown in fig. 17 and has been modified to a slightly different format as
shown in fig. 20. Also three block types are distinguished: I-blocks for information
transportation, R-blocks to acknowledge received blocks and S-blocks to change
protocol parameters. The block type is defined in the PCB byte at the beginning
of a block.
PCB CID NAD
INF
EDC
Figure 20: Structure of a block according to ISO/IEC 14443-4
This PCB together with the optional Card IDentifier (CID) and also optional
NAD bytes make up the prologue field. CID is used to send blocks to specific
PICCs. If a PICC receives a block with a CID which is different from its own it
ignores that block. A PICC may not support CID fields at all and then ignores all
blocks which contain a CID field. The NAD can be used to create logical channels
to different applications on one PICC. Information data is transported in the INF.
This could be any data format but in our case the INF contains APDUs as described earlier. The epilogue contains two error detection code bytes – EDC. With
contact cards there were two error detection code allowed, but since in contactless environments more errors are likely only a CRC27 code is allowed because
it is able to detect more errors than a simple XOR. A complete introduction on
this protocol with all details and parameters is given in [RE08, chap. 10.9], [Fin08]
and [ISO/IEC 14443-4].
26 Answer To Select. It can be compared to an ATR of contact cards.
27 Cyclic Redundancy Check, see [Hau10]
27
4.6
iso/iec 18092
The previous mentioned standards provide the basis for NFC which itself is described in ISO/IEC 18092. It defines which RF-fields28 to use, bit rates, codings,
bit representations, protocol and parameter selection and other details in order to
initiate a communication network between wireless devices. It also defines two
roles and two communication modes.
The initiator is the party which creates an RF-field and starts the communication,
whereas the target only responds to commands from the initiator. Those roles can
not change during the time of an ongoing communication.
Active communication mode means that initiator and target are generating each
their own RF-field and thus use those fields only for data transportation and not
to transport power. In passive communication mode the target doesn’t generate a
RF-field but uses the initiators field for power and data transport. Both communication modes differ in the way data is transported from the target to the initiator.
The complete standard is freely available online at [ISO/IEC 18092:2013].
4.7
hhd
Until now different technical standards have been introduced which describe specifications of the cards and communication protocols used. HHD (HandHeld Device) is a specification that describes what information should be transmitted when
interacting with a German debit card. These debit cards29 use a SECCOS30 operating system issued by the German Banking Industry31 . Descriptions of commands are collected in the HHD specifications also issued by the German Banking Industry32 . Some parts are publicly available like [Kre08]33 whilst others are
only closed34 like “Schnittstellenspezifikation für die ZKA-Chipkarte - HandheldDevice (HHD) zur TAN-Erzeugung”35 . The latter specification is central to generating a TAN and has been partially reverse engineered by [Ccc]. Commands used
and their parameters will be explained later in chapter 5. Here a look is taken to
the assignment guidelines because they give some information about startcodes
which will be used in the process of generating a TAN. As of writing the current
version of this specification is version 1.4. Unfortunately this version is not available on the homepage of the DK and during this project also version 1.3 has been
taking offline. It was possible though to save a copy of version 1.3 which will be
used here. Since these specifications have been written and published by the DK,
they apply only to the chipTAN method, so following information can be viewed
as an addition to section 2.2.4.
28 Radio Frequency Field – used to transport power and data.
29 Usually called ec-cards which stands for Electronic Cash are debit cards. They are similar to Maestro
by MasterCard and V-Pay by VISA.
30 Secure Chip Card Operating System
31 Die deutsche Kreditwirtschaft (DK) formerly known as Zentraler Kreditausschuss (ZKA) http://
www.die-deutsche-kreditwirtschaft.de
32 http://www.hbci-zka.de
33 Assignment Guidelines for dynamic TANs
34 They are available by signing a NDA an paying a fee.
35 Interface specifications for the ZKA chip-card - Handheld device for TAN generation.
28
4.7 HHD
4.7.1 Startcodes
The main use of startcodes is to bind a TAN to a specific transaction but the
specification also states that the use of such a startcode is optional.
Gemäß der HHD-Spezifikation V1.2 bzw. V1.3 des ZKA können in
die TAN-Berechnung ein von der Bank vorgegebener Start-Code und
weitere transaktionsabhngige Daten eingehen. Damit ist es möglich,
die Gültigkeit der TAN an eine bestimmte Transaktion zu binden. StartCode und Daten müssen über die Tastatur des HHD eingegeben werden. Ein Start-Code für die TAN-Berechnung besteht aus bis zu 8 Ziffern. Darüber hinaus können bis zu 12 Ziffern (bei HHD V1.3 auch
mehr) zusätzlicher Transaktionsdaten eingegeben werden.36
According to the ZKA HHD specification V1.2 and V1.3 a predetermined
– by a bank – startcode and other transaction related data can be used to
calculate a TAN. With that it is possible to bind the validity of a TAN to a
specific transaction. startcode and transaction data must be entered with the
keypad of the HHD. A startcode used for the generation of a TAN can consists
of up to eight numbers. In addition to that can up to 12 numbers (HHD V1.3
even more) of transaction data be entered.37
Because startcodes are issued by banks it is necessary to understand how to
read and use them for generating a TAN. [Kre08] defines 15 different challenge
classes for different types of transactions. Each class defines which transaction
information is requested from the user. To make the handling of those classes easier three patterns have been introduced. The startcode then tells the HHD which
transaction type it processes and which data will be used for TAN generation.
One example is the startcode 871. The first digit indicates a challenge class, in
this case 8X is used for TAN generation with basic data elements. In total eight
basic data elements are defined as shown in table 2. The following digits 71 state
which data elements are expected. In our example the user enters the startcode
871, then is asked by the HHD for the account number (7), then it asks for the
transaction amount (1) and finally returns a TAN.
Banks can ask for any combination of those basic data elements for a transaction.
Usually a nonce is added to the startcode to prevent pre-play attacks38 . Usage
of a nonce might seem optional with contact-based methods but in a contact-less
environment it is highly recommended to use a efficiently long and random nonce.
Although it is written that the startcode and all transaction data is to be entered
via the keyboard an additional method has been specified and is widely used —
the so called Flicker Code. This code uses an optical interface to transmit data from
a screen to a HHD. Details are not publicly available but have also been reverse
engineered by [Sch09]. Though interesting details won’t be discussed here because
this code won’t be used in this project. They are at length discussed in [Sch09],
[Fli] and [Ccc].
36 [Kre08]
37 [Kre08] Own translation
38 See section 7.5.3 on page 61
29
Number
1
2
3
4
5
6
7
8
Name
Betrag (Amount)
Kontonummer (Account number) Normal/IBAN
Online-Banking-PIN
Telefonnummer (Telephone number)
Bankdaten (Bank data)
Anzahl (Count)
Kontonummer (Account number) Normal
Kontonummer (Account number) IBAN
Table 2: Basic data elements according to
Belegungsrichtlinien für die Dynamisierung der TAN
4.8
emv
EMV stands for Europay, MasterCard and Visa which where the companies who
orginially founded EMVCo who has written specifications about payment methods with ISO/IEC 7816 chip cards, e.g. how to handle credit card payments is
defined here. Those specifications further define physical features and properties
of cards and terminals and also describe the type of messages exchanged. Using
ISO/IEC 7816-3 APDUs EMV specifies what commands exist, their parameters
and what responses are valid. EMV is divided in four parts called books. Book
1 describes mechanical and electrical properties of cards. Book 2 handles security
and key management. In book 3 application commands and their responses are
defined and book 4 describes what functions a terminal must support to being
able to read EMV cards.
These specifications apply to payments with the chip-PIN method39 which is
globally in use. Because of its wide use in the financial system, EMV also applies to
debit cards used in this project. Although we use a different application then chipPIN similar commands are used. Comparing what commands we see in chapter 5
with those described in EMV helps understanding the process of TAN generation.
39 Some notes about chip-PIN and security are give by [Mur11]
30
5
T H E B I R T H O F A TA N
In this chapter we want to take a look on how a TAN is generated with a current
standard ZKA debit card and a regular TAN generator. Regular German debit
card use SECCOS as operating system. A decission was made not get the SECCOS
specifications because that would mean signing an NDA and disclosing some of
the information about this project. Instead work of [Ccc] was taken and used as
a basis and their experiment repeated different hardware with. A reason for this
decision was the wish to document all steps and with that provide a basis for
others to repeat or carry on this work. For those interested the exact protocol is
defined in Schnittstellenspezifikation fur die ZKA-Chipkarte - Handheld-Device (HHD)
zur TAN-Erzeugung written by the DK1 and published by the Bank Verlag2 .
5.1
test environment
The set up was as follows: The debit card was a new card from the Sparkasse
Tübingen3 . Together with that card a TAN generator from the company Kobil4
was received. Since there were trouble successfully sniffing the traffic with this
reader a different reader was used from ReinerSCT5 which proved more reliable
for this purpose.
To connect the reader
to a PC the BusPirate
v3.6 from DangerousPrototypes6 was used.
All devices used are
shown in fig. 21 on
page 32.
In order
to see communication
data of the card and
reader we need to
connect contacts C3
(CLK), C5 (GND) and
C7 (I/O)7 of the chip- Figure 22: Soldered wires to contacts C3, C5, C7
module to the correof the TAN generator
sponding (CLK, GND,
1
2
3
4
5
6
7
http://www.die-deutsche-kreditwirtschaft.de/
http://www.bank-verlag.de/
https://www.ksk-tuebingen.de/
http://www.kobil.com/products/card-readers/optimus-comfort/overview.html
http://www.reiner-sct.com/produkte/tan-generatoren/tanJack_optic_sr.html
http://dangerousprototypes.com/docs/Bus_Pirate
See section 4.2 and [RE08, p. 303]
31
Figure 21: Devices used to sniff communication between card and TAN generator
MISO) pins of the BusPirate. To get to the contacts the card reader was opened
and wires were soldered to the contacts as shown in figure fig. 22.
We then are able to connect to the BusPirate with a serial console. To see byte
traffic from and to the card we need to set the BusPirate in the UART8 mode and
configure the correct parameters. Those are mainly bus port speed, data bits and
parity and stop bits. Finding the right bus port speed was rather difficult with the
first reader from Kobil.
Chip cards can operate at different clock speeds and because the card reader
provides a clock signal it determiens the clock speed of the cards processor. Because of that, we need to determine the frequency of the reader before we are
able to correctly interpret data. Once we have the frequency we can calculate the
corresponding bus port speed9 .
BusPirate provides a simple frequency analyser but needs a clock signal which
lasts at least one second. The Kobil device was too fast for that and so it was
not possible to determine a precise clock speed. With help of the Department for
Computer Engineering and a better frequency analyser a more accurate estimate
of the clock speed was measured. With that the cards ATR could be read successfully. But after the ATR was received numerous errors occurred. One reason for
that might be that the reader uses different clock speeds, maybe to use a lower frequency to safe energy when high performance is not needed. BusPirate however
needs a fixed bus port speed to interpret data correctly and again it was not possible
to get useful results besides the ATR.
8 Universal Asynchronous Receiver Transmitter
9 Details about the conversion from frequency to bus port speed is found at http://wiki.yobi.be/
wiki/Bus_Pirate#7816-3_T.3D0_at_arbitrary_baudrate
32
When testing a different reader from ReinerSCT much better results were achieved.
Being a little slower, we can successfully determine a clock speed of about 1.644MHz
which translated to a bus port speed of 905bps. The full parameters for the UART
mode are:
Listing 5.1: BusPirate UART Paramerters
bus p o r t speed : 905
data b i t s and p a r i t y : 8 , even
stop b i t s : 2
receive polarity : idle 1
output d r a i n : open d r a i n
1
2
3
4
5
With these settings we are able to see data and start the experiment. Since it was
just a test transaction all parameters are chosen arbitrarily. As startcode 8710000
was chosen since this is a common transaction type.
Listing 5.2: Transaction Details
S t a r t c o d e : 8710000
R e c i p i e n t Account Number : 123456
Amount : 1 2 3 , 4 5
1
2
3
The cards application transaction counter was set at 4210 . For this test the ATC
has just informational meaning because the resulting TAN won’t be used. For
a real online transaction the ATC has to match a counter the bank has stored.
Should both counters differ too much the TAN will not be accepted and an ATC
synchronisation has to be done. How the ATC affects the TAN will become clear
in the last two steps of the following section.
5.2
sniffing a tan generation
In the following sections << symbolises data sent from the reader to the card and
>> the other direction. Names of the commands were taken from [Car], [Ccc],
[Ran04] and [EMV]. This setup is pretty much the same as done by the CCCFFM but with minor hardware changes and different input data. More details on
what the commands or answers mean can be found in [Ccc] where most recent
information are held. For offline users a printed version is available in [Sch12]11 .
ATR
>>
Data
3B FF 96 00 FF 81 31 FE 45 65 63 11 0C 53 02 50 00 10 A9 0B 23 47 06 50
07
After the card has been inserted and received a reset signal from the reader
it sends an ATR. To give a brief analysis we use the ATR Parser from Ludovic
Rousseau12 which parses the data according to ISO/IEC 7816. Table 3 show the
10 For more on 42 see [Ada81].
11 Together with the author of [Ccc] we were able fix a minor error in their documentation which has
been discovered after the printed version was published.
12 http://smartcard-atr.appspot.com/
33
parsed data. Details and meaning of each value can be found in section 4.3.3
on page 23. Noteworthy are especially TD(1) and TD(2) which specify T=1 as
communication protocol and TA(3) which sets the IFSC initially to 254 byte. A
different example and more details on ATRs can be found in [Ccc] and [RE08].
Field
TS
T0
TA(1)
Value
0x3B
0xFF
0x96
TB(1)
TC(1)
TD(1)
TD(2)
TA(3)
TB(3)
0x00
0xFF
0x81
0x31
0xFE
0x45
0x65
TCK
0x07
Description
Direct Convention
Y(1): b1111, K: 15 (historical bytes)
Fi=512, Di=32, 16 cycles/ETU (250000 bits/s at 4.00 MHz,
312500 bits/s for fMax=5 MHz)
VPP is not electrically connected
Extra guard time: 255 (special value)
Y(i+1) = b1000, Protocol T=1
Y(i+1) = b0011, Protocol T=1
IFSC: 254
Block Waiting Integer: 4 - Character Waiting Integer: 5
Historical bytes 65 63 11 0C 53 02 50 00 10 A9 0B 23 47 06 50
Category indicator byte: (proprietary format)
"c..S.P....#G.P"
correct checksum
Table 3: ATR send from a debit card and parsed
IFSD
<<
>>
Header
00 C1 01
Header
00 E1 01
Data
FE
Data
FE
EDC
3E
EDC
1E
After the IFSC has been changed from its default value in the ATR, now the
IFSD13 is changed to 254 byte. The card acknowledges this with a S-Block and
repeating the field size.
SELECT FILE
<<
>>
Header
00 00 0E
Header
00 00 02
APDU
00 A4 04 0C 09 D2 76 00 00 25 54 44 01 00
Trailer
90 00
EDC
3B
EDC
92
With the previous command all communication parameter have been set up.
The SELECT FILE command selects an application on the card, in this case the
TAN application. Files in context of chip cards don’t only represent data but can
also provide access to an application for this ISO/IEC 7816-4 defines different file
types. These are defined in [ISO/IEC 7816-4] and explained in [RE08].
Taking a closer look we want to use this command as an example completing
the introduction of T=1 and APDUs in chapter 4 on page 19. Table 4 relates every
byte of the command to its function according to ISO/IEC 7816-3 and -4.
Payload of the T=1 block is an APDU of 14 byte in length as stated in the LEN
byte. According to ISO/IEC 7816-3 the APDU header consits of CLA, INS, P1 and
13 IFSC and IFSD are explained in section 4.3
34
P2 fields. CLA byte 0x00 tells us that the following instruction is found in ISO/IEC
7816-4 and there an INS of 0xA4 is defined as a SELECT FILE command.
The fifth byte indicates the data length of the APDU of 9 byte. Since this are all
remaining bytes we conclude that this is a command with no Le byte and thus the
maximum data length in the response is expected.
Byte
00
00
0E
00
A4
04
0C
09
D2
76
00
00
25
54
44
01
00
3B
Name
NAD
PCB
LEN
CLA
INS
P1
P2
Lc
Data
Data
Data
Date
Data
Data
Data
Data
Data
EDC
Description
Node ADress
Protocol Control Byte -- I-Block
Length of information field (APDU) 0x0E = 14 Bytes
Class
Instruction -- SELECT FILE (ISO/IEC 7816-4)
Parameter 1
Parameter 2
Length of Data
Databyte 1
Databyte 2
Databyte 3
Databyte 4
Databyte 5
Databyte 6
Databyte 7
Databyte 8
Databyte 9
Error Detection, XOR -- ISO/IEC 7816-3
1
2
3
4
5
6
7
8
9
Table 4: Example of an APDU with T=1 protocol
Data bytes 1 to 9 specify which application to select. Applications are identified
by an AID14 which itself consists of a RID15 and a PIX16 . More about the AID is
found in [RE08, p. 464] The correct values for the TAN application can be taken
from [SIT] or [Ran].
In the answer the card simply states that the previous command has been successful. Byte one SW1 = 0x90 and byte two SW2 = 0x00 indicate no errors during
execution.
GET PROCESSING OPTIONS
<<
>>
Header
00 40 08
Header
00 40 0E
APDU
80 A8 00 00 02 83 00 00
Body
77 0A 82 02 18 00 94 04 08 02 04 00
Trailer
90 00
EDC
E1
EDC
A5
Following the pattern used in the last command we can decode this and other
commands to different level of detail. The CLA byte set to 0x80 indicates that
this command is using secure messaging or is of proprietary format17 . Some
more information about this command can be found in [EMV, p. 6.5.8] which
state that CLA byte value 8X and INS set to A8 indicates a command named GET
PROCESSING OPTIONS. Following this we can see that the 8300 is the payload
14
15
16
17
Application IDentifier
Registered Application Identifier
Proprietary application Identifier eXtension
See [ISO/IEC 7816-4, chap. 5.4.1.]
35
defined as “Processing Options Data Object List (PDOL) related data”18 . Because
the Le byte is set to 0x00 we can assume that no PDOL is provided.
The response can be decoded with the TLV decoder from [Emv]. Again looking
at the EMV specification we see that the response states which features the selected
application supports and what other files belong to this application19 .
READ RECORD 1
<<
>>
Header
00 00 05
Header
00 00 1A
APDU
00 B2 01 BC 00
Body
67 25 60 08 51 70 01 07 58 0D 17 12 13 07 10
02 80 45 55 52 01 51 00 06
Trailer
90 00
EDC
0A
EDC
45
Of this answer we will use bytes 4 to 10 in the VERIFY step to change the
security level. Bytes 2 to 4 are a short bank identification number and bytes 5 to
10 represent the serials number of the debit card20 .
READ RECORD 2
<<
>>
Header
00 40 05
Header
00 40 1D
APDU
00 B2 03 0C 00
Body
70 19 9F 55 01 00 9F 56 12 00 00 03 FF FF 80
00 00 00 00 00 00 00 00 00 08 00 00
Trailer
90 00
EDC
F8
EDC
3F
The second READ RECORD call is different to [Ccc] where a SEARCH RECORD
IPB call was made. This might be because we use a different debit card which
might have a different software version. As in the previous command some
records of the selected file are read. Parameter byte P1 indicates which record,
here 321 .
The answer however is similar, just one byte shorter. 0x70 indicates a proprietary
format according to ISO/IEC 7816-4. The second byte in the body 0x19 gives
the length of the response data as hex value. Tags 9F55 and 9F56 can be found,
followed each by a length byte. According to EFTlab22 9F55 is a Geographic Indicator
while 9F56 is a Issuer Authentication Indicator – IAI. The exact meanings of those are
unknown. However will we use the latter in Calculate TAN as a bitmap to calculate
the TAN. This bitmap is identical with [Ccc] which might indicate that always the
same bitmap is used even over different SECCOS versions.
18 [EMV, p. 75]
19 “The AIP specifies the application functions that are supported by the application in the ICC and
is coded according to Part III. The AFL consists of the list, without delimiters, of files and related
records for the currently selected application that shall be read according to section 10.2.” [EMV,
p. 76]
20 http://ftp.ccc.de/docs/cards/geldkarte.pdf
21 See [EMV]
22 http://www.eftlab.co.uk/
36
VERIFY
<<
>>
Header
00 00 0D
Header
00 00 02
APDU
00 20 00 81 08 2C 08 51 70 01 07 58 FF
Trailer
90 00
EDC
00
EDC
92
According to [ISO/IEC 7816-4, chap. 6.12.] this command is used to modify the
security status. It could also be used to verify a PIN but in this case the card
number and one other byte23 is used.
The answers simply states that the command has been successful. If this step is
not successful an error code 63CX is returned24 . X counts to 3 and indicates the
number of retries. Once 3 has been reached the TAN application is locked and
needs to be unlocked with a PIN. So far we have been unable to get information
from banks on which PIN this is since it differs from the PIN used at ATMs.
HASH
<<
Header
00 40 4A
>>
Header
00 40 16
APDU
00 2A
6F 64
6D 65
65 74
B6 00
Body
5F 54
ED 95
90
65
72
72
A0
3A
E1
61
44
E0
FF
67
90
F8
FF
E1
00
71
FF
FF
80
00
FF
FF
81
00
FF
FF
3F
E1
FF
FF
E1
4B
31
FF
53
6F
32
FF
74
6E
33
31
61
74
34
32
72
6F
35
33
74 53 28 17 C5 B3 54 9C 50 13 3E 9F 1D
CD AB B1
74
6E
36
2C
2D
75
E1
34
43
6D
42
35
Trailer
90 00
EDC
DE
EDC
3B
With the hash command all previously collected data of the transaction is encoded and sent to the card. For the encoding two different types are used: ASCII
which is indicated by a byte 0xE1 preceding the data and BCD by 0xE0. This
coding is rather simple and the names of data fields are transmitted fully: E1 53
74 61 72 74 2D 43 6F 64 65 3A The first byte 0xE1 indicates an ASCII coding which
decodes the remaining bytes to a character string of Start-Code:. A reason for this
may be to generate a long hash string which will be used in the next step.
GENERATE AC
<<
Header
00 00 31
>>
Header
00 00 22
APDU
80 AE
9F 1D
00 00
Body
77 1E
39 9B
00 00
00 00 2B 5F 54 74 53 28 17 C5 B3 54 9C 50 13 3E
ED 95 CD AB B1 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
Trailer
9F 27 01 00 9F 36 02 00 2B 9F 26 08 4B
90 00
C1 46 13 53 99 9F 10 07 0A 82 00 00 31
EDC
C9
EDC
D5
ISO/IEC 7816-4 only states that this command is proprietary but with [EMV] we
can gather some information which are detailed shown in table 5 for the command
23 Byte 4 from the answer in READ RECORD 1
24 See [ISO/IEC 7816-4, chap. 6.1.15.]
37
and table 6 on page 39 for the response. The different parts of the response – ATC,
AC and IAD25 are used in the next step to calculate a TAN.
In this step the ATC is incremented. The ATC is used to keep track of the
number of transactions. Should this number jump or stay constant it may be an
indicator that something is wrong. The bank holds a counter for each debit card
it issues. Should the card’s counter differ too much from the bank’s counter then
the bank won’t accept a TAN until an ATC resynchronisation has been done.
Calculate TAN
Now the communication with the card is complete and all necessary data is collected. To calculate a TAN now some last steps need to be done. From previous
responses two components are used: from READ RECORD 2 a bitmask
00 00 03 FF FF 80 00 00 00 00 00 00 00 00 00 80 00 00
and payload data from GENERATE AC
00 00 2B 4B 39 9B C1 46 13 53 99 0A 82 00 00 31 00 00
.
The payload data consists of all the fields of the previous rAPDU without the tag
names and length information. So from table 6 on page 39 only bytes 6, 10 - 11
(ATC), 15 to 22 (AC) and 26 to 32 (IAD) are used.
If these byte strings are not of equal length they are padded with zeros. In a
next step they are bitwise logically AND combined and the result is compressed
by using only the values which are 1 in the bitmask. This result then is rotated
and the resulting bits are interpreted as an integer number. This this number
represents then the TAN. TANs are seven digits long so should this number be
shorter a 0 is added at the leftmost position. The exact process with examples is
described in [Ccc].
25 See table 6 for definitions of there acronyms
38
Byte
00
00
31
80
A4
Name
NAD
PCB
LEN
CLA
INS
00
P1
00
2B
5F
54
.
.
.
P2
Lc
Data 1
Data 2
.
.
.
Description
Node ADress
Length of information field (APDU) 0x31 = 49 Bytes
Class -- Proprietary (ISO/IEC 7816-4)
Instruction -- GENERATE APPLICATION CRYPTOGRAM
(EMV4.3 Book 2)
Parameter 1 -- Application Authentication Cryptogram and no
CDA signature requested (EMV4.3 Book 2)
Parameter 2 -- Always 00 (EMV4.3 Book 2)
Length of Data 0x2B = 43 Bytes
Byte 1 of HASH
Byte 2 of HASH
.
.
.
B1
00
.
.
.
Date 20
Data 00
.
.
.
Byte 20 of HASH
Padding
.
.
.
00
C9
Data 00
EDC
Padding
Table 5: GENERATE APPLICATION CRYPTOGRAM command
Byte
00
00
22
77 1E
9F 27
01
00
9F 36
02
00 2B
9F 26
08
4B
39
.
.
.
99
9F 10
07
0A
.
.
.
00
90 00
D5
Name
NAD
PCB
LEN
EMV TAG
LEN
EMV TAG
LEN
ATC
EMV TAG
LEN
AC Byte 1
AC Byte 2
.
.
.
AC Byte 8
EMV TAG
LEN
IAD Byte 1
.
.
.
IAD Byte 7
SW 1 & 2
EDC
Description
Node ADress
Length of information field (APDU) 0x22 = 34 Bytes
unknown
Cryptogram Information Data (EMV4.3 Book 2)
Length of data
unknown
Application Transaction Counter (ATC) (EMV4.3 Book 2)
Length of data
0x002B = 42 TAN have been generated with this card
Application Cryptogram (EMV4.3 Book 2)
Length of data
Cryptogram used to calculate a TAN
Issuer Application Data (EMV4.3 Book 2)
Length of data
unknown
Command Executed correctly -- ISO/IEC 7816-4
Table 6: GENERATE APPLICATION CRYPTOGRAM response
39
6
IMPLEMENTING A PROTOTYPE
This chapter discusses implementation details of the NFC-TAN prototype. When
the project started some difficulties were encountered1 like not available hardware
or SDKs. Having had to solve these may have helped in the end with the development of a more flexible software design.
Goal of this implementation was not to create a ready-to-ship product but rather
to provide a prototype which shows what is currently possible with available
technology. To push this prototype to a product which people can securely use
some further work has to be put into exception handling and input validation.
Also UI design and usability needs to be improved. This prototype explores how
TANs can be created using the NFC-TAN method on iOS devices. Using the proxy
approach of chapter 3, it is possible to connect any card reader to a smartphone,
especially also contact-based readers. With this it is easily possible to not only
implement NFC-TAN but also chipTAN. One implementation goal was to keep
the software design as modular and flexible as possible. So that when a future
iOS device supports NFC natively or an NFC adaptor becomes available only little
changes to the overall software are necessary.
6.1
environment
Developing targets for the mobile application were iPhone 4 with iOS 6.1.3 and
iPhone 3GS also with iOS 6.1.3. The application programming environment was
Xcode 4.6 on OSX 10.7.5. The server side was programmed in Java with Eclipse
Juno extending an application build by Max Günther. This server runs on any
machine that is able to run java applications. It was tested successfully on Windows 7, Windows 8 and on OSX 10.7. Contact-based card readers used were
PC USB-SL Reader from Gemalto2 and a reader which can read both, contactbased and contact-less cards – cyberJack RFID komfort from ReinerSCT3 . Figure 23
on page 42 shows the card readers used in the development process.
1 See chapter 3 on page 15
2 http://www.gemalto.com
3 http://www.reiner-sct.com
41
Figure 23: Smartcard readers. Left ReinerSCT cyberJack RFID komfort and right
gemalto PC USB-SL
6.2
structure
In section 2.2.5 on page 12 we already described a broad structure of NFC-TAN.
Figure 24 shows this idea again. As seen in fig. 25, is the proxy set between the
phone and smartcard. Any command the application on the phone would send to
a card is sent via wifi to the proxy which then passes it on to a card reader which is
connected via USB. The mobile application blocks and waits for a response. When
the card reader receives a response from the card it passes it on to the phone. An
integrated NFC reader will have a lower latency but should otherwise behave the
same.
Figure 26 shows an extended communication protocol similar to fig. 11 on page 14.
Again we see where the proxy intercepts commands to and answers from the card.
We also see that we do not need a physical card – only the TAN application that
runs on the card is needed. This TAN application can run as a module in the proxy
and made accessible by an HTTP interface. It is, for obvious security reasons, not
possible to copy applications from debit cards. But we were able to reuse the work
of [Sat12] which implemented a TAN application on a javacard. This application
can be run on our proxy without knowing its internals — we also do not know
the implementation of a debit card. The ground work for the web-interface was
done by [Gün11] and is called Card-in-the-Cloud (CiC).
A complete implementation of this project consists of three main parts. One
being a mobile application which acts as client, the second part is a proxy server
which handles communication with the card. The third part is a bank server. The
bank sever initialises a transaction by creating a startcode and sending this to the
user’s computer. After the user generated a TAN the bank server checks if the
42
6.2 Structure
a
Recp 12437
Recp
12437
123.45
Am 123.45
Am
Rent
Txt Rent
Txt
TAN
Bank
PC
b
d
Recp 12437
Am 123.45
Txt Rent
TAN
c
NFC Card
Smartphone
Figure 24: a login to online banking; b scan QR code with smartphone; c use
NFC card to generate TAN; d enter TAN in online banking website
PC
b
c0
c1
d
Recp 12437
Am 123.45
Txt Rent
TAN
Card Reader
Proxy
Smartphone
Figure 25: The proxy forwards all commands received via WiFi from the
phone c0 to a via USB connected smartcard reader c1
43
PC
Bank
Proxy
Phone
Card
1
2
3
4
5
6
6a
6b
7
8
9
10
11
12
Figure 26: 1 login at bank; 2 success; 3 create transaction; 4 startcode; 5
startcode + transaction data; 6 startcode + transaction data; 6a startcode + transaction data; 6b application cryptogram; 7 application
cryptogram; 8 generate TAN; 9 TAN; 10 TAN; 11 TAN; 12 transaction successful
44
6.2 Structure
TAN is valid. Since two different TAN methods are used, also two different bank
server implementations are necessary. NFC-TAN uses the javacard implementation from [Sat12] – called eKaayDebitCard and we can use the bank server implementation from [BG] which also uses eKaayDebitCards. The chipTAN method
uses a debit card from Sparkasse Tübingen and their online banking page can be
used as banking server4 . With those two bank servers there was no need to create
a separate bank server implementation, leaving the mobile application and proxy
server open for implementation.
6.2.1 Proxy Server
For the proxy server the Card-in-the-Cloud (CiC) server implementation could
be reused which was developed as a follow up project of [Gün11] and [Sat12].
This server provides an HTTP interface to send and receive APDUs to an eKaayDebitCard applet developed by [Sat12] which runs the same applications which
otherwise would run on a physical card. To have such a virtual card is useful
for development and also gives the possibility to provide services compatible to
physical smartcards over the web. CiC was extended so that it is also able to send
commands to locally connected card readers.
A jetty5 web server provides the interface towards the network. To make a
method accessible from the web it needs to be decided if the method should listen
to a GET or POST request. Then with an @Path statement an URL is given to
that method as shown in listing 6.1. For methods that don’t need parameters
HTTP GET is sufficient, to call a method with parameters – e.g. an APDU – a
HTTP POST request is required. In the example listed in listing 6.1 a HTTP GET
request can be made to http://proxy.srv/connect and a HTTP POST request to
http://proxy.srv/transceive.
Listing 6.1: Assigning a URI to a Java Method
1
2
3
4
5
@GET
@Path ( ” co nn e ct ” )
p u b l i c void c on n ec t ( ) {
//....//
}
6
7
8
9
10
11
12
@POST
@Path ( ” t r a n s c e i v e ” )
p u b l i c S t r i n g t r a n s c e i v e ( S t r i n g apdu ) {
//....//
r e t u r n apdu ;
}
This proxy provides an HTTP interface to communicate with locally connected
card readers. The interface definition is shown in listing 6.2 and one example
implementation of that interface can be found in SmartcardTerminal6 . Another
ITerminal implementation was added and named Card-Reader-in-the-Cloud (CRiC).
This class makes use of the javax.smartcardio7 API to connect to USB card readers
4 But we had to be careful not to create too many wrong TANs and otherwise suspicious actions as
this might freeze our account again. We had us locked out once because of too many wrong TANs
during the activation of the bank account. This was due to a wrong calculation of the HASH and
a fixed, rather then dynamic calculated length byte in the command web servers. More on APDUs
in chapter 5 on page 31
5 http://www.eclipse.org/jetty/
6 See listing 5 on page b
7 See [Ora13]
45
connected to the PC. Because it is possible that more than one reader is connected
to the proxy server, the first reader found will be used to establish a connection. A
future extension could use the connect() call to specify to which reader a connection
should be made.
Listing 6.2: ITerminal Interface
1
public i n t e r f a c e ITerminal {
2
public
public
public
public
3
4
5
6
7
byte [ ] t r a n s c e i v e ( byte [ ] data ) throws IOException ;
boolean isConnected ( ) ;
void c on n ec t ( ) throws IOException ;
void c l o s e ( ) throws IOException ;
}
Figure 27 shows a basic summary of the proxy and some of its previously introduced classes. The mobile application sends a HTTP request to the web server. A
command APDU is coded as a byte string in the requests payload. Depending on
the request’s URL an ITerminal implementation is chosen, here CiC or CRiC. This
sends the APDU to a smartcard and returns the response back as a byte string to
our mobile application.
jetty Web
ITerminal
CRiC
CiC
eKaayDC
Card Reader
Proxy
Figure 27: A HTTP request is received by the jetty web server and forwarded to an
ITerminal implementation. This sends a command APDU to a smartcard.
The response APDU is returned as a HTTP response to the web client.
Having had a functional proxy was very useful in the early development process.
Especially to test the mobile application against a working proxy was valuable to
find bugs. The development of the CRiC implementation benefited greatly from
having – with the ITerminal a well defined interface. This showed the advantages
of a good software design which lie in easier extensibility and maintenance.
6.2.2 Mobile Application
The application that runs on the smartphone is surely the centre of this project. It
coordinates communication between all other parts and processes all data. This
is basically done in five steps and very similar for both TAN methods currently
supported. For one does the application take input data about the transaction.
This data originates on a PC and is transmitted either with a QR-Code to the
46
6.2 Structure
phone or entered manually in the UI. In this step the behaviour of the application
can be compared to that of a hardware TAN generator used in chapter 5 and so
also needs to consider the HHD specifications8 concerning the interpretation of
the startcode. After that the application connects to a card reader9 . Here some
levels of abstraction are used to gain the desired functionality. Because a local
card reader does not exists, the proxy introduced earlier was used. With that the
application is able to send commands to a smartcard. More precisely are we not
sending commands to a card directly but rather to a card reader which then passes
them on to an inserted card.
The fourth step consists of receiving data and parsing the results. After all
data has been received the mobile application can start to calculate a TAN for
this transaction which will be displayed in the UI in a last step. Alternatively
to only displaying it on screen the application could send all transaction data,
including startcode and TAN directly to the bank and with that authenticating
the transaction. Following a closer look at soome implementation details of this
process will be taken.
In this implementation all information about the current transaction is held in a
TransActionObject - TAO. Listing 6.3 shows the public interface of this class. Initialisation of this object is done by a TransactionInit implementation.
Listing 6.3: Public interface of TransactionObject
1
@ i n t e r f a c e T r a n s a c t i o n : NSObject
2
@property ( readonly ) NSObject <BankAccountProtocol> ∗bankAccount ;
@property ( strong , readonly ) NSDate ∗ date ;
@property ( strong , readonly ) NSString ∗ t r a n s T e x t ;
@property ( readonly ) double amount ;
@property ( readonly ) i n t tan ;
@property ( nonatomic , r e a d w r i t e ) i n t s t a r t C o d e ;
3
4
5
6
7
8
9
10
11
12
13
− ( id ) i n i t : ( NSObject <BankAccountProtocol> ∗ ) bankAccount
andDate : ( NSDate ∗ ) date
andText : ( NSString ∗ ) t r a n s T e x t
andAmount : ( double ) amount ;
14
15
16
17
18
19
−
−
−
−
−
( void ) setTan : ( i n t ) tan ;
( NSString ∗ ) getRecipiantName ;
( NSString ∗ ) g et R e c i p ia n t B a nk I D ;
( NSString ∗ ) g e t R e c i p i a n t A c c o u n t I D ;
( NSString ∗ ) getAmountAsString ;
20
21
@end
Figure 28 shows some central parts of the application. A ViewController handles
all user input, like touch events and then calls a corresponding handler. A TransactionInit object will take care of properly initialising the TAO, either by scanning a
QR-Code or requesting manual input of transaction data. When this is done users
may call a TANGenerator to create a TAN. This in turn calls a CardReader to send
and receive data from a smartcard. When this call returns a TAN is displayed
on screen and can be automatically send to a BankServer or be manually entered
in an online banking website. Except for the ViewController these are all abstract
interfaces. This was done to make future changes more manageable and provide
a flexible environment for extensions.
8 See section 4.7 on page 28
9 The term connect is misleading here. Actually the system is stateless and no connection needs to be
opened or closed. But it helps to think as if a connection were made.
47
ViewController
Bank
Server
Protocol
Startcode
Recipient 12437
TAN
Generator
Protocol
Amount 123.45
Text Rent
TAN
Card
Reader
Protocol
TransactionInit
Figure 28: A brief summary how objects of the mobile application interact with
each other.
For TransactionInit two different implementations are provided: a QR code reader
to scan either NFC-TAN or SPAYD QR codes from a website and secondly the possibility to enter all necessary data manually. Figure 29 shows the class hierarchy
where the abstract interface is at the top and concrete implementations below.
Black names represent already implemented classes and white names show other
possible classes.
absTransactionInit
QR-Reader
FlickerReader
Manual
Figure 29: Abstract TransactionInit Classes
The QR-Reader class uses the phones camera to take a picture of a QR code in
which information about a transaction is coded. Figure 30 shows the two different
codings used but others also are possible. It would also be possible to implement
a class that scans a FlickerCode10 using the phones camera.
After a successful scan, data is then decoded and a TAO is initialised. An alternative way of initialising a transaction is to enter all information manually into
the applications UI.
10 See section 2.2.4.
11 NFC-TAN QR Code decodes to
”Musterfirma - 354489536 - 80855827 - 100,44 - Bekannt - 360363 - null”
and SPAYD QR Code decodes to
”SPD*1.0*ACC*DE89370400440532013000*AM:480:50*CC:CZK*MSG:Payment for the goods”
48
6.2 Structure
NFC-TAN QR Code
SPAYD QR Code
Figure 30: QR Codes used11
After a TAO has been initialised the user can call a TANGenerator to calculate
a TAN for this transaction. TANGenerator again is an abstract interface which
can have different implementations for different TAN applications or different
smartcards as shown in fig. 31.
absTANGenerator
eKaayDC
debit Card
nPA
credit Card
Figure 31: Abstract TAN Generator Classes
The task of this interface is to take transaction data and pass it on to a smartcard, or more precise a smartcard reader. Which smartcard to use depends on the
chosen TAN method. Here a regular German debit card and an implementation
of [Sat12]’s eKaayDebitCard was chosen as an example implementation. But it
would also be possible to use other smartcards. Some examples would be using a
new German ID card12 , a credit card or other commercial cards which are able to
generate TANs.
In order to send to and receive data from a card the TANGenerator needs to
communicate with a card reader. Usually some methods of the smartphone’s OS
would be used to access a reader but since on iOS this is not available an abstract
interface for a card reader was used. This interface is called absCardReader and
encapsulates all details about how to use card readers. With this it is possible to
implement the proxy in the prototype and provide an easy way to implement other
possibly native card readers if they become available. A specific implementation
of this interface is chosen when a TANGenerator object is initialised. After that the
card reader can not be changed again.
To adopt a more flexible approach The application could hold a list with all
available card readers. Should new card readers become available – for example
a bluetooth reader could be connected – they will be added to that list. Then
TANGenerator will be notified that the list of available card readers has changed
and it can read the list again13 . To organise possible readers we further divided
12 [Wei12] already did some evaluation if and how this ID card could be used.
13 This is the pull method where all new information is pulled by the notified object, only the notification that something has changed is pushed. Alternatively the TANGenerator could be notified which
new readers are available pushing all new information to the TANGenerator. The pull method is
49
them into NFCReader and ContactReader as shown in fig. 32 and provide for each
one implementation.
abscard reader
NFCReader
CiC
Native
FloJack
ContactReader
iCarte
CRiC
Bluetooth
Figure 32: Abstract card reader classes
As discussed in chapter 3 are some NFC readers for iOS available and for each
one a concrete NFCReader implementation would be necessary. If a future iOS
device and iOS versions will support NFC natively an absCardReader implementation can be done by using the native API and initialise the TANGenerator with
this card reader. Until then this proxy server is used and a CiC-CardReader class
is used to support eKaayDebitCards. The same applies to contact card readers.
Each differently connected card reader needs a separate implementation of the
CardReader interface. One implementation of a CRiC is provided to communicate
with a card via the proxy server. Other readers connected via bluetooth or other
methods would need their own implementation.
Actually not every different card reader requires their own implementation.
Card readers which have the same connection type (e.g. USB) and support the
same protocol (e.g. T=1) can share the same absCardReader implementation. This
allows to create some generic implementations which will work for many different
card readers. Only when readers use different protocols (e.g. T=1 and T=0), are
connected via a different interface (e.g. locally or via a proxy) or require special
connection parameters different implementations are necessary.
With this a communication path for transaction data from the bank’s online
banking website to a smartcard has been established. A TransactionInit class reads
data from a website and then passes it on to a TANGenerator class. This holds
a reference to an absCardReader implementation which can communicate with a
smartcard. Figure 33 shows how these modules interact with each other and how
in the end a TAN is created. There are of course more steps and method calls
involved in this process but only the most relevant ones were chosen to make the
concept clear.
probably more appropriate here because it keeps the code cleaner and also by reading the entire list
of connected readers disconnected card readers can be detected.
50
6.2 Structure
TransactionInit
ViewController
TANGenerator
CardReader
Bankserver
getTransaction
TAO
generateTAN
connect
ATR
generat AC
AC
calcTAN
TAN
TAO + TAN
commit
TAO + TAN
success
success
Figure 33: Process of creating a TAN
6.2.3
Helping Hands
During the implementation process some helper classes were developed to encapsulate certain functionality and to make code reuse easier. Some of them are
introduced here.
BankAccountProtocol
Germany and Europe is currently in the process of changing the system of bank
account IDs and bank IDs. Until now an account ID in combination with a bank
ID is used to identify a specific bank account. Starting in 2014 a different system
– IBAN14 and BIC15 has to be used for any transaction. To prepare for this an
abstract interface called BankAccountProtocol is used to identify an account. This
interface provides methods to get information needed to create a transaction, each
system of bank account numbers needs a concrete implementation. The interface
is listed in listing 2 on page a.
APDU
A naive and simple approach is to create APDUs manually in a TANGeneratorProtocol. Code for creating an APDU is very similar for all implementations of that
protocol. APDUs transmit commands and data and contain a checksum and information about its length. To use an APDU one should only need to know the
command and the data, checksum and length should be calculated automatically.
To do this a data type APDU was created which is initialised with a command
and an optional data string. Some basic plausibility checks are executed on these
14 International Bank Account Number
15 Bank Identifier Code
51
parameters and then checksum and length information are calculated. This gives
an easy method to safely handle APDUs. The public interface is listed in listing 6
on page c. For the command APDUs used in this project templates were created
to create APDUs by using the names of those commands.
URLConnectionHandler
Many of our classes send and receive data through a network connection. Code
which creates these connections, sends data, receives data and finally closes this
connection is the same except for the URL it connects to. In order to allow reuse
of that code we created an URLConnectionHandler class which is initialised with
an URL as parameter and provides methods to do basic actions on a network
connection. The interface is listed in listing 4 on page a.
6.3
extension: mobile banking
Mobile banking has been briefly introduced in section 2.1 on page 3 and with
the implementation of the mobile application in mind we will now see it can be
extended to also support mobile banking. Mobile banking means that all tasks are
done on the mobile device and no other computer is used. Other devices may be
used for a two-channel authentication though. The entire process of committing a
transaction is very much similar to previously described methods. Users usually
use a smartphone application provided by their bank to log in to their banking
account. In that application a transaction form is filled out and the bank displays
a startcode16 . Then users can enter the TAN and so authenticate this transaction.
To add mobile banking to the previously described application only little code
needs to be added. In fact only a different absTransactionInit17 class was needed.
Entering data manually into the application18 is already supported and this was
used as a basis. The process is that users enter transaction data into a form which
in turn sends all data to the bank. The bank initialises the transaction and returns a startcode which will be displayed in the application. From here on the
process is the same as before. Users may use their NFC card together with the
NFC smartphone to generate a TAN. Data is sent to a TANGeneratorProtocol which
uses a absCardReader to exchange data with a smartcard. The resulting TAN then
is displayed on the phone’s display. Alternatively it can automatically be sent
to the bank and thus authorise the transaction without any further user interaction. This would not add an additional security risk because only previously used
communication channels and devices are used.
In order to work securely mobile banking does require a secure communication
channel and a mobile device which has not been compromised. As chapter 7
shows can this not always be guaranteed.
16 This may again be as a number or some other coding may be used.
17 See fig. 28 on page 48 for an illustration on what parts make up the mobile application.
18 This can be done alternatively to scanning a QR- or Flickercode.
52
7
IS IT SAFE?
Banking always has been a target of crime because of it’s central role in handling
and storing money1 . Although this hasn’t changed much, banks have enough
resources to protect themselves fairly well. So the customer has become the easier
target — it is easier to steal some wallets than to rob a bank. The digital equivalent
of stealing someones wallet is grabbing online banking credentials. Not the bank’s
online website is attacked but rather the customer’s computer.
For banks one big advantage of online banking is that it scales well. With a
couple of computers and some technical staff many customers can be provided
with basic service at all times. A disadvantage is that it also scales well for attackers. They are provided with the opportunity to attack thousands of bank accounts
semi-automatically.
On one hand banks and other institutions who give out smart cards have been
putting a lot effort into securing their system against attackers and a lot of research
has been put into developing new methods that withstand current attacks2 . On
the other hand are those institution also trying to increase usability for their customers in order to increase acceptability and the number of customers who use
this new technology and with that increase their revenue. Unfortunately adding
security often means that usability is getting worse3 . And all too often users have
different priorities than people implementing a system4 . For banks this can become a simple calculation which is more expensive – implementing a new, more
secure technology or recompensing customers who were victims of fraude5 . Balancing security and usability of a new technology is a difficult task for designers
and engineers.
Psychology of usability and security will not be discussed here. [And08, chap.
2] provides a good introduction to that subject. Instead some common attacks
on TAN methods are described and how they are or could be defended. As an
example the NFC-TAN method introduced in section 2.2.5 on page 12 will be
used to describe attacks and vulnerabilities. It will be mentioned where an attack
applies particular to a different method.
1
2
3
4
5
See [Gra11]
CrontoSign and NFC-TAN are both projects that were initially developed at a university.
See [Sou] or [Sch10]
[KFR10]
This is often cheaper because the victim usually has to provide proof it’s not their fault. Some
conversations with banks have been shown by [Mur11]
53
7 is it safe?
7.1
attacks on nfc-tan
In the process of creating a TAN multiple parties are involved and each provides
different attack vectors. In particular these parties are the user, the smart card
which stores a secret key, the smartphone which communicates with the card, the
computer which connects to the banks online banking website and of course the
bank. In the following a short summary is given of how each have their own vulnerabilities.
User
Humans are often the weak link in security schemes because human behaviour
can be manipulated in many different ways6 . Often attackers are able to convince
people to willingly give out confidential information. This is commonly called
social engineering. Other traps people might get in to are phishing mails or fake
apps which will be discussed in section 7.2.
Smart Card
The security and integrity of the physical cards can only be influenced be the
manufactures and issuers of those cards. Their responsibilities lie in securing the
concepts behind and manufacturing process of these smartcards. This is done
by defining standards, checklists and evaluation methods7 . An introduction of
what can and needs to be considered when designing chip cards is given in detail
in [RE08, chap. 16].
Smartphone
Smartphones are in fact just small computers which means they are potentially
vulnerable to any attacks also known to traditional desktop computers. What is
different is that their operating system (OS) was designed to provide more security than desktop OSes. Each application that runs is specially shielded by the OS
from the rest of the system (sandbox) so that one application can not access data
from another8 , at least not without explicit consent. In recent years smartphones
have become more widely used and with that have become a more interesting
target for attackers. Today it is assumed that it is possible to inject malware into
smartphones OSes and get similar access as malware on desktop computers. Some
examples and implications are discussed in section 7.1.2.
Personal Computer
About as long as computers have existed they have been infected with viruses9 . Today’s computers implement sophisticated protection methods against malware10
but modern malware is also very advanced and often is well designed and programmed piece of software because it has to run correctly in a hostile environment.
6 Behavioural psychology is a big field whose results are – next to clinical applications also used in
education and marketing
7 As an example ISO 13491: Banking – Secure cryptographic devices
8 See for example iOS:
https://developer.apple.com/library/ios/documentation/iphone/conceptual/
iphoneosprogrammingguide/TheiOSEnvironment/TheiOSEnvironment.html
9 See [KL]
10 Malware – Malicious Software. This term is used to include the many variates of viruses, worms,
torjans, bots and more.
54
If a computer is used for sensitive applications then even more protection levels
are advised. This is where modern TAN methods pick up. They consider the computer as potentially compromised and provide methods to still do online banking
securely. We won’t go into security mechanism of desktop computers, like anti
virus products or firewalls since this is out of our scope and many references are
online available11 .
Bank
Banks often have strong incentives to secure their infrastructure against attacks.
The online banking system itself and the banks infrastructure is crucial but outside of this project’s scope. We assume that this is a secure place and everything
there works as intended.
Later each point will be further discussed but first we want to review how
a TAN is generated. In order to make the text more readable two characters
are introduced which play certain roles: Cameron the customer and Aubrey the
attacker.
The standard process of generating a TAN with NFC-TAN has been shown
in fig. 11 on page 14. Cameron creates a transaction using the website of his bank.
The bank creates a startcode12 which needs to be transferred to the smartphone.
This can be done either by entering it manually or by scanning a Flicker-Code or
QR-Code. The phone communicates with Cameron’s NFC debit card to generate
a TAN and displays it together with the transaction data on the phone’s screen for
verification. The last step is that Cameron enters the TAN in the online banking
form. Alternatively the phone could send the TAN together with the startcode directly to the bank. With that the transaction is successfully authenticated. Aubrey
now has several possibilities where to attack.
7.1.1 Malware on PC
After a PC which is used for online banking is compromised different attacks are
possible depending on the kind of malware. Keyloggers send all keystrokes and
with that all logins and passwords of that computer to the attacker. Aubrey now
can use those credentials and log in to Cameron’s online banking page and create
transactions. Those won’t be successful however since Aubrey can not generate a
correct TAN. But having those credentials is a first step of a successful attack. It
is sometimes also possible to change contact data or TAN methods without any
further authentication.
An infected PC might also be subject to a Man-in-the-Middle13 or Man-in-theBrowser14 attacks. When Cameron creates a transaction malware is able to change
transaction data in the background and send this modified transaction to the bank
while showing the original data on screen. According to NFC-TAN the bank responds with a startcode which Cameron then has to enter together with the transaction data into his smartphone. This can be done manually or by scanning a
code. If done manually Cameron will of course enter his correct transaction data
11
12
13
14
To mention one: https://www.bsi-fuer-buerger.de
See section 4.7.1 on page 29
MitM – see section 7.5.1
MitB – see section 7.5.2
55
7 is it safe?
and receive a TAN for that transaction. Because the bank expects a different transaction, it rejects the TAN and cancels the transaction. Cameron might wonder and
try again by not entering the startcode manually but scanning a QR-Code. Then
the manipulated transaction data will be sent to the phone and from there to the
card. After the TAN has been generated the NFC-TAN application displays TAN
and all transaction data on the phone’s screen for verification. Now Cameron sees
the modified transaction and cancels the process. In either case no transaction is
successfully authenticated and the attack prevented. By using two separate devices for authentication another level of security is added because in order to be
successful Aubrey now has to attack PC and phone.
7.1.2 Malware on Phone
Although not as much as on computers attacks on smartphones are today getting
more common also because more people are using smartphones. Malware tries to
gets itself installed on the phone and is then able to intercept SMS, calls and can
gain access deep into the system. One of the first examples of malware on smartphones was a SpyEye variant found by F-Secure15 and soon others followed16 .
Malware on a smartphone alone does not provide a great risk because most of
the work is done on a PC and it is easy to verify data there – if they computer
hasn’t been compromised yet. So called cross platform infection poses a risk to
smartphones where an infected PC is transferring malware to a connected smartphone. Aubrey now has control over PC and smartphone and is able to modify
the attack mentioned in section 7.1.1 to successfully generate a TAN.
Again Cameron creates a transaction and scans the startcode given by his bank
with a smartphone. Usually the phone would display the manipulated transaction data but since it is also compromised it also displays the original data and
lets Cameron think everything is ok. When Cameron then enters a TAN the manipulated transaction will succeed because the bank never received any of the original
data. That cross-infection is not just a theoretical problem was shown by [Dav+12]
and more recently by [nij].
A modification of this attack applies to TAN methods that don’t use a smart
card to generate TANs, like photoTAN. If the secret key used to generate a TAN
is stored on the phones memory sophisticated malware could possibly gain access to that memory and copy the key and sent it to Aubrey. The password for
the online bank account is captured by another malware on Cameron’s computer.
Aubrey then is able to successfully authorise any transactions at any time. Banks
are not able to differentiate if transactions come from Cameron or Aubrey and
since Aubrey has all necessary information to create and authorise transactions
Cameron is unaware that his account has been compromised.
One way to prevent such attacks would be to include a small display on the
smart card which is capable of displaying transaction data. This however is technically difficult since this would require displays which are physically rugged and
also need very little power. Especially with contact-less cards power consumption
would be a challenge.
15 http://www.f-secure.com/weblog/archives/00002135.html
16 http://nakedsecurity.sophos.com/2011/09/16/spyeye-targeting-android-users-zeusstrategy/
56
7.1.3 Theft
Another way to attack NFC-TAN would be to steal the smart card and/or the
phone. A stolen phone provides no security risk to this method since no confidential data is stored there. A stolen card alone also is a manageable risk – with
respect to online banking – because to transfer money credentials for the online
banking website are needed. Should however Aubrey successfully capture those
credentials then only the smartphone application is missing to generate a TAN. It
would be possible to further increase the security of the NFC-TAN application by
using an application PIN or bonding a device to a card or registering a card with
a device.
7.1.4 Communication Interfaces
One different attack vector would be not to attack the devices used but rather the
communication channel they use to exchange data. With NFC-TAN this communication channel is the NFC communication between phone and card. Chapter 5
shows how an interception of messages is done for contact-based chip card readers
using chipTAN.
Sniffing an NFC communication is also possible from a sufficient distance to not
arouse suspicion17 . To decide if this is a problem we need to look at what data is
transmitted. This is basically a startcode and transaction data to the card and the
TAN back18 . Although optional probably all banks use a nonce together with a
startcode to bind one TAN to a specific transaction. If this is sniffed it poses little
risk since it can’t be used for anything else than the original transaction.
More difficult but also more problematic would be a relay attack19 . The attack
scenario is very much similar to a stolen smart card but without actually stealing
the card. Assuming Aubrey already captured Cameron’s online banking credentials she then only needs the smartcard or rather the secret key on the smartcard
to create TANs. Further assuming the smartcard provides the TAN application via
NFC Aubrey then can try to contact Cameron’s smartcard. With special hardware
this can be done from a relatively safe distance. Being able to communicate with
Cameron’s smartcard and also possessing his online banking credentials a relay
attack is possible to generate a TAN without Cameron’s knowledge.
To prevent such an attack an application PIN could be used or for more security
binding or registering a card with a specific smartphone. A simple and yet effective way to prevent such an attack is to shield the smartcard when it is not in use
thus preventing any contact-less connection.
17 See [KW05]
18 The TAN will not actually be sent from the card rather different pieces of data from which it is
possible to calculate the TAN. Since just the algorithm how to calculate the TAN needs to be known,
this adds no security.
19 See section 7.5.4
57
7 is it safe?
7.2
social engineering
Against social engineering attacks there are little to no technical countermeasures
since the attacker doesn’t exploit security holes but abuses trust people usually
have in each other. This can be quite successful and as Bruce Schneier20 puts it:
Only amateurs attack machines; professionals target people”21 .
A classic example is an attacker who calls people and pretends to work at their
bank asking for their online banking password under the pretence of new service
or updated security measures. If attacking a company attackers might pretend
to work at their target and try to gain access or retrieve sensitive information by
claiming to have forgotten their badge or password. [McD13] gives some examples and [Gra01] some more information about social engineering.
Phishing
Phishing is one form of social engineering or as [Jag+07] puts it: “Phishing is a
form of deception in which an attacker attempts to fraudulently acquire sensitive
information from a victim by impersonating a trustworthy entity.”. This happens
usually either in form of fraudulent emails or websites who try to impersonate a
trustworthy institution and so trick users to willingly give sensitive information.
Modern browsers and email clients try to detect such malicious websites and warn
their users if abnormalities are detected. But even if detection is working and a
warning is displayed it doesn’t mean users pay attention to them22 . So the only
real protection against those attacks is to educate people and increase awareness
as some official institutes are trying to do23 .
Fake Apps
One other type of phishing are scam or fake apps. These are apps who again try
to trick users into installing them on their smartphones by impersonating valid
applications. Usually users pay less attention when installing applications from a
trusted source. Especially with Apples iTunes Store users tend to place trust in the
approval process in order to be allowed in the app store. But fake apps are not a
unique problem of Apple’s store24 . Fake apps can either be plain malware which
tries to capture data from the phone or phishing apps trying to get users to enter
credentials and then sending them to the attacker.
20
21
22
23
24
https://schneier.com
Bruce Schneier in his Crypto-Gram Newsletter October 15, 2000
See [DTH06]
See [McD13] and [BSI]
http://us.norton.com/fake-android-apps/article
http://www.symantec.com/connect/blogs/fake-application-found-amazon-appstoreandroid
http://m.macnn.com/fullarticles/13/06/05/apple.itunes.app.store.caught.hosting.fake.
apps/
58
7.3 GSM Security
7.3
gsm security
Not all mobile phones are smartphones and while also so called dumb-phones
could be infected with malware it is less likely. What all mobiles share though
is a wireless connection to their network operator. This alone also poses a security threat when using mTANs because usually GSM is used to receive them.
Although also a 3G connection could be used network operators usually prefer to
keep non time-critical data on the slower, cheaper networks. Due to its age and
some design flaws in the encryption algorithm of GSM, A5/1 is considered broken and can be exploited. An attacker can attack the mobile network the phone is
using and intercept or modify messages. Although technically more complex than
stealing letters it is very much feasible and alike in its risks to users. A good introduction and presentation of the risks of GSM and using an outdated encryption is
given in [PN] and [Pri11]. They describe scenarios where attackers are able to intercept messages sent to any phones in a network cell or create a mobile network
themselves and thus imitating a valid network. The latter can be used to push
applications to SIM cards and so compromising them. The relatively ease with
which one can run their own GSM network cell is shown in [SW08] and [Roa12].
Another recently discovered attack completely bypasses the technical aspects25 .
Attackers were able to install malware on the victims computer and got the password and account ID for the online banking account. Furthermore did they get
hold of the mobile number of the victim. With that they ordered a second SIM
card from the provider but to a different mailing address. The mobile provider
didn’t verify the autheticity of the address and so the attackers were able to get
hold of the ordered SIM card. Then they activated it and configured it that this
card receives all incoming SMS. Together with the password from malware on the
victim’s computer they were able to authorise arbitrary transactions.
The weakness in this case lies not in the online banking process or the TAN
method itself but rather in the assumption that SMS get securely delivered to the
right recipient and that companies are not checking their workflows for security
flaw. It shows that not only the technology used must be secure but also their
implementation and the business processes using it.
7.4
keeping secrets secret
The generation of TANs requires a secret key which is shared between the bank
and each customer. Assuming banks can keep their part safe the questions comes
up where to store the secrets of customers. Currently this is done on chip cards
but other places are possible and might provide better usability.
When using a smartphone for TAN generation it seems obvious to use the applications private memory to store the key in. A big advantage would be that no
chip card is needed and users could authorise TANs just with their mobile. But
this also poses a risk. Malware could gain access to the memory and send the
key to an attacker which then could create TANs for any transactions. If also the
online banking credentials are know to the attacker arbitrary transactions can be
authorised.
25 See [Man]
59
7 is it safe?
To improve security the key could be stored in some sort of secure element on
the phone similar to a chip card. One place for this would be the SIM card which
every phone has. Being also a ISO/IEC 7816 chip card SIM cards are very similar
to debit cards and it would be technically possible to add TAN functionality to
SIM cards. However difficulties lie in the fact that banks and phone companies
would need to cooperate since SIM cards are issued by network providers. Also
the SIM card could be infected26 with malware which then opens similar risks as
a secret stored in application memory.
Storing the key in a secure element on the phone might seem like a better solution. When such a secure storage, like a special chip or a secure digital memory
card27 is used malware can not simply access the data and copy and send the
secret to the attacker. But it still can access the secure storage through the same
interface any valid application uses. Malware then can access the secret any time
an attacker wants to authenticate a transaction. Although this attack is made more
difficult it provides less security than current systems once the smartphone is compromised.
One way to defeat this problem might be to introduce additionally to a secure
storage element a secure display element which is directly connected to the secure
storage and can not be influenced by malware or the operating system. Every time
the secure storage is accessed it shows the data on the secure screen for users to
verify it. That would be effectively a two-way-authentication within one device.
If the secret key is stored on a chip card the display would also need to be on
that card. This engineering problem might already be solved – a patent to that
application has already been granted28
7.5
common attacks explained
7.5.1 Man-in-the-Middle
In a Man-in-the-Middle (MitM) attack the attacker places itself between two communication parties who want to communicate. The attacker can not only see what
both parties send each other but is also able to change the data29 .
In the context of online banking the attacker captures transaction data the victim
is sending to the bank and changes the amount and the recipient. When the bank
answers and requests a TAN the attacker changes to response so that the victim
sees its original transaction. Since the data seems valid a TAN will be entered. The
attacker uses that TAN to authorise the changed transaction. [Pen09] provides an
example of an MitM attack against chipTAN.
A defence against classic MitM attacks is using a secured, encrypted communication channel, usually SSL30 . Since the communication between customers and
their bank is encrypted, a MitM attacker needs to decrypt the data in order to
execute this attack.
26
27
28
29
30
See [Pri11], [SW08], [PN] and [Noh13]
See https://www.sdcard.org/home/
Flexible chip card with display – US 6402039 B1
See [Vit08]
Even though SSL has its own vulnerabilities as shown in [MS13]
60
7.5 Common Attacks Explained
7.5.2 Man-in-the-Browser
Man-in-the-Browser (MitB) is a similar attack as MitM. The difference is that encrypting the communication channel does not prevent this attack because data is
captured before it is encrypted. This attack can be viewed as a Man-in-the-Middle
attack between the browser and the victim.
A MitB attacks starts with an infection of the victim’s computer. A trojan loads
a malicious plugin or extension into the browser and gains access to data the
browser sends to the bank and is also able to capture data sent back. Because
browser plugins have deep control over content that the browser shows a trojan
can alter transaction data sent to the bank while displaying the original transaction
on screen to the user. This is possible because data is intercepted before it gets
encrypted. Because the attack works on the transaction level, it can bypass many
security mechanisms which usually work on the authentication level31 . That such
attacks are not just theoretical shows the tatanga incident described in [Kle12]
where a successful MitB attack was discovered. [G06] proposes some concepts
against such attacks like using virtual machines or read-only file systems.
7.5.3 Re-, Preplay
Replay attacks are often conducted by a Man-in-the-Middle. Authorisation data
or any other kind of sensitive data is being copied and later used again to repeat
the action possibly with modifications. In the online banking scenario an attacker
would copy a transaction authorisation and repeats it. If no data is changed this
results in multiple identical transactions. The key is that the attacker does not
need to know anything about the communication protocol and data can even be
encrypted. However in order to modify the transaction data has to be decrypted.
To prevent this kind of attack additionally to encryption a nonce32 had been introduced to be used with startcodes33 . It is important that these numbers are not
predicable and are only used once or else attacks on the protocol may be possible.
In a preplay attack an attacker tries to get authorisation data in advance for a
later attack. This could be either by asking the user to enter a couple of TAN numbers from a TAN list or by simulating a transaction and so trick the user to scan
their NFC debit card. Because random numbers are used to protect against this
attack, an attacker would have to correctly guess the nonce used for a future transaction. Here we can see why it is crucial that these nonces are not predictable34 .
7.5.4 Relay Attack
In a relay attack an attacker captures data from a sender and forwards it somewhere else which is similar to MitM attacks. An example can be drawn with wireless key entry systems. Such systems often start with the lock sending a challenge
to the key. The attacker captures this challenge and forwards it to the victim’s
key. The response of that key will then be relayed to the lock which sees a correct
31
32
33
34
See [Mah11] and [Uta06]
Number used once, a random number.
See [Vit08]
[Mur13] discovered that nonces used in some ATMs are not random enough to be secure. Also there
has recently been some discussion about randomness in [Sch13]
61
7 is it safe?
authentication and opens up. Example attacks on NFC with NFC credit cards or
RFID passports are described in [Fra+11].
This type of attack does benefit from wireless technologies because victims are
often unaware that their key is being used. Several techniques exist to extend the
range of wireless devices making it easier for attackers to hide35 .
Because attackers do not need to steal a digital key or break any encryption, it
is difficult to counter this kind of attack. But because the signal travels a lot longer
then intended by the protocol, it might be possible to set timeouts for function
calls. A call from a NFC reader to a NFC card takes a lot longer then when this
card is far away and messages get processed by the relay system.
Another way to use this kind of attack in a valid scenario was shown by [Hua13].
There a relay was used to develop a payment system which uses digital wallets
on debit cards for online payments. The relay was between the debit card which
was physically at the customer and the payment terminal which is located at the
operator of the online store. The delay introduced by the relay system was no
issue there because the protocol does not specify any timeout parameters.
35 See [KW05]
62
8
CONCLUSION
Goal of this project was to examine if and how the NFC-TAN method could be
used on an iOS device thus providing a secure method for online banking . In
a first step to reach this goal different TAN methods, including NFC-TAN and
chipTAN were introduced. Since NFC on iOS is not yet available and also current
NFC debit cards do not provide all functions needed alternatives like simulating
missing functionality were described which are later used to implement a prototype.
Understanding standards and specifications describing NFC, data formats and
banking protocols were necessary for a successful implementation. These standards were introduced in regard to a following experiment and implementation.
An experiment examined how TANs are generated with the chipTAN method
since the corresponding specification is not openly available.
When implementing the simulative approach earlier introduced, some levels of
abstraction were used to keep the software flexible for future changes or extensions. In case future iOS devices and smartcards provide the functions needed for
NFC-TAN only little adaptions to the software are necessary.
Examples of this flexibility were shown by implementing some modules for
different functionalities. This made it possible to support two TAN methods –
NFC-TAN and chipTAN although no NFC or contact-based card reader was available for iOS devices. Additionally the application was extended to support mobile
banking. The method with which the TAN is generated does not depend on the
way the transaction is initialised. This way any initialisation method1 can be combined with any TAN method2 . It was shown how this application can be further
extended to support more different TAN methods or different smartcards for authentication.
This project then may serve as a basis for other projects which deal with online
or mobile banking, with NFC or contact-based smartcards or any combination of
those.
1 Implemented were scanning QR-Codes, SPAYD-Codes, manually entering startcode and mobile
banking.
2 Here NFC-TAN and chipTAN were implemented.
63
APPENDIX
Listing 1: ITerminalProtocol
1
@protocol I T e r m i n a l P r o t o c o l <NSObject>
2
−(void ) co n ne ct ;
−(void ) c l o s e ;
−(BOOL) isConnected ;
−(NSData ∗ ) t r a n s c e i v e : ( NSData ∗ ) stepName andAPDU : ( NSData ∗ ) apdu ;
3
4
5
6
7
8
@end
Listing 2: BankAccountProtocol
1
@protocol BankAccountProtocol <NSObject>
2
3
4
5
− ( NSString ∗ ) getName ;
− ( NSString ∗ ) getBankID ;
− ( NSString ∗ ) getAccountID ;
6
− ( id ) i n i t W i t h S t r i n g s : ( NSString ∗ ) name
andBankID : ( NSString ∗ ) bankID
andAccountID : ( NSString ∗ ) accountID ;
7
8
9
10
@end
Listing 3: Transaction Interface
1
@ i n t e r f a c e T r a n s a c t i o n : NSObject
2
@property ( readonly ) NSObject <BankAccountProtocol> ∗bankAccount ;
@property ( strong , readonly ) NSDate ∗ date ;
@property ( strong , readonly ) NSString ∗ t r a n s T e x t ;
@property ( readonly ) double amount ;
@property ( readonly ) i n t tan ;
@property ( nonatomic , r e a d w r i t e ) i n t s t a r t C o d e ;
3
4
5
6
7
8
9
− ( id ) i n i t : ( NSObject <BankAccountProtocol> ∗ ) bankAccount
andDate : ( NSDate ∗ ) date
andText : ( NSString ∗ ) t r a n s T e x t
andAmount : ( double ) amount ;
10
11
12
13
14
−
−
−
−
−
15
16
17
18
19
( void ) setTan : ( i n t ) tan ;
( NSString ∗ ) getRecipiantName ;
( NSString ∗ ) g et R e c i p ia n t B a nk I D ;
( NSString ∗ ) g e t R e c i p i a n t A c c o u n t I D ;
( NSString ∗ ) getAmountAsString ;
20
21
@end
Listing 4: URLConnectionHandler
1
@ i n t e r f a c e URLConnectionHandler : NSObject
2
3
4
@property ( readonly ) bool r e s p o n s e A v a i l a b l e ;
@property ( nonatomic , s t r o n g ) NSURL ∗baseURL ;
5
6
− ( id ) initWithBaseURL : ( NSURL ∗ ) baseURL ;
7
8
9
10
− ( NSData ∗ ) s e n d S t r i n g T o S e r v e r : ( NSString ∗ ) s t r i n g
andExtensionURL : ( NSString ∗ ) u r l S t r i n g ;
− ( void ) sendStringToServerAsync : ( NSString ∗ ) s t r i n g
8 conclusion
andExtensionURL : ( NSString ∗ ) u r l S t r i n g ;
− ( NSData ∗ ) getResponseFromAsync ;
− ( bool ) getURLWithString : ( NSString ∗ ) u r l S t r i n g ;
11
12
13
14
15
@end
Listing 5: SmartcardTerminal
1
2
3
4
5
6
7
8
/∗
∗ Thanks f o r help t o :
∗ h t t p ://www. smartcard −magic . n e t /pc−sc −r e a d e r /j a v a −smartcard −i −o−a p i/
∗
∗ Look i n r t . j a r f o r ” j a v a x . s m a r t c a r d i o ” t o g e t f u r t h e r i n f o r m a t i o n
∗ Defined i n : JSR 268
∗/
9
10
p u b l i c c l a s s SmartcardTerminal implements I T e r m i n a l {
11
p r i v a t e Card card ;
p r i v a t e boolean isConnected ;
12
13
14
@Override
p u b l i c byte [ ] t r a n s c e i v e ( byte [ ] data ) throws IOException {
15
16
17
CardChannel channel = card . g e t B a s i c C h a n n e l ( ) ;
18
19
CommandAPDU apdu = new CommandAPDU( data ) ;
20
21
ResponseAPDU r ;
try {
r = channel . t r a n s m i t ( apdu ) ;
} c a t c h ( CardException e ) {
// s i n c e we only have t h e IOException i n t e r f a c e , we use i t .
throw new IOException ( ” CardException ” + e . getMessage ( ) ) ;
}
22
23
24
25
26
27
28
29
System . out . p r i n t l n ( ” response : ”+ r . t o S t r i n g ( ) ) ;
return r . getBytes ( ) ;
30
31
}
32
33
@Override
p u b l i c boolean isConnected ( ) {
r e t u r n isConnected ;
}
34
35
36
37
38
@Override
p u b l i c void c on ne c t ( ) throws IOException {
TerminalFactory f a c t o r y = TerminalFactory . getDefault ( ) ;
L i s t <CardTerminal> t e r m i n a l s ;
39
40
41
42
43
try {
44
terminals = factory . terminals ( ) . l i s t ( ) ;
45
46
f o r ( CardTerminal t e r m i n a l : t e r m i n a l s ) {
47
48
i f ( t e r m i n a l . waitForCardPresent ( 5 0 0 0 ) ) {
t h i s . card = t e r m i n a l . c o nn e ct ( ” T = 1 ” ) ;
49
50
51
ATR a t r = card . getATR ( ) ;
byte [ ] a t r B y t e s = a t r . g e t B y t e s ( ) ;
byte [ ] a t r H i s t B y t e s = a t r . g e t H i s t o r i c a l B y t e s ( ) ;
52
53
54
55
}
}
isConnected = f a l s e ;
}
56
57
58
59
60
61
62
b
t h i s . isConnected = t r u e ;
63
}
64
65
@Override
p u b l i c void c l o s e ( ) throws IOException {
try {
card . d i s c o n n e c t ( t r u e ) ;
}
}
66
67
68
69
70
71
72
73
74
75
p r i v a t e s t a t i c S t r i n g b y t e s T o S t r i n g ( byte [ ] byteArr ) {
S t r i n g B u i l d e r sb = new S t r i n g B u i l d e r ( ) ;
f o r ( byte b : byteArr ) {
sb . append ( S t r i n g . format (”%02X ” , b ) ) ;
}
r e t u r n sb . t o S t r i n g ( ) ;
}
76
77
78
79
80
81
82
83
}
Listing 6: Data Type APDU
1
@ i n t e r f a c e APDU : NSObject
2
−( i d ) initWithCLAandINSandP1andP2 : ( i n t ) c l a
andINS : ( i n t ) i n s
andP1 : ( i n t ) p1
andP2 : ( i n t ) p2 ;
3
4
5
6
7
−( i d ) initWithCLAandINSandP1andP2andData : ( i n t ) c l a
andData : ( NSData ∗ ) data ;
8
9
10
11
12
13
−( i d ) initWithCLAandINSandP1andP2andDataandNe : ( i n t ) c l a
andData : ( NSData ∗ ) data
andLe : ( i n t ) l e ;
14
15
16
17
18
19
20
−( i d ) createAPDU : ( NSString ∗ )command andData : ( NSString ∗ ) data ;
21
22
23
@end
c
D E C L A R AT I O N
Erklärung
Hiermit erkläre ich, dass ich diese schriftliche Abschlussarbeit selbständig verfasst
habe, keine anderen als die angegebenen Hilfsmittel und Quellen benutzt habe
und alle wörtlich oder sinngemäß aus anderen Werken bernommenen Aussagen
als solche gekennzeichnet habe.
Datum,
Ort,
Unterschrift
BIBLIOGRAPHY
[Ada81]
D. Adams. The Hitchhiker’s Guide to the Galaxy. Pocket Books,
1981.
[Alo+13]
Javier Alonso et al. “The potential of mobile banking in
Peru as a mechanism for financial inclusion”. In: BBVA
Working Paper 25.13 (2013).
[And08]
R. Anderson. Security Engineering: A Guide to Building Dependable Distributed Systems. Wiley, 2008.
[Au+11]
Kathy Wain Yee Au et al. Short Paper: A Look at SmartPhone
Permission Models. 2011.
[BF07]
Marc-Andre Beck and Bernd R. Fix. “Smartcard protocol
sniffing”. In: 24th Chaos Communication Congress. 2007. url:
http : / / events . ccc . de / congress / 2007 / Fahrplan /
events/2364.en.html (visited on 08/22/2013).
[BG]
Bernd Borchert and Max Günther. NFC-TAN Demo. url:
http://demo.nfc-tan.com/ (visited on 08/22/2013).
[BG13]
Bernd Borchert and Max Günther. Online Banking with NFCenabled Bank Card. 2013.
[BKA11]
BKA. CYBERCRIME Bundeslagebild 2011. 2011.
[BKA12]
BKA. Cybercrime Bundeslagebild 2012. 2012.
[Bora]
Detlef Borchers. Vor 30 Jahren: Online-Banking startet in Deutschland. url: http://heise.de/-1135331 (visited on 08/22/2013).
[Borb]
Bernd Borchert. Uebersicht Online Banking Verfahren. url:
http://www-ti.informatik.uni-tuebingen.de/˜borchert/
Troja/Online-Banking.shtml (visited on 08/22/2013).
[BSI]
BSI. Welche Gefahren begegnen mir im Netz? – Phishing. url:
https://www.bsi-fuer-buerger.de/BSIFB/DE/GefahrenImNetz/
Phishing/phishing_node.html (visited on 09/09/2013).
[Car]
SmartWerk Technologies. url: http://www.cardwerk.com
(visited on 09/04/2013).
[ČBA12]
Česká bankovnı́ asociace. Standard ČBA - Formát pro sdı́lenı́
platebnı́ch údajů v rámci tuzemského platebnı́ho styku v CZK
prostřednictvı́m QR kódů. 2012. url: https://www.czechba.cz/aktivity/standardy/format-pro-sdileni-platebnichudaju-v-czk-qr-kody (visited on 06/11/2013).
[Ccc]
Chaos Computer Club Frankfurt/Main - Projekt: Tangenerator.
url: http://wiki.ccc-ffm.de/projekte:tangenerator:
start (visited on 06/02/2013).
[Dav+12]
Lucas Davi et al. “Over-the-air Cross-Platform Infection
for Breaking mTAN-based Online Banking Authentication”.
In: BlackHat Abu Dhabi. Dec. 2012.
g
Bibliography
[DTH06]
Rachna Dhamija, J. D. Tygar, and Marti Hearst. “Why phishing works”. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. CHI ’06. Montréal,
Québec, Canada: ACM, 2006, pp. 581–590.
[EMV]
EMVCo. EMV 4.3 Specifications. url: http://www.emvco.
com (visited on 06/02/2013).
[Emv]
EMVLab. url: http : / / www . emvlab . org / emvtags / all/
(visited on 06/02/2013).
[ETSI]
European Telecommunications Standards Institute. url: http:
//www.etsi.org (visited on 09/02/2013).
[Eve92]
David B. Everett. Smart Card Tutorial. 1992.
[Fin08]
Klaus Finkenzeller. RFID Handbuch. Hanser Fachbuchverlag, 2008.
[Fix06]
Bernd R. Fix. “A not so smart card”. In: 23rd Chaos Communication Congress. 2006. url: http://events.ccc.de/
congress/2006/Fahrplan/events/1449.en.html (visited
on 08/22/2013).
[Fli]
chipTAN Flickercodes. url: http://6xq.net/blog/2010/
flickercodes/ (visited on 09/05/2013).
[Fra+11]
Lishoy Francis et al. Practical Relay Attack on Contactless
Transactions by Using NFC Mobile Phones. Cryptology ePrint
Archive, Report 2011/618. http : / / eprint . iacr . org/.
2011.
[Gam09]
Erich Gamma. Design patterns: elements of reusable objectoriented software. Addison-Wesley, 2009, c1995.
[Got12]
Keren Gottfried. Interconnected World: Shopping and Personal
Finance. 2012.
[Gra01]
Sarah Granger. Social Engineering Fundamentals, Part I: Hacker
Tactics. 2001.
[Gra11]
D. Graeber. Debt: The First 5,000 Years. Melville House, 2011.
[Gün11]
Max Günther. “Sicheres Online Banking via Smartphone
mit Nahfunk”. Diploma thesis. University of Tübingen,
2011.
[G06]
Philipp Güring. Concepts against Man-in-the-Browser Attacks.
2006.
[Han]
Handelsblatt. Sparkasse treibt kontaktloses Bezahlen voran. url:
http://www.handelsblatt.com/finanzen/recht-steuern/
anleger-und-verbraucherrecht/ec-karten-sparkassetreibt- kontaktloses- bezahlen- voran/7771378.html
(visited on 08/22/2013).
[Hau10]
Peter Hauck. Vorlesung Codierungstheorie. 2010.
[Hey]
Ayelet Heyman. First SpyEye Attack on Android Mobile Platform Now in the Wild. url: https://www.trusteer.com/
blog/first-spyeye-attack-android-mobile-platformnow-wild (visited on 08/22/2013).
h
Bibliography
[Hua13]
Lei Huang. “Online Bezahlung mit NFC Smartphone und
NFC Geldkarte”. Diploma thesis. University of Tübingen,
2013.
[ISO/IEC 14443-3]
ISO/IEC 14443-3:2011 Identification cards – Contactless integrated circuit cards – Proximity cards – Part 3: Initialization
and anticollision.
[ISO/IEC 14443-4]
ISO/IEC 14443-4:2008 Identification cards – Contactless integrated circuit cards – Proximity cards – Part 4: Transmission
protocol.
[ISO/IEC 18092:2013]
ISO/IEC 18092:2013 Information technology – Telecommunications and information exchange between systems – Near Field
Communication – Interface and Protocol (NFCIP-1). url: http:
//standards.iso.org/ittf/PubliclyAvailableStandards
(visited on 09/04/2013).
[ISO/IEC 7810]
ISO/IEC 7810:2003 Identification cards – Physical characteristics.
[ISO/IEC 7816-2]
ISO/IEC 7816-2:2007 Identification cards – Integrated circuit
cards – Part 2: Cards with contacts – Dimensions and location
of the contacts.
[ISO/IEC 7816-4]
cards – Part 4: Organization, security and commands for interchange. url: http://cardwerk.com/smartcards/smartcard_
standard_ISO7816-4.aspx (visited on 06/02/2013).
[ISO/IEC 7816-8]
cards – Part 8: Commands for security operations.
[iSu]
iSuppli. NFC-Enabled Handsets to Grow Nearly Tenfold from
2012 to 2017. url: http://www.isuppli.com/Mobile-andWireless - Communications / MarketWatch / pages / NFC Enabled - Handsets - to - Grow - Nearly - Tenfold - from 2012-to-2017.aspx (visited on 08/22/2013).
[Jag+07]
Tom N. Jagatic et al. “Social phishing”. In: Commun. ACM
50.10 (Oct. 2007), pp. 94–100.
[KFR10]
Ronald Kainda, Ivan Flechais, and A.W. Roscoe. “Security
and Usability: Analysis and Evaluation”. In: Availability,
Reliability, and Security. 2010.
[KL]
Kaspersky-Lab. History of malicious programs — The beginning - a little archeology. url: http : / / www . securelist .
com/en/threats/detect?chapter=105 (visited on 09/05/2013).
[Kle12]
Amit Klein. Tatanga Attack Exposes chipTAN Weaknesses. 2012.
url: http://www.trusteer.com/blog/tatanga-attackexposes-chiptan-weaknesses (visited on 09/09/2013).
[Kre08]
Deutsche Kreditwirschaft. Belegungsrichtlinien für die Dynamisierung der TAN v1.3. 2008.
[KW05]
Ziv Kfir and Avishai Wool. Picking Virtual Pockets using
Relay Attacks on Contactless Smartcard Systems. Cryptology
ePrint Archive, Report 2005/052. 2005.
i
Bibliography
[Mah11]
Moustafa Mahmoud. The worst of all worlds. 2011. url: http:
//www.securi.me/2011/insight/the- worst- of- allworlds/ (visited on 09/09/2013).
[Man]
Urs Mansmann. Angriffe auf mit mTAN geschützte Konten.
url: http://heise.de/-1928312 (visited on 09/22/2013).
[McD13]
Mindi McDowell. Security Tip (ST04-014) - Avoiding Social
Engineering and Phishing Attacks. 2013. url: http://www.
us-cert.gov/ncas/tips/ST04-014 (visited on 09/09/2013).
[MS13]
Christopher Meyer and Jörg Schwenk. Lessons Learned From
Previous SSL/TLS Attacks - A Brief Chronology Of Attacks
And Weaknesses. Cryptology ePrint Archive, Report 2013/049.
2013.
[Mur11]
Steven J. Murdoch. Chip and PIN: 5 Years On. 2011. url:
http://www.cl.cam.ac.uk/˜sjm217/ (visited on 09/05/2013).
Steven J. Murdoch. Banking security: attacks and defences.
2013. url: http://www.cl.cam.ac.uk/ ˜sjm217/ (visited
on 09/09/2013).
[Mur13]
[nij]
nij. Kein groes Smartphone-Betriebssystem vor US-Geheimdienst
sicher. url: http://heise.de/-1952156 (visited on 09/09/2013).
[Noh13]
Karsten Nohl. Rooting SIM cards. 2013. url: https : / /
srlabs.de/rooting-sim-cards/ (visited on 09/05/2013).
[Ora13]
Oracle. JavaTM Smart Card I/O API. 2013. url: http : / /
docs.oracle.com/javase/7/docs/jre/api/security/
smartcardio/spec/javax/smartcardio/package-summary.
html (visited on 06/02/2013).
[Pen09]
RedTeam Pentesting. Man-in-the-Middle Attacks against the
chipTAN comfort Online Banking System. 2009.
[Plö08]
Henryk Plötz. “Mifare Classic — Eine Analyse der Implementierung”. Diploma thesis. Humbold-Universität zu
Berlin, 2008.
[PN]
Chris Paget and Karsten Nohl. GSM: SRSLY?
[Pre]
Cambridge University Press. Cambridge Business English
Dictionary. url: http : / / dictionary . cambridge . org /
dictionary / business - english / electronic - banking
(visited on 08/22/2013).
[Pri11]
Tim Pritlove. CRE 179: GSM Security. 2011. url: http://
cre.fm/cre179-gsm-security (visited on 09/05/2013).
[Ran]
Wolfgang Rankl. The Smart Card Tables. url: http://www.
wrankl.de/SCTables/SCTables.html#AIDRID (visited on
08/22/2013).
[Ran04]
Wolfgang Rankl. Command Searcher. 2004. url: http : / /
www.wrankl.de/JavaPC/JavaPC.html (visited on 09/01/2013).
[RE08]
Wolfgang Rankl and Wolfgang Effing. Handbuch der Chipkarten: Aufbau - Funktionsweise - Einsatz von Smart Cards.
Hanser Fachbuchverlag, 2008.
j
Bibliography
[Red]
RedTeam. New banking security system iTAN not as secure as
claimed. url: https://www.redteam-pentesting.de/en/
advisories/rt-sa-2005-014/-new-banking-securitysystem - itan - not - as - secure - as - claimed (visited on
08/22/2013).
[Roa12]
Patrick Roanhouse. Proof of Concept shows how to make your
own GSM phone network using £35 Raspberry Pi. 2012. url:
http://www.plan8.tv/201212221050/proof-of-conceptshows - how - to - make - your - own - gsm - phone - network using-35-raspberry-pi (visited on 09/15/2012).
[Rob]
Steve Robson. Six of the worlds seven billion people have mobile phones... url: http://www.dailymail.co.uk/news/
article-2297508/Six-world-s-seven-billion-peoplemobile-phones--4-5billion-toilet-says-UN-report.
html (visited on 08/22/2013).
[Rou]
Ludovic Rousseau. Smart card ATR parsing. url: http://
smartcard-atr.appspot.com/ (visited on 09/02/2013).
[Sat12]
Matthias Sattler. “Einbinden der neuen NFC-Debitkarte in
das Fotohandy-Verfahren”. Diploma thesis. University of
Tübingen, 2012.
[Sch09]
Andreas Schiermeier. TAN-Generatoren mit optischer Schnittstelle
(Flickercode). 2009. url: http://bitinfarkt.de/chiptan/
26C3_chiptan_slides.pdf (visited on 08/22/2013).
[Sch10]
Bruce Schneier. When Security Gets in the Way. 2010. url:
http://jnd.org/dn.mss/when_security_gets_in_the_
way.html (visited on 09/05/2013).
[Sch12]
Andreas Schiermeier. “Vom Überweisungsauftrag zur TAN”.
In: embedded projects Journal (15 2012), pp. 16–25. url: https:
//journal.embedded-projects.net/index.php?module=
archiv&action=pdf&id=17.
[Sch13]
Bruce Schneier. Surreptitiously Tampering with Computer Chips.
2013. url: https://www.schneier.com/blog/archives/
2013/09/surreptitiously.html (visited on 09/22/2013).
[SH]
Christiane Schulzki-Haddouti. BKA: iTAN-Verfahren keine
Hürde mehr für Kriminelle. url: http://heise.de/-219497
(visited on 08/22/2013).
[She12]
Steve Sherretta. What does mobile banking mean for banks?
Knowledge@Wharton, 2012.
[SIT]
Fraunhofer-Institut SIT. Liste der RID-Kennungen. url: http:
//www.kartenbezogene- identifier.de/de/rapi/ridliste.html (visited on 08/22/2013).
[SJH11]
Marcus-Sebastian Schröder, Florian Junge, and Jonas Heer.
Security through Sandboxing? - Towards more secure smartphone platforms. 2011.
[Sou]
Symposium On Usable Privacy and Security. url: http : / /
cups.cs.cmu.edu/soups (visited on 09/05/2013).
k
Bibliography
[SW08]
Dieter Spaar and Harald Welte. Running your own GSM network. 2008. url: http://events.ccc.de/congress/2008/
Fahrplan/events/3007.en.html (visited on 09/05/2013).
[Uta06]
Nattakant Utakrit. A Review of Browser Extensions, a Manin-the-Browser Phishing Techniques Targeting Bank Customers
Abstract. 2006.
[Vit08]
Jan Vitense. “Sichere Transaktionen beim Online-Banking”.
Diploma thesis. University of Tübingen, 2008.
[Wei12]
Olesja Weidmann. “Einbinden des nPAs in das FotohandyVerfahren mittels NFC”. Diploma thesis. University of Tübingen,
2012.
[Wg8]
ISO/IEC JTC1/SC17/WG8 ”Contactless Integrated Circuit Cards”.
url: http://wg8.de (visited on 09/05/2013).
[Zho12]
Tao Zhou. “Understanding users initial trust in mobile
banking: An elaboration likelihood perspective”. In: Computers in Human Behavior 28.4 (2012), pp. 1518 –1525. url:
http://www.sciencedirect.com/science/article/pii/
S0747563212000878.
[Zue]
CCC Zuerich. Postcard - Sicherheit ? url: http : / / www .
postcard-sicherheit.ch/ (visited on 08/22/2013).
l

Online Banking

Transcription

Similar documents

Flexible Anbindung von Smartcards an eine

WISO Mein Geld

Schnelle 2-D/3-D-Registrierung medizinischer

CHIP Bankentest 2009

Erfahrungsbericht HongKong

Housing and segregation of migrants: Case study

kundenbedingungen für hvb kreditkarten