Wilhelm Schickard Institute of Computer Science

Theoretical Computer Science

Online BankingTAN Generation via Smartphone

Author:Robert Finze

Supervisors:Dr. Borchert

Prof. Reinhardt

September 25, 2013

C O N T E N T S

1 introduction 11.1 Structure 1

2 tan methods used for online banking 32.1 Mobile Banking 32.2 How are TANs generated 5

2.2.1 TAN / iTAN List 52.2.2 mTAN 72.2.3 crontoSign 82.2.4 chipTAN 102.2.5 NFC-TAN 12

3 nfc smartphones and nfc chip cards 154 standards , norms and specifications 19

4.1 ISO/IEC 7816 204.2 ISO/IEC 7816-2 204.3 ISO/IEC 7816-3 21

4.3.1 Protocol T=0 214.3.2 Protocol T=1 224.3.3 ATR 23

4.4 ISO/IEC 7816-4 244.4.1 Command APDU 244.4.2 Response APDU 25

4.5 ISO/IEC 14443 254.5.1 ISO/IEC 14443-3 264.5.2 ISO/IEC 14443-4 27

4.6 ISO/IEC 18092 284.7 HHD 28

4.7.1 Startcodes 294.8 EMV 30

5 the birth of a tan 315.1 Test Environment 315.2 Sniffing a TAN generation 33

6 implementing a prototype 416.1 Environment 416.2 Structure 42

6.2.1 Proxy Server 456.2.2 Mobile Application 466.2.3 Helping Hands 51

6.3 Extension: Mobile Banking 527 is it safe? 53

7.1 Attacks on NFC-TAN 547.1.1 Malware on PC 557.1.2 Malware on Phone 567.1.3 Theft 577.1.4 Communication Interfaces 57

i

Contents

7.2 Social Engineering 587.3 GSM Security 597.4 Keeping Secrets Secret 597.5 Common Attacks Explained 60

7.5.1 Man-in-the-Middle 607.5.2 Man-in-the-Browser 617.5.3 Re-, Preplay 617.5.4 Relay Attack 61

8 conclusion 63

ii

L I S T O F F I G U R E S

Figure 1 Mobile Banking TAN Methods 4Figure 2 Online Banking TAN Methods 6Figure 3 Protocol with TAN Lists 6Figure 4 mTAN Protocol 7Figure 5 photoTAN reader and crontoSign application 8Figure 6 crontoSign Protocol 9Figure 7 chipTAN comfort TAN generator 10Figure 8 chipTAN Protocol 11Figure 9 Flickercode 11Figure 10 Parts of NFC-TAN 13Figure 11 protocol of tan generation 14Figure 12 Original NFC-TAN 15Figure 13 NFC-TAN without NFC smartphone 17Figure 14 NFC-TAN with Proxy 17Figure 15 Contacts of a chip card 20Figure 16 T=0 block structure 21Figure 17 T=1 block structure 22Figure 18 Structure of a complete command APDU 24Figure 19 Structure of a response APDU 25Figure 20 Structure of a block according to ISO/IEC 14443-4 27Figure 22 Wired TAN Generator 31Figure 21 Devices used to sniff communication between card and TAN

generator 32Figure 23 Smartcard readers. Left ReinerSCT cyberJack RFID komfort

and right gemalto PC USB-SL 42Figure 24 Parts of NFC-TAN 43Figure 25 NFC-TAN Proxy Summary 43Figure 26 protocol of tan generation with proxy 44Figure 27 Proxy Server Summary 46Figure 28 Mobile Application Classes 48Figure 29 Abstract Transaction Init Classes 48Figure 30 QR Codes 49Figure 31 Abstract TAN Generator Classes 49Figure 32 Abstract card reader classes 50Figure 33 Process of creating a TAN 51

iii

L I S T I N G S

5.1 BusPirate UART Paramerters . . . . . . . . . . . . . . . . . . . . . . . 335.2 Transaction Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1 Assigning a URI to a Java Method . . . . . . . . . . . . . . . . . . . . 456.2 ITerminal Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.3 Public interface of TransactionObject . . . . . . . . . . . . . . . . . . . 47

1 ITerminalProtocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a2 BankAccountProtocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . a3 Transaction Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . a4 URLConnectionHandler . . . . . . . . . . . . . . . . . . . . . . . . . . a5 SmartcardTerminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . b6 Data Type APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . c

v

A C R O N Y M S

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 fur Sicherheit in der Informationstechnik (Federal Office forInformation 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 Special 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

1I N T R O D U C T I O N

This work belongs to a series of other projects1 which all concern themselves withonline banking and methods of generating TANs.

Goal of this project is to create an implementation of NFC-TAN2 for iOS3 devicesthus enabling users to do online banking with their iOS device and a NFC debitcard 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 anunderstanding of details involved in successfully placing an online transaction.

Main challenges were iOS currently not providing NFC support and NFC debitcards only providing limited access. When developing ideas to overcome thesechallenges, other projects were found which in the end each contributed parts toa very flexible solution. This solution consists of simulating not available features.NFC debit cards were substituted with [Sat12]s eKaayDebitCards and NFC wasadded to iOS with a proxy solution to which [Gun11] provided a some ground-work. Having this already flexible concept, [Ccc]s experiment was repeated andincluded in this project to extend its application.

Online banking is a field with high security requirements and TAN methodsexist solely to prevent fraud and abuse in online banking scenarios. Differentattacks and defences will be discussed to show not only how TANs add securitybut also how TAN methods itself can be target of an attack.

1.1 structure

Following chapters will provide necessary information needed to understand tech-nologies and methods used in this project. Starting with a description of whatTANs are and how they are used, we then discuss some current methods to createTANs in chapter 2 including a new approach NFC-TAN. Chapter 3 describessome difficulties encountered in this project like NFC currently not being sup-ported on iOS devices. Some possible solutions are introduced and one of thesesolutions will be implemented in chapter 6. Chapter 4 gives an introduction tostandards and specifications associated with used technologies which are mainlychip cards and NFC. Also some specifications about banking protocols are men-tioned.

1 Especially [Sat12] and [Gun11]2 See http://nfc-tan.com, [BG13] and section 2.2.53 iOS iPhone Operating system

1

http://nfc-tan.com

1 introduction

A currently widely used TAN method is chipTAN. When implementing thismethod, a central question is how exactly are these TANs generated. Details onthis will be given in chapter 5 which is based on previous work of [Ccc]. With theirhelp it was possible to repeat their experiment and create a software implementa-tion with the results.

The concept and some details of the implementation will be described in chap-ter 6

At the end chapter 7 takes a look at security issues of TANs used in online bank-ing. By discussing possible attacks on NFC-TAN and other systems it is explainedhow they could be anticipated. If some attacks are still possible suggestions tosolutions are given. Additionally a short introduction to some standard attackscenarios are given.

2

2TA 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 ofusing the internet to organise, examine, and make changes to bank accounts, in-vestments, etc1. So instead of having to go to a bank during their opening hours,people can do their banking whenever they have time. The obvious advantagesof online banking has led many people to do most of their every-day bankingonline2.

Even before online banking the idea of a TAN, additionally to the PIN wasdeveloped3. A TAN is an one-time password which is used to authorise a spe-cific transaction. For each transaction a new TAN is used and only with that thetransaction will be carried out.

Today people doing online banking are most likely familiar with the concept ofa TAN since every time a transaction is submitted a TAN is needed to authorisethat transaction. Early TAN methods didnt completely prevent fraud so bankshave been working on new methods to counter attacks which then attackers againadopted to.

For online banking people can choose to either install an application which runson their PC and communicates with their bank or use the banks website. The firstapproach is done in Germany via the FinTS4 protocol and functions differentlyfrom the web-based method. In this work only the web-based online banking willdiscussed, keeping in mind that the arguments here might not apply to standaloneapplications for online banking.

2.1 mobile banking

Mobile banking is the next iteration after online banking. Smartphones are becom-ing more and more a part of our everyday life and with them we are getting usedto always being online. People may want to check their account balance beforedeciding to buy goods or want to transfer money while sitting in a cafe. In itsfeatures and security issues mobile banking can be compared to online bankingwith a PC because thats basically what smartphones are.

All people need for mobile banking is a device with internet access. Banksusually provide an application which makes common services easier to use but formost tasks a web browser is sufficient. Having only one device all security risksthat apply to online banking on a PC also apply to mobile banking. One might

1 [Pre]2 [Got12]3 [Bora]4 Financial Transaction Services, formerly known as HBCI Homebanking Computer Interface

3

2 tan methods used for online banking

argue that applications on smartphones are sandboxed5 and therefore more securethan common applications on PCs but this argument is deceiving6. Althoughpeople seem to be aware of the potential risks of mobile banking7, nonethelessit might likely be very common in a few years. Especially in emerging marketsmobile banking provides access to banking services for people who otherwisemight be excluded from banking services at all8.

Again the question arises which TAN method to choose. Figure 1 shows asummary of the most common TAN methods used in mobile banking ordered tosecurity and usability.

Usability

Security

secure

little risk

medium risk

high risk

insecure

very insecure

available today

ChipTAN

iTAN

SMS-TAN

App-TAN

SIM-TAN

NFC-TAN

PIN only

requirements fullledrequirements not yet fullled

PushTAN

Figure 1: Mobile Banking TAN Methods9

Although SMS-TAN (or mTAN) has a rather good usability it is very insecurewhen using mobile banking. A main feature of mTAN is the two-channel authen-tication when doing online banking. Since mTAN uses only a mobile device thereis no second channel. This led some banks prohibiting mTAN when doing mobilebanking. Other methods like App-TAN or SIM-TAN where the TAN is createdusing a secret key stored within the memory of the application or the SIM cardprovide a high usability. They are however object to other attacks. Since the TANis generated on the phone without external accessories, users might not notice ifmalware creates TANs in the background, sends them to an attacker or uses themto 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 applica-tion. Attackers then can copy the secret and create TANs whenever they chooseto10. 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 Tubingen, 2013

10 More on malware on smartphone in section 7.1.2 on page 56

4

2.2 How are TANs generated

But handling these lists has serious usability implications. ChipTAN offers a goodlevel of security because it offers a two-channel authentication also when doingmobile banking. Though users have to carry around an additional device. HereNFC-TAN tries to close the bridge between security and usability. People do notneed to carry an extra device and malware can not steal the secret to create TANssince it is not stored on the phone. This method however might be subject to mal-ware and phishing11 attacks, e.g. Man-in-the-Browser, where different transactiondata 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 fixissues with previous methods and after an adoption period to each method new at-tacks 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 arerelatively unmanageable but provide better security than no TAN. The photoTANmethod provides good usability but has security issues if the smartphone getsinfected with malware. A better way would be to use the SIM card as securestorage. SIM cards are managed by network providers so it is less easy to set upbecause two companies are involved and there will be organisational overhead.Mobile TANs are also prone to malware on smartphones but are relatively easy toset up. ChipTAN is considered a very secure method because debit cards providea secure storage and TAN generators are hard to compromise. Although in orderto use chipTAN users do need to carry an extra device around. NFC-TAN providesa good usability by using a smartphone for authentication together with a debitcard as secure storage.

2.2.1 TAN / iTAN List

When online banking was introduced probably most banks used simple lists ofpre-generated TANs which were sent to customers in a letter. With each transac-tion customers choose any TAN from that list for authorisation. The bank thenchecks if that TAN was a number from the list sent to the customer and could ac-knowledge or deny that transaction. An outline of this simple procedure is shownin fig. 3.

With an increasing number of phishing attacks13 where customers were trickedin 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 trans-action. This makes an attack harder since the attacker does not know in advancewhich iTAN will be required. Thus phishing attacks where stolen TANs are usedto authorise transactions are made more difficult. The introduction of this systeminitially had a significant effect on cybercrime statistics. In Germany the numberof phishing cases dropped about 57%14 when this system was introduced. How-

11 See section 7.212 Figure adopted from Dr. B. Borchert, University of Tubingen, 201313 See section 7.2 on page 5814 From 4164 in 2007 down to 1778 in 2008.

5

2 tan methods used for online banking

Usability

Security

secure

little risk

medium risk

high risk

insecure

ChipTAN

NFC-TAN

iTAN

PIN only

PhotoTAN b)mTAN

PhotoTAN a)

a) credential on SIM cardb) credential in application memory

Figure 2: Comparison of TAN methods for online banking12

Bank PC TAN List

1

2

3

4

5

Figure 3: 1 create transaction; 2 request TAN; 3 customer chooses a TANfrom list; 4 send TAN to bank; 4 transaction successful

6

2.2 How are TANs generated

ever after this initial drop attackers adopted rather quickly and the number ofcases and total amount of money stolen rose again15. This shows that also withiTANs customers are not safe from attacks like Man-in-the-Middle16. A weaknessof both systems is that when letters with those lists are stolen. An attacker is thenable to authorise as many transactions as are TANs on that list.

With the advent of mobile computers and people wanting to do online bankingaway from home, TAN lists became very unhandy because they always had to becarried around. This also made them easier to get stolen. For some years nowworking 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 accessto mobile phones18 so it is possible to send TANs to customers mobiles when atransaction is made. Figure 4 shows the basic steps for placing a transaction. Themain difference to fig. 3 is the source of the TAN. Here the TAN is sent to thecustomer just after a transaction had been created and only the currently neededTAN is created.

Bank PC 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 trans-action successful

This was believed to be more secure because no paper lists could be stolen andalso pre-generated TANs for future use dont exist. Statistics by the BKA19 showthat after mTAN had been widely adopted a decline in phishing attacks in onlinebanking of about 40% was noticed20. TANs could not easily get stolen becausecustomers did not have any laying around. Only the currently needed TAN issend to the customer.

Man-in-the-Middle attacks where the computer had been compromised andshowed false transaction data were countered by sending not only the TAN to

15 See [BKA11]16 Man in the Middle attacks are described in section 7.5.1 on page 6017 See [SH] and [Red]18 [Rob]19 BundesKriminalAmt (Federal Criminal Police Office)20 See [BKA12]

7

2 tan methods used for online banking

the customer but also the recipient and amount. Customers were then able toverify the transaction data before entering the TAN. If a mobile phone gets stolensimilar attacks are possible as were with stolen TAN lists. People tend to pay moreattention to their mobile than to a sheet of paper so a stolen mobile gets lockedfairly quickly by the owner and no TANs can be received anymore.

With mTANs attackers are provided new attack vectors. Possible attack targetsare SIM cards, mobile phones or the communication channel which is very oftenGSM. Some examples on how these attacks could work are outlined section 7.1.2and section 7.3.

2.2.3 crontoSign

In search for new and more secure methods to authorise online transactions, ateam of the University of Cambridge developed a new protocol to generate trans-action numbers called crontoSign21. Goal was to develop a method that is easyto use and yet not frail to a Man-in-the-Browser attack22. Developed in cooperationwith the German Commerzbank crontoSign has recently been sold to a companyspecialising in authentication products23. This shows that interest in secure TANsis 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 TANthan is used to create transactions. TANs are created by the customer alone and areonly send to the bank as an authorisation code. Banks do not need to send TANs tocustomers which removes the risk of stolen or captured TANs. One advantage ofcrontoSign is that a smartphone is used to generate TANs. Smartphones are widelyadopted and users usually always have their smartphones at hand. Also do theyprovide 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 additionaldevice for online banking is needed. People not having a smartphone can use a

21 See http://www.cronto.com/ andhttp://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 6123 http://www.businessweekly.co.uk/hi-tech/15425-cambridge-university-spin-out-sold-

for-22m/24 http://www.cronto.com/commerzbank-and-cronto-launch-phototan-for-secure-online-

banking-transactions.htm/

8

http://www.cronto.com/http://www.cam.ac.uk/research/news/new-system-to-combat-online-banking-fraudhttp://www.businessweekly.co.uk/hi-tech/15425-cambridge-university-spin-out-sold-for-22m/http://www.businessweekly.co.uk/hi-tech/15425-cambridge-university-spin-out-sold-for-22m/http://www.cronto.com/commerzbank-and-cronto-launch-phototan-for-secure-online-banking-transactions.htm/http://www.cronto.com/commerzbank-and-cronto-launch-phototan-for-secure-online-banking-transactions.htm/

2.2 How are TANs generated

special device25 which runs the smartphone application however mitigatingthe advantage of not needing another device to carry around. Using two separatedevices to create a TAN is called a two-channel-authentication.

To generate a TAN the bank shows the customer an image in which transactiondata is encoded. A smartphone with a crontoSign application then decodes thisimage and displays data for customers to verify it. Together with the transactiondata a TAN is generated and displayed. If everything seems to be correct cus-tomers 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 thecomputer customers are able to notice this because the modified transaction datawould be shown on the phones display.

Bank PC 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]. Therebanks create a TAN when customers initially create a transaction. This TAN to-gether with the transaction data is encrypted with a secret key which is stored onthe customers smartphone. The encrypted data is shown on the website encodedin an image. An application on the smartphone then decodes and decrypts thisimage and displays all containing data, which includes the TAN.

Either way malware on the smartphone poses a threat because the secret keyis always stored in application memory on the phone. Malware which is able toaccess that data can also use or copy the secret key. SpyEye has shown that smart-phones are prone to malware attacks26. Once infected with malware phishing orMan-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 tan methods used for online banking

2.2.4 chipTAN

A different approach to counter problems with iTAN letters was made with thechipTAN method which has been introduced shortly before crontoSign28. It is alsoa two-channel authentication method with an additional device called TAN gen-erator or HHD29 shown in fig. 7. The difference is that the key used to generatea TAN is not stored in the device itself but instead the customers debit card30 isused as secure storage.

Figure 7: chipTAN comfortTAN generator

As before the user fill out a transac-tion form at their online banking web-site. After that a number calledstartcode31 is displayed which thenhas to be entered in the TAN gen-erator. This startcode contains someinformation about the type of thetransaction and a random number nonce32. Together with the start-code the user enters the transactiondata, e.g the amount and recipientinto the TAN generator. With thisinformation and a debit card the de-vice can generate a TAN which is dis-played.

A summary of the protocol is shownin fig. 8 and will be described in detailin chapter 5. All details of this processare described in the SECCOS Specifi-cations33 which are available from theBank Verlag34 for a fee35.

Because the exact specification ofthis protocol are not publicly available,some groups started to look at the communication between reader and cards andattempted to reverse engineer this protocol with some insightful results. Thesegroups were namely [Ccc], [Fix06], [BF07] and [Zue]. Some of their results areused in chapter 5.

28 ChipTAN has been introduced around 2006 even though many features like the optical inter-face have been introduced until 2010. CrontoSign started development in 2008 http://www.chipcardmaster.de/smarttanchiptan.htm

29 HandHeld Device30 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.132 Number used Once - a random number which is only used once.33 Schnittstellenspezifikationen der ZKA-Chipkarte34 http://www.bank-verlag.de/35 This is not a licence fee but the fee for the login to the download page.

10

http://www.chipcardmaster.de/smarttanchiptan.htmhttp://www.chipcardmaster.de/smarttanchiptan.htmhttp://www.bank-verlag.de/

2.2 How are TANs generated

Bank PC 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 cal-culate TAN from cryptogram; 7 final TAN; 9 enter TAN into online

banking website; 9 sent data to bank; 10 transaction successful

To further improve usability a different way of getting transaction data into theTAN generator was developed called Flickercode36. After filling out a transactionform on the website an image is shown which contains five stripes that switchbetween black and white as seen in fig. 9. Flickercodes are described in detailin [Sch09] and [Fli]. The TAN generator is modified to read this Flickercode andso data can be transferred from the computer to the TAN generator without havingto enter them manually. Transaction data is shown in the display of the device andcan 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 epilepsythe manual method of entering data is alternatively provided.

cloc

k

bit

1 /

5

bit

2 /

6

bit

3 /

7

bit

4 /

8

Figure 9: Flickercode image: first bar gives clock signal, then every clock four bitare 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 TANis 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

2 tan methods used for online banking

the victims online banking website but also access to the debit card. Some knownattacks do not attack the smartcard or TAN generator but rather exploit the sizeof the small display of the generator and with that the limitations and decisionswhat data to show to customers37. These are typically Man-in-the-Middle or Man-in-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 andwas developed by [BG]. The idea is to use NFC debit cards and a NFC smartphoneto generate TANs for online banking and so providing a method with good secu-rity and good usability. Since smartphones with NFC capabilities are getting morecommon38 and NFC debit cards are already being rolled out39 these requirementsshould be met in the near future40.

Figure 10 on page 13 shows all parties involved in creating a TAN which aresimilar to chipTAN41. After logging in to the banks website information abouta transaction needs to be transferred from a PC to a smartphone. This is eitherdone manually be the user or by scanning a QR-Code. The phone then commu-nicates with a NFC smartcard to calculate the corresponding TAN which will bedisplayed 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 andauthenticates the transaction.

A more detailed view of the NFC-TAN protocol is shown in fig. 11. To illustratethis a use case is used. To successfully complete a transaction a customer Claraneeds to log in into her online banking account 1 . The bank server checks hercredentials and then provides access to the online banking forms 2 . She thenputs in the information to the transaction she wants to make 3 and receives astartcode42 4 . This startcode can be coded, for example in a Flickercode43, in aQR-Code44 or just be given as plain number. Then she uses the NFC-TAN appli-cation on her smartphone 5 and enters the startcode and transaction data45 inthe NFC-TAN application on her smartphone. Now Clara needs to hold her NFCdebit card close to the phone. The phone starts sending the startcode and all trans-action data to the card via NFC in several steps 6 and at the end receives a bytestring 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 TANis shown on the phones display together with the original transaction data to let

37 See [Pen09]38 [iSu]39 [Han]40 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.41 For chipTAN see section 2.2.442 Details of the startcode are explained in section 4.7.1 on page 29.43 See section 2.2.4 on page 1044 [CBA12] would be one example coding.45 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.46 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 discussedin detail in chapter 5 on page 31

12

2.2 How are TANs generated

12437

123.45

Rent

Recp

Am

Txt

12437

123.45

Rent

Recp

Am

Txt

TAN

12437

123.45

Rent

Recp

Am

Txt

TAN

a

b

c

d

Bank PC

SmartphoneNFC Card

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

2 tan methods used for online banking

Clara verify if this is the transaction she intended to do. If everything is correctshe 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 thesame 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 modificationof this process would be to let the phone sent the TAN directly to the bank afterClara checked if the transaction data is correct. This way Clara doesnt need toenter the TAN manually in the online banking form. More on NFC-TAN can befound in [Sat12, chap. 4] and [BG13].

Bank PC Phone Card

1

2

3

4

5

6

7

8

910

11

12

Figure 11: 1 login at bank; 2 success; 3 create transaction; 4 startcode; 5

startcode + transaction data; 6 startcode + transaction data; 7 ap-

plication cryptogram; 8 generate TAN; 9 TAN; 10 TAN; 11 TAN;

12 transaction successful

Compared to mTAN or photoTAN more security is gained by separating thedevice which generates TANs from the device which stores the secret key usedto generate them. In this way it is similar to chipTAN but with added usabilitybecause 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 severalTANs are generated on the bank side because the cards TAN depends on an internal counter. Detailswill be shown in section 5.2

14

3N 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 foundedin 2004. Although first specifications have been available since 2006 it took arelatively long time until enough NFC devices were available to make an impacton the market. In the last years many new smartphones were introduced whichhave built-in NFC capabilities and this trend seems to continue2. Except Apple,all major smartphone manufactures and operating systems support NFC. Androidseems 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 imple-menting the NFC-TAN method introduced in section 2.2.5 hardware which sup-ports NFC is needed. Namely a chip card which is accessible via NFC and asmartphone 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 whichplatform to develop for. Android or iOS are the obvious choices sine they have thebiggest market share5. Android the operating system (OS) of choice in a previouswork about NFC-TAN done by [Sat12]. In this project iOS is chosen to show thatNFC-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 thefact that current debit cards do not support the generation of a TAN via the NFCinterface6. And a second one is that iOS currently doesnt feature NFC natively.

1 http://www.nfc-forum.org2 http://blogs.synopsys.com/theeyeshaveit/2012/03/26/non-volatile-memory-technology-

for-nfc-enabled-smartphones/3 http://en.wikipedia.org/wiki/List_of_NFC-enabled_mobile_devices4 Near Field Communication5 http://www.statista.com/topics/876/android/chart/1366/smartphone-os-market-share/6 Currently only the digital wallet application is supported.

15

http://www.nfc-forum.orghttp://blogs.synopsys.com/theeyeshaveit/2012/03/26/non-volatile-memory-technology-for-nfc-enabled-smartphones/http://blogs.synopsys.com/theeyeshaveit/2012/03/26/non-volatile-memory-technology-for-nfc-enabled-smartphones/http://en.wikipedia.org/wiki/List_of_NFC-enabled_mobile_deviceshttp://www.statista.com/topics/876/android/chart/1366/smartphone-os-market-share/

3 nfc smartphones and nfc chip cards

The first point is more an organisational than a technical one. Debit cards cur-rently issued already feature an NFC interface and also support the TAN applica-tion via a contact based interface. Having this it is only a matter of access rightsto also make the TAN application accessible via NFC. No hardware changes arenecessary and software changes are minimal. Because those software changescan only be done by the banks who issue those card an alternative was needed.[Sat12] developed a java card called eKaayDebitCard which implements the TANapplication according to the same specifications as regular debit cards as closelyas possible and also providing a NFC interface. Using these eKaayDebitCards itis possible to simulate how the entire system would behave if a regular NFC debitcard from a bank were available. Figure 12 on page 15 still applies but now theNFC debit card is exchanged with a eKaayDebitCard.

The second issue iOS not supporting NFC has several possible solutions. Away 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 witheither the availability or with the provided feature set. One adaptor7 seems toprovide all necessary functionality. Unfortunately it was not possible to find a re-seller which sells the adaptor with SDK. Efforts trying to contact the manufacturerdirectly were not successful. Emails werent 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 andshipment was supposed to start in April 2013. Problems in production delayed theshipment 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 supportall 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 thesmartphone. Such a NFC reader has recently been announced as a developer de-vice from ReinerSCT10. Unfortunately it has only become available in late Augustso there was no time to evaluate this solution. Figure 13 on page 17 shows howthe original idea of NFC-TAN would change when the smartphone doesnt sup-port NFC. Either a NFC hardware adaptor needs to be used to connect to a NFCdebit 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 touse this simulated NFC reader instead of a native reader.

Having no direct approach to use NFC on iOS an indirect way to connect toa card reader was needed and for that a proxy pattern11 was chosen. The proxyserver is connected to a physical card reader and provides a web interface. Whena client send data to the web interface the proxy forwards all data to the cardreader. The mobile client can then communicate with a card as if it were locallyconnected. An application on the smartphone can send and receive data via WiFi

7 iCarte http://www.icarte.ca8 http://flomio.com/flojack/9 At least not directly.

10 http://www.reiner-sct.com/produkte/chipkartenleser/cyberjack_wave.html11 See [Gam09]

16

http://www.icarte.cahttp://flomio.com/flojack/http://www.reiner-sct.com/produkte/chipkartenleser/cyberjack_wave.html

Bluetooth CardreaderSmartphone

NFC DebitcardSmartphone

Figure 13: When smartphone doesnt support NFC other ways of connecting to theNFC debit card have to be found; here bluetooth or hardware dongles.

to the card reader. More details about design and implementation of this proxyare found in chapter 6 on page 41.

In fig. 14 we see how this double simulation looks like. On one side a NFC debitcard is simulated using by a eKaayDebitCard and on the other side a local NFCreader is simulated by using our proxy server approach.

USB CardreaderProxySmartphone

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 orcontact based smartcards. To show the flexibility of this approach besides NFC-TAN another TAN method is implemented chipTAN. This is useful because regu-lar debit cards can be used additionally to the also supported eKaayDebitCards.

Although contact based readers for smartphones exist12, these companies onlysell a service and not hardware which means that it is not possible to get access tothe API of the hardware card readers.

12 https://www.izettle.com orhttps://sumup.de/

17

https://www.izettle.comhttps://sumup.de/

4S 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 contactwith even more standards, norms and specifications describing and defining thosetechnologies. This chapter will introduce some of them and point out why andhow they are important for this project. We wont however go into the details ofdifferences between these three terms1 and just take them as something that needsto be fulfilled in order to create a working application. All three terms will herebe used interchangeably and without semantic difference.

To list all involved standards and describe them thoroughly would be out ofscope and could possibly distract from the goal of giving information needed forthe following chapters. Though all necessary standards will be mentioned andrelations between them shown. Because some standards are not publicly or freelyavailable, references about those standards are used. Most information is takenfrom [RE08] who provides a complete introduction chip cards in general and alsoto standards in particular. CardWerk Technologies2 provide comments about partsof ISO/IEC 7816 which are helpful. Being a bit older [Eve92] still applies andgives information about chip cards and standards used here. Although here notecovered, one might find useful details about otherwise non accessible informationin the GSM specifications3 because chip cards used for debit cards and SIM cardsused in mobile phones are very much alike.

These standards can be categorised in two different fields: one describing chipcards and the infrastructure around them and the other being standards from thebanking sector describing procedures and business processes. ISO/IEC standardfamily 7816 and here especially parts three and four describe how we can accesscontact cards and how data is organised on them. ISO/IEC 14443 does similarthings for contact-less or more precisely proximity coupled cards. NFC usesthese standards and further refines its usage in ISO/IEC 18092 and some specifi-cations by the NFC forum4. The physical implementation of data transfers eitherin contact or contact-less cards are left out. They are not essentially necessary forimplementation or to understand how it functions. A good introduction to thephysical layer of contact-based cards can be found in [RE08, chap. 3-5] and forcontact-less cards in [Fin08] and also [RE08, chap. 10]. From the banking sector weare mainly concerned with specifications by the German Banking Industry5. De-vices used for chipTAN their protocols and commands are specified in the HHD6

specifications.

1 This is done in [Fin08, p.11]2 http://www.cardwerk.com3 See [ETSI]4 http://www.nfc-forum.org5 http://www.hbci-zka.de/6 HandHeld Device

19

http://www.cardwerk.comhttp://www.nfc-forum.orghttp://www.hbci-zka.de/

4 standards , norms and specifications

4.1 iso/iec 7816

This series of standards describes the main characteristics of contact based chipcards and is build on [ISO/IEC 7810] in which identification (ID) cards are cov-ered. [ISO/IEC 7810] defines physical dimensions of most of our every day plasticcards, from SIM cards to credit cards and more. The most common form factoris the ID 17 format which is also the format of the cards used here. ISO/IEC7816 part 1 and 2 describe the physical properties of chip cards and where theelectrical contacts are placed. Those standards are mainly of interest for chipcards manufacturers or hardware experiments with chip cards. More relevant forthe development of this application are parts 3 and 4 where transmission proto-cols, data organisation and commands to and responses from cards are described.[ISO/IEC 7816-8] defines some commands for security operations additionally topart 4. Other parts are of less significance for this project because features de-scribed 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 contacts8 on achip card. In the experiment in chapter 5 this is used to correctly connect theprobes 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. Todaythat future has come and they are used for either connecting an USB interface, anantenna for contact-less systems or other applications. If manufacturing costs needto be cut chips with only six contacts can be produced and still comply to ISO/IEC7816. Early chip cards had an EEPROM9 chip which could be reprogrammed.Todays chips dont 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 viaSWP10. Table 1 lists each contact with its short name and the function it has11.

Contact Name FunctionC1 Vcc Provides power to the chip.C2 RST Reset line - used to request reset sequence.C3 CLK Clock signal for the chips processor.C4 AUX1 Auxiliary contact 1.C5 GND Ground line.C6 Vpp Provides power to program a chips EEPROM. Today used for other

purposes like SWP.C7 I/O Data channel for half-duplex communicationC8 AUX2 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 ofchip cards. It defines which voltages and currents are to be used and what datais transmitted over the electrical contacts defined in part 2. Chip cards accordingto ISO/IEC 7816 can transmit data with different protocols. Currently there are15 different protocols standardised although T=0 and T=1 are primarily used12.Communication is also possible with protocols not defined in this standard likeUSB13 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 doneon bytes. If during a transmission an error occurs the last byte has to be retransmit-ted. To recognise transmission errors a parity bit is send after each data byte. Eachcommand according to T=0 has class, instruction and parameter bytes followed byoptional data bytes as shown in fig. 16. This makes this protocol fast and efficientbecause commands are only as long as necessary. Difficulties can arise when han-dling encrypted data. Even if data bytes are encrypted the header bytes class,instruction, parameters and especially length value have to be unencrypted. Oneexample where this protocol is used are GSM SIM cards. A thorough introduc-tion to T=0 gives [RE08, chap. 9.3.1] and further standards describing T=0 are TS51.011, TS 102221, EMV15.

CLA INS P1 P2 P3 Data

Figure 16: Structure of a block according to T=0

10 Single Wire Protocol see [RE08, chap. 9.6]11 See [RE08, chap. 4.1] and [Car]12 See [RE08, p. 276]13 Universal Serial Bus see [RE08, chap. 9.4]14 Single Wire Protocol see [RE08, chap. 9.5]15 See [EMV; ETSI]

21

4 standards , norms and specifications

4.3.2 Protocol T=1

In contrast to T=0 is T=1 a block oriented protocol which allows a strict separa-tion of data link and transport layer of the ISO/OSI model16. This in turn enablesan easier implementation of secure messaging techniques because the applicationlayer does not need to consider requirements of the transport layer. Another ad-vantage of this protocol is that it has the ability to chain blocks together to senddata which would otherwise not fit into a single block. A disadvantage is that forthe added features more memory is needed on the card and since more protocoldata is transmitted this protocol is slower than T=0.

Each block has a defined structure consisting of three parts a prologue, anoptional information field and an epilogue. The prologue contains a node addressbyte (NAD), a protocol control byte (PCB) and a length byte (LEN). The followinginformation field containing an APDU is optional for this protocol. At the end anerror detection byte (EDC) is added. Figure 17 shows the structure of a full T=1block.

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 whichtype a block has. In T=1 three types are defined: information I blocks, readyreceive 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 areused to send and receive data, R blocks are used as an acknowledge message whenblock chaining is used and S blocks set protocol control parameters or handle errorconditions. The last field in the prologue is the LEN byte which states the lengthof the information field in number of bytes. If no information is being transmittedLEN is considered 0. Since LEN is only one byte the maximum length of theinformation field is 254 bytes17. Because of the block chaining mode, howeverthere is no limitation on how much data can be sent.

If present the information field usually contains an APDU which will be in-troduced later but any information type can be transported. The length of theinformation 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 differ-ent information field lengths. For the device this is called IFSD (IFS Device) andrespectively IFSC (IFS Card) for the card. Both are defaulted to 32 byte and limitedto 254 byte.The IFSC can be changed to a different value during start up when the card sendsan ATR18. If the IFSD needs to be changed an S block with the corresponding flagsset in the PCB byte can be send to the card. In the this case the information fieldcontains 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:199417 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 allprevious bytes is computed and used as EDC. Because this is very fast and suf-ficient accurate for contact-based communication, it is the standard method usedfor error detection. When using CRC more errors can be detected but two bytesfor 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 readingdevice one of the first things the reader sends to the card is a signal on the resetline C2. A card reset is initiated by the interface device, whereupon the card shallrespond with an Answer to Reset[...]21. This ATR contains information about thecapabilities of the card and which communication parameters it supports as wellas some proprietary data. Since an ATR contains information about transfer pro-tocols and parameters, it needs to be ensured that all readers are able to correctlyreceive and interpret an ATR.

An ATR consists of five parts22: initial character (TS), format character (TO), in-terface 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 determinethe transmission rate. After the TS a format character (TO) is sent. It provides in-formation 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 tobe sent, interface characters however not. They describe transmission parameterand available protocols of the card like voltages and timings. It is optional to sentthem because for every parameter default values exist which will be used other-wise. Not sending the interface characters can speed up the initialisation processof the card since less bytes have to be transmitted. The exact meanings of thosevalues can be looked up in [RE08, chap. 8.1] and [Eve92, part 4]. [Rou] provides atool which parses ATRs, decodes the data contained and visually processes themfor easier viewing. Some special values in the experiment in chapter 5 on page 31are TA3 which describes the cards information field size (IFSC) and TD2 whichspecifies 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 arenot 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, operat-ing system or serial numbers. At the end a check character (TCK) may be sentdepending on the transmission protocol used. With T=1 a XOR checksum is cal-culated and used as TCK. If T=0 is used this is not needed because every bytealready has a checksum according to the protocol definition.

19 For more on coding theory see [Hau10] or [RE08, chap. 6.5.2]20 logical eXclusive OR21 ISO7816 3.2.b according to [Car]22 An example of an ATR is give in chapter 5

23

4 standards , norms and specifications

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 histori-cal bytes in the ATR, structure, identification of and access to files and applicationson cards, a security architecture for files and data including secure messaging andother details about how data is stored on and can securely be accessed from thecard23.

Most relevant for this project is the part of ISO/ICE 7816-4 where commandsand response objects are defined. These application protocol data units APDUsare used to send commands to cards and return responses. Two different typescan be distinguished: command APDUs (cAPDU) send from the reader to the cardand 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 afixed-sized mandatory header and a variable-sized optional body. The four bytesof the header are a class instruction byte (CLA), an instruction byte (INS) and twoparameter bytes (P1, P2). A complete body field consists of one length byte Lcwhich states the number of following data bytes, data bytes and another lengthbyte Le which says how many data bytes are expected in the response. A cAPDUwith all fields is shown in fig. 18.

CLA INS P1 P2 Lc Data Le

Figure 18: Structure of a complete command APDU

CLAThe CLA indicates to which standard this command belongs to. APDUs are usednot only for ISO/IEC 7816-3 protocols but for various others. Some examples areA0 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 com-plete list is found in [ISO/IEC 7816-4]

INSThis 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, P2These bytes provide parameters for the command. If no parameters are used theyare 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

LcIf 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 usethree byte long Lc fields. In this case the first byte is used as an escape sequence.

DataAfter the Lc field follow the data bytes. On this layer no information about thecontents is either needed or known.

LeLe describes how many data bytes are expected in the response from the card. Thisagain is optional and can be omitted if no data is expected. 0x00 indicates thatthe maximum allowed is expected. Le is usually one byte long but also three byteLe fields are allowed. The first byte then is escaped leaving two bytes for lengthinformation similar to the Lc field.

Since parts of a cAPDU are optional, ISO/IEC 7816-4 states four different casesof 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 fieldto specify the length of the data. Case four has all available fields and is shownin 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 issimpler 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 bytesof the rAPDU. If an error occurs during the execution of the command no data istransmitted. Status words SW1 and SW2 also called return code give informationabout 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 61XXindicate 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 stan-dards for contact-less systems which are divided into three groups based on theirrange of coverage. ISO/IEC 10536 describes close coupling cards (CICC) with cov-erage of 1 cm while ISO/IEC 15693 describes vicinity coupling cards (VICC) witha range of about 1 m. ISO/IEC 14443 is the basis for NFC and describes proximitycoupling cards (PICC) with a specified range of about 10 cm. Throughout this

25

4 standards , norms and specifications

standard the reading device is called PCD Proximity Coupling Device. The cardis usually referred to as PICC Proximity Integrated Circuit Card.

Physical characteristics are covered in part 1. The signal interface and propertiesof the radio frequency field are described in part 2. Because members of theworking group writing this standard could not consent on one protocol used, twotypes have been taken into the standard Typ A and Typ B which are differentin their anti-collison methods and the codings they use. Part 3 covers detection,initialisation and anti-collision methods, information structures similar to an ATRof contact cards as well as other communication parameters. Part 4 describes ahalf-duplex transmission protocol which is designed for contact-less environments.This standard is not available for free so we took our information from a publiclyavailable draft [Wg8] of the working group 8 and from [RE08, chap. 10.9]. A shortintroduction of this standard family can be found in [Plo08].

4.5.1 ISO/IEC 14443-3

Part three of ISO/IEC 14443 describes procedures of the initialisation of cards andanti-collision methods. Although the standard defines two different types of cardsthe basic principles are similar. Here the similarities rather the differences areemphasised.

Contact-less cards deal with more difficulties and have to consider differentscenarios than contact-based cards. Some of the added complexity deals with thefact that multiple cards could be in the readers area of operation thus effectiveanti-collision methods have to be used. Another scenario to consider is how tobehave 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 Aand Typ B need to be supported by PCDs. To support all this and provide a stableenvironment for communication anti-collision and card identification methods aredescribed in this part of the standard.

The basic idea is that each PICC can be in a different state. Once a card comesinto the area of operation of a PCD, the cards processor is provided with powerand boots up. Right after that it enters an IDLE state where it only listens to certainwake-up commands in order not to interfere with ongoing communication to othercards. After it receives a wake-up command it enters a READY state and sendssome information about its capabilities to the PCD. Then an anti-collision processstarts after which the PCD send a select commands with the cards id (CID) andthe PICC enters and ACTIVE state in which communication is possible with theprotocol described in ISO/IEC 14443-4. After communication is done the PCD setsthe PICC into a HALT state which is similar to IDLE in that the PICC only listensto certain wake-up commands. Details of this processes and differences betweentypes 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 pro-tocol used is described in the fourth part of ISO/IEC 14443 which is similar toISO/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 7816-4 APDUs. Those similarities make it easier to develop dual interface cards whichsupport a contact-based and a contact-less interface to the same operating systemunderneath. The communication protocol begins after a PICC is selected with aSELECT command. PICCs of Typ A need to go through an activation sequencewhere communication parameters are exchanged while Typ B PICCs can enter theACTIVE state directly. During the activation of Typ A an ATS26 is sent to thePCD where the PICC states which protocol parameters it supports. The PCD andPICC can then adjust these parameters like bit rates and frame sizes to optimalsettings.

For this protocol the basic structure of a block has been take form the T=1protocol as shown in fig. 17 and has been modified to a slightly different format asshown in fig. 20. Also three block types are distinguished: I-blocks for informationtransportation, R-blocks to acknowledge received blocks and S-blocks to changeprotocol parameters. The block type is defined in the PCB byte at the beginningof 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 optionalNAD bytes make up the prologue field. CID is used to send blocks to specificPICCs. If a PICC receives a block with a CID which is different from its own itignores that block. A PICC may not support CID fields at all and then ignores allblocks which contain a CID field. The NAD can be used to create logical channelsto 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 de-scribed earlier. The epilogue contains two error detection code bytes EDC. Withcontact cards there were two error detection code allowed, but since in contact-less environments more errors are likely only a CRC27 code is allowed becauseit is able to detect more errors than a simple XOR. A complete introduction onthis 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 standards , norms and specifications

4.6 iso/iec 18092

The previous mentioned standards provide the basis for NFC which itself is de-scribed 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 toinitiate a communication network between wireless devices. It also defines tworoles 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 cannot change during the time of an ongoing communication.

Active communication mode means that initiator and target are generating eachtheir own RF-field and thus use those fields only for data transportation and notto transport power. In passive communication mode the target doesnt generate aRF-field but uses the initiators field for power and data transport. Both communi-cation 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 spec-ifications of the cards and communication protocols used. HHD (HandHeld De-vice) is a specification that describes what information should be transmitted wheninteracting with a German debit card. These debit cards29 use a SECCOS30 oper-ating system issued by the German Banking Industry31. Descriptions of com-mands are collected in the HHD specifications also issued by the German Bank-ing Industry32. Some parts are publicly available like [Kre08]33 whilst others areonly closed34 like Schnittstellenspezifikation fur die ZKA-Chipkarte - Handheld-Device (HHD) zur TAN-Erzeugung35. The latter specification is central to gener-ating a TAN and has been partially reverse engineered by [Ccc]. Commands usedand their parameters will be explained later in chapter 5. Here a look is taken tothe assignment guidelines because they give some information about startcodeswhich will be used in the process of generating a TAN. As of writing the currentversion of this specification is version 1.4. Unfortunately this version is not avail-able on the homepage of the DK and during this project also version 1.3 has beentaking offline. It was possible though to save a copy of version 1.3 which will beused here. Since these specifications have been written and published by the DK,they apply only to the chipTAN method, so following information can be viewedas 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 System31 Die deutsche Kreditwirtschaft (DK) formerly known as Zentraler Kreditausschuss (ZKA) http://

www.die-deutsche-kreditwirtschaft.de32 http://www.hbci-zka.de33 Assignment Guidelines for dynamic TANs34 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

http://www.die-deutsche-kreditwirtschaft.dehttp://www.die-deutsche-kreditwirtschaft.dehttp://www.hbci-zka.de

4.7 HHD

4.7.1 Startcodes

The main use of startcodes is to bind a TAN to a specific transaction but thespecification also states that the use of such a startcode is optional.

Gema der HHD-Spezifikation V1.2 bzw. V1.3 des ZKA konnen indie TAN-Berechnung ein von der Bank vorgegebener Start-Code undweitere transaktionsabhngige Daten eingehen. Damit ist es moglich,die Gultigkeit der TAN an eine bestimmte Transaktion zu binden. Start-Code und Daten mussen uber die Tastatur des HHD eingegeben wer-den. Ein Start-Code fur die TAN-Berechnung besteht aus bis zu 8 Zif-fern. Daruber hinaus konnen bis zu 12 Ziffern (bei HHD V1.3 auchmehr) zusatzlicher 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 tocalculate a TAN. With that it is possible to bind the validity of a TAN to aspecific transaction. startcode and transaction data must be entered with thekeypad of the HHD. A startcode used for the generation of a TAN can consistsof up to eight numbers. In addition to that can up to 12 numbers (HHD V1.3even more) of transaction data be entered.37

Because startcodes are issued by banks it is necessary to understand how toread and use them for generating a TAN. [Kre08] defines 15 different challengeclasses for different types of transactions. Each class defines which transactioninformation is requested from the user. To make the handling of those classes eas-ier three patterns have been introduced. The startcode then tells the HHD whichtransaction 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, inthis case 8X is used for TAN generation with basic data elements. In total eightbasic data elements are defined as shown in table 2. The following digits 71 statewhich data elements are expected. In our example the user enters the startcode871, then is asked by the HHD for the account number (7), then it asks for thetransaction 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. Usageof a nonce might seem optional with contact-based methods but in a contact-lessenvironment 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 enteredvia 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 froma screen to a HHD. Details are not publicly available but have also been reverseengineered by [Sch09]. Though interesting details wont be discussed here becausethis code wont be used in this project. They are at length discussed in [Sch09],[Fli] and [Ccc].

36 [Kre08]37 [Kre08] Own translation38 See section 7.5.3 on page 61

29

4 standards , norms and specifications

Number Name1 Betrag (Amount)2 Kontonummer (Account number) Normal/IBAN3 Online-Banking-PIN4 Telefonnummer (Telephone number)5 Bankdaten (Bank data)6 Anzahl (Count)7 Kontonummer (Account number) Normal8 Kontonummer (Account number) IBAN

Table 2: Basic data elements according toBelegungsrichtlinien fur die Dynamisierung der TAN

4.8 emv

EMV stands for Europay, MasterCard and Visa which where the companies whoorginially founded EMVCo who has written specifications about payment meth-ods with ISO/IEC 7816 chip cards, e.g. how to handle credit card payments isdefined here. Those specifications further define physical features and propertiesof cards and terminals and also describe the type of messages exchanged. UsingISO/IEC 7816-3 APDUs EMV specifies what commands exist, their parametersand what responses are valid. EMV is divided in four parts called books. Book1 describes mechanical and electrical properties of cards. Book 2 handles securityand key management. In book 3 application commands and their responses aredefined and book 4 describes what functions a terminal must support to beingable to read EMV cards.

These specifications apply to payments with the chip-PIN method39 which isglobally in use. Because of its wide use in the financial system, EMV also applies todebit cards used in this project. Although we use a different application then chip-PIN similar commands are used. Comparing what commands we see in chapter 5with those described in EMV helps understanding the process of TAN generation.

39 Some notes about chip-PIN and security are give by [Mur11]

30

5T H E B I RT H O F A TA N

In this chapter we want to take a look on how a TAN is generated with a currentstandard ZKA debit card and a regular TAN generator. Regular German debitcard use SECCOS as operating system. A decission was made not get the SECCOSspecifications because that would mean signing an NDA and disclosing some ofthe information about this project. Instead work of [Ccc] was taken and used asa basis and their experiment repeated different hardware with. A reason for thisdecision was the wish to document all steps and with that provide a basis forothers to repeat or carry on this work. For those interested the exact protocol isdefined 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 SparkasseTubingen3. Together with that card a TAN generator from the company Kobil4

was received. Since there were trouble successfully sniffing the traffic with thisreader a different reader was used from ReinerSCT5 which proved more reliablefor this purpose.

Figure 22: Soldered wires to contacts C3, C5, C7of the TAN generator

To connect the readerto a PC the BusPiratev3.6 from Dangerous-Prototypes6 was used.All devices used areshown in fig. 21 onpage 32. In orderto see communicationdata of the card andreader we need toconnect contacts C3(CLK), C5 (GND) andC7 (I/O)7 of the chip-module to the corre-sponding (CLK, GND,

1 http://www.die-deutsche-kreditwirtschaft.de/2 http://www.bank-verlag.de/3 https://www.ksk-tuebingen.de/4 http://www.kobil.com/products/card-readers/optimus-comfort/overview.html5 http://www.reiner-sct.com/produkte/tan-generatoren/tanJack_optic_sr.html6 http://dangerousprototypes.com/docs/Bus_Pirate7 See section 4.2 and [RE08, p. 303]

31

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.htmlhttp://www.reiner-sct.com/produkte/tan-generatoren/tanJack_optic_sr.htmlhttp://dangerousprototypes.com/docs/Bus_Pirate

5 the birth of a tan

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 openedand 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 bytetraffic from and to the card we need to set the BusPirate in the UART8 mode andconfigure the correct parameters. Those are mainly bus port speed, data bits andparity and stop bits. Finding the right bus port speed was rather difficult with thefirst reader from Kobil.

Chip cards can operate at different clock speeds and because the card readerprovides a clock signal it determiens the clock speed of the cards processor. Be-cause of that, we need to determine the frequency of the reader before we areable to correctly interpret data. Once we have the frequency we can calculate thecorresponding bus port speed9.

BusPirate provides a simple frequency analyser but needs a clock signal whichlasts at least one second. The Kobil device was too fast for that and so it wasnot possible to determine a precise clock speed. With help of the Department forComputer Engineering and a better frequency analyser a more accurate estimateof the clock speed was measured. With that the cards ATR could be read success-fully. But after the ATR was received numerous errors occurred. One reason forthat might be that the reader uses different clock speeds, maybe to use a lower fre-quency to safe energy when high performance is not needed. BusPirate howeverneeds a fixed bus port speed to interpret data correctly and again it was not possibleto get useful results besides the ATR.

8 Universal Asynchronous Receiver Transmitter9 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

http://wiki.yobi.be/wiki/Bus_Pirate##7816-3_T.3D0_at_arbitrary_baudratehttp://wiki.yobi.be/wiki/Bus_Pirate##7816-3_T.3D0_at_arbitrary_baudrate

5.2 Sniffing a TAN generation

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.644MHzwhich translated to a bus port speed of 905bps. The full parameters for the UARTmode are:

Listing 5.1: BusPirate UART Paramerters

1 bus port speed : 9052 data b i t s and p a r i t y : 8 , even3 stop b i t s : 24 r e c e i v e p o l a r i t y : i d l e 15 output drain : open drain

With these settings we are able to see data and start the experiment. Since it wasjust a test transaction all parameters are chosen arbitrarily. As startcode 8710000was chosen since this is a common transaction type.

Listing 5.2: Transaction Details

1 Star t code : 87100002 Rec ip ient Account Number : 1234563 Amount : 123 ,45

The cards application transaction counter was set at 4210. For this test the ATChas just informational meaning because the resulting TAN wont be used. Fora 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 ATCsynchronisation has to be done. How the ATC affects the TAN will become clearin the last two steps of the following section.

5.2 sniffing a tan generation

In the following sections > 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 CCC-FFM but with minor hardware changes and different input data. More details onwhat the commands or answers mean can be found in [Ccc] where most recentinformation 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 readerit sends an ATR. To give a brief analysis we use the ATR Parser from LudovicRousseau12 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

http://smartcard-atr.appspot.com/

5 the birth of a tan

parsed data. Details and meaning of each value can be found in section 4.3.3on page 23. Noteworthy are especially TD(1) and TD(2) which specify T=1 ascommunication protocol and TA(3) which sets the IFSC initially to 254 byte. Adifferent example and more details on ATRs can be found in [Ccc] and [RE08].

Field Value DescriptionTS 0x3B Direct ConventionT0 0xFF Y(1): b1111, K: 15 (historical bytes)TA(1) 0x96 Fi=512, Di=32, 16 cycles/ETU (250000 bits/s at 4.00 MHz,

312500 bits/s for fMax=5 MHz)TB(1) 0x00 VPP is not electrically connectedTC(1) 0xFF Extra guard time: 255 (special value)TD(1) 0x81 Y(i+1) = b1000, Protocol T=1TD(2) 0x31 Y(i+1) = b0011, Protocol T=1TA(3) 0xFE IFSC: 254TB(3) 0x45 Block Waiting Integer: 4 - Character Waiting Integer: 5

Historical bytes 65 63 11 0C 53 02 50 00 10 A9 0B 23 47 06 500x65 Category indicator byte: (proprietary format)

"c..S.P....#G.P"TCK 0x07 correct checksum

Table 3: ATR send from a debit card and parsed

IFSD

Header Data EDC> 00 E1 01 FE 1E

After the IFSC has been changed from its default value in the ATR, now theIFSD13 is changed to 254 byte. The card acknowledges this with a S-Block andrepeating the field size.

SELECT FILE

Header APDU EDC> 00 00 02 90 00 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 theTAN application. Files in context of chip cards dont only represent data but canalso provide access to an application for this ISO/IEC 7816-4 defines different filetypes. 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 completingthe introduction of T=1 and APDUs in chapter 4 on page 19. Table 4 relates everybyte 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 LENbyte. 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

5.2 Sniffing a TAN generation

P2 fields. CLA byte 0x00 tells us that the following instruction is found in ISO/IEC7816-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 allremaining bytes we conclude that this is a command with no Le byte and thus themaximum data length in the response is expected.

Byte Name Description00 NAD Node ADress00 PCB Protocol Control Byte -- I-Block0E LEN Length of information field (APDU) 0x0E = 14 Bytes00 CLA ClassA4 INS Instruction -- SELECT FILE (ISO/IEC 7816-4)04 P1 Parameter 10C P2 Parameter 209 Lc Length of DataD2 Data 1 Databyte 176 Data 2 Databyte 200 Data 3 Databyte 300 Date 4 Databyte 425 Data 5 Databyte 554 Data 6 Databyte 644 Data 7 Databyte 701 Data 8 Databyte 800 Data 9 Databyte 93B EDC Error Detection, XOR -- ISO/IEC 7816-3

Table 4: Example of an APDU with T=1 protocol

Data bytes 1 to 9 specify which application to select. Applications are identifiedby an AID14 which itself consists of a RID15 and a PIX16. More about the AID isfound in [RE08, p. 464] The correct values for the TAN application can be takenfrom [SIT] or [Ran].

In the answer the card simply states that the previous command has been suc-cessful. Byte one SW1 = 0x90 and byte two SW2 = 0x00 indicate no errors duringexecution.

GET PROCESSING OPTIONS

Header APDU EDC> 00 40 0E 77 0A 82 02 18 00 94 04 08 02 04 00 90 00 A5

Following the pattern used in the last command we can decode this and othercommands to different level of detail. The CLA byte set to 0x80 indicates thatthis command is using secure messaging or is of proprietary format17. Somemore information about this command can be found in [EMV, p. 6.5.8] whichstate that CLA byte value 8X and INS set to A8 indicates a command named GETPROCESSING OPTIONS. Following this we can see that the 8300 is the payload

14 Application IDentifier15 Registered Application Identifier16 Proprietary application Identifier eXtension17 See [ISO/IEC 7816-4, chap. 5.4.1.]

35

5 the birth of a tan

defined as Processing Options Data Object List (PDOL) related data18. Becausethe 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 lookingat the EMV specification we see that the response states which features the selectedapplication supports and what other files belong to this application19.

READ RECORD 1

Header APDU EDC> 00 00 1A 67 25 60 08 51 70 01 07 58 0D 17 12 13 07 10

02 80 45 55 52 01 51 00 0690 00 45

Of this answer we will use bytes 4 to 10 in the VERIFY step to change thesecurity level. Bytes 2 to 4 are a short bank identification number and bytes 5 to10 represent the serials number of the debit card20.

READ RECORD 2

Header APDU EDC> 00 40 1D 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 0090 00 3F

The second READ RECORD call is different to [Ccc] where a SEARCH RECORDIPB call was made. This might be because we use a different debit card whichmight have a different software version. As in the previous command somerecords 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 proprietaryformat according to ISO/IEC 7816-4. The second byte in the body 0x19 givesthe 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 Indicatorwhile 9F56 is a Issuer Authentication Indicator IAI. The exact meanings of those areunknown. However will we use the latter in Calculate TAN as a bitmap to calculatethe TAN. This bitmap is identical with [Ccc] which might indicate that always thesame 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 relatedrecords 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.pdf21 See [EMV]22 http://www.eftlab.co.uk/

36

http://ftp.ccc.de/docs/cards/geldkarte.pdfhttp://www.eftlab.co.uk/

5.2 Sniffing a TAN generation

VERIFY

Header APDU EDC> 00 00 02 90 00 92

According to [ISO/IEC 7816-4, chap. 6.12.] this command is used to modify thesecurity status. It could also be used to verify a PIN but in this case the cardnumber and one other byte23 is used.

The answers simply states that the command has been successful. If this step isnot successful an error code 63CX is returned24. X counts to 3 and indicates thenumber of retries. Once 3 has been reached the TAN application is locked andneeds to be unlocked with a PIN. So far we have been unable to get informationfrom banks on which PIN this is since it differs from the PIN used at ATMs.

HASH

Header APDU EDC> 00 40 16 5F 54 74 53 28 17 C5 B3 54 9C 50 13 3E 9F 1D

ED 95 CD AB B190 00 3B

With the hash command all previously collected data of the transaction is en-coded and sent to the card. For the encoding two different types are used: ASCIIwhich is indicated by a byte 0xE1 preceding the data and BCD by 0xE0. Thiscoding is rather simple and the names of data fields are transmitted fully: E1 5374 61 72 74 2D 43 6F 64 65 3A The first byte 0xE1 indicates an ASCII coding whichdecodes the remaining bytes to a character string of Start-Code:. A reason for thismay be to generate a long hash string which will be used in the next step.

GENERATE AC

Header APDU EDC> 00 00 22 77 1E 9F 27 01 00 9F 36 02 00 2B 9F 26 08 4B

39 9B C1 46 13 53 99 9F 10 07 0A 82 00 00 3100 00

90 00 D5

ISO/IEC 7816-4 only states that this command is proprietary but with [EMV] wecan gather s