e-payments: cardholder privacy and non-repudiation · number of fraudulent payments made with falsi...

E-Payments: Cardholder Privacy andNon-Repudiation

David John Boyd

Technical ReportRHUL–MA–2009–2511 January 2010

Department of MathematicsRoyal Holloway, University of LondonEgham, Surrey TW20 0EX, England

http://www.rhul.ac.uk/mathematics/techreports

E-Payments: Cardholder Privacy and

Non-Repudiation

David John Boyd

Thesis submitted to the University of London

for the degree of Doctor of Philosophy

Information Security Group

Department of Mathematics

Royal Holloway, University of London

2009

Declaration

These doctoral studies were conducted under the supervision of Dr. Mick Ganleyand Prof. Chris Mitchell.

The work presented in this thesis is the result of original research carried outby myself, in collaboration with my supervisors, whilst enrolled in the Departmentof Mathematics as a candidate for the degree of Doctor of Philosophy. This workhas not been submitted for any other degree or award in any other university oreducational establishment.

David J. BoydOctober, 2009

2

Abstract

The development of electronic payment cards has been evolutionary, of late pushingto protect the card issuers’ financial interests by counteracting an increase in thenumber of fraudulent payments made with falsified cards. The cardholders havea different emphasis: only to be liable for their own payments and to be able toevidence the payments that they have or have not made. Card payments tendnot to keep the cardholder’s details private, which can facilitate fraud, and it canbe exceedingly difficult for a cardholder to repudiate a completed payment. Thisthesis aims to support cardholders by enhancing their privacy and non-repudiationcapabilities.

This thesis is divided into four parts.

The first part looks at how privacy and non-repudiation fit into the informationsecurity hierarchy, and then the cryptographic mechanisms and algorithms used inthis thesis are described. The widely-used EMV electronic payment card system isreviewed; followed by card-not-present transactions, which are particularly problem-atical.

The main contribution follows where four novel schemes are proposed that pro-vide enhanced privacy and non-repudiation services for both card-present and card-not-present payments. Each of these four categories of payment and security servicerequires its own scheme. Privacy is enhanced by stripping out personally identifi-able information and using a different account number for each transaction. Non-repudiation is enhanced by leaving an electronic footprint after each transaction.

Web payments require particular attention. Banks are adept at authenticatingclients. The third part of this thesis brings together those factors and proposestwo further schemes that provide a single sign-on service to the Web and clientauthentication for the Transport Layer Security communications protocol. The cardissuer provides privacy by vouching that it knows the cardholder and some non-repudiation properties by maintaining an audit trail.

Finally the thesis concludes and outlines some opportunities for further research.

3

Contents

1 Introduction 22

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.2 Main Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.3 Structure of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.4 Scope: E-payments and Payment Cards . . . . . . . . . . . . . . . . 28

I Overview 29

2 Security Building Blocks 30

2.1 Foundation Security Services . . . . . . . . . . . . . . . . . . . . . . 31

2.1.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.1.3 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2 Privacy and Non-Repudiation . . . . . . . . . . . . . . . . . . . . . . 33

2.2.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2.2 Non-Repudiation . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.3 Principal Cryptographic Primitives and Constructs . . . . . . . . . . 45

2.3.1 Hash Function . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.3.2 Symmetric Cryptography . . . . . . . . . . . . . . . . . . . . 46

2.3.3 Message Authentication Code . . . . . . . . . . . . . . . . . . 48

2.3.4 Asymmetric Cryptography . . . . . . . . . . . . . . . . . . . 50

4

CONTENTS

2.3.5 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.3.6 Pseudorandom Functions . . . . . . . . . . . . . . . . . . . . 53

2.4 Principal Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.4.1 Data Encryption Standard . . . . . . . . . . . . . . . . . . . 54

2.4.2 RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.4.3 Secure Hash Algorithm . . . . . . . . . . . . . . . . . . . . . 56

3 Methods of Payment 58

3.1 Cash: The Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2 EMV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2.1 Introduction to EMV . . . . . . . . . . . . . . . . . . . . . . 60

3.2.2 EMV Authentication . . . . . . . . . . . . . . . . . . . . . . . 60

3.2.3 EMV Cryptography . . . . . . . . . . . . . . . . . . . . . . . 63

3.3 Card Not Present Payments . . . . . . . . . . . . . . . . . . . . . . . 63

3.3.1 CNP - The Problem . . . . . . . . . . . . . . . . . . . . . . . 64

3.3.2 CNP - Deployed Solutions . . . . . . . . . . . . . . . . . . . . 64

4 Attributes 67

4.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.1.1 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.1.2 Pseudonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.1.3 Unlinkability . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.1.4 Unobservability . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.1.5 Privacy Summary . . . . . . . . . . . . . . . . . . . . . . . . 71

4.2 Non-Repudiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.3 Internet Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

II E-Payment Schemes:

5

CONTENTS

Cardholder Privacy and Non-Repudiation 73

5 Payment Cards: Privacy 74

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.3 A Card Not Present Scheme . . . . . . . . . . . . . . . . . . . . . . . 77

5.4 The Proposed Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 78

5.4.1 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.4.2 EMV: Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 80

5.4.3 Pseudonymity and Unlinkability . . . . . . . . . . . . . . . . 81

5.4.4 EMV: Pseudonymity and Unlinkability . . . . . . . . . . . . . 83

5.4.5 Effect on Payment Processing Entities . . . . . . . . . . . . . 90

5.5 Residual Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . . 91

5.5.1 Passive Attack . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.5.2 Active Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.5.3 Size of Anonymity Set . . . . . . . . . . . . . . . . . . . . . . 93

5.5.4 Floor Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.5.5 Birthday Attack . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.5.6 Issuer Impersonation . . . . . . . . . . . . . . . . . . . . . . . 95

5.5.7 Non-Repudiation . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.5.8 Physical Security . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.5.9 Legal Precedent . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6 Payment Cards: Non-Repudiation 99

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6.3 The Proposed Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 103

6.3.1 Electronic Receipts . . . . . . . . . . . . . . . . . . . . . . . . 104

6.3.2 Condensed Electronic Receipts . . . . . . . . . . . . . . . . . 109

6

CONTENTS

6.3.3 Electronic Footprint . . . . . . . . . . . . . . . . . . . . . . . 113

6.4 Privacy and Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . 115


6.5.1 The Evidence Causing Disputes . . . . . . . . . . . . . . . . . 117

6.5.2 Too Much Trust in the System . . . . . . . . . . . . . . . . . 117

6.5.3 Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 118

6.5.4 Misplaced Trust . . . . . . . . . . . . . . . . . . . . . . . . . 119

6.5.5 Cardholder Practices . . . . . . . . . . . . . . . . . . . . . . . 120

6.5.6 Inconsistencies Between Statements . . . . . . . . . . . . . . 121

6.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

7 CNP Payments: Privacy 123

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

7.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

7.3 Temporary Card Number Schemes . . . . . . . . . . . . . . . . . . . 128

7.3.1 Controlled Payment Numbers™ . . . . . . . . . . . . . . . . . 128

7.3.2 SecureClick® . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

7.3.3 Rubin and Wright . . . . . . . . . . . . . . . . . . . . . . . . 130

7.3.4 Li and Zhang . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

7.3.5 Assora, Kadirire and Shirvani . . . . . . . . . . . . . . . . . . 134


7.4.1 Protecting Identity . . . . . . . . . . . . . . . . . . . . . . . . 136

7.4.2 Allocating Temporary Card Numbers . . . . . . . . . . . . . 137

7.4.3 Allocating a Card Verification Value . . . . . . . . . . . . . . 139

7.4.4 Address Verification . . . . . . . . . . . . . . . . . . . . . . . 142

7.4.5 Operating the Scheme . . . . . . . . . . . . . . . . . . . . . . 144

7.4.6 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

7.4.7 Non-Repudiation and Other Security Services . . . . . . . . . 147


7

CONTENTS

7.5.1 Insufficient TCNs . . . . . . . . . . . . . . . . . . . . . . . . . 148

7.5.2 No TCNs Left on Card . . . . . . . . . . . . . . . . . . . . . 149

7.5.3 Guessing TCNs . . . . . . . . . . . . . . . . . . . . . . . . . . 150

7.5.4 Reduction of Privacy . . . . . . . . . . . . . . . . . . . . . . . 150

7.5.5 Re-use of TCNs . . . . . . . . . . . . . . . . . . . . . . . . . . 150


7.5.7 Proof of Payment Source . . . . . . . . . . . . . . . . . . . . 151

7.5.8 Merchant Practices . . . . . . . . . . . . . . . . . . . . . . . . 152

7.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

8 CNP Payments: Non-Repudiation 154

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

8.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

8.3 Biometrics for Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 157

8.3.1 Which Biometric? . . . . . . . . . . . . . . . . . . . . . . . . 157

8.3.2 Applying the Biometric Standard . . . . . . . . . . . . . . . . 160


8.4.1 The Trusted Third Party . . . . . . . . . . . . . . . . . . . . 163

8.4.2 Calling the TTP Service . . . . . . . . . . . . . . . . . . . . . 164

8.4.3 Processing the Transaction . . . . . . . . . . . . . . . . . . . 165

8.4.4 When There is a Dispute . . . . . . . . . . . . . . . . . . . . 169

8.4.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172


8.5.1 Availability of the TTP . . . . . . . . . . . . . . . . . . . . . 174

8.5.2 TTP Impersonation or Interception . . . . . . . . . . . . . . 175

8.5.3 Sensitivity of Biometric Data . . . . . . . . . . . . . . . . . . 176

8.5.4 Integrity of TTP . . . . . . . . . . . . . . . . . . . . . . . . . 177

8.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

8

CONTENTS

III Web Schemes:

Cardholder Authentication 179

9 Cardholder Authentication: Web Single Sign-On 180

9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

9.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

9.3 An EMV-Based SSO Scheme . . . . . . . . . . . . . . . . . . . . . . 184

9.3.1 The Pashalidis-Mitchell Mechanism . . . . . . . . . . . . . . 185

9.3.2 Areas for Potential Improvement . . . . . . . . . . . . . . . . 187


9.4.1 An Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

9.4.2 The SSO Infrastructure . . . . . . . . . . . . . . . . . . . . . 194

9.4.3 Avoiding Changes to the Card . . . . . . . . . . . . . . . . . 198

9.4.4 SSO User Registration . . . . . . . . . . . . . . . . . . . . . . 198

9.4.5 SSO Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 200

9.4.6 The SSO Protocol . . . . . . . . . . . . . . . . . . . . . . . . 203

9.4.7 CMS Maintenance and Administration . . . . . . . . . . . . . 206


9.5.1 Issuer Impersonation or Interception . . . . . . . . . . . . . . 208

9.5.2 Use of Other User’s Attestation . . . . . . . . . . . . . . . . . 208


9.5.4 Leakage of Information . . . . . . . . . . . . . . . . . . . . . 209

9.5.5 Availability of the Authentication, CMS and NTP Components210

9.5.6 Integrity of the Authentication, CMS and NTP Components 211

9.5.7 Time of Check to Time of Use . . . . . . . . . . . . . . . . . 212

9.5.8 Incomplete Audit Trail . . . . . . . . . . . . . . . . . . . . . . 213

9.5.9 Strength of Response . . . . . . . . . . . . . . . . . . . . . . . 213

9.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

10 Cardholder Authentication: TLS Client Authentication 215

9

CONTENTS

10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

10.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

10.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

10.4 The TLS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

10.4.1 The TLS Record Protocol . . . . . . . . . . . . . . . . . . . . 220

10.4.2 The TLS Handshake Protocol . . . . . . . . . . . . . . . . . . 222

10.4.3 Keys and Algorithms . . . . . . . . . . . . . . . . . . . . . . . 225


10.5.1 The Extended TLS Handshake Protocol . . . . . . . . . . . . 229

10.5.2 Authenticating the Client . . . . . . . . . . . . . . . . . . . . 233

10.5.3 Other Considerations . . . . . . . . . . . . . . . . . . . . . . 235

10.5.4 Security Services . . . . . . . . . . . . . . . . . . . . . . . . . 236


10.6.1 Issuer Impersonation or Interception . . . . . . . . . . . . . . 238

10.6.2 Leakage of Information . . . . . . . . . . . . . . . . . . . . . 239

10.6.3 Financial Exposure . . . . . . . . . . . . . . . . . . . . . . . . 239


10.6.5 Issuer Availability . . . . . . . . . . . . . . . . . . . . . . . . 240

10.6.6 Changing IP Address . . . . . . . . . . . . . . . . . . . . . . 241

10.6.7 Data on Client and Server . . . . . . . . . . . . . . . . . . . . 241

10.6.8 Time of Check to Time of Use . . . . . . . . . . . . . . . . . 241

10.6.9 Incomplete Audit Trail . . . . . . . . . . . . . . . . . . . . . . 242

10.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

IV Conclusions 244

11 Conclusions and Further Research 245

11.1 Summary and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 245

11.2 Opportunities for Further Research . . . . . . . . . . . . . . . . . . . 248

10

CONTENTS

Bibliography 250

11

List of Figures

2.1 Common Criteria privacy class . . . . . . . . . . . . . . . . . . . . . 35

2.2 Common Criteria communication class . . . . . . . . . . . . . . . . . 42

5.1 EMV transaction flow example . . . . . . . . . . . . . . . . . . . . . 79

6.1 Example of EMV log format . . . . . . . . . . . . . . . . . . . . . . . 105

6.2 Proposed Electronic Receipts log . . . . . . . . . . . . . . . . . . . . 105

6.3 Bit map of the ATCs . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.4 Proposed Condensed Electronic Receipts log . . . . . . . . . . . . . . 113

6.5 Proposed Electronic Footprint . . . . . . . . . . . . . . . . . . . . . . 114

7.1 Citibank account online: sign-on Web page . . . . . . . . . . . . . . 129

8.1 Location and direction of a ridge bifurcation . . . . . . . . . . . . . . 160

8.2 Location and direction of a ridge ending . . . . . . . . . . . . . . . . 160

8.3 Core and delta fingerprint features . . . . . . . . . . . . . . . . . . . 161

8.4 Fingerprint coordinates . . . . . . . . . . . . . . . . . . . . . . . . . 161

8.5 Calling the TTP with an API . . . . . . . . . . . . . . . . . . . . . . 165

8.6 Calling the TTP with https . . . . . . . . . . . . . . . . . . . . . . . 165

8.7 The TTP daily log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

9.1 Pashalidis-Mitchell SSO protocol . . . . . . . . . . . . . . . . . . . . 185

9.2 Participating entities in the enhanced SSO proposal . . . . . . . . . 193

10.1 TLS handshake protocol . . . . . . . . . . . . . . . . . . . . . . . . . 223

12

LIST OF FIGURES

10.2 Extended TLS handshake protocol . . . . . . . . . . . . . . . . . . . 229

13

List of Tables

7.1 Payment card data elements . . . . . . . . . . . . . . . . . . . . . . . 138

8.1 Finger minutia record format . . . . . . . . . . . . . . . . . . . . . . 162

10.1 TLS record layer fields . . . . . . . . . . . . . . . . . . . . . . . . . . 221

14

Acknowledgements

This thesis is the culmination of four years of study which has been both an inter-esting and stimulating experience. It is a stark contrast to my previous 32 years,working in the IT department of a large multinational company. That businessexperience helped me afford to pursue this lifelong ambition and gain the personalorganisation skills that are necessary to undertake such a large project.

However research and writing a thesis take a lot more than time and organisa-tion. My particular thanks go to my immediate supervisor, Dr. Mick Ganley, for hisinvaluable guidance and support throughout my studies at Royal Holloway. Mickalso supervised my dissertation towards an MSc in Information Security. My thanksalso go to Prof. Chris Mitchell, my other supervisor, for overseeing my doctoralstudies and in particular for providing strategic direction. Prof. Fred Piper gave mesound advice when I was deliberating whether to commence these doctoral studiesand he provided considerable help by reviewing the iterations of my draft thesis.Finally, during my studies I needed to contact various academic staff at Royal Hol-loway’s Information Security Group for specific advice and that timely assistance(and knowing it was available) helped keep me on track.

15

List of Publications

This thesis contains research that has been published as six refereed papers in ajournal and various conference proceedings.

David J. Boyd. Towards a private and anonymous EMV payment application.In John Haggerty and Madjid Merabti, editors, Proceedings of the 3rd Confer-ence on Advances in Computer Security and Forensics (ACSF 2008), pages53-59, July 2008. ISBN: 978-1902560205 [30].

David J. Boyd. Enhancing the non-repudiation properties of EMV paymentcards. In Sanjay Goel, editor, Proceedings of the 3rd Annual Symposium onInformation Assurance (ASIA ’08): The Academic Track of the 11th AnnualNew York State Cyber Security Conference, pages 63-70, June 2008 [27].

David J. Boyd. A pragmatic approach to temporary payment card numbers.International Journal of Electronic Security and Digital Forensics (IJESDF),Volume 2, Number 3, pages 253-268, July 2009 [31].

David J. Boyd. Enhancing the non-repudiation properties of Internet pay-ments through a third dimension. In Kamel Adi, Mourad Debbabi, and LuigiLogrippo, editors, Proceedings of the 2nd Workshop on Practice and Theory ofIT Security (PTITS 2008), pages 33-39, January 2008 [28].

David J. Boyd. Single sign-on to the Web with an EMV card. In WaleedW. Smari and William McQuay, editors, Proceedings of the 2008 InternationalSymposium on Collaborative Technologies and Systems (CTS 2008), pages 112-120. IEEE, May 2008. ISBN: 978-1424422487 [29].

David J. Boyd. TLS client handshake with a payment card. In Proceedingsof the 23rd IEEE International Parallel and Distributed Processing Symposium(IPDPS 2009). IEEE, May 2009. ISBN: 978-1424437504 [32].

Additionally one short paper resulting from this research has been presented.

David J. Boyd. Increasing the Non-Repudiation Properties of EMV PaymentCards. The 12th Nordic Workshop on Secure IT Systems (NordSec 2007),October 2007.

16

Abbreviations

2FA: Two-Factor Authentication2TDES: Double-length key Triple Data Encryption Standard3TDES: Triple-length key Triple Data Encryption Standard4DBC: Four-Digit Bank CodeAA: Amount AuthorisedAAC: Application Authentication CryptogramAC: Application CryptogramAFL: Application File LocatorANO: ANOnymityAPI: Application Programming InterfaceASP: Authentication Service ProviderATC: Application Transaction CounterATM: Automatic Teller MachineCA: Certification AuthorityCBC: Cipher Block ChainingCC: Currency CodeCCD: Common Core DefinitionsCDA: Combined DDA/Application cryptogram generationCID: Card Identification CodeCMS: Central Mapping ServiceCNP: Card Not PresentCP: Card PresentCRV: Client Random ValueCS: Cardholder SystemCSC: Card Security CodeCVC: Card Verification CodeCVM: Cardholder Verification MethodCVV: Card Verification ValueDDA: Dynamic Data AuthenticationDES: Data Encryption StandardDH: Diffie-HellmanDNA: DeoxyriboNucleic AcidDNS: Domain Name SystemDoS: Denial of ServiceE-commerce: Electronic commerce

17

LIST OF TABLES

ECB: Electronic Code BookEEPROM: Electrically Erasable Programmable Read-Only MemoryEMV: Europay MasterCard VisaE-payment: Electronic paymentEXP: EXPiry dateHMAC: keyed-Hash Message Authentication Codehttps: HyperText Transfer Protocol SecureIAD: Issuer Application DataICC: Integrated Circuit Cardid: identifierIEC: International Electrotechnical CommissionIETF: Internet Engineering Task ForceIP: Internet ProtocolISO: International Organization for StandardizationISP: Internet Service ProviderIV: Initialisation VectorMAC: Message Authentication CodeMS: Master SecretNIST: National Institute of Standards and TechnologyNRO: Non-Repudiation of OriginNRR: Non-Repudiation of ReceiptNTP: Network Time ProtocolOAN: One-time Account NumberPAN: Primary Account NumberPANSEQ: PAN SEQuence numberPDA: Personal Digital AssistantPII: Personally Identifiable InformationPIN: Personal Identification NumberPKI: Public Key InfrastructurePRF: PseudoRandom FunctionPS: Premaster SecretPSE: PSEudonymityPVDE: PIN Verification Data ElementRAN: Real Account NumberRCA: Remote Card AuthenticationSDA: Static Data AuthenticationSHA: Secure Hash AlgorithmSP: Service ProviderSPID: Service Provider IDentifierSRP: Secure Remote PasswordSRV: Server Random ValueSSL: Secure Sockets LayerSSO: Single Sign-OnSV: Starting VariableSYN: SYNchroniseTC: Transaction Certificate

18

LIST OF TABLES

TCN: Temporary Card NumberTCP: Transmission Control ProtocolTDES: Triple Data Encryption StandardTLS: Transport Layer SecurityTRUN: TRUNcateTTP: Trusted Third PartyTVR: Terminal Verification ResultsUAN: Umbrella Account NumberUNL: UNLinkabilityUNO: UNObservabilityURL: Uniform Record LocatorVPN: Virtual Private NetworkWeb: World Wide WebXOR: eXclusive OR

19

Notation

‖: Concatenation⊕: Exclusive or (XOR)a: Personal identification number (PIN)A: Amount authorised (AA)b: Identification numberB : Biometric sampleB2D: Binary to decimal functionc: CiphertextC: LiteralsC : Currency code (CC)d : Private key for asymmetric decryptionD: Decrypt functionD : Datee: Public key for asymmetric encryptionE: Encrypt functionE : Expiry date (EXP)F: Diversification functionF : Finger positiong : NonceG : Counter or sequence numberh: Hash valueH: Hash functionHK : Keyed-hash message authentication code (HMAC) with secret key KHS : Keyed-hash message authentication code (HMAC) with secret SH : Labeli : Current line, operation or valueI : Seedj : Last line, operation or valueJ : Primary account number (PAN)k : Current line, operation or value. Used to avoid confusion with iK : Secret key for symmetric encryptionKB : Key blockKI : Card issuer’s secret symmetric encryption keyKIM : Card issuer’s master key for deriving other keysKM : Card’s master key for deriving other keys

20

LIST OF TABLES

KS : Card’s session key for symmetric encryptionKt: Trusted third party’s (TTP) secret symmetric encryption keyl : ChallengeL: Function that extracts characters from the left-hand sideL: Log entry or left-hand side componentm: Length of cryptographic output, in bitsM : Output from a MAC functionn: Block size of a symmetric cipher or modulus of an asymmetric cipherN : Application transaction counter (ATC)O : One-time account number (OAN) - Chapter 5,

Temporary card number (TCN) - Chapter 7, or equivalent.Also: Online value

p: Input message, often plaintext.Also indicates a prime number for RSA algorithm

P : Transaction or request parametersPAD : Padding valuePAR: Function that sets the least significant bits of each byte to odd parityq : Prime number for RSA algorithmQ : Primary account number sequence number (PANSEQ)r : Client random value (CRV)R: Real account number (RAN) or right-hand side components: Server random value (SRV)S : Shared secrett : Low thresholdT : Timeu: Check digit(s)U : Umbrella account number (UAN)v : Premaster secret (PS)V : Merchant identifierw : Master secret (MS)W : Transaction certificate (TC)X : DataY : DataZ : Data

21

Chapter 1

Introduction

Contents

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.2 Main Contributions . . . . . . . . . . . . . . . . . . . . . . 24

1.3 Structure of Thesis . . . . . . . . . . . . . . . . . . . . . . 26

1.4 Scope: E-payments and Payment Cards . . . . . . . . . . 28

This chapter provides an overview of the thesis, outlines its contribution to the

field of secure electronic payment systems and describes the structure of the thesis.

1.1 Motivation

Since the dawn of commerce mechanisms have been devised for paying a consid-

eration to recompense, after an offer has been made and accepted, to fulfil a con-

tract. The method of recompense has been evolutionary with gradual change over

many thousands of years and taking many guises to represent value to the recipient;

physical items of value such as precious metals evolved into coins and eventually

promissory notes from banks or possibly other issuers.

The rate of change has increased, particular in the past century, with banks

playing a dominant role and building on their promise of payment. Promissory

notes are often thought of as being transferrable and to pay the bearer a fixed sum,

but nowadays that note can be an electronic payment (e-payment) that exactly

22

1.1 Motivation

matches the consideration and only payable to one entity.

Credit cards were mentioned in futuristic fiction in 1887 [21]. According to the

Encyclopædia Britannica [57], credit cards were first issued in a limited form by

individual suppliers for use in their outlets in the 1920s, and in a universal form

that could be used in a variety of establishments in the 1950s. Today credit cards

are just one of several types of payment card which are typically issued by banks,

although cards tied to individual suppliers or products still have a role to play: store

cards and fuel cards for example. Payment cards are now a ubiquitous source for

consumer e-payments; some 84% of the UK’s adult population hold a debit card and

62% a credit or charge card [8].

Consumers, merchants and financial institutions like the convenience of payment

cards and the growth of the Internet has fuelled a remote dimension to e-payments:

Card-Not-Present (CNP) payments. The traditional methods of payment whereby

monies are physically exchanged for goods do not lend themselves to the Internet.

The Internet has brought its own set of problems, notably opportunities for payment

fraud.

E-payment security could be seen as somewhat single-sided. The card issuers

trust their e-payment systems and payment cards. The card issuer usually carries

the liability should anything go wrong unless the card issuer considers the cardholder

or other identifiable party to have been at fault. The temptation is for the card issuer

to build an infrastructure to mitigate its financial risks in a cost-effective manner by

increasing the difficulty for committing fraud, rather than creating an environment

where it can be demonstrated whether the cardholder was behind the payment.

A particular need is for a stronger binding of both the card and its holder to their

payments: to assure any payment to be genuine, to hold the cardholder accountable,

but just for his or her payments, and to stop the cardholder repudiating his or

23

Introduction

her authorised payments. Often authentication, accountability and non-repudiation

counteract privacy. Privacy allows the cardholder to be secluded and to be selective

about the release of his or her personal and payment information. In the wrong

hands, card and cardholder information can facilitate subsequent crime, notably:

payment fraud and identity theft.

The motivation for this research is that I frequently use payment cards and

have (so far) avoided security problems, but get the impression that cardholders

with security problems sometimes feel like David facing Goliath. This research is

to move the next stage of e-payment evolution towards addressing the risks for

and concerns of honest and prudent cardholders, through the provision of privacy

and non-repudiation security services. Some research has been done to look at the

reported and theoretical methods of attack, but far less research has sought solutions.

1.2 Main Contributions

This thesis proposes a novel set of six complementary modular solutions that en-

hance the privacy and non-repudiation security properties of chip-card orientated

e-payments, and the authenticating infrastructure that protects Internet payments1.

The solutions have the cardholders’ interests at heart and are independent so one,

some or all of the solutions can be selected to meet the cardholders’ and card issuers’

needs.

First, a scheme is proposed for making Card-Present (CP) payments that are

effected with a payment card private for the cardholder at the point of payment

and through clearing . By using a one-time account number and not using the card-

holder’s name, the proposal allows the cardholder to be anonymous and for his or1These are web payments made over the Internet. This thesis follows common parlance: Internet

payments.

24

1.2 Main Contributions

her payments not to be linkable to his or her other payments, whilst still allowing

the cardholder to evidence making payment should the payee repudiate receipt. The

cardholder has his or her personal and account details hidden by default, making

one less enabler for identity theft.

The second scheme extends the non-repudiation boundary for CP payments by

proposing three methods for leaving a cryptographic mark of previous payments on

a payment card’s chip to demonstrate whether the card was present for any recent

transaction that is disputed. For the cardholder the three methods provide a trade-

off between ease of reading the cryptographic mark and privacy; for the card issuer

the balance is between processing overhead and storage space on the card’s chip.

The third and fourth schemes extend the security services offered by the first two

schemes to CNP payments and in particular: Internet payments. The methods are

different because the card’s physical presence and chip’s contents do not play a direct

part in the transaction. One scheme allocates an offline Temporary Card Number

(TCN) for each transaction and the other scheme uses a Trusted Third Party (TTP)

to store a biometric sample from the person making the Internet payment.

However authenticating web users remains a particular problem. The fifth

scheme proposes to extend the use of a payment card to provide a Single Sign-

On (SSO) scheme that could be adapted to provide both authentication for the

scheme and the authentication component for other SSO schemes. The sixth scheme

proposes to facilitate client authentication for the Transport Layer Security (TLS)

protocol2 by authenticating with a payment card rather than Public Key Infrastruc-

ture (PKI - outlined in Subsection 2.3.4.1). In both proposals the web server does

not need to know the identity or invade the privacy of the client (cardholder) and

the card issuer maintains a log which could vouch for some of the actions taken by2TLS is used in this thesis as the indicated abbreviation and sometimes to refer to the TLS

protocol.

25

Introduction

the cardholder.

With one, some or all of these proposed schemes, a cardholder can make pay-

ments whilst maintaining as much privacy as he or she wishes. Notwithstanding

this privacy, a cardholder is able to evidence making those payments. Additionally,

with the SSO or TLS schemes there is evidence of any prior authentication over the

Internet. However in certain situations a cardholder may be held accountable for

actions that he or she may (incorrectly) wish to repudiate, for example a purchase

or actions that the cardholder later regrets.

1.3 Structure of Thesis

This thesis is organised as follows:

Chapter 2 provides a hierarchical overview of the security definitions, services

and components on which this thesis builds. First the three foundation information

security services are described, followed by the subservient security services that are

of particular interest for this thesis, next the cryptographic primitives and constructs

that build those services and finally an outline of the three principal cryptographic

algorithms used by this thesis.

Chapter 3 introduces three cornerstones for the e-payment systems that are dis-

cussed in this thesis. Cash is the traditional method of payment and a yardstick

for e-payment systems. Its pros and cons with respect to security services are dis-

cussed. EMV (Europay, MasterCard, Visa) is a widely-used e-payment system for

consumers and where this thesis needs to exemplify with a specific system, then it

is with EMV. Finally CNP payments are discussed because they require special

26

1.3 Structure of Thesis

attention due to the higher risks involved when a card does not directly participate

in a transaction.

Chapter 4 provides a summary of the privacy and non-repudiation attributes

from which specific schemes can be developed and measured. The chapter links the

overview in Chapters 2 and 3 with the next six chapters where schemes are proposed.

Chapter 5 proposes a scheme to enhance the privacy properties of CP payments

made with chip-based payment cards. The scheme uses a one-time account number

for each transaction which acts as the cardholder’s pseudonym and only identifying

mark. It is up to the cardholder whether he or she wishes to disclose any information

that erodes his or her anonymity or allows others to link his or her payments.

Chapter 6 proposes a non-repudiation scheme that leaves a cryptographic mark

on a payment card’s chip each time it is used for a CP payment. The absence or

presence of a mark can show whether the card was involved with a recently-made

payment that is disputed.

Chapter 7 proposes a scheme to enhance the privacy properties of CNP payments.

This offers a comparable service to Chapter 5, but in an environment where the card

does not make direct contact with the merchant.

Chapter 8 proposes a scheme to enhance the non-repudiation properties of pay-

ments made over the Internet. This offers a comparable service to Chapter 6, but

stores a biometric sample from the person making the payment with a TTP as

evidence of participation in the transaction.

27

Introduction

Chapter 9 proposes a scheme to extend the reach of the identity checks that are

undertaken by a bank before it issues a payment card to provide an SSO service for

the World Wide Web (Web). The proposal provides a Two-Factor Authentication

(2FA) framework and a basic single point of user registration that respects the user’s

right to privacy. It also offers certain non-repudiation services.

Chapter 10 proposes another general authentication scheme for a payment-card

holder: client authentication for the TLS protocol. Again, the user’s privacy is

respected and some non-repudiation services are delivered. Typically only the server

is authenticated for a TLS session due to most users not being enrolled in a PKI.

This TLS protocol extension allows a user to authenticate himself or herself with a

payment card instead of PKI.

Chapter 11 gives the conclusions to this thesis and discusses opportunities for

further research.

1.4 Scope: E-payments and Payment Cards

A payment system in this thesis refers to an e-payment system that is associated

with a chip-based payment card, although alternative authentication mechanisms

are not precluded for the two proposed web authentication schemes.

28

Part I

Overview

29

Chapter 2

Security Building Blocks

Contents

2.1 Foundation Security Services . . . . . . . . . . . . . . . . 31

2.1.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.1.3 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2 Privacy and Non-Repudiation . . . . . . . . . . . . . . . . 33

2.2.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2.2 Non-Repudiation . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.3 Principal Cryptographic Primitives and Constructs . . . 45

2.3.1 Hash Function . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.3.2 Symmetric Cryptography . . . . . . . . . . . . . . . . . . . 46

2.3.3 Message Authentication Code . . . . . . . . . . . . . . . . . 48

2.3.4 Asymmetric Cryptography . . . . . . . . . . . . . . . . . . 50

2.3.5 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.3.6 Pseudorandom Functions . . . . . . . . . . . . . . . . . . . 53

2.4 Principal Algorithms . . . . . . . . . . . . . . . . . . . . . 54

2.4.1 Data Encryption Standard . . . . . . . . . . . . . . . . . . 54

2.4.2 RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.4.3 Secure Hash Algorithm . . . . . . . . . . . . . . . . . . . . 56

30

2.1 Foundation Security Services

This chapter provides a hierarchical overview of the security definitions, services

and components on which this thesis builds. First, the three foundation information

security services are described and then those services are subdivided into some spe-

cific security services that are at the heart of this thesis. Underpinning those specific

security services are some cryptographic primitives and constructs which are then

described. Finally, the three main cryptographic algorithms and their variants that

provide those primitives and constructs are outlined.

2.1 Foundation Security Services

No description of information security services is complete without mentioning the

widely-used CIA (or C-I-A) triad information security model which identifies con-

fidentiality, integrity and availability as the fundamental security characteristics of

information. Started by Clark and Wilson [36], it is an idealised model that “strips

away” all properties that are believed to be irrelevant and focuses on a limited set

of properties in isolation.

2.1.1 Confidentiality

Confidentiality is the quality or state of information being protected against disclo-

sure to unauthorised entities: individuals or systems. For example when using a

payment card over the Internet to make a payment, sensitive information need to

be transferred from the client’s computer to the merchant’s computer over a net-

work that is not trusted. Confidentiality during transmission is typically ensured by

encrypting the card number and other payment details whilst in transit. This is a

narrower view than the dictionary definition which covers all types of information,

31


including the spoken word, and without specifying which entities must not know the

information [127].

Confidentiality is about protecting READ access.

2.1.2 Integrity

Integrity is the condition of (the protected information) not being marred or vio-

lated; being in unimpaired or uncorrupted condition; being in its original perfect

state [127]. For a payment this is to prevent fraud or error, or both: in other words,

intentional or accidental harm. Integrity can be protected through various mecha-

nisms; often a cryptographic mark accompanies the protected information in order

that the verifier can recompute that mark to make sure that the information of

interest and its mark tally.

Integrity is about protecting WRITE access.

2.1.3 Availability

Availability is about ensuring that information and services are capable of producing

the desired result when needed [127]. An online system has greater demands for

availability than an offline system. Many of the proposals in this thesis require an

online service to be provided for real-time operations.

32

2.2 Privacy and Non-Repudiation


Confidentiality can be achieved through one or more security services; privacy is

a confidentiality security service which pertains to a person or persons. In turn

privacy is not a solitary security service but an umbrella service for four other

services: anonymity, pseudonymity, unlinkability and unobservability, which can also

be subdivided.

Integrity can also be achieved through one or more security services and non-

repudiation is one such service. Non-repudiation provides integrity by giving evi-

dence that binds an action to an entity, although non-repudiation is not exclusively

an integrity security service.

Payment systems, privacy services and non-repudiation services all rely on other

security services. For example: a consumer payment system needs to authenticate

the card’s data and cardholder to ensure that a payment is authorised, legal consid-

erations require the cardholder to be held accountable for his or her e-payments and

noteworthy events are often recorded in an audit trail for potential analysis.

This section defines the above-mentioned security services in the context of a

card-based payment system.

2.2.1 Privacy

Privacy is the state or condition of being withdrawn from others, or from public

interest, or secluded as a matter of choice or right [127].

Many states protect their citizens’ privacy, particularly European states3:3Member states of The Council of Europe - http://www.coe.int/.

33


• With respect to public (state) authorities “everyone has the right to respect

for his private and family life, his home and his correspondence” [42, Article

8.1] [154, Article 8.1]. However this is not an absolute right but a qualified

right: the public authority is allowed to interfere with this right to privacy,

in part, where necessary in the interests of national security, the economic

wellbeing of the country and the prevention of crime [42, Article 8.2] [154,

Article 8.2].

• With respect to Personally Identifiable Information (PII), this is information

unique to a person and can act as a locator for that person or distinguish that

person from others, the level of protection is more prescriptive [62,153]. Data

solely related to payments and payment cards typically do not fall into the

elevated classification of sensitive data, but they could if a payment were to

point to an unrelated sensitive facet such as a payment to a political party.

Privacy is not a solitary security service. Privacy is a combination of security

services meeting to provide a cohesive service. Particularly for a payment system, the

bounds of the service may change in certain circumstances such as: the cardholder

waiving his or her rights, or where the public authorities exert their rights.

2.2.1.1 Privacy: Terminology and Interrelationship

ISO/IEC 15408-2:2008 is the second part of the three-part international standard

from the International Organization for Standardization (ISO)4 and the Interna-

tional Electrotechnical Commission (IEC)5 that covers evaluation criteria for infor-

mation technology security and, in particular, security functional components [101].

First published in 1999, it is often referred to by its formative name: Common Crite-4http://www.iso.org/.5http://www.iec.org/.

34


ria (for Information Technology Security Evaluation)6. It states that the majority of

terms are used either according to their accepted dictionary definitions or according

to commonly accepted definitions.

The Common Criteria expresses security functional requirements in terms of

classes, families and components. Privacy is a functional class with four member

families: ANOnymity (ANO), PSEudonymity (PSE), UNLinkability (UNL) and UN-

Observability (UNO). These families are subdivided into one or more components.

Figure 2.1 outlines the mostly hierarchical structure of the privacy functional class.

UNO Unobservability

UNL Unlinkability

PSE Pseudonymity

Functional Class: FPR

Class Name: PRIVACY

Class Introduction:

Provide a user protection against discovery and

misuse of identity by others.

Functional Family:

ANO Anonymity ANO.1 Anonymity

ANO.2 Anonymity Without soliciting info

PSE.1 Pseudonymity

PSE.2 Reversible Pseudonymity

PSE.3 Alias Pseudonymity

UNL.1 Unlinkability

UNO.1 Unobservability

UNO.2 Allocation of info impacting unobservability

UNO.3 Unobservability without soliciting info

UNO.4 Authorized user observability

Figure 2.1: Common Criteria privacy class

Where there is a privacy requirement, one or more elements (member families)

may be chosen from the privacy set (class). In other words:

Privacy = {ANO ,PSE ,UNL,UNO}

Pfitzmann and Hansen (formerly Kohntopp) proposed terminology to define the

four families of the privacy class so as to avoid each researcher reinventing a language6http://www.commoncriteriaportal.org/.

35


from scratch and to give consistency [133]. The challenging nature of the task is

illustrated by the paper now (October 2009) being in its 31st iteration [132]. The

definitions are in the specific setting of senders sending messages to recipients using

a communications network, with the thrust being towards unauthorised access by

an attacker rather than access in general (that is: authorised and unauthorised

access) and the assumption that the attacker is not able to get information on the

sender or recipient from the message content. This limitation is partly articulated

by Clauß and Schiffner [39]: “On the network layer, message content is considered

as a black box.” For a payment system it is the message content that is of essence;

the application layer where it can be seen who is paying whom and the details of

the payment. Vice versa, the network layer information and routing do not have

any bearing on cardholder privacy. Integrity and availability are already suitably

protected and, in difference with both papers, unauthorised and authorised read

access is the concern. Pfitzmann-Hansen recognise that in other settings their terms

may need to be derived by abstraction, which this thesis does.

2.2.1.2 Anonymity

Anonymity is the state of being nameless, having no name or of unknown name [127].

The Common Criteria is dependent upon there being a distinction between user

identity and subject identity: the user’s real identity (user identity) versus the

identity or identities representing the user (subject identity). Anonymity is not

intended to protect the subject’s identity, only the user’s identity.

Component ANO.1 contains all the requirements of the anonymity family and

requires that other users or subjects are unable to determine the identity of a user

bound to a subject or activity. Enhanced component ANO.2 requires that the

system does not ask for user identity and the component can be used to satisfy all of

36


ANO.1’s requirements. Both components can allow authorised users to know users’

identities and only protect a defined user or set of users: the anonymity set7.

ANO = ANO .1 or ANO .2

ANO .2 ⊂ ANO .1

2.2.1.3 Pseudonymity

Pseudonymity is the fact or condition of bearing or assuming a false or fictitious

name; the use of an alias or assumed name [127]. A pen name of an author is an

often cited example, but the author’s true name is not necessarily unknown.

The Common Criteria takes a tougher stand than the dictionary and describes

three components that employ a pseudonym when using a resource or service so as

not to disclose its user’s identity, but that user can still be held accountable. Again

a defined set of users are generally protected against unauthorised users. A user (or

cardholder) could be the holder of a subject pseudonym (account number).

Component PSE.1 is the broadest of these components and contains all of those

pseudonymity family requirements. Either or both of the enhanced components

PSE.2 and PSE.3 can be used to satisfy all of PSE.1’s requirements by making the

pseudonymity reversible by the system’s security functions (PSE.2) or by following

certain construction rules for the alias (PSE.3).

PSE = PSE .1 or PSE .2 or PSE .37Chaum introduced the concept of an anonymity set with his Dining Cryptographers’ Prob-

lem [33]. For this thesis, it is the set of all users who could be the anonymous entity. As thesize of an anonymity set increases, so does the strength of anonymity for the elements of that set.The anonymity set is relative to the attacker, context dependent and the set’s size decreases as theattacker’s knowledge increases.

37


PSE .2 ⊂ PSE .1

PSE .3 ⊂ PSE .1

2.2.1.4 Unlinkability

The Common Criteria states that unlinkability allows a user to make multiple uses

of resources or services without unauthorised users being able to link those uses

together. Solitary component UNL.1 satisfies that family requirement. Effectively:

UNL = UNL.1

2.2.1.5 Unobservability

The Common Criteria states that unobservability ensures that a user may use a

resource or service without others, especially third parties, being able to observe

that the resource or service is being used. The unobservability family consists of four

components but this family is not a privacy objective for this thesis (see Subsection

4.1.4).

UNO = UNO .1 or UNO .2 or UNO .3 or UNO .4

UNO .2 ⊂ UNO .1

2.2.1.6 Caveats on Privacy

The Common Criteria recognises that for “ultimate privacy”, no user or authorised

user can see the identity of anyone performing any action. Privacy is also dependent

38


on the “strength of function”, that is the minimum efforts assumed necessary to

defeat the expected security behaviour.

Cardholder’s Actions. For all four families, the Common Criteria excludes the

user’s explicit actions that disclose his or her identity. This thesis similarly excludes

such explicit actions. The proposed privacy properties are optional and there will

be situations where these properties are not desirable or not possible.

Statutory and Regulatory Requirements. In most states the statutory and

regulatory framework does not allow credit and financial institutions to keep anony-

mous accounts [63, Article 6] [147, Section 326.a.2] [155, Regulation 16.(3)], but

not all states [75]. However most states allow anonymity for the cardholder with

other entities in the payment chain when paying for uncontrolled products or ser-

vices, and some digital cash service providers claim their payment application to be

anonymous [58,129].

Per the Common Criteria’s ANO family definitions, a payment system where the

card issuer knows its cardholders’ identities but does not allow other entities to know

that information in normal operation could be deemed anonymous.

Police Investigations. Notably had anonymity been readily available, the UK

Police’s Operation Ore would not have been able to identify 6,000 suspected users of

child pornography that was accessed over the Internet and make 1,300 arrests [19].

By paying the service provider with traceable payment cards, a large number of

the cardholders could be identified to the Police through the card issuers and held

accountable.

39


Pragmatism. Providers of payment systems usually have privacy policies, possi-

bly coupled with an opt-in or opt-out clause depending upon the perceived value

of the information, to clarify the terms and details of the service with the payment

system users. Apart from ensuring compliance with most data protection legislation

by virtue of subject consent, it also adds clarity to the terminology.

2.2.2 Non-Repudiation

Repudiation is an action of rejection or denial of, for example: a thing, an action, a

contract, a person or an obligation [127].

International standard ISO/IEC 10181-4:1997 [84] provides a non-repudiation

framework and discusses non-repudiation in terms of evidence: “The goal of the non-

repudiation service is to collect, maintain, make available, and validate irrefutable

evidence concerning a claimed event or action in order to resolve disputes about the

occurrence or non-occurrence of the event or action”. Earlier international stan-

dards (for example ISO 7498-2:1989 [79]) tended to use the term “proof” rather

than “evidence” and did not use a term akin to “evidence subject” to recognise that

the entity involved in the event or action may not be same as the entity in dispute.

The latest framework is also more open-minded about the technical mechanisms

for providing a non-repudiation protocol and no longer implies digital signatures

(Subsection 2.3.4.3) to be the only mechanism for non-repudiation services. Sub-

sequent three-part international standard ISO/IEC 13888 describes mechanisms for

non-repudiation services using secure envelopes with the participation of a TTP as

well as digital signatures [85,87,91].

The mentioned international standards again concentrate on the specific setting

of senders sending messages to recipients using a communications network. For

this thesis, in the context of a consumer e-payment system there are two main non-

40


repudiation services: non-repudiation of making (or originating) a payment and non-

repudiation of receiving a payment. Often a payer claims to have made payment

which the payee claims not to have received, but it can also be vice versa where

the recipient claims to have received a payment that the payer claims not to have

made. For example, when a stolen payment card is used or the recipient is handling

ill-gotten gains. There are other payment-related actions that could be repudiated

such as a payment processor could deny processing a payment.

The term non-repudiation has differing interpretations in electronic commerce

(e-commerce); a cardholder may be liable irrespective of who made the payment.

Bohm et al. [25] state that “A technical assessment may prove that it is highly

probable that (the payment) was made by its apparent maker. A legal assessment

may hold that the apparent maker (of the payment) is bound by it whether the

apparent maker made it or not.” This thesis looks at the technical assessment.

Figure 2.2 outlines the mostly hierarchical structure of the Common Criteria’s

communication functional class which contains two families: Non-Repudiation of

Origin (NRO) and Non-Repudiation of Receipt (NRR). Each family is divided into

two components. NRO.1 provides proof of origin on request whereas enhanced

component NRO.2 provides that proof all of the time. Either can be used to meet

all the requirements of the NRO family. Similarly, NRR.1 provides proof of receipt

on request whereas NRR.2 provides that proof all of the time. It is for the chosen

Common Criteria protection profile to define the security requirements and to specify

the recipient of the proof.

Communication = {NRO ,NRR}

NRO = NRO .1 or NRO .2

NRR = NRR.1 or NRR.2

41


NRR Non-repudiation of receipt

Functional Class: FCO

Class Name: COMMUNICATION

Class Introduction:

Provides two families specifically concerned with assuring the identity of a party participating in a data exchange.

Functional Family:

NRO Non-repudiation of origin NRO.1 Selective proof of origin

NRO.2 Enforced proof of origin

NRR.1 Selective proof of receipt

NRR.2 Enforced proof of receipt

Figure 2.2: Common Criteria communication class

2.2.2.1 Accountability

Accountability is the quality of being liable to be called to answer for responsibilities

and conduct: answerable and responsible. Chiefly of person(s), to a person, for a

thing [127].

For an information or payment system, accountability usually requires the entity

that is accountable to be authenticated and the event that is accountable to be

recorded in a secure audit trail (sometimes known as an audit log) [68, Subsection

1.1.6].

2.2.2.2 Non-Repudiation versus Accountability

The terms non-repudiation and accountability are often used interchangeably but

this thesis makes a distinction. Accountability is where the entity is liable to be

called to account, supported by collecting, maintaining and making available evi-

dence. Non-repudiation adds validation of evidence in order to resolve disputes. This

interpretation is aligned with some [168], but not all [20]. For example, Bella and

Paulson suggest that correctness of accountability protocols involves two concepts:

validity of evidence and fairness.

42


Zhou and Gollmann [168] consider fairness to be optional and for a fair non-

repudiation protocol not to give one party an advantage over the other or vice

versa, although Gollmann et al. later describe that as vague [114]. This thesis

proposes schemes that are intended to be advantageous for the cardholder and does

not consider a point of balance for fairness.

Non-repudiation services establish evidence: evidence establishes accountabil-

ity [91].

2.2.2.3 Audit

Although it is preferable to prevent unauthorised activity and problems, it is not

always possible or practical. Further mechanisms are therefore required to help

detect security and other noteworthy events. Auditing is the process of recording

relevant events in an audit trail for potential later analysis: an audit [68, Subsection

1.1.6].

To be effective the audit trail needs to be held in a secure place that is not

susceptible to the same perils as the subject(s) being monitored. The volume of

data written to an audit trail also has to strike a balance between being sufficient

and not capturing every detail so as to create storage problems and an audit trail

that is too large for effective analysis.

An audit trail can be a repository of evidence that supports accountability and

non-repudiation although auditing has a wider remit. An audit trail can also help

other security services, for example confidentiality: a review may identify an entity

reading beyond its intended bounds.

43


2.2.3 Authentication

Authentication both needs and supports other security services. It is implicit for

many of the mentioned security services.

Authentication in the context of this thesis is the action or processes of es-

tablishing the validity of a claim [127]. This can be a claim to be a particular

identity: entity authentication, or a claim that data originated from a particular

source: data origin authentication. International standards describe authentication

terminology [79], albeit in a networking setting, and others describe the protocols:

most notably ISO/IEC 9798-1:1997 [86] and ISO 16609:2004 [82].

Unilateral authentication is entity authentication which provides one entity with

assurance of the other’s identity but not vice versa. Mutual authentication provides

each entity with assurance of the other’s identity.

Entity authentication only provides confidence at the time of check and authen-

tication of origin only provides confidence of source and does not, on its own, provide

confidence that the data have not been altered or duplicated.

When a card payment is initiated typically two things are authenticated: the

cardholder as an entity and the origin of the card’s data. Subsection 3.2.2 describes

the authentication of an EMV payment card’s data and its cardholder. Later on in

the EMV payment cycle the card issuer, transaction data and secure messages may

also be authenticated.

44

2.3 Principal Cryptographic Primitives and Constructs


This section describes the cryptographic building blocks that are used in this thesis

to provide the desired security services.

X‖Y is used throughout this thesis to denote the concatenation of data items X

and Y .

2.3.1 Hash Function

A hash function is a cryptographic algorithm that takes input of an arbitrary length

and creates an output, or hash, of a fixed length. Some other terms are used for a

hash and hash functions; for consistency this thesis avoids those other terms. The

assumption is that a hash can be created by any entity with access to the input

so on its own a hash only provides integrity protection against accidental harm. It

is usual to find a hash as a building block of a larger construct. A hash value, h,

calculated by a hash function, H, on an input message, p, is written thus:

h = H(p)

A hash function is associated with the following properties [68, Subsection 12.2.1]:

• Deterministic: for a given input, p, the same hash value, h, is always gener-

ated.

• Ease of computation: given p, it is easy and typically efficient to compute

H(p).

• Compression: function H maps arbitrary length input p to fixed-length out-

put h. The length is algorithm dependent.

45


• Preimage resistance: one-way. Given a value h it is generally computation-

ally infeasible to find value p.

• 2nd preimage resistance: weak collision resistance. Given both h and p it

is computationally infeasible to find another and different message, the hash

of which matches h.

• Collision resistance: strong collision resistance. It is computationally in-

feasible to find two different inputs that generate the same h. Outputs are

mapped evenly over the range and are uniformly distributed.

2.3.2 Symmetric Cryptography

Symmetric or secret key cryptography uses a secret data string, known as a key,

and an algorithm to transform a plaintext (or cleartext) message into ciphertext

and vice versa with the same key. This cryptographic primitive can be used in

different constructs to offer various security services, but its main drawback is that

the participating entities must know the key before they can transform data. In this

thesis specific key derivation functions are discussed but key management generally

entails prior knowledge of the key, or deriving the key from a shared secret and a

salting value, or from a transfer of secret(s) using another cryptographic channel.

2.3.2.1 Symmetric Encryption

Symmetric encryption provides confidentiality security services and uses secret key

K to encrypt (E) message p into ciphertext c. For the purposes of this thesis the

following representation is used:

c = EK(p)

46


That ciphertext can be decrypted (D) with the same key into the original plaintext:

p = DK(c)

There are two widely-used categories of symmetric encryption schemes: block and

stream ciphers. Both are mentioned in this thesis, although only block ciphers

are explored. Block ciphers break the input data into fixed size blocks (that are

algorithm dependent) and encrypt or decrypt in sequence. This simple mode of

operation is referred to as Electronic Code Book (ECB) mode.

2.3.2.2 Cipher Block Chaining

Cipher Block Chaining (CBC) is a mode of encipherment that was patented by IBM

in 1978 [77]. CBC is similar to ECB except that each block of plaintext is processed

by an eXclusive OR (XOR) operation with the previous block’s ciphertext before

being encrypted. This gives some integrity to the ciphertext because each cipher

block is dependent on its preceding cipher block; should one or more bits of a block

of ciphertext be altered then that block and the following block will be corrupt when

decrypted. Confidentiality is also enhanced because if the same plaintext block in a

message is encrypted at two points, then each will give different cipher blocks. An

Initialisation Vector (IV) is used in place of input ciphertext for the first block, which

in the case of EMV and the UK’s payment card processors8 is always set to binary

zeros [54, Annex A.1.1] [14, Subsection 10.2.2]. The CBC encryption operation is as

follows:

ci = EK(pi ⊕ ci−1)

where: c0 is the IV.

The CBC decryption operation is as follows:8CBC is only specified by APACS for message authentication between the card acceptor and

acquirer. APACS is the UK trade association for payment service providers.

47


pi = DK(ci)⊕ ci−1

where: c0 is the IV.

2.3.3 Message Authentication Code

A cryptographic Message Authentication Code (MAC) can provide integrity assur-

ance and data origin authentication services to the other holder(s) of the secret key.

If a TTP is involved and it shares the only other key, then a MAC can in some

situations also provide non-repudiation services.

A MAC function must be resistant to chosen plaintext attack forgeries.

Two inputs are necessary: an arbitrary-length message that is to be authen-

ticated and a secret key. The output is a short m-bit cryptographic check value.

International standards are in place for creating a MAC with a symmetric block

cipher or a hash function. This subsection gives examples of both.

2.3.3.1 Message Authentication Code with a Block Cipher

International standard ISO/IEC 9797-1:1999 covers the use of an n-bit symmetric

block cipher in CBC mode: a CBC-MAC [88].

m ≤ n

In this thesis a MAC is a CBC-MAC unless stated to the contrary and created

in a four-step process:

1. Padding: message p is padded so that its length is a multiple of n bits. The

padding is not retained with the message and only used for creating a MAC.

48


This thesis uses a method of padding that is consistent with international

standards ISO/IEC 7816-4:2005 [94], method 2 of ISO/IEC 9797-1:1999 and

EMV [54, Annex A.1.2]. Specifically: a binary “1” is always appended followed

by the fewest binary “0”s necessary.

p = (p‖PAD)

where: PAD = (binary 1‖ . . . ‖0‖ . . . ‖0)

(That is: add a mandatory “1” and then “0”s if or as needed.)

2. Encipherment: p is CBC enciphered with just the last cipher block retained.

The Starting Variable (SV) is binary “0”s9.

ci = EK(pi ⊕ ci−1), for i = 1, 2, . . . , j

where: c0 is the SV.

3. Optional Encipherment: optionally (but encouraged and used in this the-

sis) cj is encrypted with a second key, K ′.

Either: cj+1 = EK′(cj)

Or: cj+1 = EK(DK′(cj))

Should a 2nd key not be available then K ′ = K is possible in conjunction with

the 1st method of optional encipherment.

However EMV specifies no optional encipherment when using a double key or

the 2nd method of optional encipherment when a double key is split and used

as two single keys. Subsection 2.4.1 describes double and single key operation

of a block cipher.

4. Optional Truncation: the resulting MAC is equal to the most significant m

bits of cj+1.

9MACs refer to an IV as an SV. However the TLS specifications use the term IV throughout.This thesis follows the convention for the specifications under discussion.

49


2.3.3.2 Keyed-Hash Message Authentication Code

A keyed-Hash Message Authentication Code (HMAC) uses an iterative crypto-

graphic hash function with a shared secret key to create its message authentication

code. The strength of the HMAC depends on the key, the properties of the un-

derlying hash function and the size of hash output. First published by Bellare et

al. in 1996 [22], there are now a few international standards which all cover a sim-

ilar definition [90, 108, 123]. This thesis uses the Internet Engineering Task Force’s

(IETF)10 definition because the discussed HMACs are primarily used to protect the

integrity of Internet communications. An HMAC, HK (or sometimes HS), performs

the following computation on message p:

HK(p) = H((K ⊕X )‖H((K ⊕Y )‖p))

Where:

K is the secret key. Bytes 0x00 appended as required to make the key equal

to the hash’s input block length.

X is the outer key pad. The byte 0x5C repeated to the hash’s input block

length.

Y is the inner key pad. The byte 0x36 repeated to the hash’s input block

length.

2.3.4 Asymmetric Cryptography

The technique for asymmetric or public key cryptography was first published by

Diffie and Hellman in 1976 [46] and is characterised by each participant using its

own key pair: a mathematically related public and private key. The public key can

be freely distributed and the private key must be kept secret by its user. The use10http://www.ietf.org/.

50


of the keys depends on the cryptographic scheme. Two cryptographic schemes and

an infrastructure to support public keys are covered in this subsection.

When compared to symmetric keys, an asymmetric public key can be communi-

cated over a public channel without having to protect the key’s confidentiality, but

when enciphering or deciphering the level of computation is significantly higher mak-

ing asymmetric cryptography computationally expensive or even prohibitive, partic-

ularly in a resource constrained environment such as a low-cost payment card [17]11.

2.3.4.1 Public Key Infrastructure

Integrity of public keys is a particular problem, specifically: knowing who is using

the matching private key and ensuring that the public key has not been changed.

Should a public key be altered then any data processed by the corrupt key would

not tally with the data processed by the genuine private key. However a public key

could be substituted by an attacker who then uses his or her own private key to

assume the capabilities of the original private key user.

A Public Key Infrastructure (PKI) is typically a scheme whereby public keys

are bound to their respective user by a Certification Authority (CA) [1, 67]. A

CA is a form of TTP that registers users once they have been identified and can

demonstrate possessing the private key that matches the public key12. A digital

certificate is issued to bind the verified public key to the registered using entity. The

certificate also contains other details such as period of validity and the cryptographic11Tested on a specific hand-held device: an iPAQ H3630.

A digital signature and verification with a 1,024-bit RSA key took 83 milliseconds, and 513 mil-liseconds with a 2,048-bit key. One symmetric encryption and decryption with the DES algorithmtook just 0.07 milliseconds. However RSA works with far larger input blocks (the size of modulus)versus just 64 bits for DES, but the difference remains significant.The mentioned cryptographic operations and algorithms are discussed in the remaining pages ofthis chapter.

12The role of registering users may be delegated to a registration authority by the CA.

51


purpose of the key.

2.3.4.2 Asymmetric Encryption

Asymmetric encryption is where the data recipient’s public key is used to encrypt

and only the corresponding private key can be used to decrypt those data. This

offers confidentiality services for information passing from the entity that encrypts

to the entity that is using the private key. Often hybrid encryption is used where

the entity that encrypts communicates a secret to the private key user. That secret

can be used as a key for symmetric encryption or be used to derive a shared secret.

2.3.4.3 Digital Signatures

Digital signatures are where the key user signs (deciphers) with his or her private

key (at minimum) a hash of a protected message that anyone with access to the

public key can verify (encipher) [89, 95, 98–100]. If used in conjunction with a PKI

then a digital certificate can be used to tie the public key to the signing entity. A

digital signature can provide data integrity, authentication and non-repudiation of

message origin.

2.3.5 Nonce

The term “nonce” stands for “number used once”. It is a finite sequence of bits that

is selected to ensure uniqueness of the output by only being used once within a given

setting. The choice should be unpredictable to any third party. A nonce has many

cryptographic applications including: prevention of message replay attacks, ensuring

the “freshness” of messages and ensuring the “liveness” of an entity. Authentication

52


services often use a nonce. A nonce can be assured to be used just once with any

of several mechanisms, for example: including a time-related variable, or being of a

sufficient size and randomness so that the chance of a service-affecting collision is

insignificant, or the nonce issuer keeping a table of the values already used.

2.3.6 Pseudorandom Functions

In difference to a nonce, a random value can be used more than once; the emphasis

is on the lack of predictability (although some applications may have problems if

the same value were to be used on two separate occasions). A random string can

be a stream of values or a fixed-length value. The next random value should not be

predictable; it should be probabilistic, even to an attacker who knows how the value

is generated. International standards cover random bit generation [92].

A random value is an ideal addition to many cryptographic constructs, for ex-

ample: a digital signature scheme where the keys are salted with a random value

when signing so as to make each signature different, even when the same message

is signed on two occasions (with both signatures salted with different random val-

ues) [98,117,125].

In practice most random value generators are an algorithm with external input

to influence the output, often called a seed, with possibly some adjustment to the

final output should it otherwise appear to be predictable. Such generators are in

fact deterministic and therefore a PseudoRandom Function (PRF). The collision-

resistance properties of hash functions make them particularly suitable to act as a

PRF.

References to random in this thesis may appear to imply a probabilistic value

that may be generated in a manner of the creator’s choosing but in practice it is

53


usually a pseudorandom value.

2.4 Principal Algorithms

This section outlines the principal cryptographic algorithms that are referenced in

this thesis. These are not necessarily the algorithms that are particularly resilient

against published attacks, but more the tried and tested algorithms that are the

cryptographic mainstay of the banking industry [54, Annex B].

2.4.1 Data Encryption Standard

The Data Encryption Standard (DES) [76, 121] was patented by IBM in 1976 and

is a symmetric block cipher that encrypts information, 64-bit blocks at a time.

It also has a 64-bit key but the least significant bit of each byte is reserved and

recommended to be set to odd parity, making the effective key size (or key space)

just 56 bits. This key size is DES’s primary weakness leaving it vulnerable to brute

force attacks: where each possible key is tried until one is successful [142].

To overcome the weaknesses that is caused by short keys, variants of Triple DES

(TDES) uses three keys as follows. To encrypt:

c = EK1(DK2(EK3(p)))

To decrypt:

p = DK1(EK2(DK3(c)))

Terminology:

54


• 3TDES is where K1, K2 and K3 are all different. Key space is 168 bits. This

variant is not used in this thesis but mentioned for completeness.

• 2TDES is where K1 and K2 are different but K1 = K3. Key space is 112 bits.

Unless mentioned to the contrary, the 2TDES variant is used throughout this

thesis.

• TDES can also run in compatibility mode where K1, K2 and K3 are all the

same and has the same result as the original DES. Key space is 56 bits.

• Single DES is use to describe the original mode of DES operation. One key

with a key space of 56 bits.

2.4.2 RSA

Rivest Shamir and Adleman are the eponymous publishers of the asymmetric RSA

algorithm [139,140]. The algorithm is suited to both encrypting and signing, making

it particularly versatile.

The process for computing RSA keys is as follows:

Select two large prime numbers: p and q

Modulus n is the product of those two prime numbers: n = p× q

A number e is chosen. It is smaller than: (p− 1)× (q − 1)

and also coprime: gcd(e, [(p− 1)× (q − 1)]) = 1

The public key is: (n, e)

Private key d is the inverse modulo of (p− 1)× (q − 1):

ed = 1 (mod (p− 1)× (q − 1))

55


To encrypt:

c = pe (mod n)

To decrypt:

p = cd (mod n)

The RSA algorithm’s strength is in the difficulty of factoring a large integer

(the modulus) into its two prime factors [141]. If that were to be feasible, then an

attacker could construct the private key d from public key (n, e). This difficulty

holds provided the modulus is large; 1024 bits, or even 2048 bits, is quite common

in e-commerce.

2.4.3 Secure Hash Algorithm

The Secure Hash Algorithm (SHA) is a family of 5 cryptographic algorithms that

can be used as hash functions and are published by the USA’s National Institute

of Standards and Technology (NIST)13 [122]14. In this thesis algorithms SHA-1

and SHA-256 are discussed and from a usage standpoint both take in a message of

arbitrary length, pad the message, if necessary parse it into blocks that equal the

input block length (512-bits) and through iteration produce an output of 160-bits

or 256-bits respectively. Both algorithms are different with the linkage being the

standard.

The padding mechanism performs the following operations:

1. Takes input message p that is X -bits long and appends the bit “1” to its end.

2. Adds Y “0” bits to the end of the message where:13http://www.nist.gov/.14Other variants exist that are not published in this standard.

56


X + 1 + Y ≡ 448 (mod 512)

3. The remaining 64-bits are filled with the number X expressed in binary. This

limits the maximum message length to 264− 1 bits, which is not a problem for

this thesis.

Per Subsection 2.3.1, this thesis writes a hash operation thus:

h = H(p)

When the hash function is SHA-1 or SHA-256 then that has operation is written

thus:

h = SHA-1(p)

Or:

h = SHA-256(p)

57

Chapter 3

Methods of Payment

Contents

3.1 Cash: The Benchmark . . . . . . . . . . . . . . . . . . . . 59

3.2 EMV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2.1 Introduction to EMV . . . . . . . . . . . . . . . . . . . . . 60

3.2.2 EMV Authentication . . . . . . . . . . . . . . . . . . . . . . 60

3.2.3 EMV Cryptography . . . . . . . . . . . . . . . . . . . . . . 63

3.3 Card Not Present Payments . . . . . . . . . . . . . . . . . 63

3.3.1 CNP - The Problem . . . . . . . . . . . . . . . . . . . . . . 64

3.3.2 CNP - Deployed Solutions . . . . . . . . . . . . . . . . . . . 64

This chapter introduces three cornerstones for the e-payment systems that are the

focus of this thesis. Cash is the traditional method of payment and a yardstick for

e-payment systems. Its pros and cons with respect to security services are discussed.

EMV is a widely-used e-payment system for consumers and where this thesis needs

to exemplify with a specific system then it is with EMV. Finally, CNP payments are

discussed because they require special attention due to the higher risks involved when

a card’s chip does not directly participate in a transaction.

58

3.1 Cash: The Benchmark

3.1 Cash: The Benchmark

Cash payments have a distinct advantage over their latter-day electronic counter-

parts — any cash transaction can be as private and anonymous as the people involved

wish it to be, unless other external factors are brought into play. Some digital cash

systems have tried to emulate those privacy and anonymity properties with varying

levels of success.

In contrast, cash payments rely on independent methods for providing other

security services. For example, on its own cash does not provide any form of receipt

to evidence payment and neither party is identified or authenticated. This allows

either or both parties to repudiate any transaction and to avoid accountability. A

cash payment cannot be linked to other payments.

As a physical medium the primary security consideration for cash is physical

security; for e-payments there are also logical information security considerations:

the risk of data capture, analysis and manipulation. The logical side of e-payment

systems can facilitate both overt and covert monitoring and even an active attack.

There is a different set of vulnerabilities that can lead to fraudulent payments.

3.2 EMV

Probably the most widely-used e-payment system is EMV, which is specified by

EMVCo LLC15 and mainly deployed in Europe, Asia and South America (Canada

started trials in late 2007 but the USA has yet to follow [65]).15http://www.emvco.com/.

59

Methods of Payment

3.2.1 Introduction to EMV

EMVCo was formed in 1999 by Europay International, MasterCard International16

and Visa International17 to manage, maintain and enhance the “EMV Integrated

Circuit Card Specifications for Payment Systems” [53–56]. Europay has since been

acquired by MasterCard and JCB International18 has now joined the organisation.

Although the EMV specifications are primarily concerned with the interaction be-

tween an EMV smart card and terminal, the specifications describe the design of

an EMV smart card on which the card issuers may build their EMV-compliant

application. The overarching principles also apply to other payment systems.

In the UK, smart cards with an embedded chip that authenticates the cardholder

with a Personal Identification Number (PIN) are better known as “chip and PIN”

cards. In February 2006, the majority of the UK’s payment cards cut-over from

using the card’s magnetic stripe mechanism to using EMV’s implementation of chip

and PIN as the primary payment card mechanism19.

3.2.2 EMV Authentication

Building on the concepts outlined in Subsection 2.2.3, at the start of an EMV trans-

action two authentication steps are completed: cardholder (entity) authentication

and authentication of (the origin of) the card’s data.16http://www.mastercard.com/.17http://www.visa.com/.18https://www.jcbinternational.com/.19http://www.chipandpin.co.uk/.

60

3.2 EMV

3.2.2.1 Cardholder Authentication

Cardholder authentication is to verify that the person presenting the payment card

is the person to whom the card was issued. The Cardholder Verification Method

(CVM) can take several forms [55, Table 39]:

• PIN verification: is the method used for most transactions.

– Plaintext or enciphered PIN verified by the card’s chip and offline to the

card issuer.

– Enciphered PIN verified online by the card issuer.

• Paper signature: can be particularly useful for people with disabilities who are

unable to operate a PIN-based card. Typically the person is given a chip and

signature card which brings many of the EMV benefits with just the CVM

changing.

• Combination: of a paper signature and offline PIN verification by the card’s

chip.

• No verification: is typically used for low-value transactions at unattended

terminals where speed of payment is of the essence. For example: road tolls

and car parks [162].

This thesis builds on PIN verification because paper signatures presently do not

lend themselves so well to e-commerce and no verification is only for a small number

of specific applications where presumably the higher risk of fraud is accepted.

61

Methods of Payment

3.2.2.2 Data Authentication

Data authentication is to verify the legitimacy of the card’s data and uses a closed

PKI; that is a PKI system with compact certificates that are only used within the

controlled community of EMV payment card processors. There are three methods

of data authentication [54, Chapters 5 and 6] and this is the main variable that

influences the design, capabilities and operation of the card.

Static Data Authentication (SDA) is the most basic design with the cheapest

to produce cards; these cards’ chips process symmetric cryptography. The signed

data and certificates that are presented to authenticate are placed on the card’s chip

when it is personalised by the card issuer for the cardholder.

Dynamic Data Authentication (DDA) is a more complex and expensive de-

sign; most notably DDA card chips also process some asymmetric cryptography.

DDA requires the payment card’s chip to produce a digital signature for some vari-

able data. However the use of asymmetric cryptography only extends to validating

the card’s resident data and not to the transaction data.

Combined DDA/Application Cryptogram Generation (CDA) is an exten-

sion to DDA and the use of asymmetric cryptography can extend to the transaction

data.

The Mainstay is SDA. It appears that EMV cards in the UK are predominantly

SDA cards and presumably most other countries are much the same [6,163].

62

3.3 Card Not Present Payments

Fallback Mode payments. Most EMV cards continue to carry a magnetic stripe

so that they can still be used in locations that have not converted to EMV. It also

means that should the card’s chip or merchant’s reader fail during a transaction,

“fallback” to using the magnetic stripe’s data can optionally take place.

Cardholder (implicitly) trusts the card issuer because all keys, shared se-

crets and resident data are placed on the card’s chip during personalisation. The

need for this level of trust is probably not apparent to the cardholder, who proba-

bly knows little or nothing about the card’s design and construct. The card issuer

has the theoretical capability to falsify most cardholder transactions, although in

practice the card issuers are banks with a control framework and a reputation to

protect; but lapses have been reported [4].

3.2.3 EMV Cryptography

The algorithms approved for EMV are 2TDES (symmetric encryption and MAC),

RSA (asymmetric encryption and digital signatures) and SHA-1 (hash) [54, Annex

B]. Single DES is only approved for one of the two specified MAC mechanisms where

one single key is used to compute the MAC and a different single key must be used

for the optional encipherment step, which is now mandatory. RSA is used with a

maximum modulus of 248 bytes (1984 bits).


EMV and most payment card systems are designed to operate in a CP environment,

where the cardholder presents his or her card to a merchant who places the card in

a terminal to process the transaction. The card’s data and cardholder are authen-

63

Methods of Payment

ticated using the mentioned or equivalent methods. As an extension, cards can be

used to make payments remotely: over the Internet mainly but also by mail order

and telephone order. These Card-Not-Present (CNP) transactions do not allow the

card’s chip to participate directly in the transaction.

3.3.1 CNP - The Problem

Cyber criminals closely follow advancing technology and seek out the most vulnera-

ble points to attack; when a weakness is remedied the next weakest link comes into

focus. For payment cards in the UK, in the four years straddling the introduction of

chip and PIN cards, the monies lost through CP fraud with UK retailers fell by 55%

and Automatic Teller Machine (ATM) fraud fell by 39% but CNP fraud increased

by 118% [9]. During the same period, the monies lost through online banking fraud

increased by 330%. Criminals are now specifically targeting payment methods that

are not chip and PIN protected, although for the last reported year all of these types

of fraud increased.

To make a CNP payment, the cardholder traditionally quotes his or her card

number to the merchant and it is for the merchant to authenticate the card and

cardholder or to implement a control to mitigate the risk of fraud. A control could

be only to deliver physical goods to the cardholder’s billing address and verify that

address with the bank; some merchants just accept the risk. Passive mechanisms for

authenticating cards and cardholders are a soft target, although still widely used.

3.3.2 CNP - Deployed Solutions

The authentication of CNP payments has been an evolutionary process, but the

widespread use of the Internet as a conduit for consumer payments and the increase

64


in fraud have given a new impetus to developing solutions.

3.3.2.1 Remote Card Authentication

To extend the reach of chip and PIN authentication to the Internet, and potentially

all CNP transactions, Visa’s European card issuers often provide hand-held Dynamic

Passcode Authentication [158] devices to facilitate a chip and PIN response from

the 2FA of the cardholder using the provided offline card reader. Other payment

associations have followed suit; MasterCard has its Chip Authentication Program.

In mid-2008, Visa launched a pilot for a card that integrates the authentication

device [159]. APACS20, the UK trade association for payment service providers,

generically refers to such offerings as Remote Card Authentication (RCA) systems.

It is both the possession of the payment card and knowledge of its PIN that make

up the two factors which influence the generation of a one-time passcode by the

card’s chip, which is then displayed on the RCA device. Typically an unpredictable

challenge from the card issuer is used to influence the one-time passcode, or response,

for an even stronger authentication that also verifies the liveness of the cardholder.

The card’s logical environment is trusted by the card issuer who verifies the RCA

response.

An analysis of three RCA-enabled cards by Drimer et al. indicates the use of a

dedicated smart-card application and RCA card reader, both specific to the card

issuer. The sampled cards were all EMV-complaint MasterCards, each from a dif-

ferent UK issuer. The sampled RCA applications are heavily based on the EMV

protocol and able to access the main EMV application files. All three RCA pro-

tocols have noteworthy differences, including different application identifiers which

the card readers are programmed to select [48].20http://www.apacs.org.uk/.

65

Methods of Payment

The RCA protocol has not been published and this thesis considers a generalised

implementation for any chip-based payment card.

3.3.2.2 Online Temporary Card Numbers

Orbiscom’s21 Controlled Payment Numbers™ product supports the card issuer by

keeping the card’s real account number hidden from the merchant and any at-

tacker(s). Orbiscom allocates a TCN to the cardholder before he or she makes

a CNP payment and translates that number back again when the TCN is presented

in place of the Primary Account Number (PAN). Each TCN is only valid for a

relatively short period, can be limited to one or multiple transactions and optionally

has a maximum payment value. One of a growing number of examples of a Con-

trolled Payment Numbers™ implementation is Citibank’s22 Virtual Account Number

service [35].

21http://www.orbiscom.com/.22http://www.citibank.com/.

66

Chapter 4

Attributes

Contents

4.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.1.1 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.1.2 Pseudonymity . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.1.3 Unlinkability . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.1.4 Unobservability . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.1.5 Privacy Summary . . . . . . . . . . . . . . . . . . . . . . . 71

4.2 Non-Repudiation . . . . . . . . . . . . . . . . . . . . . . . . 71

4.3 Internet Payments . . . . . . . . . . . . . . . . . . . . . . . 72

This chapter quantifies the attributes of the privacy and non-repudiation schemes

that are proposed in Parts II and III of this thesis. The proposed schemes tread a

fine line between theory and practicality, and can be measured against this summary.

4.1 Privacy

Privacy is not a solitary security service. One or more member “families” can be

selected and used in whatever proportion and depth the e-payment system needs.

Different people have differing combinations of requirements. For example:

67

Attributes

• Some people are happy to forego some privacy when making an e-payment

because, for example, goods may need to be delivered or the cardholder may

wish to be known as a loyal customer and receive a direct discount or be

credited with points for his or her purchases. Loyalty cards typically give

customers low-cost rewards when they forego some privacy.

• Some people may wish for “ultimate privacy” but this is not achievable. There

are various barriers, for example: in most states the card issuer is not allowed

to keep anonymous accounts (see Subsection 2.2.1.6).

This thesis errs on the side of facilitating as much privacy as practicable and

leaves it to the cardholder to decide whether any privacy-related information is

released.

4.1.1 Anonymity

In most states a cardholder can be anonymous to all bar the card issuer. As a

financial institution the card issuer is legally obliged to know its customers, whilst

recognising that a cardholder’s name is not necessarily a unique locator for any

cardholder because more than one cardholder may be known by the same name. It

is for the card issuer to be clear on the bounds of any claimed anonymity and under

what circumstances it would expose a cardholder’s identity, and to whom.

For a card-based payment system to be anonymous the card and transaction

data must not include the user’s identity, specifically: the cardholder’s name or any

other information that could infer the user’s identity, and the merchant’s payment

application must not expect to receive the user’s identity. However most states

require the card issuer to know the user’s identity and potentially release it to

authorised entities.

68

4.1 Privacy

Omitting PII and just using a subject identity meets Common Criteria compo-

nent ANO.1, where subject identity can only be mapped to user identity by the

cardholder and card issuer. The payment system must know the user’s identity and

just protects it from disclosure making Common Criteria component ANO.2 too

stringent.

4.1.2 Pseudonymity

For a card-based payment system to be pseudonymous, the user’s identity must be

protected but the cardholder must remain accountable. Accountability is maintained

by using a reference or alias that can be mapped to a user identity by the payment

system.

Using an account number as a subject identity in place of a user identity, which

only the cardholder or card issuer can correlate, meets Common Criteria component

PSE.1 (generalised pseudonymity). Two of the proposed schemes use temporary

identifiers, which still act as a subject identity and maintain accountability. En-

hanced component PSE.2 (reversible pseudonymity) requires the pseudonymity to

be reversible in certain circumstances, which does not happen in the field with the

proposed schemes. Enhanced component PSE.3 (alias pseudonymity) requires cer-

tain construction rules to be followed for an alias, which is only the case for static

account numbers.

Common Criteria component PSE.1 can be met by both static and variable

account numbers, but more-stringent component PSE.3 can only be met by static

account numbers.

69

Attributes

4.1.3 Unlinkability

Should any piece of static information be used on more than one payment, then

payments with that information may potentially be linked. For an e-payment card,

the account number is the most-likely field that could allow payments to be linked,

although the cardholder’s name could also allow for considerable linkability. The

remaining fields such as expiry date provide some linkage, but probably not sufficient

to be of use due to an unknown number of other cardholders also having the same

values for those fields.

For a card payment to be unlinkable there must be no cardholder-specific static

information carried between transactions, particularly the user’s identity or a static

subject identity.

Removing cardholder-specific static information meets Common Criteria compo-

nent UNL.1 because a user may make multiple uses of a resource or service without

others being able to link those uses together. As authorised entities, the cardholder

and card issuer are able to link the cardholder’s payments.

4.1.4 Unobservability

Unobservability is where a user may use a resource or service without others, es-

pecially third parties, being able to observe that the resource or service is being

used. Should a payment card be unobservable then only the card issuer can observe

whether a cardholder is making a payment.

Although unobservability as a distinct service is particularly important for the

privacy of a network, it is not so applicable to a payment system where it is the

traffic content rather than the presence of traffic that could compromise privacy.

70

4.2 Non-Repudiation

The other three privacy families protect message content and together they provide

sufficient protection for an unobservability service.

4.1.5 Privacy Summary

For a payment to be private, the card and payment application must not include

the user’s identity or any other information that could infer that identity. A unique

subject identifier (id) must be used for each payment and that identifier together

with any static information must not link the payment to the user’s identity or any

other payments made by that user.

However the cardholder and card issuer are authorised to be excluded from these

requirements and either may release the protected information to other authorised

entities.

Chapters 5 and 7 propose schemes that implement the mentioned levels of pri-

vacy.

4.2 Non-Repudiation

Non-repudiation is about evidence with the goal of resolving disputes by, for ex-

ample, determining whether a payment was made or received, or both. This thesis

concentrates on disputes over the making of payments where the cardholder is the

evidence subject. Electronic evidence can take many forms and often they are stored

in a secure audit trail that is not subject to the same perils as the events and ac-

tions being observed and cannot be manipulated by any party potentially involved

in any dispute. The evidence should be created as a routine operation, irrespective

of whether there is a dispute, and be presented to a TTP or other arbitrator should

71

Attributes

the parties involved not be able to resolve the dispute themselves.

For an e-payment system to offer non-repudiation properties, irrefutable evidence

must be (1) collected, (2) maintained, (3) made available and (4) validated in order

to resolve disputes about whether a payment was made (or received). A mechanism

must be in place to resolve any dispute.

Chapters 6 and 8 propose schemes that implement non-repudiation of origin

(payment) security services. These meet Common Criteria component NRO.1, but

where the cardholder can use that evidence directly as a matter of routine then

enhanced Common Criteria component NRO.2 can be met.

4.3 Internet Payments

Privacy and non-repudiation may be provided for the payment itself, but Internet

payments require particular attention. These security properties may be eroded

when the cardholder registers with and signs-on to the merchant, or by using a

connection protocol that is not secure and so does not protect the payment source

or data.

For an Internet payment to offer privacy and non-repudiation services, the ses-

sion’s sign-on mechanism and networking protocol must also offer comparable ser-

vices.

Chapters 9 and 10 propose schemes that provide a single-sign-on service and

secure network protocol that use a payment card for authentication. At minimum,

these two schemes can meet Common Criteria components ANO.1, PSE.1, UNL.1

and NRO.1.

72

Part II

E-Payment Schemes:

Cardholder Privacy and

Non-Repudiation

73

Chapter 5

Payment Cards: Privacy

Contents

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.3 A Card Not Present Scheme . . . . . . . . . . . . . . . . . 77

5.4 The Proposed Mechanism . . . . . . . . . . . . . . . . . . 78

5.4.1 Anonymity . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.4.2 EMV: Anonymity . . . . . . . . . . . . . . . . . . . . . . . 80

5.4.3 Pseudonymity and Unlinkability . . . . . . . . . . . . . . . 81

5.4.4 EMV: Pseudonymity and Unlinkability . . . . . . . . . . . . 83

5.4.5 Effect on Payment Processing Entities . . . . . . . . . . . . 90

5.5 Residual Threat Analysis . . . . . . . . . . . . . . . . . . . 91

5.5.1 Passive Attack . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.5.2 Active Attack . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.5.3 Size of Anonymity Set . . . . . . . . . . . . . . . . . . . . . 93

5.5.4 Floor Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.5.5 Birthday Attack . . . . . . . . . . . . . . . . . . . . . . . . 95

5.5.6 Issuer Impersonation . . . . . . . . . . . . . . . . . . . . . . 95

5.5.7 Non-Repudiation . . . . . . . . . . . . . . . . . . . . . . . . 95

5.5.8 Physical Security . . . . . . . . . . . . . . . . . . . . . . . . 96

5.5.9 Legal Precedent . . . . . . . . . . . . . . . . . . . . . . . . 96

74

5.1 Introduction

5.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

This chapter proposes a mechanism for making card-present payments that are

effected with a chip-based payment card private for the cardholder at the point of

payment and through clearing, provided an out-of-band action by the cardholder or

card issuer does not erode the cardholder’s privacy. This allows the cardholder to

be secluded and without identity when making a payment, and for the payment not

to be linkable to the cardholder’s other payments, whilst still holding the cardholder

accountable for the payment and allowing the cardholder to evidence payment should

the payee repudiate receipt.

This proposal is intended to be adaptable for most chip-based payment card sys-

tems. However, to exemplify the design criteria and an implementation, a generic

EMV payment card is used.

Much of the material in this chapter has been previously published [30].

5.1 Introduction

It is customary for a payment-card holder to have his or her identity and account

number exposed to all merchants with whom he or she does business. The card-

holder’s name and PAN are usually embossed on the card and passed electronically

to the merchant from either the card’s magnetic stripe or the card’s chip. However

in most states identifying the cardholder to the merchant is not mandatory; only

the card issuer needs to know the cardholder’s identity, account number and the

other payments that he or she makes. From a payment perspective, it is sufficient

for a merchant to know that a reliable entity can match any given card payment

to a person. If anything, the card issuer should err in favour of the cardholder and

75


leave it for the cardholder to decide whether his or her identity and account number

are exposed: privacy is the cardholder’s (qualified) right. Subsection 2.2.1 looks at

the right to privacy and how it can be achieved.

The EMV specifications do not prevent or claim to allow cardholder anonymity,

and include just one incidental reference to privacy. The card issuers are intended

to build on the EMV specifications baseline and to make claims about their EMV-

compliant payment application as they see appropriate.

Privacy is not only a right that may be appealing to security-conscious cardhold-

ers, but also an effective protection against fraud. Banks that have migrated to chip

and PIN payment cards describe their cards as secure [70] or even “more secure” [73]

(without saying what is being compared). However the financial risk to the card-

holder is not just about potential problems with the immediate payment process, it

can also come with the loss of privacy to an attacker through a side channel. This

can be through the card being skimmed by a malicious merchant (or a member of

the merchant’s staff) [149], or the card being intercepted by a skimming device [115];

skimming is the root cause of 28% of the monies lost through card fraud [9]. Those

data can also be disclosed through modified terminals [151], while in the merchant’s

possession [37], or while they are held by a payment processor [124]. The attackers

tend to have a common goal: monetary gain through direct or indirect payment

card fraud. Standards, such as the Payment Card Industry Standards [130], and

data encryption do not always protect the cardholder; the point of data capture and

authorisation processing are particularly vulnerable.

Cardholder privacy with anonymity and unlinkability by default gives payment

cards a closer parity with cash and, if this proposal is applied to all transactions,

drastically reduces the usability and value of any “stolen” payment-related informa-

tion.

76

5.2 Contribution

5.2 Contribution

This chapter treads the fine line between theoretical capability and practical limita-

tion to propose a method for making Card-Present (CP) payments that are effected

with a chip-based payment card private for the cardholder at the point of payment

and through clearing, provided an out-of-band action by the cardholder or card issuer

does not erode this security property.

Privacy allows the cardholder’s details and activities to be secluded by default.

Anonymity allows the cardholder not to be identified by default, making one less

enabler for identity theft (which accounts for approximately 7½% of the monies lost

through payment card fraud [9] ).

Unlinkability allows the cardholder to make a payment without that payment

being linked to his or her other payments.

Even with privacy, anonymity and unlinkability, this proposal allows the cardholder

to evidence payment should the payee repudiate receipt and holds the cardholder

accountable for the payment.

5.3 A Card Not Present Scheme

Orbiscom has already deployed a system that protects the cardholder’s PAN by

allocating TCNs for each transaction. (See Subsection 3.3.2.2.) However Orbiscom’s

solution is designed for CNP transactions; the solution does not allow the payment

77


card to be present with the card’s chip participating in the transaction. Orbiscom’s

solution also requires the user to have access to the issuing bank through a secure

Internet terminal to enter his or her identifier, password and card number and then

make a note of the TCN that is displayed on the screen.

The solution in this chapter covers CP transactions where the card is processed

by the merchant’s terminal, often offline and for a spontaneous payment.

If an Orbiscom-type scheme were to allocate a temporary PAN to an EMV

cardholder for each payment, a considerable change to the EMV specifications would

be required. The PAN must be present in the Integrated Circuit Card’s (ICC)23

files [55, Section 7.2] that are read using the READ RECORD command. The

READ RECORD command [55, Section 10.2] takes place immediately after the

EMV application selection [55, Chapter 8] [53, Chapter 12] and initiation [55, Section

10.1], before either the card’s data or cardholder is verified. The PAN read from

the ICC’s files is compared to the data read from the issuer-signed certificate that

is passed by the card to the terminal during data authentication [54, Chapter 5 and

6]. Figure 5.1 is an example of an EMV transaction flow [55, Section 8.2].

5.4 The Proposed Mechanism

This chapter proposes a mechanism to protect the cardholder’s privacy when making

a CP payment using a chip-based payment card by providing anonymity and unlink-

ability, aided by a one-time pseudonym. These security properties are only for the

cardholder at the point of payment and through clearing, in keeping with: dictio-

nary definitions, Common Criteria functional requirements and Pfitzmann-Hansen

terminology. They are conditional on there not being an out-of-band action by the23This thesis uses the term “chip card” rather than ICC. ICC is only used to refer to the ICC’s

master key and files so as to be consistent with the EMV specifications.

78


Card Contact With Terminal?

EMV Application Selected?

Initiate EMV Application?

Read Application Data

? ?Data Authentication

?

Terminal Risk Management

�

Processing Restrictions Terminal Risk Managementis performed in parallel.?

Cardholder Verification?

Terminal Action Analysis?

Card Action Analysis?

Online? Offline?(((((((

((hhhh

hhhhh

hhhhhhhhh(((((((((

?Offline

-Online

Online Proc. & Issuer Auth.

?Script Processing�Completion

Figure 5.1: EMV transaction flow example

cardholder or card issuer to erode these properties.

This proposal requires any magnetic stripe for fallback mode payments and any

other applications on the payment card to provide an equal or greater level of privacy.

Otherwise this chapter’s proposal can be implemented on its own, or with some or

all of the proposals in other chapters.

5.4.1 Anonymity

In most payment applications it is a unique pseudonym in the form of an account

number or PAN that is used to identify the cardholder to the card issuer. A card-

holder’s name is not necessarily a unique locator, particularly when a person with a

common forename and surname is registered with a large card issuer. The inclusion

79


of the cardholder’s name is usual practice, but most payment systems could operate

without it or with a false name.

5.4.2 EMV: Anonymity

The EMV specifications do not require the cardholder’s name to be valid or present,

although it may appear implicit. Therefore the EMV specifications do not prevent

an EMV card from being anonymous at the point of payment and through clearing.

The EMV specifications exclude cardholder name from the tables of mandatory

data objects and only include it in the data elements that may be used for financial

transaction interchange [55, Section 7.2 and Annex A1]. Also, the EMV Card Per-

sonalisation Specification makes no mention of cardholder name [52]. EMV cards

do not have to be embossed or posses a magnetic stripe for backward compatibility,

both of which typically include the cardholder’s name. The only requirements are

the use of alphanumeric and certain special characters [56, Annex B], and compli-

ance with international standard ISO/IEC 7813:2006 (which also does not mandate

the presence of cardholder name) [97].

Visa’s Common Personalization Technical Requirements [161] build on the EMV

specifications and make three references to cardholder name. Two occurrences are

marked “optional” and one is marked “required” which means that the data element

must be present, but the terminal should not terminate the transaction if it is not

received. The term “mandatory” is used for data elements that must be present in

order for transaction processing to continue. Visa also does not mention anonymity

for cardholders apart from incidental processing, such as on the Internet, statistics

and surveys.

The 26-byte “cardholder name” and the additional 19-byte “cardholder name

80


extended” fields are out of scope of this proposal, although using these fields with

a fixed pseudonym could provide a linkage between transactions and potentially a

link to identity, should identity ever be exposed to a merchant.

5.4.3 Pseudonymity and Unlinkability

This proposal uses a one-time account number, or pseudonym, for identification

that can be forward computed by the card’s chip and reverse computed by the card

issuer. This provides unlinkability security properties with respect to the merchant

and during clearing, while allowing the card issuer to identify its cardholder.

Three account numbers are used:

1. The cardholder’s Real Account Number (RAN) is not embossed on the card

or included in the data objects and certificates that are accessible by or sent

to the merchant’s terminal. The RAN is a primitive data object that is placed

on the card’s chip during personalisation, after which only the card can access

that number: read-only. Both the card issuer and cardholder have a separate

record of that number. The RAN acts as a mutual reference number between

the cardholder and the card issuer and is used as a PAN in all other payment-

card related activities; this proposal only affects CP payments.

2. An Umbrella Account Number (UAN) is used in place of the PAN and is

embossed on the card if embossing is the card issuer’s practice; the UAN takes

the appearance of a normal card number. Each issuer uses just one account

number for all of its cards that have adopted the proposed mechanism. The

number of cards behind each UAN is the size of the anonymity set, although

the size of the set is reduced by other data elements such as the card’s EXPiry

date (EXP). The UAN is blocked from being used for any other payment-

81


card related service in the same manner as a stolen card, notably the UAN is

blocked from making CNP payments. As now, each card has its own PIN (or

other CVM).

3. A One-time Account Number (OAN) is also a primitive data object but cal-

culated by the card’s chip during a CP transaction and reversed by the card

issuer when an online transaction makes contact or a completed offline trans-

action is presented for payment. The OAN contains a tag, length and value,

and is included in all Application Cryptograms (AC) as well as the data ob-

jects or transaction data that accompany the ACs. Although called a number

for consistency of terminology, it is a binary primitive data object.

This proposal recommends that an OAN is computed as follows:

O = EK(R‖A‖C )

Where:

O is the OAN.

K is the key that is known to, or can be derived by, both the card’s chip

and the card issuer.

R is the RAN.

A is the Amount Authorised (AA) for the transaction.

C is the transaction Currency Code (CC).

In practice, the cardholder is unlikely to remember his or her RAN and that

could be problematic when the card is used for other services. The cardholder may

be tempted to jot down the RAN and carry that note with or on the card, which

would go some way to defeating the goals of this proposal.

For CNP payments, an equivalent scheme is proposed in Chapter 7 and its im-

plementation is highly advisable if this proposal is implemented. For direct commu-

82


nications with the card issuer the cardholder could use the next card number from

the Chapter 7 scheme or be identified through contextual information, for example:

when the cardholder sends a letter to the card issuer or makes contact over the

telephone.

5.4.4 EMV: Pseudonymity and Unlinkability

The EMV specifications allow card issuers to include additional data elements [55,

Section 5.1]. Data elements associated with financial transaction interchange that

are not specified [55, Annex A] are outside the scope of the specifications. A range

of tag values is reserved for such elements and the coding is left to the discretion of

the card issuer [55, Annex B1]. EMV views the RAN and OAN as additional data

elements.

If files such as the RAN are on the card’s chip and are not listed in the EMV

Application File Locator (AFL), then only the card’s chip can read those files [55,

Section 10.2].

5.4.4.1 One-Time Account Number

A 16-byte OAN is computed by the card’s chip as follows, by a card-resident applet

that gets called when the transaction’s first “GENERATE AC” command is received

from the terminal. A “GENERATE AC” command is the outcome of the Terminal

Action Analysis step (see Figure 5.1) [55, Section 10.7]:

O = EKS(R‖A‖C )

The RAN, which can be up to 10 bytes, is concatenated with the transaction’s

83


4-byte binary AA and the 2-byte transaction CC. This 16-byte string is encrypted

with a 16-byte session key, KS , in 64-bit CBC mode [54, Annex A1.1]. EMV PANs

are compressed numeric data objects with two numeric digits (0x0 to 0x9) per

byte, padded to the right with 0xF to make the required length; 10 bytes in this

instance. 2TDES is the only approved symmetric cryptographic algorithm and mode

of use [54, Annex B1.1].

Expanded, this gives the following DES cipher operation:

(R‖A‖C ) = YL‖YR

KS = KSL‖KSR

XL = EKSL(DKSR

(EKSL(YL)))

XR = EKSL(DKSR

(EKSL(XL ⊕ YR)))

O = XL‖XR

The OAN is communicated by the card’s chip to the card issuer in the transaction

data that accompany all ACs and also used as input to the AC, which is a MAC and

potentially proprietary in format [55, Subsection 6.5.5.1]. EMV does not specify the

input data for an AC, EMV only recommends a minimum set of data elements for

AC generation [54, Table 26]. The OAN is stored temporarily by the card’s chip so

as to be available should the terminal issue a second “GENERATE AC” command.

The mechanism for transporting the OAN may be by including that data in

the optional Issuer Application Data (IAD) for a Format 1 response [55, Subsec-

tion 6.5.5.4], which is specified by EMV to contain up to 32 bytes of proprietary

application data in binary format for transmission to the issuer in an online trans-

action [55, Annex A1]. The UK’s APACS Standard 70 [10–16] specifies a common

84


interface by which card acceptor terminals and acquirer computer systems can ex-

change messages in support of transactions undertaken using financial transaction

cards. Two of the seven books specify message structures, format and content,

data elements and values for data elements that shall be used when card acceptors

and acquirers exchange messages in real-time or post-event [11, 12]. Both reference

the IAD as “additional, undefined, data sent by the card to the issuer to enable

authentication of the card” and just pass it on when present [11, Section 6.1].

However, if the card issuer adopts EMV’s Common Core Definitions (CCD) [55,

Part V], which are an optional extension to the EMV baseline, 17 bytes of the IAD

are reserved by the CCD and only 15 bytes remain for issuer discretionary data [55,

Table CCD 9]. To accommodate the CCD and other issuer implementations that

leave fewer than 16 bytes of IAD available for this proposal, the OAN can be reduced

to 8 bytes. This is possible because the transaction data must contain the AA and

CC [11, Table 24 & Table 27] so that the card issuer knows the transaction value

processed by the card, and only bytes 4 to 9 of the RAN contain data that cannot be

calculated by the issuer. (Bytes 1 to 3 contain the 6-digit issuer identification number

and byte 10 may contain a check digit and a padding character, or more usually two

padding characters. Section 7.4 describes the account number construct.) For this

proposal the leading 3 bytes of the RAN are removed from the front and placed

at the end of the RAN so that the issuer identifier becomes a suffix rather than a

prefix. The processing is as follows:

Remove leading 3 bytes from RAN and place them at end of RAN to give R′.

(R′‖A‖C ) = YL‖YR

X = YL ⊕ YR

KS = KSL‖KSR

85


O = EKSL(DKSR

(EKSL(X)))

When a 16-byte or 8-byte OAN is included in the IAD, no changes are required

to the merchant’s terminal or by the acquirer. Only the card issuer needs to make

changes to its payment processor, its card personalisation system and its cards. The

cards are best updated before issue but could be updated when in the field and

housed in a secure-messaging capable online terminal and then using issuer-to-card

script processing functions [55, Section 10.10].

Note: EMV has a binary AA data element of 4 bytes (tag 81) and a numeric AA

data element of 6 bytes (tag 9F02). This chapter’s proposal uses the binary AA data

element. There is also an EMV “transaction amount” data element (no tag) that is

generated by the terminal which is the clearing amount of the transaction, including

tips and other adjustments. The card is only aware of the amount authorised: the

AA. APACS Standard 70 refers to EMV’s AA as the “cryptogram amount” and

the “transaction amount” (both tag 9F02), and only mentions the data element in

numeric format.

5.4.4.2 Session Key Derivation

Session key KS is just used for this proposal. It requires a new 16-byte ICC master

key, KM , in the card’s Electrically Erasable Programmable Read-Only Memory

(EEPROM). KM is common to all cards that use a particular UAN, that have the

same PAN sequence number (PANSEQ) and the same EXP24. The actual method

for deriving a session key is for the card issuer to choose, however EMV’s session key

derivation annex gives guidance on how this proposal can derive a 16-byte session24This is the only proposed scheme that requires a new ICC master key. This is due to the same

key being used by all cards whose holders make an anonymity set. The card issuer’s decision onwhether to use a new ICC master key for the scheme proposed in Chapter 9 is based on risk.

86


key from both the card’s respective 16-byte master key and the transaction’s 2-

byte Application Transaction Counter (ATC), Ni [54, Annex A1.3]. The ATC is a

binary data element [55, Annex A1] [11, Sections 6.1 & 6.3.11] that is incremented

by one at the start of each transaction, ideally when the card receives the “GET

PROCESSING OPTIONS” command from the terminal during the Initiate EMV

Application step (see Figure 5.1) [54, Annex D3] [55, Section 10.3].

KS = PAR(F(KM )[Ni])

F is a diversification function that maps the ICC’s master key and the transac-

tion’s ATC to a large and uniformly distributed number of 16-byte outputs. Function

PAR then sets the least significant bit of each byte to odd parity, a recommendation

for DES keys. The EMV specifications suggest how F can use 2TDES to create, by

encipherment, a KSL and a KSR that are concatenated to form KS .

KSL = EKM(Ni‖0xF00000000000)

KSR = EKM(Ni‖0x0F0000000000)

KS = PAR(KSL‖KSR)

When used, the 16-byte double key is split back into two 8-byte keys:

KS = KSL‖KSR

KSR must be used for the optional encipherment step when KSL is used on its

own with single DES for one of the two approved MAC mechanisms. In all other

instances, the EMV specifications use 2TDES.

87


5.4.4.3 Master Key Derivation

ICC master key KM is derived when the card is personalised, usually from the card

issuer’s master key KIM , the PAN and the PANSEQ [54, Annex A1.4]. KM is only

used to create session keys for this proposal. The EXP of the card is also included

to salt the master key:

h = SHA-1(U ‖Q‖E )

First: a 20-byte SHA-1 hash is created from the concatenation of the decimal

digits of the UAN, U ; 2-digit PANSEQ, Q; and 6-digit EXP, E. The PANSEQ is

used following normal convention and replaced by decimal “00” if not present.

h is viewed as 40 nibbles and the first 16 decimal characters are extracted. Where

this is insufficient then the first few characters that are > 9 are used, reduced by

modulo 0xA. For example:

h = 7C 3F AB CD D5 E8 FA D3 B0 CD F2 DF D4 FD C6 8F A1 7B 6E DF

Z = 73 58 30 24 68 17 62 50

The 8-byte left and right components of KM are 2TDES computed, concatenated

and the least significant bit of each byte set to odd parity.

KML = EKIML(DKIMR

(EKIML(Z)))

KMR = EKIML(DKIMR

(EKIML(Z ⊕ 0xFFFFFFFFFFFFFFFF)))

KM = PAR(KML‖KMR)

88


5.4.4.4 Issuer Processing

The card issuer needs to implement changes to its processing for when an online

transaction makes contact for authorisation; or a completed transaction is presented

for settlement; or the acquirer advises of a transaction being declined by a card. The

readable transaction data that accompany the AC include the OAN, ATC, UAN,

PANSEQ and EXP. The OAN is part of the IAD. Per the UK’s card acceptor to

acquirer interface standards, any IAD and the ATC are part of the card’s request

data, and the UAN, PANSEQ and EXP are all part of the card details. The card’s

request data and card details are both mandatory for inclusion in the transaction

data [11, Tables 5, 24 & 27]. The processing steps are:

As described, derive or otherwise obtain this proposal’s ICC master key, KM .

As described, derive this proposal’s session key, KS .

Then either:

Split the 16-byte OAN into two 8-byte blocks: O = XL‖XR

YL = DKSL(EKSR

(DKSL(XL)))

YR = DKSL(EKSR

(DKSL(XR)))⊕XL

(R‖A‖C ) = YL‖YR

Where necessary, the RAN has to be stripped of the 0xF characters to its right.

Or with an 8-byte OAN:

X = DKSL(EKSR

(DKSL(O)))

YR = (U ′‖A‖C )

YL = YR ⊕X

(R′‖A‖C ) = YL‖YR

Where U ′ is bytes 2 and 3 of the issuer number, taken from the UAN.

Remove trailing 3 bytes from R′ and append to front to give the RAN.

Where necessary, the RAN has to be stripped of the 0xF characters to its right.

With the RAN to hand and verified to be of the correct format, normal processing

89


can continue.

5.4.5 Effect on Payment Processing Entities

This proposal produces an overhead for both the card’s chip and its issuer. The

modified data elements and performance-affecting changes for those entities are:

The card issuer. When personalising the card, the card issuer:

• excludes the cardholder’s name information.

• inserts the UAN in place of the PAN.

• adds an extra 16-byte ICC (master) key. (Only this key is associated with the

UAN; the other stored keys are associated with the RAN.)

• adds two additional primitive data objects: the RAN which contains the card-

holder’s account number and temporary space for the OAN which is created

during each transaction.

• adds and enables an applet which triggers the creation of the OAN.

• includes the OAN in the list of contents of all ACs and the accompanying data.

• removes any PII that has been specified by the card issuer or payment associ-

ation.

When processing the first message in a session from a transaction using a UAN, the

card issuer performs the necessary processing to compute the RAN.

90

5.5 Residual Threat Analysis

The card’s chip. Once during each transaction, the card’s chip computes the

OAN and this proposal’s session key if a static shared secret is not used. The content

of the data packets that flow between the card’s chip and card issuer does not affect

the interaction between the card and the terminal, or the terminal and acquirer, or

the acquirer and issuer; it is just extra data for the card issuer. Wherever the UAN

is included then the OAN is also included, probably increasing those data packets

by 16 bytes. The length of MACs that include both the UAN and OAN will not be

affected, although two extra iterations of the MAC are probably required because

the input text may increase by 2 blocks.

The merchant and acquirer. This proposal makes no material change for the

merchant, acquirer or their networks. The only difference for them is that certain

data packets that they transfer from the card to its issuer may contain in the region

of 16 extra bytes of data: the OAN.

The cardholder The cardholder may notice CP transactions taking a greater

elapsed time due to the extra computations.


As with any application, there are potential threats to this proposal’s smooth oper-

ation. These mainly concern the proposed enhancements rather than the fabric of

the underlying payment process.

91


5.5.1 Passive Attack

Loss of Privacy: should a cardholder’s real identity be exposed or any information

that relates to the cardholder’s privacy be disclosed, even just once, the assumption

is that the attacker does not forget and may accumulate information over elapsing

time. For other cardholders this reduces the size of the anonymity set.

The anonymity set is not a fixed size or with static membership. The effect

of any disclosure may be offset as new cards are issued, old cards expire and card

accounts are closed prematurely. Cardholders may also hold more than one payment

card and so belong to more than one anonymity set.

5.5.2 Active Attack

With or without this proposal, an attacker is not prevented from replaying or mod-

ifying completed transactions, or both.

Normally, replays can be detected and counteracted by the card issuer monitor-

ing the cardholder’s ATC values, a nonce in this situation, and only allowing the

first presented transaction to be paid. With an OAN, a replay attack or re-use of

an account number is more evident to the card issuer. Any alteration to the criti-

cal elements of the transaction data should be detected by a discrepancy with the

Transaction Certificate (TC); the content of both is specified by the card issuer that

also carries the liability associated with this fraud. Including the merchant identifier

in the TC should ensure that the authorised payment goes to the intended recipient.

92


5.5.3 Size of Anonymity Set

The size of the anonymity set is the number of cardholders using a particular UAN

and EXP. Especially when the proposal is launched or new card issuers participate,

the size of the anonymity set is not particularly large.

Although to some extent it is security by obscurity, an attacker is unlikely to

know the size of an anonymity set. For smaller issuers it is possible to use a front-end

clearer that uses one UAN for all of its subscribers’ cardholders.

When a front-end clearer is used with an 8-byte OAN implementation, the card

issuer must alter the first 3 bytes of the RAN to give a unique issuer identifier for

the clearer. Bytes 2 and 3 must be fixed for all of the clearing group’s cards and

byte 1 contains an identifier that can be mapped to an issuer. The clearer changes

the 6-digit issuer number that it recognises to the issuer’s registered identification

number before passing the payment on for settlement. With 100 combinations for

issuer codes, this should not materially affect the number of clients that can be

managed by each front-end clearing group; large clearing groups may need to be

split where it would not otherwise have been needed.

5.5.4 Floor Limits

A merchant’s terminal may incorrectly detect a split sale, or a suspicious consecutive

sale, when more than one cardholder uses a card with the same UAN in the period

sampled by the terminal.

The card issuer’s detection capability is not affected and the issuer could perform

the check in real time for online payments. Inconvenience to the cardholder could

be avoided by setting the terminal’s response to such an alert so as to complete

93


the identified transaction online or, where that is not practicable, either to accept

the risk based on other transaction criteria or to refer the transaction for manual

verification.

The EMV specifications describe optional floor limit checking to detect split

sales, and state that a terminal may have a transaction log of approved transactions

stored in the terminal consisting of at least the PAN, the transaction amount, pos-

sibly the PANSEQ and the transaction date [55, Subsection 10.6.1]. The number of

stored transactions and maintenance of the log are outside the scope of the EMV

specifications. If floor limit checking is enabled, a potential split sale is detected

and the sum of the linked transactions exceeds the terminal’s floor limit value, then

the “transaction exceeds floor limit” bit in the Terminal Verification Results (TVR)

for the transaction causing the floor limit to be exceeded is set to “1”. When the

following optional data elements are configured and the “transaction exceeds floor

limit” bit is set as indicated, the cardholder will not be inconvenienced:

• Card’s “Issuer Action Code - Denial”: Bit set to zero by the card issuer.

• “Terminal Action Code - Denial”: Bit set to zero by the acquirer.

• Card’s “Issuer Action Code - Online”: Bit set to one by the card issuer.

If online processing does not or cannot take place then the following must be in

place:

• Card’s “Issuer Action Code - Default”: Bit set to zero by the card issuer.

• “Terminal Action Code - Default”: Bit set to zero by the acquirer.

The result: When a floor limit is exceeded, the above configuration causes the

identified EMV transaction to be completed online. Where online processing cannot

94


or does not take place, then the transaction is accepted.

5.5.5 Birthday Attack

In the proposed EMV example, all cards with the same UAN, PANSEQ and EXP

have the same master key, KM . It follows that all cards with the same UAN,

PANSEQ and EXP which are using the same ATC also have the same session key,

KS .

The risk is mitigated because neither key leaves the card’s chip, each session key

is only used for one transaction and the data being encrypted are always different.

5.5.6 Issuer Impersonation

An attacker could still attempt to impersonate the card issuer with the intent of

gleaning information.

If successful, any captured information is of less value due to the absence of a

cardholder name and permanent card number in clear or consistent text.

5.5.7 Non-Repudiation

The cardholder is not identified to the payment recipient or other parties in the

payment process. This could make proof of payment difficult.

The card issuer knows its customer and the payments he or she makes. In the

event of a dispute this allows the cardholder to evidence whether a card payment

was made.

95


5.5.8 Physical Security

The proposed solution requires the cardholder to keep the card in a secure place,

to keep his or her PIN confidential and to report any loss of the card to the card

issuer in a timely manner. Of particular concern, if the PIN is disclosed, the card

not reported to be lost or stolen, and another person who knows the PIN makes

use of the card, then the transaction will probably be successful. This could be an

acquaintance of the cardholder who borrows and returns the card before its absence

is noticed, or the card being trapped in a bogus device and the PIN captured [115].

The cardholder agreement should cover cardholder practices and in particular:

the need to keep the PIN confidential and to report card loss as soon as the loss is

detected.

5.5.9 Legal Precedent

During a digital cash trial in the UK in 1995 [105], Mondex25 was marketed as anony-

mous. That claim was reported by Privacy International26 to the UK’s Office of Fair

Trading27 for allegedly breaching the UK’s Trade Descriptions Act (1968) [152], be-

cause the banks could identify any cardholder through the linkage between each

Mondex card and a bank account. Before a decision was reached, Mondex substi-

tuted the word “anonymous” with “private” and the Office of Fair Trading investi-

gation was left as informal in nature, to a large extent due to the then embryonic

state of Mondex and the Internet [135]. In September 2003, a European Commit-

tee for Banking Standards’ technical report summarised European electronic purse

products [61] and listed the French Mondex card as being “anonymous of payment”,25http://www.mondex.com/. Brand now owned by MasterCard International.26http://www.privacyinternational.org/.27http://www.oft.gov.uk/.

96

5.6 Conclusions

along with many other electronic purse products, using information provided di-

rectly by the payment scheme providers. E-mails to Privacy International to ask

whether it considers such terminology to be appropriate today, in light of technical

and legislative maturity, have not been answered.

Although there was no need to keep other PII on the card or to pass that in-

formation on during a transaction, and Mondex said that the general scheme did

not require it, the practice was otherwise with either the cardholder’s initials or the

first seven characters of his or her surname being included [38]. It appears that the

Office of Fair Trading was not aware of this twist.

The risk of a legal challenge against this proposal could be mitigated by being

clear on the level of anonymity offered: just for the cardholder at the point of

payment and through clearing, save for any counteractive out-of-band action by the

cardholder or card issuer.

5.6 Conclusions

A mechanism for making CP payments, that are effected with a chip-based payment

card, private for the cardholder at the point of payment and through clearing has

been proposed. Through anonymity and unlinkability to all bar the card issuer,

the proposal treads the fine line between legislative requirements and theoretical

possibility whilst still meeting prevailing definitions, criteria and terminology. The

scope and limitations of the offered privacy need to be clearly articulated; privacy

policies are quite common in e-commerce. In normal use the cardholder pays as

at present and benefits from the usual attractions of a card payment, but CNP

transactions would be little more cumbersome if Chapter 7’s proposal is not also

implemented because the account number is no longer embossed on the card. Once

97


a payment has been made and cleared, in the event of a dispute the cardholder is

able to evidence having made the payment.

98

Chapter 6

Payment Cards:Non-Repudiation

Contents

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6.3 The Proposed Mechanisms . . . . . . . . . . . . . . . . . . 103

6.3.1 Electronic Receipts . . . . . . . . . . . . . . . . . . . . . . . 104

6.3.2 Condensed Electronic Receipts . . . . . . . . . . . . . . . . 109

6.3.3 Electronic Footprint . . . . . . . . . . . . . . . . . . . . . . 113

6.4 Privacy and Integrity . . . . . . . . . . . . . . . . . . . . . 115


6.5.1 The Evidence Causing Disputes . . . . . . . . . . . . . . . . 117

6.5.2 Too Much Trust in the System . . . . . . . . . . . . . . . . 117

6.5.3 Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . 118

6.5.4 Misplaced Trust . . . . . . . . . . . . . . . . . . . . . . . . 119

6.5.5 Cardholder Practices . . . . . . . . . . . . . . . . . . . . . . 120

6.5.6 Inconsistencies Between Statements . . . . . . . . . . . . . 121

6.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

99

Payment Cards: Non-Repudiation

This chapter proposes three mechanisms for leaving a cryptographic mark on the

chip of a payment card, to help determine whether a given card was present for a dis-

puted transaction. This assists any adjudication by either supporting the cardholder’s

repudiation of the payment, or conversely supporting the cardholder accountability

for that payment: non-repudiation. Two of the proposed mechanisms can also act

as an aide memoire for the cardholder and offer an alternative to paper receipts,

which usually pass from merchant to cardholder once the payment transaction has

completed.

This proposal is intended to be adaptable for most chip-based payment cards.

However, to illustrate the proposed mechanism the EMV specifications are used to

identify intercept points, data element names and the size of data elements, and to

specify some of the processing.


6.1 Introduction

Although the vast majority of chip-card payments are processed without a hitch,

there are occasions when a cardholder later repudiates a payment. The cardholder

may be adamant that he or she was not present to authorise the transaction, but the

issuing bank considers the transaction data and certificate to evidence otherwise be-

cause they show that a chip and PIN mechanism had been used to authenticate the

cardholder. The card issuer trusts its chip-card environment and thinks the trans-

action to be authentic, but the cardholder thinks the transaction to be fraudulent;

the ingredients of a dispute.

100

6.1 Introduction

The occurrence of a discrepancy, where the cardholder is not intimating the card

to have been lost or stolen, is often referred to as a “phantom withdrawal” from an

ATM, or simply a “disputed payment” if goods or services were purchased. Such

disputes are difficult to resolve and discussions with people involved with adjudica-

tion indicate that when a PIN-verified chip-card transaction is completed, the card

issuer feels confident that the cardholder made the transaction but will look towards

the human and environmental factors when deciding who should be liable. The

human factors include the length of time the issuer has known the cardholder, the

cardholder’s reputation with the issuer and how the issuer values the cardholder as

a customer. It is in essence a non-technical solution to a technical problem and the

method is not something that is published or openly discussed. In a UK court in

June 2009, a judge ruled in favour of a high street bank in a dispute with a customer

over phantom withdrawals, notwithstanding that the only available evidence were

the bank’s log files. The payment card and the authorization request cryptogram

(an AC) that were once held by the bank had been destroyed [41].

Save for dishonest intent and forgetfulness on the cardholder’s part, there are

reasons why such a discrepancy could occur making both parties theoretically cor-

rect. For example: an acquaintance of the cardholder may know the PIN, “borrows”

the card and returns it before its absence is noticed or a trusted person(s) may abuse

a position of trust with the card issuer to create a perfectly formed but fraudulent

transaction [4].

If there were to be a lasting transaction-related mark left on a payment card’s

chip each time the card processes a payment and that mark could be examined by

the cardholder or an adjudicator, then it would increase the confidence of all parties

in any technical assessment and give less credence to it being a “payment system

fault”. It would give objectivity to an otherwise subjective assessment and protect

the interests of both the card issuer and cardholder. Presently the only transaction-

101


related mark left on an EMV card is a 16-bit ATC, which increments by a bit each

time a transaction starts (see Subsection 5.4.4.2). However the ATC only shows how

many transactions have taken place and not the specifics of the transaction, and not

all transactions certify a payment.

6.2 Contribution

This chapter proposes three methods for leaving a cryptographic mark of previous

payments on a payment card’s chip, to demonstrate whether the card was present

for a disputed transaction. If said transaction has a matching on-card mark then it

shows, beyond reasonable doubt, that the card was indeed present.

Electronic Receipts. The first method provides the easiest to use form of evi-

dence, but consumes the most potentially-scarce storage space on the chip and could

open concerns over privacy. The cardholder can view the receipts and the card issuer

can verify their authenticity.

Condensed Electronic Receipts. The second method is a subset of the first

method and reduces the detail in each receipt making it less meaningful to the

cardholder, although still quite usable. On the other hand this method increases the

cardholder’s privacy, uses less storage space on the chip and reduces payment-time

processing. In the relatively unlikely event of the card issuer wishing to verify receipt

authenticity, then this method requires more processing.

Electronic Footprint. The third method further reduces the stored details and

leaves it to the card issuer to demonstrate to an adjudicator, not the cardholder,

102

6.3 The Proposed Mechanisms

whether the on-card Electronic Footprint includes the disputed transaction. The

cardholder cannot view any receipts, but conversely the cardholder’s privacy is not

eroded by the proposal and this method is the most economical with the chip’s

storage space.

The choice of method is a balance between usability for the cardholder, card-

holder privacy, point of processing overhead and storage space on the chip.


The proposed mechanisms are nothing more than an add-on to an existing chip-

based payment card application. As evolution, rather than revolution, any or all

three variants could be phased-in as and when cards are replaced, deploying only one

non-repudiation mechanism per card. This chapter’s proposal can be implemented

on its own, or with some or all of the proposals in other chapters. The data sent to

and from the card’s chip during normal use are not affected; only the fabrication of

the card and inspecting the on-card cryptographic marks entail new data entering

or leaving the card’s chip.

Per the UK’s card acceptor to acquirer interface standards, all data elements

used to make a transaction mark in this proposal are mandatory for inclusion in the

transaction data [11, Tables 5, 24 & 27]28.

In the event of a dispute and where there is more than one payment card asso-

ciated with an account, it requires the card issuer to identify which card made the

payment, and to pass that on to the cardholder in a digestible form. The optional

PANSEQ data element has this detail but without that information all possible28The ATC and TC are part of the card’s request data.

103


cards need to be tested. The transaction data that are retained by the card issuer

are the likely source for the PANSEQ. For card processors in the UK, including

the PANSEQ with the transaction data’s card details field is mandatory when a

PANSEQ data element is supplied by the card [11, Subsection 6.3.6].

To illustrate the proposed mechanism the EMV specifications are used to identify

intercept points, data element names and the size of data elements, and to specify

some of the processing. This proposal could be part of future EMV specifications,

or be part of an existing EMV compliant application. It should also be compatible

with any future EMV modes of implementation, such as on a contact-less card or

mobile telephone.

6.3.1 Electronic Receipts

Taking a lead from some digital cash systems, an electronic transaction receipt is

retained on the card’s chip for the card’s most recent CP transactions [34, 40, 59].

Some of those digital cash providers mention on-card receipts as an aid to resolving

disputes but the presence of such information has previously contributed to con-

cerns over terminology [135], particularly when describing the offering as anonymous

rather than private – which some digital cash providers still do [58,129].

When receipt information is read-protected by the cardholder’s PIN, which this

proposal recommends, the main privacy concern with on-card transaction informa-

tion is its availability for reading by or with the collaboration of the card issuer (see

Subsection 2.2.1.6: this is a required risk).

104


6.3.1.1 The Receipt Log

The values suggested by the EMV specifications “for example purposes only” for a

transaction log are listed in Figure 6.1 [55, Table 45]. These are proffered with the

intent of supporting access to transaction logs by special devices such as personal

computers, Personal Digital Assistants (PDA) and ATMs rather than for storage on

a card’s chip. The specifications do not say how the information is to be used and

propagated, or how integrity is ensured [51].

Transaction Date 3 bytesTransaction Time 3 bytesTransaction Currency Code 2 bytesAmount Authorised 6 bytesMerchant Name and Location 20 bytesApplication Transaction Counter 2 bytes

Figure 6.1: Example of EMV log format

20 bytes are specified for the merchant name and location field but, unlike the

other mentioned data fields, it is of variable length [55, Table 33]. A unique29

merchant identifier is also available and, at a fixed 15 bytes, it is also relatively large.

Omitting readable merchant information reduces each record from a minimum of 36

bytes to a fixed 16 bytes, which is beneficial in a storage constrained environment and

its absence probably does not too adversely affect the usability for most cardholders.

Figure 6.2 outlines the proposal for an electronic receipts log.

Li−8 = Di−8 ‖ Ti−8 ‖ Ci−8 ‖ Ai−8 ‖ Ni−8 ↓Li−7 = Di−7 ‖ Ti−7 ‖ Ci−7 ‖ Ai−7 ‖ Ni−7 −→ ‖ Mi−7

Li−6 = Di−6 ‖ Ti−6 ‖ Ci−6 ‖ Ai−6 ‖ Ni−6 ↓Li−5 = Di−5 ‖ Ti−5 ‖ Ci−5 ‖ Ai−5 ‖ Ni−5 ↓Li−4 = Di−4 ‖ Ti−4 ‖ Ci−4 ‖ Ai−4 ‖ Ni−4 ↓Li−3 = Di−3 ‖ Ti−3 ‖ Ci−3 ‖ Ai−3 ‖ Ni−3 ↓Li−2 = Di−2 ‖ Ti−2 ‖ Ci−2 ‖ Ai−2 ‖ Ni−2 −→ ‖ Mi−2

Li−1 = Di−1 ‖ Ti−1 ‖ Ci−1 ‖ Ai−1 ‖ Ni−1 ↓Li = Di ‖ Ti ‖ Ci ‖ Ai ‖ Ni −→ ‖ Mi

Figure 6.2: Proposed Electronic Receipts log29Unique to the acquirer.

105


Each log entry is constructed to the same specification, one line per payment.

Taking the most recent payment, i, as an example:

• Li is the ith entry in log L and is the concatenation of the next 5 values.

• Di is the 3-byte transaction date.

• Ti is the 3-byte transaction time.

• Ci is the 2-byte transaction CC.

• Ai is the 6-byte numeric AA.

• Ni is the 2-byte ATC.

• Mi is an 8-byte MAC spanning the concatenation of the previous record’s

MAC, Mi−1, the current line, Li, and the merchant identifier, Vi. The message

is padded to the next 8-byte boundary. Should this payment be disputed then

the card issuer can verify the integrity of Li and its preceding transactions.

Mi = MACKS(Mi−1‖Li‖Vi‖PAD)

PAD = (0x80‖ . . . ‖0x00‖ . . . ‖0x00)

(That is: add a mandatory “0x80” and then “0x00”s if or as needed.)

• KS is the EMV message authentication session key that is already used during

the ith transaction. Another symmetric key, the EMV application cryptogram

session key, is used to create the TC.

The method for deriving a session key is for the card issuer to choose. Subsec-

tion 5.4.4.2 discusses EMV’s guidance on how to derive a 16-byte session key

from both the card’s respective 16-byte master key, KM the message authen-

tication master key in this case, and the transaction’s ATC, Ni.

KS = PAR(F(KM )[Ni])

KS = KSL‖KSR

106


A log entry is written by an applet that is triggered when the card receives a

“GENERATE AC” command from the terminal requesting approval of the transac-

tion, and the card’s chip approves the transaction by issuing the requested TC [55,

Section 9.3]. This applet could double-up with the applet that is outlined in Sub-

section 5.4.4.1 and logic used to determine which actions to take, if any.

6.3.1.2 MAC Processing

The MAC’s input is divided into 8-byte blocks (also see Subsection 2.3.3.1):

X1‖X2‖ . . . ‖Xj

Those blocks are CBC enciphered:

Yi = EKS(Xi ⊕ Yi−1) for i = 1, 2, . . . , j

Y0 is an SV of 8-bytes of binary zeros: 0x0000000000000000.

If processed with a 16-byte 2TDES key there is no optional encipherment:

Mi = Yj

If processed with an 8-byte key using single DES, optional encipherment is with a

2nd 8-byte key:

Yj = EKSL(Xj ⊕ Yj−1)

Mi = EKSL(DKSR

(Yj))

EMV allows for an m-bit MAC, where 32 ≤ m ≤ 64, by stripping the least significant

107


bytes (so as to be aligned on a byte boundary). This proposal does not truncate the

MAC, although it could if storage is of essence.

A MAC does not need to be retained for every transaction, just sufficient to

allow for verification. With the most recent electronic receipts on the card’s chip

in chronological order, at a minimum just the oldest transaction’s MAC and latest

transaction’s MAC are needed. In normal operation those MACs need to be re-

calculated just before the oldest transaction is deleted or when a new transaction

is added. However any failed verification could point to an inconsistency that has

since been age-deleted, unless routine MAC verifications are performed to reduce the

time window for such a problem. Instead, keeping a set cycle of MACs is proposed:

every 5th MAC and the latest MAC. This allows 58 electronic receipts to be stored

per kilobyte of EEPROM, but the oldest few entries may not always be spanned by

a MAC that assures receipt integrity.

Each log entry remains on the card’s chip until the table wraps to overwrite the

oldest entry with a new transaction.

6.3.1.3 Other Considerations

Bolstered by the card’s tamper-resistant properties and programming language-

based technique for security, the presence or absence of an electronic receipt could

be the deciding factor in a dispute; but this evidence must be considered to be in an

otherwise hostile environment. Logically it is the card issuer’s trusted environment

but physically the cardholder’s trusted environment. The cardholder is primarily

concerned with disclosure whereas the card issuer is more concerned with integrity.

Protecting against information disclosure is by means of PIN protection with

viewing or printing through a secure device: say an ATM, dedicated kiosk or hand-

108


held reader which could be a design extension to an RCA device. In many disputes

the cardholder could check the card without involving the card issuer, but only the

card issuer can verify the MAC to ensure integrity. Both the card’s chip and issuer

are able to derive session keys and calculate the associated MACs.

EEPROM is the card’s only storage area that can be both updated and preserved

between payments when there is no electrical power to the circuitry. The quantity

of EEPROM has quite a bearing on the cost of the card, giving the card issuers the

incentive to purchase just enough EEPROM to meet the immediate need with not

too much left over. Most Visa approved chip cards [163] contain between 2 kilobytes

and 8 kilobytes of EEPROM, although some top of the range cards have as much as

64 kilobytes with even more potentially available if it were to be a dual-chip card.

Per card, an extra 4 kilobytes probably costs in the region of one US dollar when

bought in bulk, although it is difficult to be precise on cost, but collectively the cost

to the card issuer is more noticeable.

Of the three, this mechanism is the most comprehensive for the cardholder but

there could be concerns over EEPROM consumption and privacy with respect to

the cardholder’s spending patterns, although it could replace paper receipts from

the merchant and the on-card receipt does not state the payment recipient or what

was purchased.

6.3.2 Condensed Electronic Receipts

The Condensed Electronic Receipts proposal cuts away at the demand for EEPROM,

but there are both positive and negative consequences for the cardholder. As pieces

of information are removed the cardholder’s privacy is increased, but each receipt

carries less information so placing greater dependence on the card issuer for receipt

verification and dispute resolution. In the event of a dispute the assurance for the

109


card issuer is equal to that for the Electronic Receipts proposal, but the cardholder

needs to place greater trust in the card issuer and that probably affects his or her

level of assurance.

6.3.2.1 The Condensed Receipt Log

When an EMV card accepts a transaction its chip generates an 8-byte AC, specif-

ically: a TC [55]. This lasting “proof” of the transaction is simply a MAC that

is computed on data that the card issuer considers important to the transaction

and uses the transaction’s application cryptogram symmetric session key. The key

is derived with the same mechanism as the message authentication session key, as

discussed in Subsection 6.3.1.1, only with a different ICC master key. The TC pro-

vides a cryptographic seal for the transaction which should include the CVM that

shows whether the PIN was entered (see Subsection 3.2.2.1). These data are not in

EMV’s minimum set of data elements for inclusion in an AC per se [54, Table 26],

although the TVR are recommended for inclusion and they record whether card-

holder verification was successful and some status data on PIN entry [55, Annex

C5: Byte 3]. When compared to the Electronic Receipts proposal, the TC spans far

more information than the Electronic Receipts MAC, but it is not linked to adjacent

transactions other than by taking increasing ATC values. On its own neither form

of MAC compromises privacy and both are equally economic on storage.

There are gaps in the chain because not all ATC allocations result in a payment.

The ATC should be incremented at the start of each transaction (see Subsection

5.4.4.2) before any personalised card data or transaction data are exchanged, or

cardholder verification take place and, for example, the AC may result in an Appli-

cation Authentication Cryptogram (AAC) where the transaction is declined by the

card. It is only successful payment transactions that are of interest to this proposal.

110


To overcome the problem with gaps in the ATC chain, in this proposal sixteen

ordered tables of 256 bits each are allocated, initially with all 4096 bits set to zero.

When a TC is issued, an applet examines the lowest 8 bits of the ATC and the

matching bit in the current bit map table is changed from zero to one. The ap-

plet triggers at the same intercept point and conditions as the Electronic Receipts

proposal. When the ATC is incremented and the lowest bit of the leading byte is

altered then the oldest table is set to zeros and moved to become the current bit

map table, with all other tables moving up one in the hierarchy. Another applet is

used for monitoring the leading byte of the ATC and, if the EMV recommendation is

followed for incrementing the ATC, is called when the card’s chip receives a “GET

PROCESSING OPTIONS” command from the terminal. These two applets and

the tables gives an efficient method of mapping which of the previous 4,000 or so

ATCs became a TC, and uses half a kilobyte for that table data. It even allows for

situations where the ATC does not start at zero and removes the requirement for

any other mapping between TCs and ATCs. Figure 6.3 illustrates the principle by

using 16 stacked folders to represent the tables, where the last TC used ATC value

0x0B6D, decimal 2925. The highest bit that is set to one is in table 0x0B, row 0x6,

column 0xD. The last four folders have never been used so are already set to zero

throughout. When the second applet detects that present folder has become full

from observing an increment to the leading byte of the ATC, the applet moves the

current folder to the back and the remaining folders all move forward one place with

the new front folder’s bits set to zero. The folder tabs are not actually present; the

tabs are calculated by working back from the current ATC.

The Condensed Electronic Receipts log follows the same outline as the Electronic

Receipts log but only the AA and transaction CC are available to the cardholder.

Figure 6.4 outlines the proposal, again with one line per payment and using similar

notation.

111


nnnn

nnnn

nnnn

nnnn

nnnn

nnnn

nnnn

nnnn

nnnn

nnnn

nnnn

nnnn

nnnn

nnnn

nnnn

0000000000000000

0000000000001011

0000001000000001

0000000000000000

0000011000000101

0000010000000011

0000101000001001

0000100000000111

0 1 0 0 1 0 1 0 0 0 1 0 0 0 1 01 0 1 0 0 1 0 1 0 0 1 0 1 0 0 10 1 0 0 1 1 0 1 0 1 0 0 1 0 1 01 0 0 0 0 1 0 0 0 0 1 0 1 0 0 10 1 0 0 1 0 0 0 0 1 0 1 0 0 1 01 0 0 0 1 0 0 0 1 0 1 0 0 1 0 10 0 0 1 0 0 1 0 0 0 0 1 0 1 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Figure 6.3: Bit map of the ATCs


• Li is the ith entry in log L and is the concatenation of the next 2 values.

• Ci is the 2-byte transaction CC.

• Ai is the 6-byte numeric AA.

• Mi is a similar 8-byte MAC to that outlined in the Electronic Receipts proposal

but using the TC, Wi, in place of the merchant identifier, Vi. Again not all

MACs are stored. In difference this variant does not require the session key

(KS) to be correlated with the ATC.

Mi = MACKS(Mi−1‖Li‖Wi‖PAD)

112


Li−8 = Ci−8 ‖ Ai−8 ↓Li−7 = Ci−7 ‖ Ai−7 −→ ‖ Mi−7

Li−6 = Ci−6 ‖ Ai−6 ↓Li−5 = Ci−5 ‖ Ai−5 ↓Li−4 = Ci−4 ‖ Ai−4 ↓Li−3 = Ci−3 ‖ Ai−3 ↓Li−2 = Ci−2 ‖ Ai−2 −→ ‖ Mi−2

Li−1 = Ci−1 ‖ Ai−1 ↓Li = Ci ‖ Ai −→ ‖ Mi

Figure 6.4: Proposed Condensed Electronic Receipts log

With just 8 bytes per payment, plus the MACs and the ATC table, 100 transac-

tions and a table of 512 ATCs could be stored in each kilobyte of EEPROM. This is

72% more than the Electronic Receipts proposal, but at the expense of detail for the

cardholder. As a consequence, in the event of a dispute there is a greater reliance

on the card issuer and more queries need card issuer involvement.

6.3.2.2 CDA Cards

Both SDA and DDA cards operate as described in this proposal, but when a CDA

capable card is used in a CDA enabled terminal, the TC is a (longer) digital signature

rather than a MAC [54, Section 6.6]. The Electronic Receipts proposal can still

proceed because all the required information and the capability to generate a MAC

are still present. The Condensed Electronic Receipts proposal can use either form

of TC: a MAC or a digital signature.

6.3.3 Electronic Footprint

The Electronic Footprint proposal further reduces the information stored on EEP-

ROM, leaving just the MACs and bit map of ATCs. Transaction details are not

stored which ensures privacy for the cardholder, but the footprint can only be val-

113


idated by the card issuer or a TTP with the card issuer’s help. In the event of a

dispute, the assurance for the card issuer is equal to that given by the other two

proposals but the cardholder needs to place complete trust in the participants in

the dispute resolution process. The cardholder will probably have little trust in

that process should the resolution not fall in his or her favour, in part because the

evidence is intangible to the cardholder. Involving a TTP gives independence to the

dispute resolution process and is therefore recommended by this proposal.

When a TC is created, the bit map of ATCs is updated. In the event of a dispute,

the card issuer identifies the ATC value and the bit map can be checked by the TTP

for the presence or absence of a matching entry. Some disputes may be resolved by

this simple check alone.

The MAC is created and retained along similar lines to the Condensed Electronic

Receipts proposal. Figure 6.5 outlines the proposal, illustrated with the 9 most-

recent payments and using similar notation.

-Mi−8

Mi−7-

Mi−6-

Mi−5-

Mi−4-

Mi−3

Mi−2-

Mi−1

Mi, G

Figure 6.5: Proposed Electronic Footprint


• Mi is still an 8-byte MAC using key KS , but just covering a concatenation

of the previous record’s MAC, Mi−1, and the TC, Wi. All other aspects of

the MAC mechanism are as outlined in the Condensed Electronic Receipts

proposal.

Mi = MACKS(Mi−1‖Wi‖PAD)

For SDA and DDA cards, an XOR operation could have been used to amal-

gamate the two 8-byte values, Mi−1 and Wi, but the resulting Mi would only

114

6.4 Privacy and Integrity

be the result of two encipherments, rather than three, with potentially known

input text.

A hash is not used because EMV only uses a hash for digital signatures and

SDA cards are not capable of producing a digital signature. SDA cards may

not be able to produce a hash because it is a redundant capability consuming

scarce resources.

• G is a 4-bit counter towards the next boundary for retaining a MAC. 4-bits are

allocated so that the counter can be set to any value between 0 and 15, with a

maximum value of 4 being used in this example in order that 4 intermediary

MACs are not-retained.

With just one-in-five MACs plus the latest MAC and the ATC table, 400 trans-

action footprints and a table of approximately 3,000 ATCs could be stored in each

kilobyte of EEPROM. This is 590% more than the Electronic Receipts proposal, but

void of detail for the cardholder. In the event of a dispute there is absolute reliance

on the TTP, who requires the card issuer to detail how the MAC that spans the

disputed entry was built, specifically: the TCs, the relevant message authentication

and application cryptogram session keys, and the data that made up each TC. With

increasing brevity of the evidence, the burden moves to a small overhead with each

transaction with a far greater overhead on any dispute.

6.4 Privacy and Integrity

Each of the three types of marking is a combination of transaction information with

a MAC that binds the current payment to the preceding payment. The transaction

information can be selected to suit the specific payment-card application.

115


Privacy for the cardholder could be eroded by the inclusion of information that

another party may be able to read. On a chip card that information is resistant to

physical and logical penetration but there are occasions when others may read the

data, covertly or overtly. For example, by someone looking over the cardholder’s

shoulder when viewing the receipts at an ATM or by any person involved with

resolving a dispute. The Electronic Receipts proposal provides the most information

so as to keep the cardholder fairly self-sufficient, but it also has the most to disclose.

The Electronic Footprint does not allow the cardholder to make any meaningful

assessment of the transaction information that are stored on the card, hence the need

for a TTP, but there is little additional information to disclose to an eavesdropper.

The Condensed Electronic Receipts proposal seeks the middle ground.

Integrity of the transaction marks is ensured with a MAC which is created using

a key that can be derived by both the card’s chip and the card issuer. Logically

the card is the card issuer’s trusted environment but physically the card is the

cardholder’s trusted environment. It is theoretically possible for an agent of the card

issuer with inappropriate access to tamper with the marks during a transaction,

but the difficulties of accessing that information and ensuring concurrency make

exploitation exceedingly difficult. Should the general integrity of the marks be in

question, then in the event of a dispute it is possible to prove the correctness of

the other transactions by regenerating the preceding MACs. This proposal’s MAC

is cryptographically similar to the TC that ensures the integrity of the transaction

data; they both use a similar process but with different ICC master keys.

116



As with any application, there are potential threats to this proposal’s smooth oper-

ation. These mainly concern the processing, storage and presence of the additional

evidence of payment rather than affecting the fabric of the underlying payment pro-

cess. That said, the vast majority of payments will continue to be processed without

a hitch.

6.5.1 The Evidence Causing Disputes

Particularly with electronic receipts and to a lesser extent with condensed electronic

receipts, the cardholder is able to view the on-card evidence of CP payments and

may be able to see an opportunity to dispute a genuine payment.

This is most likely to be the manifestation of another listed residual threat.

However, the transaction data and its certificate would still be valid and whenever

a cardholder disputes a payment the human factors presently used still have a role

to play.

6.5.2 Too Much Trust in the System

Where a disputed transaction is supported by an on-card receipt or footprint, the

case for dismissing the dispute is strengthened. But for example, a new card and

PIN could be sent through the postal service and both intercepted, exploited and

then forwarded to the intended recipient. Particularly where there is no obvious

evidence of attack, the presence of the on-card receipt or footprint could cause a

wrong conclusion to be drawn.

117


This proposal does not provide irrefutable evidence. The human factors presently

used still have a role to play.

6.5.3 Race Conditions

A residual threat with all three proposed solutions is that the receipt log and the

ATC table are both smaller than the total number of possible entries, and when

either or both are full they wrap to overwrite the oldest records.

• The Condensed Electronic Receipts and Electronic Footprint proposals both

use a bit map of ATCs that resulted in a TC. For example, if an attacker could

cause the ATC to increase by the number of bits in the ATC tables through

bogus activity without issuing a TC, then the bit map would no longer relate

to any of the transactions.

This could be counteracted by increasing the size of the bit map to 8 kilobytes

so as to span all possible ATC values. However exploitation should be evident

to the card issuer through the sudden increase in ATC values. This attack

would not affect the other transaction information, for example any transaction

log and the MACs.

• With all three proposals, only a certain number of transactions are retained

on the card’s chip which could be a genuine problem for cards in very frequent

use.

There are 65,535 (216 − 1) available ATC values but not all result in a TC

although if this were to happen and all transactions were stored, 1.1 megabytes

would be needed for the Electronic Receipts, 614 kilobytes for the Condensed

Electronic Receipts and 102 kilobytes for the Electronic Footprint.

118


6.5.4 Misplaced Trust

Both the card issuer and cardholder trust others. That trust could be misplaced, or

appear to be misplaced.

• The card issuer is responsible for preparing a card and setting the payment

application criterion, while retaining the capability to derive all keys, secrets

and data held on or generated by a card’s chip. Insiders may be able to exploit

the card issuer’s trust.

The scope for fraud is very much reduced because any exploit has to keep the

chip’s cryptographic mark in synchronisation with the card issuer’s records.

Once the card is in the field it is very difficult to insert an erroneous transac-

tion, although the card issuer has the theoretical capability. The card issuer

probably supplies a hand-held reader for viewing receipts, but the cardholder

can use independent devices such as an independent ATM or another issuer’s

portable reader, provided the card is not dependent on a personalised reader.

Many recorded exploits and errors [4] could have been detected through any

of the proposed mechanisms. The most effective card issuer control against

this threat is to segregate the people analysing disputes from the people with

access to other parts of payment card processing; using a TTP for disputes

gives much of that segregation.

• If used, the TTP resolves disputes and is therefore in a position of trust. It

may well be selected and financed by the card issuer, making the cardholder

perceive it to be an extension of the issuer.

The TTP not only needs to be independent, but also needs to be visibly

independent.

• The trust that cardholders need to place in card terminals and the difficulties

with detecting rogue terminals is a threat that still requires attention [6, Sec-

119


tion 3.5] [47]. Cited as an example is where a modified terminal with a genuine

card communicates with a nearby genuine terminal with a modified card in

real time so that the transaction appears as if the genuine card made a pay-

ment on the genuine terminal. The false terminal hoodwinks the cardholder

into paying for a high value item rather than the intended purchase.

This proposal could help detection because the higher value transaction’s re-

ceipt would be recorded on the card’s chip and the cardholder may notice

before receiving his or her statement.

6.5.5 Cardholder Practices

None of the proposed solutions address cardholder practices. In particular, if the

PIN is not kept secret and another person who knows the PIN makes use of the card

and returns it before the card’s absence is noticed, then the transaction appears to

be genuine with a matching on-card receipt.

The cardholder agreement should cover this situation from a legal liability per-

spective and a technical assessment under this proposal will work as intended to

show that the card was present, ideally causing the cardholder to consider a culprit

close to home. This scenario could be addressed by extending the Electronic Re-

ceipts proposal: taking and keeping a copy of a biometric sample on the card’s chip

with the transaction mark. Although storage space is configuration, biometric and

algorithm dependent, finger minutiae handled in keeping with international stan-

dards use 102 bytes per sample when viewing just one finger on an extraction device

that is set to limit data capture to 12 minutiae, the recommended minimum for

verification [93, Annex D.1.1]. The number of receipts per kilobyte reduces from 58

to 8½, making biometrics an expensive option and impractical for cards in frequent

use. Upgrading a low-specification 2-kilobyte card to a top-of-the-range 64 kilobyte

120

6.6 Conclusions

card allows 530 electronic receipts with a biometric to be stored, almost 6 a day for

three months which would be reasonable for many users. Chapter 8 proposes a non-

repudiation mechanism using biometrics to link Internet payments to the payment

maker in an environment where that amount of storage is not such a constraint.

6.5.6 Inconsistencies Between Statements

On-card receipts and footprints only include payments processed by the card’s chip.

The most notable omissions are: CNP transactions, any fallback mode payments and

credit card repayments. Conversely, any CP payments that have not been presented

to the card issuer will be missing from any issuer supplied statement. Payments that

are authorised before the final transaction amount is known will also not necessarily

tally, with the card showing the AA but the statement showing the final transaction

amount including tips and other adjustments [56, Subsection 6.5.1].

On its own, neither source can be certified to be an up-to-the-minute statement

of account.

6.6 Conclusions

This chapter has proposed three mechanisms for enhancing the non-repudiation

properties of chip card payments, each creating a cryptographic mark covering the

most recent payment transactions processed by the card’s chip. In the event of a

disputed transaction, the card’s chip is inspected to tell whether the card was present

for the transaction. The presence or absence of a cryptographic mark helps decide

the outcome.

The proposal does not affect the underlying payment process.

121


There are occasions when the card does not participate in a transaction or is only

aware of the AA and not the final transaction amount. The presence or absence of a

receipt could cause disputes or encourage too much trust to be placed in the payment

system. Capturing a biometric sample from the cardholder at the time of payment

would create a closer linkage between the person and the transaction, but it is an

expensive option for storage.

All three proposed mechanisms consume some computing resource at the time of

payment and storage space on the card’s chip, but these mechanisms are presented

to strike a balance between cardholder privacy, payment-time overhead, cost and

overhead in the event of a dispute. It is also designed to operate as an optional ex-

tension to a card-based payment application. As a framework rather than a specific

design, the amount of information processed and stored could be further adjusted

in keeping with the type of card, need, cost and risk.

122

Chapter 7

CNP Payments: Privacy

Contents

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 125

7.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 127

7.3 Temporary Card Number Schemes . . . . . . . . . . . . . 128

7.3.1 Controlled Payment Numbers™ . . . . . . . . . . . . . . . . 128

7.3.2 SecureClick® . . . . . . . . . . . . . . . . . . . . . . . . . . 129

7.3.3 Rubin and Wright . . . . . . . . . . . . . . . . . . . . . . . 130

7.3.4 Li and Zhang . . . . . . . . . . . . . . . . . . . . . . . . . . 132

7.3.5 Assora, Kadirire and Shirvani . . . . . . . . . . . . . . . . . 134


7.4.1 Protecting Identity . . . . . . . . . . . . . . . . . . . . . . . 136

7.4.2 Allocating Temporary Card Numbers . . . . . . . . . . . . 137

7.4.3 Allocating a Card Verification Value . . . . . . . . . . . . . 139

7.4.4 Address Verification . . . . . . . . . . . . . . . . . . . . . . 142

7.4.5 Operating the Scheme . . . . . . . . . . . . . . . . . . . . . 144

7.4.6 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

7.4.7 Non-Repudiation and Other Security Services . . . . . . . . 147


7.5.1 Insufficient TCNs . . . . . . . . . . . . . . . . . . . . . . . . 148

7.5.2 No TCNs Left on Card . . . . . . . . . . . . . . . . . . . . 149

123


7.5.3 Guessing TCNs . . . . . . . . . . . . . . . . . . . . . . . . . 150

7.5.4 Reduction of Privacy . . . . . . . . . . . . . . . . . . . . . . 150

7.5.5 Re-use of TCNs . . . . . . . . . . . . . . . . . . . . . . . . . 150


7.5.7 Proof of Payment Source . . . . . . . . . . . . . . . . . . . 151

7.5.8 Merchant Practices . . . . . . . . . . . . . . . . . . . . . . . 152

7.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

This chapter follows on from Chapter 5 and proposes a comparable mechanism

for making CNP payments private for the cardholder at the point of payment and

through clearing, provided an out-of-band action by the cardholder or card issuer

does not erode the cardholder’s privacy.

This chapter examines the mechanisms of, and snags with, a selection of both

commercial online and previously-proposed offline solutions for allocating TCNs,

and then proposes an offline allocation mechanism that gives a similar service to the

online mechanisms.

The proposal allows the cardholder to opt for as much privacy as he or she wants,

without affecting the cardholder’s capability to evidence payment should the recipient

later repudiate receipt. With this privacy and when compared to traditional CNP

payments, the opportunity for “stealing” details from the payment mechanism is

reduced thereby increasing the confidence in the cardholder’s accountability for his

or her payments.


124

7.1 Introduction

7.1 Introduction

With the push towards e-payments that are secured with chip and PIN or similar

mechanisms, much fraud has switched from counterfeit and modified cards to the

residual payment methods that primarily rely on knowing the card’s details: CNP

payments. Any card payment can be traced by the card issuer to the cardholder

who can then be held accountable, but that person is not necessarily the person

that made the payment. The cardholder may be an innocent victim of compromised

privacy.

The consequences of compromised payment privacy can be severe. The initial

euphoria over news reports of the UK Police’s Operation Ore swiftly identifying 6,000

suspected Internet users of child pornography with 1,300 arrests (see Subsection

2.2.1.6) was diluted when, a few years later, it was subsequently reported that

over 20% of the payment card numbers on the payment portal computer had been

“stolen” [69]. The (false) assumption is reported to have been that all of those CNP

transactions had been made by the cardholder. The payment portal had apparently

been used as a vehicle for fraudulent payments with 90% of the victims not noticing

or not reporting their loss. When this came to light, the UK Police had 7,272

suspects, specifically the cardholders, with nearly 4,000 arrests but there were also

reports of at least 34 suicides [74], including at least one person where the subsequent

investigation revealed no other evidence. This cast doubts over the credibility of the

whole investigation and spawned an action group30.

There are various countermeasures:

Some card issuers use an RCA system that employs an offline device, but the

cardholder must use an online browser to receive any challenge from the card issuer30http://ore-exposed.obu-investigators.com/.

125


and to send the response that the cardholder transcribes from the RCA reader’s

display. RCA and the merchant’s payment application also require the cardholder

to be identified and that typically is by means of the card’s static PAN. Should

the PAN be known to an attacker then that number could still be used for a CNP

payment with a merchant that does not support additional authentication or where

the merchant’s cardholder authentication can be circumvented.

Some card issuers allocate disposable, limited-use or one-time card numbers.

Such Temporary Card Numbers (TCN)s help detect any re-use of copied or purloined

card numbers and have the additional benefit of making it harder for observers to

link a cardholder’s payments. Each TCN is the card’s pseudonym and sometimes

just good for one transaction although it may sometimes be permissible to use a TCN

on more than one occasion with the same merchant, for example: registering and

then paying for a service or goods whenever monies are due; or placing a deposit

on order with full payment due on completion; or a split shipment of goods; or

paying by instalment. TCNs can also be restricted by having a maximum payment

value. The tightest control is to require single-use, value-restricted TCNs for all CNP

payments although this may not necessarily be the merchant’s and cardholder’s

favoured option. The snag with the implemented TCN schemes is that they are

online solutions that require the cardholder to be identified and authenticated over

a separate and direct communication link between the cardholder and card issuer

each time a TCN is allocated. The need for an online connection is a constraint,

particularly when a user makes a spontaneous payment where an Internet connection

to the card issuer is not necessarily convenient or available, or the payment is being

made from a terminal that the cardholder does not trust. The PAN or other static

identification details still need to be entered into that terminal by the user for the

session with the card issuer.

Some mechanisms have been proposed that allocate TCNs when offline to the

126

7.2 Contribution

card issuer, but those TCNs do not act as a direct replacement for some form of

static identity; that static identification data needs to be given to the merchant

for forwarding with the payment data and could also be vulnerable to attack or

otherwise erode the cardholder’s privacy. With both online and offline TCNs the

cardholder’s name is passed to the merchant.

7.2 Contribution

This chapter proposes a solution that allocates TCNs to the cardholder when he

or she is offline to the card issuer and these TCNs identify the cardholder to the

card issuer, are used in place of the PAN and do not require any other identifying

information for CNP payments. In keeping with the most successful online solution,

existing e-commerce applications and the user’s web browser do not need to be

modified. The manner of cardholder authentication to the merchant and card issuer,

if any, is not affected.

The TCN is the cardholder’s pseudonym for a transaction and the proposed

payment mechanism does not require any other PII to be disclosed. This allows the

cardholder to be anonymous to, and his or her transactions to be unlinkable by all

entities in the payment process apart from the card issuer.

Should a completed payment need to be traced or evidenced, for example in the

event of a police investigation or the payment recipient repudiating receipt, then

both the payment and cardholder can be traced and matched by the card issuer.

127


7.3 Temporary Card Number Schemes

This section looks at five TCN schemes for CNP payments. Two of the schemes

allocate a TCN online and have been implemented commercially. Three example

papers propose differing methods for allocating TCNs offline.

7.3.1 Controlled Payment Numbers™

Subsection 3.3.2.2 outlines Orbiscom’s Controlled Payment Numbers™ product. Of

particular note, to be allocated a TCN the cardholder is required to sign-on to the

card issuer over a secure link and through a secure Internet terminal, making it an

online solution.

Figure 7.1 shows a user’s session with Citibank’s Virtual Account Number ser-

vice to be over a TLS v1.0 [44] protocol connection, using stream cipher RC4 [138]

with a 128-bit encryption key for confidentiality, and asymmetric cipher RSA (see

Subsection 2.4.2) with a 1024-bit modulus during the handshake exchange for server-

end authentication and to protect the premaster secret (see Chapter 10)31. This is a

common, but not the most up-to-date or the strongest combination. It is also noted

that the sign-on web page does not have a web address name or digital certificate

that bear the Citibank name, nor does the certificate benefit from extended valida-

tion [157] – just normal validation resulting in the user’s browser security status bar

being white rather than the more-comforting green that is used by many modern

browsers. The user is therefore only able to confirm that the web page was sent from

a server that has a certificate chain back to VeriSign32; the user cannot verify that

it is a Citibank or Citibank endorsed site. Further analysis of the Internet Protocol31Client using the Windows XP (Service Pack 3) Operating System with Internet Explorer 7.0.

Screen image captured and information extracted on 17th July 2008.32http://www.verisign.com/.

128


(IP) addresses of Citibank’s home web page and the reviewed sign-on page shows

that both are assigned to the Citicorp Global Information Network33, but this is

probably not a test to be expected from an average end-user.

Figure 7.1: Citibank account online: sign-on Web page

The user enters his or her identifier, static password and card number, and then

makes a note of the TCN response that is displayed on the screen so that it can be

used in place of the PAN.

7.3.2 SecureClick®

Shamir’s paper titled SecureClick [148] outlines the design philosophy and general

architecture for a product of that name from Cyota34. RSA Security Inc.35 ac-

quired Cyota in December 2005 [144] and still holds SecureClick® as a registered

trade mark. According to Orbiscom, Cyota stopped promoting SecureClick® in

2004 [126]. Israel’s Isracard was Cyota’s partner for the commercial development33Citibank - 192.193.217.120; Accountonline - 192.193.222.22.34http://www.cyota.com/.35http://www.rsa.com/.

129


of SecureClick [143] and it is unclear whether the product is presently being used

commercially.

SecureClick also requires the user to sign-on to the card issuer over a secure link

and through a secure Internet terminal to be identified, authenticated and to receive

a TCN; but that connection is recommended to be triggered by a browser plug-in.

The plug-in is typically downloaded during the user’s initial SecureClick registra-

tion, which restricts SecureClick just to Internet payments through configured web

browsers. When a payment screen that requires a card number to be input is sensed

an automatic connection is made to the card issuer, the transaction details are sent

to the issuer and in response a TCN and EXP are then generated and entered into

the web form by the plug-in. Issuer availability is even more critical than with Con-

trolled Payment Numbers™ where a TCN could be requested in anticipation. The

authentication technique is not standardised, allowing the card issuer to choose as

appropriate.

Shamir refers to the card numbers as “disposable credit card numbers” and to

be a form of nonce. In this thesis, the term TCN is used so as not to imply that the

card number is used just once and then thrown away; with some schemes the card

number can be used more than once with the same merchant and in all schemes the

TCN needs to be remembered by the card issuer for some time after the payment to

keep the cardholder accountable once the transaction completes. Also, the solution

covers any payment card including debit and charge cards.

7.3.3 Rubin and Wright

In the same publication as Shamir, a paper by Rubin and Wright proposes a cryp-

tographic method for the offline generation of “limited-use credit card numbers”, or

TCN, where the cardholder’s secure device and the card issuer share a static sym-

130


metric key [145]. During a transaction, the cardholder activates his or her secure

device, inputs some transaction parameters and a time stamp (called restrictions),

then those values are encrypted to form a TCN that is used in place of the PAN.

O = EK(P‖T )

Where:

O is the “limited-use credit card number” cum TCN.

K is the shared symmetric key.

P is the transaction parameters.

T is the time stamp.

The TCN and some identifying information, such as the cardholder’s name and

billing address, are given to the merchant who requests approval from the card issuer.

The assumption is that some identifying information is already typically requested,

but this may not always be the case. The proposal seems to leave the choice of

manner of identification to the merchant rather than the card issuer or cardholder

who are at the two opposite ends of the transaction.

On a practical note, it may not be possible for the merchant to add arbitrary

identification data to the transaction’s data and then bind those data together for

passing on to the acquirer, and then onward to the card issuer. The acquirer needs

to know that the additional data has to be passed on without any interpretation.

On receipt the card issuer has to expect and recognise the chosen data format and

those data have to bring uniqueness to the cardholder in the eyes of the card issuer.

Transaction data has to meet banking industry specifications [11, Table 24 & Table

27]. The comparable CP proposal in Chapter 5 includes fixed-format identification

data in the IAD which are designed to transport additional, undefined, data from the

card to the issuer to enable authentication of the card. Auxiliary data are available

to transmit extra transaction data, but these are for data flowing between capable

131


terminals and the acquirer [11, Appendix B].

The secure device is an auxiliary tamper-resistant computing device with a re-

liable clock, generally not a personal computer but more a PDA, Windows CE

device36 or similar. The cardholder is assumed to supply this device, notwithstand-

ing that the card issuer or merchant typically carry the risk for any fraud. Many of

the inherent risks are therefore out of scope for the paper, for example chosen text

attacks, key management issues, time synchronisation, and establishing and main-

taining the tamper-resistant properties. A bespoke application and user interface,

probably with pull-down menus, need to be installed on the device to force the use

of acceptable restrictions and to display the resulting TCN. It is not stated how an

encrypted block is translated into a numeric value of the correct format for a PAN:

up to 19 numeric characters of which 12 (39 bits if all digits are available) could be

used by this application [96] [55, Annex A1]. The card issuer decrypts the TCN and

verifies the resulting values so it seems to preclude the use of the 64-bit block DES

algorithm, a cryptographic mainstay of banking.

The solution erodes any anonymity that the cardholder may otherwise have with

the merchant and his agents, and does not prevent transactions being linked by those

entities or by any other person with access to transaction data. For identification, the

PAN pseudonym is simply substituted with other PII that may be equally damaging

if disclosed.

7.3.4 Li and Zhang

Li and Zhang’s journal proposal is to hash the current “one-time credit card transac-

tion number”, or TCN, concatenated with a static secret that is shared between the36Resource constrained device running Microsoft’s Windows Embedded Compact operating sys-

tem.

132


card’s chip and the card issuer to create the next TCN [109]. Both the current TCN

and the secret are stored on the card and, after completion, the new TCN replaces

the current TCN. Processing takes place on an unspecified smart card “reader” and

offline to the card issuer. The TCN is effectively an HMAC in a very simplistic

form, that is: a hash of the text with the key and text interchanged, but without a

specified hash algorithm, any key pad or truncation of output and probably not in

keeping with the specified minimum key size. The TCN does not replace the PAN,

which is still used for identification and on its own for transactions with merchants

that do not support the TCN field.

Oi+1 = H(Oi‖S)

Where:

Oi+1 is the new “one-time credit card transaction number” cum TCN.

Oi is the current TCN.

S is the shared secret.

With the current and new TCNs to hand and use of the hash algorithm, an

attack could be mounted; a brute force attack from another system that emulates

the most recent transaction to expose the shared secret for example, but recognising

that collisions may occur.

From an EMV perspective, most cards are the SDA variety (Subsection 3.2.2.2),

which is the most basic of the three data authentication methods and SDA cards

may not be able to produce a hash (Subsection 6.3.3).

The proposal does not generate the “one-time credit card numbers” described

in the proposal’s abstract and its contribution meets the same functional criterion

as an RCA system, without any challenge from the card issuer. Again, there could

also be problems including and binding the TCN with the transaction data.

133


7.3.5 Assora, Kadirire and Shirvani

Assora, Kadirire and Shirvani’s journal proposal [18] recognises a few of the limita-

tions with the other two offline proposals and makes three changes to the Li-Zhang

mechanism:

1. The shared secret is a prefix rather than a suffix,

2. a fixed Rubin-Wright style message is used in place of the current TCN, Oi,

and

3. a one or two digit nonce is selected by the client, but if truly a nonce would

restrict the solution to 10 or 100 uses.

O ′′ = H(S‖A‖D‖V ‖g)

The resulting variable, O ′′, is truncated to the leftmost 30 bits and represented

as 9 decimal characters.

O ′ = B2D(L(O ′′, 30))

Where:

O ′ is the variable component of the “disposable credit card number” cum

TCN.

S is the shared secret.

A is the price.

D is the date.

V is the merchant identifier.

g is a nonce.

B2D is a function that converts binary data to decimal representation.

134


In fact there are up to 12 digits available and the stated 30 bits could in some

cases require 10 decimal characters. 12 digits could span 39 bits - see Subsection

7.3.3.

In keeping with the Rubin-Wright scheme:

1. Identification uses the billing address rather than the PAN, and

2. the device that calculates the TCN is left for the cardholder to supply.

This proposal does generate a replacement PAN, but that PAN no longer acts

as the cardholder’s pseudonym. Any anonymity that the cardholder has with the

merchant and his agents is still eroded and transactions could still be linked, but

not differentiated from transactions made by other cardholders at the same address

that use the same card issuer. Some of the shortcomings with the other two offline

proposals have been addressed, but most remain.


This section considers the best features of each reviewed TCN scheme and proposes

an enhanced scheme that can be used spontaneously and without the cardholder

requiring an online connection to the card issuer at the time of payment. The TCN

is used in place of the PAN and is the cardholder’s only identification.

The proposed mechanism should work with most chip-based payment cards and

can be implemented on its own, or with some or all of the proposals in other chap-

ters. If Chapter 5’s proposal is implemented then this proposal should also be

implemented, otherwise making CNP payments is cumbersome for the cardholder

because the cardholder’s own account number, the RAN, is not usually visible. If

135


implemented with Chapter 8’s proposal, then there are some dispute resolution con-

siderations for that proposal which are covered in Subsection 8.4.5.

International standard ISO/IEC 7812-1:2006 specifies a numbering system for

identification cards, which includes payment cards [96]. The card number may be

up to 19 characters with the first six digits being the issuer identifier number and the

last digit a software computation using Luhn’s Algorithm to help detect accidental

errors in the copying of the other digits [113]. That leaves up to 12 digits for a

variable element, but in practice this is often just 9 digits of a 16-character card

number.

When the solution is enforced for all of a card’s CNP payments, each TCN is

used only once and the merchant checks the payment’s validity immediately with the

card issuer, then any “stolen” card numbers can be detected by the card issuer at

the point of payment provided the cardholder does not compromise the system (for

example, by not keeping his or her PIN secret). Purely from a security perspective,

this is the recommended mode of implementation. Where the card issuer considers

the merchant’s and cardholder’s requirements to outweigh the risks, TCNs can be

used for more than one payment to the same merchant and without checking the

payment’s validity on-line; this is the mechanism described in this chapter because

it includes and extends the features of the single-use TCN scheme.

7.4.1 Protecting Identity

Both of the online solutions entail the card issuer allocating a TCN after the card-

holder has been identified and authenticated over a second and secure Internet con-

nection. The allocated number is a shared nonce and therefore identifies the card-

holder to the card issuer when subsequently a payment or authentication request is

presented. The merchant and intermediaries do not need to know any other detail

136


about the cardholder or the PAN when processing the payment.

The three reviewed offline systems all depend on a static secret that is shared

between the cardholder and card issuer. The cardholder needs to be identified to

the merchant, or the PAN used, in order that the cardholder’s identifying infor-

mation can be passed through clearing to the card issuer with the payment or any

authentication request. The card issuer needs to know which secret to use.

Sharing some identification information is necessary with all protocols that have

many participants where each uses its own shared secret; each party needs to know

which secret to use and that is typically based on a guise of identity. Even “zero-

knowledge” proofs of identity such as the Feige-Fiat-Shamir scheme require the entity

being identified to share something static with the verifier in order that knowledge

of a secret can be demonstrated interactively [64].

This chapter proposes using the TCN for identification with no other identifying

information needing to be shared.

7.4.2 Allocating Temporary Card Numbers

The payment card’s chip stores the variable part of all the TCNs that have been

allocated to the card by the card issuer. When that card is placed in an RCA (or

equivalent) device and the appropriate function selected, the next available TCN is

displayed to the cardholder. The chip’s logic ensures that only a PIN authenticated

cardholder can see a TCN and, once displayed, the TCN is marked as used. This

requires a small applet to be placed on the card’s chip and potentially a minor

change to the RCA device. The additional data elements on the card are listed in

Table 7.1. The field sizes and number of stored TCNs can be altered to suit the

business need.

137


Table 7.1: Payment card data elements

Field content Values and data types Field sizeTable of 255 TCNs Each ≤ 12 compressed numerics ≤ 6 bytes each *

≤ 1530 bytes totalHigh water marker 0 - 255 stored in binary 1 byteLow water marker 0 - 255 stored in binary 1 byteNext TCN location 0 - 255 stored in binary 1 byte

Note: *Only the variable part of the TCN need be stored.

255 19-digit TCNs can be stored in just under 1.5 kilobytes of the card’s EEP-

ROM. Should the TCN be 16 digits then only 1.13 kilobytes are needed.

In keeping with the online TCN solutions, the card issuer allocates the TCNs and

ensures their uniqueness. The issuer identifier number is per the PAN, the variable

digits are stored in a table on the card’s chip and the trailing digit is calculated with

Luhn’s algorithm. To display the next TCN:

1. Read the next TCN location field, i, which points to a position in TCN table,

L. Then, read that stored variable part of the TCN, O ′′, and increment the

TCN location field.

O ′′ = Li

i = i+ 1

2. Should the TCN location field increase above an issuer-defined threshold, t the

low water mark, then the user is warned.

Warn user when i > t

3. Prefix stored variable O ′′ with the 6-digit issuer identifier number, b, from the

PAN.

O ′ = b‖O ′′

4. Use Luhn’s Algorithm to calculate the trailing check digit.

Start with the rightmost digit, digit position 1, and working from right to

138


left identify the other odd-position digits. Each of those digits is doubled and

where two digits result those two digits are added.

For example: 3× 2 = 6, so digit 3 becomes 6.

7× 2 = 14; 1 + 4 = 5, so digit 7 becomes 5.

Add the computed odd-position digits to the even-position digits. The check

digit that is added, u, makes the result a multiple of 10.

Card number 5 4 3 5 5 6 6 3 0 7 3 6 4 8 9

Becomes (when reversed and the odd digit positions computed:

(1+8)+8+(8)+6+(6)+7+(0)+3+(1+2)+6+(1+0)+5+(6)+4+(1+0)

= 73

u = 80− 73 = 7

O = O ′‖u

Should the RCA reader not be able to display the whole TCN then the cardholder

could insert the issuer identifier number. This proposal could be adapted should the

card issuer use a different issuer identifier number for TCNs.

7.4.3 Allocating a Card Verification Value

Any additional authentication with an RCA device can still take place. The card

issuer maps the TCN to its PAN and then carries out the authentication. Other

card objects such as the card’s EXP are used unaltered although the three or four

digit Card Verification Value (CVV)37, which is usually printed on the back of the

card and manually passed on to the merchant, is calculated in the next step of the

TCN applet to give a one-time value.37Visa’s terminology; MasterCard refers to the same value as a Card Verification Code (CVC),

American Express calls it a Card Identification Number (CID) or 4-Digit Bank Code (4DBC), andAPACS calls it a Card Security Code (CSC). Many merchants use the term CVV, as does thisthesis.

139


A CVV is effectively a MAC from which the required number of decimal char-

acters is extracted. The MAC is calculated from the card’s data, specifically: the

card’s PAN, expiration date and service code (not provided to merchants for CNP

transactions) [66]. The 2TDES key is known to the card issuer and optionally the

payment association(s)38, for example: Visa or MasterCard [78, Chapter 2]. The

card issuer places the CVV on the card during personalisation and that value helps

the key holder(s) detect counterfeit cards if validated against the card’s data dur-

ing the authorization process. The general term CVV is used in this subsection,

although chip-based payment cards have three different CVVs and this proposal

replaces just one of those [162]. The three CVVs are:

1. the CVV, which is placed on the card’s magnetic stripe. It is sometimes called

a CVV1 [162, Appendix A].

2. the CVV2, which is printed on the card and of interest to this proposal [162,

Section 6.8].

3. the iCVV, which is placed on the card’s chip. From January 2009 many

payment associations have made the iCVV, rather than CVV1, mandatory for

inclusion on all new or replacement chip cards that make contact with the

merchant’s terminal [162, Appendix A].

In the following example, two optional EMV processes and one optional EMV

data element are used as a foundation, although equivalent processes and element

from other chip-based payment card systems could be used. The processes are

to derive a session key from an ICC master key and the last online ATC (see

Subsection 5.4.4.2), and then converting a MAC output created with that key to

decimal digits following a mechanism from the EMV ICC master key derivation38Sharing the key with the payment association is only mandatory when the card is used in an

ATM transaction [162, Appendix C.1.3], so necessary for the proposal in Chapter 5. That proposaldoes not replace any data elements in the merchant’s or acquirer’s view of those payments; theOAN is an additional data element.

140


process (see Subsection 5.4.4.3). The last online ATC, or chosen salting value, needs

to be retained by both the card’s chip and card issuer. The master key is not shared

with the card’s payment association and is known to both the card issuer and card’s

chip.

1. 16-byte session key, KS , is derived from the card’s 16-byte message authenti-

cation master key, KM , and the 2-byte last online ATC, NO−1.

KS = PAR(F(KM )[NO−1])

The 16-byte double key is split into two 8-byte keys:

KS = KSL‖KSR

In difference to the three referenced offline TCN proposals, this enhanced pro-

posal does not cipher with a single static key and so keeps closer to the second

design principle of Kerckhoff’s Law [106] - Everything about the cryptosys-

tem may be public knowledge; it is the key that makes a cryptosystem secure

(paraphrased from French).

2. The TCN is padded to create a 10-byte compressed numeric object. See Sub-

section 5.4.4.1 for the mechanism.

3. An 8-byte MAC, M, is created from (in the order listed): the 10-byte TCN,

1-byte (2-digit) PANSEQ, 3-byte (6-digit) EXP and a 2-byte 0x8000 pad. The

PANSEQ is replaced by decimal “00” if not present. DES is the symmetric

cryptographic algorithm with a split double-length key.

YL‖YR = (O‖Q‖E‖0x8000)

X1 = EKSL(YL)

X2 = EKSL(YR ⊕X1)

M = EKSL(DKSR

(X2))

4. M is viewed as 16 nibbles and the first 3 or 4 decimal characters are extracted.

The number of characters extracted is payment-system specific. Where this

is insufficient then the first few characters that are > 9 are used, reduced by

141


modulo 0xA. For example:

Where: M = 7C EF AB CD DD EA 0A DC

CVV = 702 or CVV = 7024

In this proposal the replacement CVV cannot be verified by the payment asso-

ciation, only the card issuer. If it were to be a problem, then the CVV calculation

could be altered to suit the card association or a CVV downloaded with each TCN.

Downloading CVVs requires more storage space on the card’s chip.

7.4.4 Address Verification

Often validating a CVV goes hand-in-hand with verifying the cardholder’s address,

which if carried out could negate much of the privacy that this proposal brings.

Although this chapter’s proposal is designed to be independent of address verifica-

tion, some merchants insist on it being carried out so as to reduce their exposure to

fraudulent payments. To a merchant, a TCN looks like a normal PAN.

The mechanism for validating a CVV and address is through one message to the

card issuer that only includes the data items of interest [11, Appendix D.1]. The

card issuer responds with the results of the validation. The joint CVV and address

verification mechanism can verify up to 14 digits as follows:

• the 3 or 4 CVV digits, plus

• the numeric characters from the cardholder’s post code, plus

• the numeric characters from the cardholder’s address.

If there are more than 14 digits then the post code or address digits are truncated

from the right, although this would not normally happen with a UK address.

142


With this proposal there are four suggested methods for generating the vari-

able digits for address verification, from which the card issuer can select the most

appropriate method:

1. Continue the process for generating a CVV and produce further digits for ad-

dress verification. But this would not create the (unused) alphabetic characters

of an address and postcode, and any external mapping of a house number to

a postcode may fail.

2. If the CVV is downloaded then the address verification digits could also be

downloaded, but this method again would not create the alphabetic characters

of the address and this may not allow the house number to be correctly mapped

to the postcode by any external service.

3. Use the post code of the cardholder’s bank branch, although this would reduce

the size of the anonymity set.

4. Each card issuer allocates one valid address and postcode to all of its partici-

pating cardholders.

Using one short and memorable address for all participating cardholders is this

proposal’s preferred method.

With any of the four methods, any delivery of physical goods would not be to

the address verified through the card issuer’s address verification service. For that

reason, this proposal recommends that the address verification service works with

either the cardholder’s real address or the substitute address that is generated by

this proposal. The cardholder decides which address to use when making a CNP

payment.

143


7.4.5 Operating the Scheme

When a payment card is issued it has a full complement of TCNs, Table 7.1 ex-

emplifies with 255. The TCNs are chosen in a pseudorandom manner by the card

issuer that stores all potential TCNs in a table which contains:

Initially:

• the variable part of the TCN.

When a TCN is placed on a card, the following are added:

• the variable part of the PAN, and

• the PANSEQ or decimal “00” if not present, and

• the date allocated.

When a payment is made, the following are added:

• the date of first payment, or

• the date of last payment,

• and the merchant and acquirer identifier if it is a first payment.

A merchant may charge the same TCN on more than one occasion or refund to a

TCN within a card-issuer defined period from the point of last payment, provided the

PAN remains active. All uses of each TCN need to remain on file for an appropriate

time to allow for any enquires where just the TCN is known, for example a police

investigation. Should a TCN be allocated but not used before the card’s expiry, or

the time elapsing since the last payment be greater the card issuer’s threshold, the

TCN may be reallocated on condition that the previous associations are retained for

an appropriate time by the card issuer. Any replay attacks or re-use of old TCNs

or attempts to guess a TCN could be detected by the CVV not being valid or the

failure of any RCA activity39. The card issuer could log and analyse violations by39Of course, there is a chance of correctly guessing the CVV or RCA response in the same way

that a PIN could be guessed correctly. The control outlined in Subsection 7.5.3 would help detect,as would the non-repudiation solution that is proposed in Chapter 8.

144


TCN and merchant. However, any double or erroneous additional charging by a

merchant is not aided, detected or prevented by this proposal.

When the card is used in a terminal that is capable of full real-time communica-

tions with the card issuer, for example an ATM, a second small applet is called to

check whether the available TCNs are beyond the high water mark. If they are, more

TCNs are added. In an EMV environment this applet could be called during the

Script Processing step (see Figure 5.1) [55, Section 10.10], using secure messaging

so as to ensure authentication of the card issuer, data integrity and data confiden-

tiality [54, Chapter 9]. The format of a secure message is card issuer defined but

the construct is as follows:

• optional tag and length of cryptogram,

• cryptogram of command and its data,

• optional tag and length of MAC,

• MAC.

The process flow is:

1. Verify whether the TCNs need refreshing:

Next TCN location ≥ High water marker?

2. If yes, then through a secure message command:

Delete the TCNs that are above the next TCN location marker.

Add an equal number of replacement TCNs to the bottom of the table.

Set the next TCN location to 1.

An extension to this proposal could be for the cardholder to use the next available

TCN as an identifier when signing-on for online banking.

145


7.4.6 Privacy

With this enhanced scheme, the cardholder can opt for as much privacy as he or she

wants with respect to all parties, apart from the card issuer. Specifically:

Anonymity. No information that identifies the cardholder to the merchant and

those involved in the clearing process are mandatory in the widely-used EMV pay-

ment system (see Subsection 5.4.2), and most comparable payment schemes [11, Ta-

ble 5]. Most payments can complete without the cardholder’s name or address,

although other non-payment components of the transaction may make identifica-

tion to the merchant necessary or possible. For example: a name and address for

delivering physical goods, completing records when selling controlled goods or by

capturing the user’s IP address and seeking the help of the user’s Internet Service

Provider (ISP) to tie the IP address to an ISP customer. Only the card issuer must

know the cardholder’s identity.

Pseudonymity. The cardholder is only identified through a TCN which becomes

the cardholder’s pseudonym for that payment. Only the card issuer and cardholder

can associate a given TCN to a person, unless an out-of-band action by the card-

holder or card issuer erodes the cardholder’s privacy.

Unlinkability. Where the cardholder uses a TCN on just one occasion and does

not supply or leak other identifying information, then that payment can only be

linked to the cardholder and other payments by that cardholder and the card’s

issuer.

146


7.4.7 Non-Repudiation and Other Security Services

Non-repudiation of receipt. In the event of a merchant disputing a payment,

the cardholder can still evidence whether a card payment was made and the details

of any payment.

Accountability for payment. Should any payment need to be traced from the

recipient’s end, then the TCN identifies the card issuer that can then identify the

cardholder. The circumstances behind and control over any identification are mostly

administrative and situation dependent, therefore those processes are beyond the

scope of this thesis.

Fraud detection. To an attacker or a merchant, a TCN is usually indistinguish-

able from a PAN. Should the same TCN be used with different merchants then the

card issuer is alerted to the potential fraud, making detection possible as soon as

the second merchant’s request reaches the card issuer. The card issuer can detect

invalid TCNs immediately. If cards with a TCN capability are blocked from using

their PAN for CNP payments, the opportunities for fraud reduce even further.


As with any application, there are potential threats to this proposal’s smooth op-

eration. This section looks at the threats that are introduced or affected by this

proposal.

147


7.5.1 Insufficient TCNs

TCNs are a finite resource that could be exhausted.

• For each issuer identifier, there are 1012 numbers available for PANs and TCNs,

but in practice this is often just 109.

• International standard ISO/IEC 7812-1:2006 [96] allocates 3 × 105 card issuer

numbers to banking institutions. Some payment card issuers allocate from other

sectors, for example American Express issue payment cards from the travel and

entertainment sector range.

• According to the United Nations40, the world’s population is 6.8 × 109 and the

UK’s population is 6.2× 107 [156].

• According to APACS there are 1.65× 108 payment cards in issue in the UK [8].

That is 2.75 cards per adult and child.

• A business intelligence report states that, in 2006, Citigroup was the world’s

largest card issuer with 1.8 × 108 payment cards in issue in more than 40 coun-

tries [23]. Typically such cards are spread over several card issuer numbers, for

example by: card type, brand label, payment association, country.

If each person in the world were to be allocated 2.75 cards, each with 255 TCNs

and one PAN, some 4.8×1012 card numbers would be needed. That allocation could

be covered by just 5 of the potential 3×105 plus card issuers if 19-digit card numbers

are used or 4.8×103 card issuers if the more-common 16-digit card numbers are used:

1.6% of the available 16-digit numbers.40http://www.un.org/.

148


Similarly for Citigroup’s 1.8× 108 payment cards, each with 255 TCNs and one

PAN, some 4.6× 1010 card numbers would be needed which is just under 1% of the

allocation described in the previous paragraph.

Collectively, the available TCNs are enough to withstand both exemplified allo-

cations as well as previously used but not reallocated TCNs, although issuers would

probably have to extend their card numbers to make use of all 19 available digits if

the proposal were to be adopted by all card issuers for all of their cards.

Denial of Service (DoS) attacks, where a bank’s resources are exhausted process-

ing spurious requests, are difficult because banks allocate TCNs to authenticated

customers and excessive use by any customer(s) could be detected.

7.5.2 No TCNs Left on Card

Accidentally, intentionally or by making many CNP payments a card could be de-

pleted of TCNs.

TCNs are only displayed to PIN-authenticated cardholders and a warning mes-

sage is also displayed each time a TCN is given to the cardholder and the number

of displayed TCNs has passed the low water mark. Top-up takes place when the

card is used in a terminal that is capable of full real-time communications with the

card issuer and the number of remaining TCNs has exceeded the high water mark.

As necessary, individual cardholders can be given a larger allocation of TCNs or the

card’s high and low water marks adjusted.

149


7.5.3 Guessing TCNs

An attacker could guess an allocated but unused TCN, then use that number with

a merchant who does not verify a CVV or require any other authentication. With

TCNs in active use, the attacker is more likely to guess correctly than where only

PANs are used.

The payment would complete but be charged back to the merchant when the

cardholder disputes the payment. Monitoring merchants with a high charge-back

rate or a larger than usual number of rejected TCNs, or both, could help detect

high-risk merchants.

7.5.4 Reduction of Privacy

Where a TCN is used with a merchant on more than one occasion or where a

cardholder gives a merchant some other identifying or linkable information, the

cardholder’s privacy will reduce.

This is sometimes necessary or beneficial for the cardholder and this proposal

cannot offer any further protection in these situations.

7.5.5 Re-use of TCNs

An attacker could glean a TCN when it is used and make a fraudulent payment

before the genuine payment is presented to the card issuer. If used and observed,

the CVV would also match. Similarly, a cardholder could use the same TCN and

CVV with two different merchants.

150


This proposal recommends that merchants request online authorisation from the

card issuer at the time of payment. An attacker would probably fail any additional

authentication such as RCA. Should the attacker or cardholder get past the online

clearing and authentication hurdles, the fraudulent payment would complete but

the fraud would be detected and charged back to the merchant when the cardholder

disputes the payment or the 2nd transaction is presented for payment and the card

issuer detects two different merchant and acquirer identifiers.


Like any other payment card mechanism, this proposal relies on good cardholder

practices. In particular, the cardholder needs to keep the card in a secure place and

the card’s PIN secret. If another person knows the PIN and is able to make use

of the card in an RCA device, then returns it before the card’s absence is noticed,

then the transaction will appear to be genuine. Similarly, the cardholder may be

tempted to write down TCNs and CVVs in an insecure place in anticipation of

making payments in the future.

The cardholder agreement should cover cardholder practices but evidencing an

act of fraud, its cause and the culprit in these situations would be difficult.

7.5.7 Proof of Payment Source

Some merchants require the cardholder to evidence possession of the card used for

a CNP payment when collecting or making use of the purchased item. Theatre,

cinema or airline tickets, for instance.

To resolve, merchants need to use a different method of matching goods to card-

151


holder.

Of particular note, Quercia and Hailes proposed an electronic ticketing mech-

anism for mobile e-commerce in which customer anonymity and non-repudiation

security properties are key features [136]. They recognise that when purchasing

tickets, the identity of the customer may well be visible if a payment card is used

and propose splitting the role of ticketing agent and ticketed-service provider. The

agent knows the customer and the provider knows the purchase. Customer and

purchase are only linked in defined situations such as overspending. If deployed

in conjunction with this chapter’s proposal then identity would not be revealed to

the ticketing agent, just a pointer to the card issuer who could then intervene on

behalf of the cardholder. The two proposals are mutually compatible; exposure in

the Quercia-Hailes proposal could be through oversight, attack or the two ticket-

ing entities colluding (which could be just a logical separation of the same entity).

With the merging of both proposals, the anonymous cardholder is able to attend

events without the card issuer knowing which events and is able to evidence the

CNP payment to the ticketed-service provider.

7.5.8 Merchant Practices

When making a CNP payment, the cardholder does not see the final amount claimed

by the merchant until after the payment has cleared. The merchant could claim more

monies than agreed.

This scheme does not add the approved transaction amount to the TCN or CVV

calculation so as to keep the information keyed-in by the user to a minimum and to

protect the merchant who could not check the amount entered by the cardholder.

Even with chip and PIN transactions, the merchant can add items like tips after

the payment has been approved. Users should receive invoices or receipts, which are

152

7.6 Conclusions

best retained.

7.6 Conclusions

In-production and proposed schemes for TCNs have been reviewed and the merits

of each noted. A scheme for making TCNs available to the cardholder when he or

she is offline to the card issuer has been proposed, which incorporates some of the

best features of the other schemes. The strength of the validation is enhanced with

a unique CVV being calculated for each payment, a feature not available in those

other schemes. Making a payment with a TCN and matching CVV validates both

the presence of the card and knowledge of the card’s PIN, whilst still allowing other

authentication to take place.

There is no need for the cardholder to sign-on to the card issuer over the Internet

before making a payment and the cardholder’s privacy at the point of payment is

not compromised, provided the cardholder or card issuer does not undermine the

status quo. The cardholder is accountable for his or her payments and can be traced

through the card issuer should the need arise. Conversely once a payment has been

made and cleared, in the event of a dispute the cardholder is able to evidence making

the payment.

153

Chapter 8

CNP Payments:Non-Repudiation

Contents

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 155

8.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 156

8.3 Biometrics for Non-Repudiation . . . . . . . . . . . . . . 157

8.3.1 Which Biometric? . . . . . . . . . . . . . . . . . . . . . . . 157

8.3.2 Applying the Biometric Standard . . . . . . . . . . . . . . . 160


8.4.1 The Trusted Third Party . . . . . . . . . . . . . . . . . . . 163

8.4.2 Calling the TTP Service . . . . . . . . . . . . . . . . . . . . 164

8.4.3 Processing the Transaction . . . . . . . . . . . . . . . . . . 165

8.4.4 When There is a Dispute . . . . . . . . . . . . . . . . . . . 169

8.4.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172


8.5.1 Availability of the TTP . . . . . . . . . . . . . . . . . . . . 174

8.5.2 TTP Impersonation or Interception . . . . . . . . . . . . . 175

8.5.3 Sensitivity of Biometric Data . . . . . . . . . . . . . . . . . 176

8.5.4 Integrity of TTP . . . . . . . . . . . . . . . . . . . . . . . . 177

8.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

154

8.1 Introduction

This chapter follows on from Chapter 6 and proposes a mechanism that provides

a comparable non-repudiation security service for Internet payments, by leaving a

biometric sample with a trusted third party to help determine whether the cardholder

made a disputed Internet payment. This chapter examines the availability, suitability

and practicality of various biometrics and then proposes a mechanism.

The proposal complements the preventative and detective controls that are already

in place, or planned, by giving Internet payments a “third dimension” — the use of a

trusted third party and using biometrics for a third purpose: non-repudiation. This

assists any adjudication of disputes by either supporting the cardholder’s repudia-

tion of the payment, or conversely supporting the cardholder accountability for that

payment: non-repudiation.


8.1 Introduction

Chapter 7 highlights some of the risks to a cardholder from fraudulent CNP pay-

ments, which have increased in the UK since chip and PIN was introduced to protect

CP payments from fraud perpetrated with counterfeit and modified cards. Chapter

7 also proposes a privacy solution which also goes go a long way to counteracting

fraudulent CNP payments, but it does not necessarily evidence cardholder partici-

pation in a CNP payment. A non-repudiation service is needed.

Chapter 6 proposes an on-card non-repudiation solution, but on-card solutions

do not really help with Internet payments; there are few instances where a payment

card makes online contact with the Internet and the method of RCA implementa-

155

CNP Payments: Non-Repudiation

tion indicates this to be by design (although there is online and unsupported RCA

program code for a software rather than a hardware implementation freely available

over the Internet [7] ). Furthermore, that on-card evidence only demonstrates that

the card was present and possibly that the PIN was entered; it does not necessarily

evidence that the cardholder was present.

In normal use, biometrics provide identification (one to many) or verification

(one to one) security services [166] against an enrolled population and make a close

connection to the person requesting the access. Chip and PIN just verifies that the

person knows the card’s PIN and is in possession of the card. However unlike a

PIN, a comparison between a biometric sample and a stored reference copy does not

usually produce a perfect match. A margin of error has to be allowed and this can

cause some authorised users to be rejected, or potentially some unauthorised users

to be accepted.

8.2 Contribution

This chapter proposes that by using biometrics for a third security service, non-

repudiation (one to many), and using a Trusted Third Party (TTP) to store bio-

metric evidence of payment through a secure and public service, it helps determine

whether a disputed Internet payment was indeed made by the account holder. The

TTP does not need to know the identity of the account holder or enrol any party.

Should the TTP be successfully attacked then the account holder’s privacy is pro-

tected, as is the integrity of the logs. In the unlikely event of an Internet pay-

ment dispute, the TTP can analyse the biometric samples and the corresponding

transaction data, then state whether the account holder made the payment and its

confidence in that assessment.

156

8.3 Biometrics for Non-Repudiation


Biometrics are the application of mathematics to biology, especially the study of

resemblances between living things by statistical methods [127]. With respect to

controlling physical and logical access, the US Army defines biometrics as physical

characteristics or personal traits of a person that can be measured and used to

recognise that person either by identification or verification [166].

8.3.1 Which Biometric?

There are several biometric characteristics that could be candidates for a non-

repudiation service. These include: DeoxyriboNucleic Acid (DNA), gait, facial

recognition or thermograph, fingerprints, finger or hand geometry, hand veins, iris

scan, keystroke dynamics, odour, retina scan, signature verification and voice recog-

nition.

8.3.1.1 Practical Considerations

Itakura et al. state that DNA contains approximately three billion measurable base

sequences and that DNA is one of the most universal, unique and accurate biometrics

as well as being intrinsically digital. They propose a method of giving a unique global

personal identifier, at a certain probability, using a large number of DNA short

tandem repeat location measurements [104]. At first glance, it is an ideal choice

for a biometric to use in this chapter’s proposal. However Itakura et al. recognise

that DNA is difficult to collect and slow to analyse, making it impractical for use

in real-time; a 3 hour wait for making an Internet payment while DNA processing

takes place would not be warmly received.

157


Along similar lines, measuring a person’s gait may not be possible in a confined

space. There is no perfect solution. The two guiding criteria for this proposal are:

the likelihood of the user having a biometric reader and whether there are standards

to ensure compatibility and interoperability between systems.

8.3.1.2 Availability of a Biometric Reader

The web sites of three large and global personal computer manufacturers41 show

fingerprint readers to be a dominant built-in device for biometric security, particu-

larly for laptop computers. If not built-in, a fingerprint reader is readily available as

a low-cost peripheral device. Keyboards are obviously built-in; cameras and voice

capture hardware are also readily available but, unlike fingerprint readers, these

devices are not usually sold with biometric security services in mind.

8.3.1.3 Availability of Biometric Standards

With the worldwide reach of the Internet, international standards from a globally-

sponsored organisation are the most likely to have universal acceptance. In April

2007, the USA’s National Biometric Security Project noted in its annual report [118]

on the state of biometric standards that the USA’s “International” Committee for

Information Technology Standards42 was very active with 17 published standards,

nine relating to data interchange formats. The ISO was close behind with 16 pub-

lished, of which eight are data interchange format standards. There are standards by

other organisations [119], but not in such numbers or width of cover. This proposal

uses the joint ISO and IEC biometric data interchange format standards that are

published as parts of international standard ISO/IEC 19794 [102], which are now43

41http://www.dell.com ; http://www.hp.com ; http://www.lenovo.com.42http://www.incits.org.43October 2009.

158


nine44 in total.

8.3.1.4 Selecting a Biometric

ISO/IEC 19794-2:2005 [93], part 2 of the standard, covers finger minutiae biometric

data: the digital representation of the ridge characteristics of a fingerprint. Minutiae

are a widely used technique for representing fingerprint data and therefore used by

this proposal. The biometrics that are covered in other parts of the standard could

be used, even concurrently, each extract being distinguishable by a format identifier

in the interchangeable record’s header. See Table 8.1 in Subsection 8.3.2 for an

example of an interchangeable record’s format.

Part 3 of the standard covers finger pattern spectral data: the orientation, frequency

and phase, for example. Part 4 covers finger image data, with the assumption that

data storage and transmitting time are not a limitation; they are a limitation in this

proposal.

Part 8 covers finger pattern skeletal data and produces either minutiae or pattern

spectral data.

Parts 5 - 7, 9 and 10 cover the data from: a face image, an iris image, signature

timing, a vascular image and a hand geometry silhouette.

Parts 11, 13, 14 and N are in various stages of development.44Part 1 is the framework, parts 2 to 10 are the formats.

159


8.3.2 Applying the Biometric Standard

ISO/IEC 19794-2:2005 describes three methods for expressing finger minutiae, two

for smart card or token based systems and one for general storage and transport.

The latter is known as the record format and used in this proposal.

A fingerprint is scanned and converted to a digital format by thinning down all

ridges to a single-pixel-wide skeleton. A finger minutia is where a single ridge stops

being an uninterrupted line, by virtue of splitting or ending. The two basic and

most common forms of finger minutiae are: a ridge bifurcation, measured as per

Figure 8.1, and a ridge ending, measured as a valley bifurcation as per Figure 8.2.

Figure 8.1: Location and direction of aridge bifurcation

Figure 8.2: Location and direction of aridge ending

Angles are measured anti-clockwise from the right horizontal. The angle, θ, is

coded as its part of a 255 segment circle.

Other points of interest are similarly measured. A third finger minutia type,

“other”, defines the remaining less-frequently occurring features.

The eponymous Henry Classification System [71] documents four types of finger-

print: arch, loop, whorl and a composite of these. Fixed points in impressions are

core and delta points. There may be 0, 1 or more than 1 of each. Figure 8.3 maps

160


these points on a loop type fingerprint (left) and a whorl type fingerprint (right).

Arch type fingerprints ordinarily have no delta point with ridges running from one

side to the other.

Figure 8.3: Core and delta fingerprint features

Each measured feature is given an “x” and “y” Cartesian coordinate as outlined

in Figure 8.4, illustrated as a fingerprint image to the left and as an actual finger to

the right. The intersection is at zero and the coordinates increase by one with each

pixel unit making all coordinates a positive value.

Figure 8.4: Fingerprint coordinates

161


Finger minutiae data are recorded as summarised in Table 8.1. Each record

starts with a header that includes the total record length, which is between 24 bytes

and 4 gigabytes. The former is just a record header with no other information and

the latter is very much a theoretical value. Each read, or view, of a finger also has its

own header allowing each finger to be read up to 16 times and for up to 255 views in

a record. Extended data may also be recorded; these fields are not described in the

table. Importantly, any core, delta and inter-minutiae ridge count data are stored

as extended data, which incidentally are the only extended types that are not coded

in a vendor specified manner. This proposal requires the entire record to be stored

so that the header tallies and to give as much data for matching as possible.

Table 8.1: Finger minutia record formatField Size Valid Values NotesFormat Identifier 4 bytes 0x464D5200

(‘F’ ‘M’ ‘R’ 0x0)ASCII “FMR ” – Finger Minutiae Record.Followed by a zero byte.

Version (of this standard) 4 bytes n n n 0x0 ASCII ”XXX”, with XXX = " 20" or greater. Zero byte follows

Length of total record (in bytes) 4 bytes 24 - 4294967295 0x0018 to 0xFFFFFFFFCapture Equipment Certification 4 bits 0x4 or 0x0 Vendor specified. 0x4 = "Certified".Capture Device Type ID 12 bits Vendor specified - Type or model. 0x000 = unreported.Image Size in X 2 bytes In pixelsImage Size in Y 2 bytes In pixelsX (horizontal) Resolution 2 bytes In pixels per cm. Must be > 98.45 pixels per cm.Y (vertical) Resolution 2 bytes In pixels per cm. Must be > 98.45 pixels per cm.Number of Finger Views 1 byte 0 to 255 A finger can be scanned a few times, each is a viewReserved byte 1 byte 0x00 0 for this version of the standard

(reserved for future use)Finger Position 1 byte 0 to 10 0 - Unknown finger, otherwise 1 thru 10.

Right thumb to right little finger then same on left hand.View Number 4 bits 0 to 15Impression Type 4 bits 0 to 3 or 8 0 = Live-scan plain; 1 = Live-scan rolled

2 = Non-live-scan plain; 3 = Non-live-scan rolled8 = Swipe (Sliding finger across a small sensor)

Finger Quality 1 byte 0 to 100 Over all of this finger's minutiae data. 0 is low.Number of Minutiae 1 byteX(minutia type in upper 2 bits)

2 byte Types: 0x00 = Other; 0x01 = ending; 0x10 = bifurcationPosition expressed in image pixels.

Y(upper 2 bits reserved)

2 byte Position expressed in image pixels.Position and angle for type "other" are vendor defined.

Angle - θ 1 byte 0 to 255 Each bit increment represents 1.40625 degreesQuality 1 byte 0 to 100 1 to 100 (0 indicates “quality not reported”)

On

ep

erV

iew Extended Data Block Length 2 bytes 0 x0000 = No extended data

Extended Data Area Type Code 2 bytes Only present if Extended Data Block Length ≠ 0Extended Data Area Length 2 bytes Only present if Extended Data Block Length ≠ 0Extended Data In prev. field Only present if Extended Data Block Length ≠ 0

0+ per

Vie

w

Each extended data area may also contain additional vendor specified data

24-b

yte

Hea

der

:O

ne

per

Rec

ord

4-b

yte

Fin

ger

Hea

der

:O

ne

per

Fin

ger

Vie

w6

byt

es:

On

ep

er M

inu

tia

162



To make a financial commitment over the Internet, the web application moves the

user’s session to the payment processing phase. If both the payment processor

and the user agree to use the biometric non-repudiation service, then the payment

application directs the user to the TTP immediately after the payment is approved

in principle and just before completion. This proposal cuts in where the service is

used by mutual capability and consent.

The proposed mechanism should work with most payment cards and can be

implemented on its own, or with some or all of the proposals in other chapters. If

implemented with the proposal in Chapter 7, then there are some dispute resolution

considerations for this proposal which are covered in Subsection 8.4.5.

8.4.1 The Trusted Third Party

The TTP manages the collection of the biometric sample, carries out some basic

analysis, retains the biometric sample, binds in the transaction data and finally

communicates the outcome.

From a privacy perspective the payment maker is only identified to the TTP by

an account number and IP address, not by name. The payment processor chooses a

name that is familiar to the user and not necessarily the processor’s true name. The

payment account number acts as a unique pseudonym for the payer and identifier

for the sponsoring bank. For payment cards, the card issuer is identified through

the first 6 characters of the card number. Section 7.4 describes the account number

construct. If the payment account is not to the international standard format, then

the bank registers with the TTP and is allocated a unique 6 digit number to prefix

163


its accounts. No other enrolment is needed to use the service. In the event of a

dispute, the account holder complains to his or her bank which liaises with the TTP

and payment processor. The payment processor can be located by the source of the

charge.

8.4.2 Calling the TTP Service

To use the biometric non-repudiation service, the payment processor inserts a few

lines of program code into the payment application, just before the payment trans-

action completes, to make the call and to manage the response. The user needs

to have use of an attached fingerprint reader and any locally executed code can be

downloaded as a digitally-signed applet as needed.

Passing control of the user’s session to the TTP is ideally done with a TTP

supplied Application Programming Interface (API) to formulate that call. An al-

ternative is to use an https request, a secure variant of the hypertext transfer (com-

munications) protocol, at the application layer. Both methods use a TLS session,

or a session with its Secure Sockets Layer (SSL) predecessor. This cryptographi-

cally protected protocol with handshake helps defend communications against any

attacker eavesdropping, tampering or forging messages. Chapter 10 looks at the

TLS networking protocol.

Following the lead of external payment processors [131, 167], Figure 8.5 is an

example request and response to and from the TTP using an API. Figure 8.6 shows

the foundation for an equivalent call using a simplistic https redirect Uniform Record

Locator (URL). Both are generated by the payment application for the user behind

the payment web page. The payment processor can detect any account numbers

that are not to the international standard format and will have been advised of the

account number prefix when agreeing to accept those cards.

164


Phase ParameterRequest action = take sample

&amount = 182.76&currency = GBP&userip = 82.10.104.140&account = 5721341234567890&merchant name = <NAME>&transaction = <TRANSACTION DATA>

Response response = success(Success) &transactionid = <REFERENCE>

&amount = 182.76Response response = fail(Failure)

Figure 8.5: Calling the TTP with an API

https://www.ttp.com/non-rep?cmd=take_sample&amount=182.76&currency= . . .

Figure 8.6: Calling the TTP with https

Simplistic https coding could be prone to a successful response being spoofed,

because the user may be able to deduce the expected response from the outgoing

message and enter that response manually. A control is for a 2nd response with

an acknowledgement number being sent directly from the TTP to the payment

processor in a predefined format, possibly digitally signed.

8.4.3 Processing the Transaction

Once the TTP is in control and has confirmed a suitable fingerprint reader to be

accessible, the user’s screen displays a message that:

1. states the merchant’s preferred name,

2. states the payment currency and amount,

3. requests the user to confirm which finger will be used, but discouraging change

from the suggested default.

165


After the user has responded, two views of one finger are taken with the user

removing and repositioning his or her finger between reads. For consistency, by

default the right hand index finger is read but the user can swap to another finger,

for example in the event of an injury. The proposal does not authenticate; there is

no comparison of the sample to any template when paying. Only a reasonableness

check is undertaken of certain fields:

1. Before uploading, the “length of total record” field in the record’s header is

checked to ensure that the sample is not unreasonably large for transmission

and not too extravagant on storage. Conversely, the sample is ensured to be

of sufficient length so as to contain enough information to make its content

distinctive. The TTP has maximum and minimum thresholds.

2. The “format identifier” and “version” fields in the record’s header are checked

for being acceptable by referencing the TTP’s table.

3. The “number of finger views” field in the record’s header is ensured to be set

to two.

4. Both the horizontal and vertical “image size” and “resolution” fields in the

record’s header record are checked against the TTP’s minimum value thresh-

olds to ensure that the sample is sufficiently representative and likely to contain

reasonable detail.

5. The “finger quality” [93, Annex B] and “number of minutia” fields for both

finger records are averaged and measured [93, Annex D.1.1] to ensure that they

exceed the TTP’s minimum threshold. A minimum of 12 minutiae per view

is normally required, which is the recommended minimum for verification [93,

Annex D.1.1], making for at least 180 bytes per record.

166


Notwithstanding the TTP being trusted and just providing further evidence of

payment rather than the transaction record itself, once uploaded and validated the

records are stored in a mode that protects their integrity and confidentiality in the

event of an attack. A method proposed by Schneier and Kelsey [146] is used as a

foundation, as per Figure 8.7.

Xi Li−1 = EKt(Ji−1) ‖ Fi−1 ‖ EKi(Pi−1) ‖ EKi(Bi−1) ‖ hi−1 ‖ Mi−1

↓ −→ ↓−→Xi+1 Li = EKt(Ji) ‖ Fi ‖ EKi(Pi) ‖ EKi(Bi) ‖ hi ‖ Mi

↓ −→ ↓−→Xi+2 Li+1 = EKt(Ji+1) ‖ Fi+1 ‖ EKi(Pi+1) ‖ EKi(Bi+1) ‖ hi+1 ‖ Mi+1

Figure 8.7: The TTP daily log

The TTP starts a new non-repudiation log each day; its secret symmetric en-

cryption key, Kt, is loaded from secure storage and a secure starting value45 for that

day, X0, is derived. The method for deriving the daily starting value is out of scope

for this thesis, but the requirements are that the value is secure, not predictable and

can be derived again at any point in the future should there be a disputed payment.

Ideally both the key and starting value are sent in from a separate and secure server.

Each log entry is constructed with the same mechanism, one line per payment.

Taking middle line i as an example:

• Xi is used from the previous step and Xi+1 is computed for the next step

by hashing the concatenation of the literal “Increment Hash” and Xi. X0 is

the derived starting value which is similarly hashed on receipt and before use.

Only the latest value for X is retained. X is the passed-through secret that

provides the log scheme’s security.

Xi+1 = H(C‖Xi)

X1 = H(C‖X0)45Much the same function as an IV or SV that are used in CBC encipherment or a MAC, see

Subsection 2.3.2.1, but those terms not used so as to avoid confusion.

167


Where C is the literal “Increment Hash”.

• Li is the ith entry in log L and the concatenation of the next 6 values.

• EKt(Ji) is the account number, J, encrypted with the TTP’s secret symmetric

key46.

• Fi is the finger position that is coded in the two biometric view headers.

Default value is 0x02 - right index.

• EKi(Pi) is the request parameters received from the payment processor, P,

encrypted with that line’s symmetric key.

• EKi(Bi) is the biometric sample received from the user, B, encrypted with that

line’s symmetric key.

• hi is a hash of the previous entry’s hash and the 4 preceding Li values. It

allows Li to be validated without knowing any secret values.

hi = H(hi−1‖EKi(Bi)‖EKi(Pi)‖Fi‖EKt(Ji))

• Mi is a MAC of hash hi to ensure the integrity of Li, using Xi as the key. The

key is truncated as necessary by ignoring the least significant bits and if DES

is used, the least significant bit of each byte is set to odd parity.

Mi = MACXi(hi)

• Ki is used to encrypt the ith request parameters and biometric sample data

elements of the log and is a hash of the literal “Encryption Key”, the account

number: Ji, and the passed-through value: Xi. The value for Ki is not retained

once Li has been created.

Ki = H(C‖Ji‖Xi)

Where C is the literal “Encryption Key”.

Again the key is truncated as necessary by ignoring the least significant bits

and if DES is used, the least significant bit of each byte is set to odd parity.46Rendering the account number unreadable is a Payment Card Industry requirement [130, Re-

quirement 3.4].

168


• i is the entry’s position in the log. Once Li has been stored, i is converted from

binary to printable characters using Base64 [111, Part 4.3.2.4] and communi-

cated to the payment processor as the transaction reference which, together

with the date, act as a locator should the payment be disputed.

The TTP prefixes the variable data EKi(Pi) and EKi(Bi) with a length field. All

other data items are of known fixed lengths.

8.4.4 When There is a Dispute

Should a user dispute a payment, the user contacts his or her bank which asks the

payment processor for the original request parameters, P ′, and the TTP’s locator, i

(in printable characters). The payment processor digitally signs these values so as

to ensure that any alteration by any other entity can be detected. The bank verifies

that the user’s account number matches the account number in the supplied request

parameters, J ′, and that the transaction amount, currency and data are as expected.

Where the identity of the payment processor is not evident, it can be located through

the reverse of the clearing process because the bank knows the acquirer and the

transaction data of the disputed payment includes the merchant’s identifier from

which the acquirer can locate the payment processor [11, Table 27]. Once the initial

checks are complete, the bank passes the digitally signed information to the TTP.

The TTP then carries out the following checks in order or until a verification fails:

1. Preliminary checks:

Converts the locator back to binary characters with Base64 and encrypts the

supplied account number with the TTP secret key. It then checks whether that

ciphertext matches Li’s encrypted account number. The TTP also ensures that

the account number points to the enquiring bank by inspecting the leading 6

169


numbers (24 bits) and checking that these are allocated to the enquiring bank.

J therefore doubles up as a permission mask.

EKt(J ′)

Checks whether EKt(J ′) = EKt(Ji) and the log entry hash:

hi -versus- H(hi−1‖EKi(Bi)‖EKi(Pi)‖Fi‖EKt(J ′))

Checks whether the account is allocated to the enquiring bank:

L(J ′, 6)

2. Calculate secret values:

Obtains that day’s starting value, X0, and then derives the two variables that

secure log entry Li. Xi is derived by repeated hashing and thenKi is computed:

X1 = H(C‖X0)

Xk = H(C‖Xk−1) for k = 1, 2, . . . , i

Where C is the literal “Increment Hash”.

Ki = H(C‖J ′‖Xi)

Where C is the literal “Encryption Key”.

The key is truncated as necessary by ignoring the least significant bits and if

DES is used, the least significant bit of each byte is set to odd parity.

3. Integrity check:

Verifies the log entry’s MAC by checking whether:

Mi = MACXi(hi)

4. Matching request parameters:

Matches the supplied request parameters with the TTP’s stored request pa-

rameters.

EKi(P′)

Checks whether EKi(P′) = EKi(Pi))

5. Obtain biometric sample:

Decrypts the biometric sample ready for matching.

170


DKi(Bi)

6. Biometric matching:

Searches the current and the most recent logs for other transactions with the

same encrypted account number and finger, Fi. Where found, those samples

are decrypted and matched against i ’s sample on the principle that those

payments were not disputed, making the biometric admissible [93, Annex D].

Should there not be any suitable transactions but there are log entries for other

fingers, then these are checked. Possibly the scanned finger was not the finger

coded.

If there are no suitable previous records then the TTP requests the user to

supply a biometric sample for matching.

Once complete, the bank is told of the outcome: match or no match, and the

TTP’s confidence in the matching. Confidence depends on several factors, including

the quality of the biometric samples, the number of finger minutiae compared, the

number of samples compared and the matching score. The threshold for a match is

deliberately very permissive with the expression of confidence compensating for the

increased false match rate and reduced false non-match rate. The non-repudiation

service is different to a verification and identification biometric service in that false

acceptance does not automatically confer privilege.

The outcome communication is digitally signed by the TTP and includes the

transaction data that were submitted as input to dispute resolution. Should the

cardholder, bank or payment processor question the outcome then the information

used by the TTP can be verified by any party.

A possible extension to the service could be for the matching with previous

samples also to take place at the time of payment, although this would increase

the processing overhead on the TTP and elapsed time for processing the payment.

171


A compromise might be just to do this for higher-risk payments such as those of

high-value and for users who have been previously in dispute.

8.4.5 Privacy

This proposal uses the services of a TTP where the plaintext of stored transaction

entries cannot be read by any attacker, apart from the finger position parameter

Fi, because an attacker does not have the TTP’s secret symmetric key Kt or the

necessary passed-through value Xi; the passed-through value can only be forward

computed. (Any alterations to the log could be detected because hash hi and MAC

Mi would no longer match.)

The TTP knows the cardholder’s account number, Ji, and it is encrypted with

the TTP’s secret symmetric key. The cardholder is not otherwise identified to the

TTP and the cardholder does not need to enrol to use the service. This means that

the cardholder has anonymity with the TTP but his or her transactions are linkable

by the TTP. The TTP knows all payment request parameters and biometric samples

associated with any account number that calls the service47. An attacker may also

link stored payments although he or she would not know the plaintext account

number and cannot decrypt the request parameters or the biometric samples.

Chapter 7 proposes a mechanism that allocates TCNs which make transactions

unlinkable. A TCN could be used in place of an account number with this proposal

but the described dispute resolution process would always require the cardholder

to supply a biometric sample for matching and the possible extension for selective

matching at the time of payment would no longer work as described.47The TTP could observe the cardholder’s IP address and this could provide some linkability and

a route to discovering the cardholder’s identity, although this proposal only requires the TTP toencrypt and store those data.

172


In this situation, should the cardholder dispute a payment with the card issuer

then the card issuer must identify a small collection of the cardholder’s most re-

cent CNP payments and supply the account number(s) that were used. These are

the transactions’ TCNs or the cardholder’s PAN if the privacy proposal was not

employed. Dispute resolution therefore reverts the level of privacy to that of the

original proposal, but only for the cardholder’s most recent TCN payments and po-

tentially many other CNP payments if a TCN was not used for any recent CNP

payment. The card issuer could supply transaction dates so as to relieve the burden

on the TTP of searching.

Where TCNs are used, any matching at the time of payment requires the affected

cardholder’s payments to be linkable by the TTP and it may also require the TTP

to be given on-demand lookup access to the card issuer’s table that maps TCNs

to PANs. Any lookups that are not matched by an expected condition could be

reported for possible manual investigation after the event. The lookup with the

card issuer would either return a collection of recently-used TCNs or confirm the

account number to be a PAN.

The TTP is trusted by both the cardholder and card issuer, and consequently

any loss of privacy to the TTP may be acceptable to the cardholder. However any

card issuer imposed obligation for the cardholder to use the service may exacerbate

any privacy concerns.

The data transmission link between the user and the TTP uses a TLS-secured

network connection to prevent eavesdropping. The TTP’s server supports a wide

rage of ciphers suites. Should the user’s client computer not propose an encrypted

link in its cipher suite list, then the server will still accept one of the offered cipher

suites.

173



As with any service, there are potential threats to the operation of this proposal.

These mainly concern the collection, processing and storage of the additional evi-

dence of payment rather than with the payment process itself.

8.5.1 Availability of the TTP

The TTP provides a publicly-available service with a published application inter-

face over the Internet, accessed through an API or a https call, which runs on top of

a cryptographically protected network protocol, TLS or SSL, and a reliable trans-

port protocol, the Transmission Control Protocol (TCP) [43]. The service could be

susceptible to an attacker mounting a DoS attack where the TTP’s resources are

exhausted processing spurious requests. Notably:

• The application’s external interface could be sent an inordinate number of

messages from, say, a looping payment transaction or as a result of a malicious

act.

This requires the TTP to implement application controls, for example moni-

toring the IP addresses that originated the most recent transactions looking

for repetition and by expecting a pause while the biometric sample is prepared.

• A “TCP SYN flooding” attack, where an attacker initiates numerous synchro-

nise (SYN) requests, each of which ties up resources while the TTP retains

state and waits for the next message in the protocol which never arrives.

A number of countermeasures are documented that make the TCP SYN flood-

ing attack less effective [49].

174


• Availability could also be affected by a fault with the TTP’s hardware or

software.

This risk can be mitigated by the TTP duplicating all components that could

be a single point of failure.

The TTP can take certain measures to counteract known threats, as far as it

is cost effective, and possibly operate a distributed service. Ultimately the API, or

client application if https is used, needs a timer that records the TTP as not being

available should at any point a response threshold be exceeded, and then leaves it for

the application to decide whether to proceed with or abort the payment transaction.

8.5.2 TTP Impersonation or Interception

Through various mechanisms, an attacker may attempt to impersonate the TTP

or to intercept the TTP’s messages with, for example, the intent of harvesting or

harming payment and biometric data. This could be by masquerading as the TTP,

or acting as the surreptitious intermediary in a man-in-the-middle attack, or by

reading data as they pass over the communications link.

Impersonation: During the TLS (or SSL) handshake exchange the TTP is iden-

tified when it sends its public key digital certificate and the certificate chain to the

user’s computer, and the user’s computer sends a protocol secret that is encrypted

with that public key. The TLS protocol does not check that the domain name in

the certificate matches the domain name of the server, or that the domain name is

that of the TTP, or the certificates in the chain. The TLS protocol specification

leaves implementations of the protocol to be responsible for verifying the integrity of

certificates [45, Appendix D2]. Verification is possible though the user’s interaction

with his or her browser or programmable through the API.

175


Interception: The TLS (or SSL) session between the TTP’s server and the user’s

computer is configured to encrypt all of this application’s data to prevent eaves-

dropping. The TLS session is also configured to protect its messages from being

tampered with or forged by adding a message sequence number and a MAC to each

of its records. If any message were to be altered or forged then the protocol is

designed to reject any message with suspicious content or of suspicious origin.

8.5.3 Sensitivity of Biometric Data

Many people consider their biometric data to be sensitive and collecting such data

in central storage could be a delicate point. However:

• Finger minutiae data, unlike finger image data, cannot be reverse engineered

and are unlikely to leak other information such as physical characteristics or

illness.

• Fingerprints were traditionally considered a forensic biometric, but that view

has not hindered the US-VISIT48 program that, since 2004, has required fin-

gerprint scans from most people who elect to visit the USA.

• The proposal discusses the TTP as one global entity. It is possible for there to

be multiple TTPs by using a front-end router, for example to scan the first 6

characters of the account number, as outlined in Section 8.4, and having TTPs

assigned on that or a similar basis. This could enable the data to be kept in

the card issuer’s own country and in smaller repositories.

Notwithstanding the above, some objections may remain:48www.dhs.gov/us-visit.

176


• Proponents of civil liberties may consider this to be a further example of

surveillance.

• Some Christians may have concerns with respect the Bible’s reference to the

“Mark of the Beast”, specifically Revelation 13:16-17: “He causes all . . . to

receive a mark on their right hand or on their foreheads, and that no one may

buy or sell except one who has the mark or the name of the beast, or the

number of his name”.

• The small number of people who are unable to give a finger minutiae biometric

sample may be disadvantaged or have their privacy reduced. The root cause

could be, for example, through surgery, illness or occupation.

8.5.4 Integrity of TTP

In the event of a successful attack on the TTP, the account holders’ privacy and

the integrity of the logs are both protected. However that protection would not

necessarily hold over incoming transactions should an attacker be in control of the

TTP; an attacker could be an outsider or an insider abusing a position of trust.

The attacker may be able to see incoming biometric samples, identify account

numbers and transaction details but collusion with the bank, or possibly the mer-

chant or the ISP, would be needed to translate data sent to the TTP into PII. This

reduces the potential for identity theft, tracking users and for the service creeping

beyond its intended function.

177


8.6 Conclusions

A method for enhancing the non-repudiation and accountability properties of Inter-

net payments by using finger minutiae biometric data and the services of a TTP

has been proposed. Once the infrastructure is in place, the processing overhead and

inconvenience for all parties is kept to a minimum; typically there is no need for any

party to enrol. Participating payment processors need to add a programmed inter-

face with the TTP and the participating user needs to have an attached biometric

reader.

Finger minutiae are used in the example, but the proposal could be adapted to

support just about any type of viable biometric concurrently, although in practice

the choice is limited by available standards and the likelihood of the user having

suitable biometric apparatus attached to his or her networked device. In the event

of a disputed payment, the TTP is able to comment on whether the biometric is that

of the account holder and if it is, articulate the level of confidence in that statement.

That attestation then helps adjudication.

178

Part III

Web Schemes:

Cardholder Authentication

179

Chapter 9

Cardholder Authentication:Web Single Sign-On

Contents

9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 182

9.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 184

9.3 An EMV-Based SSO Scheme . . . . . . . . . . . . . . . . 184

9.3.1 The Pashalidis-Mitchell Mechanism . . . . . . . . . . . . . 185

9.3.2 Areas for Potential Improvement . . . . . . . . . . . . . . . 187


9.4.1 An Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 192

9.4.2 The SSO Infrastructure . . . . . . . . . . . . . . . . . . . . 194

9.4.3 Avoiding Changes to the Card . . . . . . . . . . . . . . . . 198

9.4.4 SSO User Registration . . . . . . . . . . . . . . . . . . . . . 198

9.4.5 SSO Operation . . . . . . . . . . . . . . . . . . . . . . . . . 200

9.4.6 The SSO Protocol . . . . . . . . . . . . . . . . . . . . . . . 203

9.4.7 CMS Maintenance and Administration . . . . . . . . . . . . 206


9.5.1 Issuer Impersonation or Interception . . . . . . . . . . . . . 208

9.5.2 Use of Other User’s Attestation . . . . . . . . . . . . . . . . 208


180

9.5.4 Leakage of Information . . . . . . . . . . . . . . . . . . . . 209

9.5.5 Availability of the Authentication, CMS and NTP Compo-

nents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

9.5.6 Integrity of the Authentication, CMS and NTP Components211

9.5.7 Time of Check to Time of Use . . . . . . . . . . . . . . . . 212

9.5.8 Incomplete Audit Trail . . . . . . . . . . . . . . . . . . . . . 213

9.5.9 Strength of Response . . . . . . . . . . . . . . . . . . . . . . 213

9.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

This chapter follows on from Chapters 7 and 8 which propose mechanisms that

provide cardholder privacy and non-repudiation security services for CNP payments,

and in particular payments made over the Internet. One of the missing ingredients is

a web authentication service that carries forward those privacy and non-repudiation

security services and (ideally) for the authentication to be linked to the payment card

account.

This chapter’s proposal is a modular framework for single sign-on to the Web

that uses a chip-based payment card for 2FA, without the card making physical con-

tact with the network connected device, and without exposing the keys and PIN that

are used to protect financial transactions. The proposed framework also offers a

basic form of single point of user registration that helps protect the cardholder’s pri-

vacy with respect to the service provider(s) and offers some non-repudiation security

properties.

This chapter’s proposal is an extension to a generalised chip-based payment card

application, although the card’s processing concepts are illustrated by referencing

EMV and the proposed mode of authentication is illustrated by referencing a gener-

alised RCA application.


181

Cardholder Authentication: Web Single Sign-On

9.1 Introduction

Although an e-payment system that adopts the mechanism proposed in Chapter 7

may offer privacy for the cardholder at the point of payment and through clearing,

there are other opportunities for the cardholder’s personal details to be captured.

Internet payments are particularly prone to this risk. Notably, cardholders are often

required to open and maintain an account with each web Service Provider (SP)

before they can make a purchase.

When a web SP wants to authenticate a user it typically, in the first instance,

asks that user to register and then allocates a unique user id and an initial password.

After registration the user only needs his or her user id and password. The rigour of

both the initial identification and mode of future authentication is variable; many

SPs balance that rigour with the risks posed by an authenticated user’s capabilities.

Risk may be in proportion to the potential for direct fraud, for example online

banking; or the potential for misuse, for example a free web-based e-mail service.

When each SP operates as an independent entity the user needs to register with each

SP that requires identification and authentication, and have a user id and password

with each. This tempts undesirable user practices such as: jotting down user id

and password pairs for those web sites, using the same password at multiple sites

or using weak passwords. A few providers of web applications with higher potential

for financial loss are introducing 2FA, where both knowledge of a password and

possession of the provider’s physical token are required for authentication.

Single Sign-On (SSO) has been on the wish-list of many information systems pro-

fessionals since the early days of networked computers. Initially the challenge was

to bridge a diverse range of proprietary systems but more recently the challenge has

been to specify a system, particularly for the Web, that is: portable, suitable for uni-

versal deployment and sufficiently trustworthy for the participating entities. Some

182

9.1 Introduction

solutions have been developed but in general they rely on one party authenticating a

user through a user id and password and the other participant organisations trusting

that authentication. Typically there is no facility to follow-up on an authentication

with the authenticating SP once that authentication has completed.

Two global organisations have led the field in seeking to address the need for an

SSO service49 with a level of success, although neither has reached a critical mass

of disparate SPs. In practice both extend the range of a user id and password so

that after the first successful identification and authentication to one of the SSO

service agents, that event is recorded and used to attest any further requests from

other SPs that have enabled the service. For some users this may have reduced the

number of times that they need to authenticate themselves manually, but neither

has solved the multiple sign-on problem. The Liberty Alliance has been working

on strong authentication since the autumn of 2005 [110], specifically a form of 2FA,

but recognises that it could exacerbate the situation by facing the end users with

yet another unique authentication mechanism. This could lead to authentication

“build-up” as users collect these 2FA tokens, a phenomenon which is also known as

the “token necklace” problem.

An RCA device is an example of a form of 2FA using a chip-based payment card

in a special offline and portable reader, helping to protect financial transactions such

as access to online banking and the verification of payments made over the Internet

(see Subsection 3.3.2.1). In the UK some 84% of the adult population holds a debit

card and 62% a credit or charge card [8].49Microsoft’s Windows Live Id (formerly .NET

Passport and Microsoft Passport Network). http://www.passport.net/.The Liberty Alliance. http://www.projectliberty.org/.

183


9.2 Contribution

Pashalidis and Mitchell proposed an SSO scheme and associated protocol in which

a variant on an EMV specification payment application provides cardholder authen-

tication and exploits the identity checks that are carried out by a bank before it

issues a payment card [128]. This chapter examines that proposal and identifies

improvements so as to create a modular framework that can either be used in its

entirety or in part; for example the authentication module could be used to replace

the equivalent mechanism in other SSO offerings, leaving those underlying sign-on

propagation mechanisms in place so as to give the user a uniform authentication

experience and possibly allow the disparate authentication systems to trust each

other.

The proposed authentication mechanism calls on the card issuer to perform the

2FA of the cardholder and to create an attestation for subsequent SP sign-on re-

quests. That attestation is then presented to those SPs and the protocol leaves it

for the SPs to decide whether the strength and freshness of the attestation meets

their need. The protocol specifically provides an anonymity service to complement

that proposed for Internet payments in Chapter 7, but authentication is usually

with a static pseudonym so as to provide linkability between sessions with that SP.

However sessions with different SPs do not have to be linkable. The card issuer

maintains an audit trail and that can offer some non-repudiation services.

9.3 An EMV-Based SSO Scheme

The Pashalidis-Mitchell proposal [128] operates with the Cardholder System (CS)

and its attached card reader at the client end, the CS typically taking the form of

a home computer but it could be any other networked and programmable device,

184


and the SP that requires the cardholder to authenticate at the other end. Not

articulated, it is in essence an authentication service for the Web.

9.3.1 The Pashalidis-Mitchell Mechanism

A dedicated application on the EMV card’s chip together with some downloaded

CS software act as an Authentication Service Provider (ASP) and respond to the

SP’s request for user authentication, without having to make contact with the card

issuer. Figure 9.1 illustrates the protocol.

Figure 9.1: Pashalidis-Mitchell SSO protocol

Step 1 CS −→ SP. The user initiates a sign-on (or login) request, presumably

intentionally or through an SP application that initiates the request. Both the

CS and SP have previously been prepared with the necessary supporting soft-

ware, although the CS could download as required. The CS needs an attached

card reader with an EMV card in situ and the SP has already registered the

185


cardholder.

Step 2 CS←− SP. The SP sends its identifier (SPID) to the CS and a TLS ses-

sion is established, or a session with its SSL predecessor, although the specifics

of that session are out of scope. The SPID could be the domain name. The

SSO protocol also checks the SP’s digital certificate, its certificate chain and

whether the EMV card is capable of SSO.

Step 3 CS ←− SP. The SP sends a nonce and the CS decides whether PIN

verification is required; PIN verification may have already taken place during

the user’s session on the CS.

Step 4 Card ←− CS. If required, the CS requests that the cardholder enters

his or her PIN and then sends that PIN to the card’s chip for verification. An

alternate authentication PIN is used rather than the card’s main PIN, but the

mechanism for segregation is not explained.

Step 5 Card←− CS. The SPID and nonce from steps 2 and 3 respectively are

forwarded to the card’s chip for inclusion in its digitally signed response which

authenticates both the card’s content and the freshness of the returned mes-

sage. The response also includes the PIN Verification Data Element (PVDE)

which records whether the PIN has been input during the user’s session and,

if so, whether PIN verification was successful. The signing mechanism is an

adaptation of EMV’s DDA.

Step 6 Card −→ CS. Certificates and card’s response are passed to the CS.

Step 7 CS −→ SP. Data from step 6 are forwarded to the SP. The SP can

186


check certificates and the hierarchical chain to verify validity and for exclusion

from blacklists, then finally verify the signed data’s origin.

During a cardholder’s session on the CS, various SPs may request user authenti-

cation. Typically, in the first instance the full protocol is followed and requires the

user to insert his or her EMV card into the attached reader and to enter his or her

PIN. Subsequent authentication requests, where the cardholder has not removed his

or her card from the reader or otherwise ended the CS session, are managed by the

ASP without involving the user.

The proposal has the potential to reduce the usual dependence on multiple user-

names and passwords and instead allow once-per-session strong(er) authentication.

9.3.2 Areas for Potential Improvement

There are a few areas of the Pashalidis-Mitchell proposal that could be improved:

to keep the card and credentials out of harm’s way, to make the service available to

more people, to simplify deployment and use, and to be modular to facilitate partial

adoption. Specifically:

9.3.2.1 Keeping the Card and Authentication Credentials Secure

The threat posed to the card’s input and output by a potentially hostile CS and po-

tentially corrupt downloaded software could be minimised by eliminating the direct

connection between the CS and card so that neither authentication factor is di-

rectly exposed. Some payment systems have been designed so that the card makes

direct contact with the CS [105], and the EMV specifications allow for such inter-

action [56, Annex A1], there are even examples of EMV cards connecting to the

187


Internet directly through the users’ hardware for an alternate payment applica-

tion [60].

The card and credentials would have a reduced attack surface and the solution

would be more portable if an RCA device were to introduce an air gap between the

payment card and the CS, leaving only a one-time challenge and response to traverse

the gap.

9.3.2.2 Making the Application More Inclusive

The proposal only works with EMV cards that support DDA and therefore capable

of processing asymmetric cryptography; specifically the card’s chip needs to create

a digital signature for a message.

Subsection 3.2.2.2 notes that most EMV cards appear to be the SDA variety and

SDA cards are only capable of processing symmetric cryptography. Furthermore not

all chip cards are EMV cards. If the proposal were to support:

• EMV SDA cards,

• non-EMV chip-based payment cards, and

• authentication by user id and password for people without a payment card,

and indicate that this weaker authentication has been used,

then the SSO application could cater for all Internet users.

188


9.3.2.3 Protecting the PIN and Encryption Keys

The proposal does not say how the SSO and the financial application PINs are

segregated, only that they are, or whether there is segregation of the cryptographic

keys.

Although both the financial and SSO applications should be secure, dual usage

of one PIN or one set of keys, or both, could increase the likelihood and consequence

of compromise. The proposal states that the PIN may or may not be encrypted, but

EMV then required the PIN to be encrypted where the card reader and PIN entry

device are not integrated, which would be the case with a personal computer and

an externally attached card reader [50, Subsection 11.1.2 point 3]. An RCA device

has an integrated PIN pad.

(The EMV specifications that have since been released, in June 2008 [54], now leave

the security requirements for PIN pads to the individual payment systems and for

general PIN management and security principles to international standard ISO 9564

parts 1 and 3 [80,81]. However it is part 4 of the standard, that is not referenced, that

deals with open networks [83]. Parts 1 and 3 only deal with ATMs and point-of-sale

terminals.)

9.3.2.4 Let the SP Decide

Any authentication only attests identity at that point in time. When asked, the

ASP effectively answers “yes” or “no” to any authentication request.

If the SP were to be informed when and how authentication took place, and

whether the session had been broken since authentication, then it would be for the

SP to assess the time-of-check-to-time-of-use risk and decide whether the presented

attestation meets the service’s need.

189


9.3.2.5 Reducing the CS Load

The overhead on the CS could be reduced by only consuming resources when the

SSO facility is needed.

By possibly triggering the SSO agent as an applet, or the device specific equiva-

lent, when first used rather than proposing a continually-running background service

or dæmon, the application would only consume CS resource when authentication

support is needed. The background service is only needed to manage state and au-

thentication requests during SSO sessions and need not run before the first sign-on

or continue running after the SSO application is closed: deliberately, or by falling

idle, or when the CS is closed.

9.3.2.6 Consolidating Applications

Creating a dedicated EMV application could cause a potential barrier to implemen-

tation.

Adding the SSO proposal to the existing payment or its RCA application with

just two minor additions to that application would reduce the cost and complexity

of implementation. The reduced complexity and air gap between the card and CS

could help assure the integrity of both the payment and SSO applications.

9.3.2.7 Rationalising Registration

Where registration is purely to provide uniqueness of the subject, for example when

an SP just wishes to personalise web content or for accessing an Internet relay chat

room, registration with individual SPs could be automated because the attestation

190


holds all the necessary details. In other instances the rigour of registration could

possibly be relaxed. The proposal offers an “anonymous certificate” to establish a

subject name, with little else made known about it.

In most countries banks are required to “know your customer”50, which involves

far more background and identity checks than normally undertaken by an SP.


This chapter’s proposal not only enhances the Pashalidis-Mitchell SSO mechanism,

but in addition specifically offers privacy properties with some anonymity and un-

linkability capabilities through the use of pseudonyms. This proposal also provides

some non-repudiation properties.

The proposed solution is nothing more than an add-on and as such could be

part of an existing application: a generalised chip-based payment card application

or an RCA application. It does not entail creating a dedicated application on the

card’s chip or rely on the EMV specifications. However, the card’s processing and

authentication proposals make specific references; processing cites some specific im-

plementations and authentication is implemented as a generalised RCA application

so as to provide an air gap between the card and CS. Deployment is more evolution-

ary than revolutionary and as such could be a phased implementation as and when

a new or replacement card is issued. It should also be compatible with any future

modes of payment card implementation such as on a contact-less card or mobile

telephone.

The proposed mechanism can be implemented on its own, or with some or all50One of the very few advertised exceptions includes an online bank operating out of Somalia and

North Korea. http://www.1stdigibank.com/.

191


of the proposals in other chapters. If implemented with Chapter 7’s proposal, then

there are no additional considerations: the cardholder does not need to enter his

or her card number or a TCN when authenticating with this proposal. PANs are

only used when registering cardholder details to the SSO service once access to

the SSO service has been granted and the cardholder is signed on to complete his

or her registration. For ease of use the registration process could be adapted to

accept TCNs and, if requested by the user, for those to be translated to a PAN

by the card issuer before the registration is completed. The proposal described in

Chapter 8 could be called to require a biometric sample be taken each time the

user authenticates for SSO with a payment card to the card issuer. Specifically:

the transaction amount could be zero, the merchant’s name could be SSO and the

transaction data could be a hash of the entry that is written to the issuer’s audit

trail. The issuer’s audit trail data could then be appended with the TTP’s locator.

The SSO service could be provided by the banks as a value-added service that

may be chargeable or, more likely for most cardholders, as a complementary service

that is intended to give competitive advantage and increase the use of revenue-

earning banking services. Banks providing value-added services on their payment

cards, in order to reach a large proportion of the adult population, is charted terri-

tory. In Iceland, the banks have agreed to use their EMV debit cards as the carrier

for Iceland’s PKI certificates and keys to meet the needs of the government. The

certification root is to be state-owned. With this collaboration, Iceland claim that

the country could become the first nation in the world to reach general usage of

qualified PKI certificates, although the project has been running since 2003 [2,134].

9.4.1 An Overview

A diagrammatic overview of this chapter’s proposal for SSO is outlined in Figure 9.2.

192


Cardholder

NTP Server

Air Gap

RCA Device

Audit Trail

Issuing Bank

(Issuer)

Service Provider (SP)

Central

Mapping

Service

(CMS) Cardholder

System

(CS)

Payment Card

Figure 9.2: Participating entities in the enhanced SSO proposal

A distinct difference with the Pashalidis-Mitchell mechanism is that cardholder

authentication is intended to be an online rather than an offline operation, which

also requires the card issuer to be online. With the SP already online and the card

issuer needing to be online for the existing RCA financial requests, this is not a too

onerous requirement. In practice some smaller issuers may pool their online service

or contract it to a larger issuer. The card issuer being occasionally offline for short

periods is not necessarily a problem.

193


The TLS protocol [45] would probably still be used to help secure the network

connection between the CS and SP because the user is requesting a protected re-

source. If used, the TLS protocol provides the only form of SP authentication which

is typically trusted to the user’s interaction with his or her browser. Chapter 10

proposes a scheme for using a payment card for TLS client authentication, which

provides comparable privacy services to this proposal and certain non-repudiation

services.

9.4.2 The SSO Infrastructure

The RCA (or payment) application needs extending and two infrastructure services

need to be established: the card issuer needs both to provide an online authentication

service and to contribute towards a Central Mapping Service (CMS) that translates

pseudonyms to PANs and vice versa. The application changes and new infrastructure

services are described in this subsection. Use of a central and synchronised clock is

also discussed.

The proposed SSO service only requires two minor modifications to the payment

card’s application51. First, the addition of an extra card-unique symmetric ICC

master key for SSO in the card’s EEPROM. The card’s SSO master key is derived

when the card is personalised (for example [161] ), and that key is only used to

derive variable SSO session keys. Subsections 5.4.4.3 and 5.4.4.2 outline processes

for deriving ICC master and session keys for an EMV card. Second, the extension

of the RCA application so that its host card works with any PIN when housed in

an RCA device. Should an entered PIN match the financial PIN then it works

as present; should any other PIN be entered then it follows another computation

without letting the user know which computation path is taken.51In an EMV card environment, the EMV specifications would not necessarily need changing

because these describe the minimum functionality required.

194


Per the following example, the SSO PIN is concatenated with the online SSO

service’s challenge and a MAC computed with a derived SSO session key. That

MAC is then converted into a numeric response.

1. Concatenating the PIN and challenge.

2. Creating a MAC of the concatenated data (Subsection 2.3.3.1).

Subsection 6.3.1.2 describes EMV’s MAC process which uses an approved al-

gorithm (Subsection 3.2.3) and a session key that is derived from the card’s

SSO master key (Subsection 5.4.4.2). The diversification data for the session

key in this proposal are dependent on the last online ATC, NO−1, or the chal-

lenge if that optional value is not available.

KS = PAR(F(KM )[NO−1])

M = MACKS(a‖l‖PAD)

where:

a is the entered PIN.

l is the challenge.

PAD = (0x80‖ . . . ‖0x00‖ . . . ‖0x00)

(That is: add a mandatory “0x80” and then “0x00”s if or as needed.)

3. Truncating and converting the MAC to an appropriate quantity and format

of characters.

IBM introduced a conversion method through mapping in the 1980s that could

be adapted [26]. Alternatively, if a response of decimal numbers is required, the

extraction method used by EMV’s ICC master key derivation process could

be employed which is illustrated in Subsection 5.4.4.3 and used below. For

example, to produce an 8-digit response from a DES based MAC:

M is viewed as 16 nibbles and the first 8 decimal characters are extracted.

Where this is insufficient then the first few characters that are greater than 9

are used, reduced by modulo 0xA. For example:

195


M = 7C 3F AB CD D5 E8 FA D3

response = 73 58 32 50

The SSO PIN is not stored on the card; only at the card issuer. During PIN

verification just the challenge and response from the RCA are communicated be-

yond the confines of the RCA device and card, not the PIN. For PIN management

and security, EMV [54, Section 11.1] and APACS [13] both refer to international

standard ISO 9564-1:2002 [80] and in addition the Payment Card Industry PIN

Security Requirements [160, Requirement 2a] refer to American Standard ANSI52

X9.52 [3] for PIN processing. Both standards support this proposal’s use of 2TDES

for processing online PINs.

Verification and management of the SSO PIN is performed centrally by the card

issuer. The PIN could either be stored by the issuer in its own right or, more securely,

as a computable natural PIN with only an offset stored [5, Chapter 10] following

the early IBM method that was used for ATMs where each character of the offset is

added to the matching character of the computable natural PIN, modulo the base,

and the result is the PIN that the cardholder must enter. For example:

1. Encrypt the PAN, J, with the card issuer’s fixed secret symmetric key:

c = EKI(J‖PAD)

where:

PAD = 0x800000000000

2. Take ciphertext c, truncate and decimalise to create the natural PIN. The

method that has just been described for generating the authentication response

(step 3) could be used. For example:

c = A0 2C D7 FC D2 CF EA 1D D3 51 D7 0C 1C 2A FF DA

natural PIN = 027252http://www.ansi.org/.

196


3. When each decimal digit of the natural PIN is added to the corresponding

digit of the offset and where necessary reduced by modulo 10, the cardholder’s

PIN is derived. For example, where:

natural PIN = 0272 and offset = 9864

cardholder ’s SSO PIN =

(0 + 9 (mod 10))‖(2 + 8 (mod 10))‖(7 + 6 (mod 10))‖(2 + 4 (mod 10))

cardholder ’s SSO PIN = 9036

PIN management is all under the card issuer’s online processing remit, such as:

enforcing strength, facilitating changes when the card is in a secure online environ-

ment53 and recording violations with a view to suspending access once a threshold

has been reached. Should any attacker try to use this mechanism to discern the

financial PIN, then these attempts could be detected by the card issuer. The issuer

also maintains an audit trail of all online authentications in order to provide evi-

dence to resolve any disputes between a cardholder and SP. It is for the issuer to

decide whether to allow the SSO PIN to be the same as the financial PIN.

The CMS acts like a Domain Name System (DNS) but instead looks up e-

mail addresses to find PANs for traffic coming from the SPs, without leaking PAN

information, and potentially vice versa for the card issuers. The service could be

provided by a consortium of issuers or by one of the large payment associations.

A central pivot to the system is a Network Time Protocol (NTP) service [116]

that ensures the card issuers’ time stamps are in synchronisation with a central

clock. SPs can either use the central clock or tell to what extent they are adrift.53An ATM, for example.

197


9.4.3 Avoiding Changes to the Card

Some card issuers may prefer to avoid the burden of allocating an extra ICC master

key, or altering the payment card’s application. As a modular framework there are

two alternatives: the choice is a question of whether that burden exceeds the card

issuer’s appetite for risk.

Master key. It is possible to use an existing master key, such as the card’s EMV

message authentication master key. However the more any key is used then the

greater the number of opportunities for compromise. A separate key is also used

in this proposal so as to give independence to this application extension. An EMV

session key cannot be created in the manner suggested in the EMV specifications

because an RCA transaction does not necessarily increment or communicate the

card’s ATC.

Master key and application. All changes to the card could be avoided by using

the financial PIN and using that response for SSO authentication. However the

more any PIN is used the greater the number of opportunities for exposure and by

including this application, the greater the potential loss.

9.4.4 SSO User Registration

Before a person can use the SSO service, he or she has to apply to an issuing bank

for a chip-based payment card and request that the card is enrolled for the SSO

service. When processing the application the issuing bank acts as a registration

authority by verifying identity, a well-established banking practice. Once approved,

the issuer supplies a personalised payment card together with an RCA device. Some

198


RCA devices are also personalised and if this is the case, the cardholder is restricted

to using only the supplied device.

The CMS allows cardholders to use one or more pseudonyms with the SPs, in the

form of e-mail addresses, and to be known by their PAN to the issuing banks. The

CMS also acts as a router; for issuer bound traffic by mapping an e-mail address to

the PAN and then inspecting the first 6 characters of the PAN so it can forward the

message to the correct issuing bank [96]. The CMS only receives information from

the SPs and only sends messages back to them to communicate an error condition.

Communications with the issuing banks are both ways.

Cardholders need to register their e-mail address(es) and card number(s) with

the CMS, possibly via the issuing bank, and demonstrate possession of both the

card and e-mail account through a fresh SSO PIN authentication and active use of

the e-mail account respectively. At registration, the issuing bank informs the CMS

of the newly registered user’s primary e-mail address and PAN so that they can be

used as identification to the CMS, then the cardholder can register, change or delete

e-mail account and PAN combinations. The CMS uses static PANs in its operation

and those PANs are only visible to the CMS and issuing bank. A cardholder can

have many e-mail addresses to one card to increase his or her transaction unlinka-

bility properties. Conversely more than one PAN can be associated with one e-mail

address. Registering e-mail accounts and PANs is the only time that a card number

is entered, which is after cardholder authentication; this is a preparatory task that

is typically not as spontaneous as a payment. The initial SSO PIN is selected by

the user after being validated through an RCA session with his or her financial PIN

and the CMS mapping the user’s primary e-mail address to primary PAN.

For people without a chip and PIN card or with a card from an issuer that has

chosen not to participate, an id and password mechanism can be provided by an

199


entity in place of the issuing bank, but the SPs are then made aware of the weaker

level of registration and authentication through the attestation communication. To

help protect against key stroke loggers the password could be entered through an

on-screen keyboard, operated by a mouse or touch screen, and the input area masked

although this does not give total immunity from all types of spyware.

As an extension to the service it could also be possible to make contextual

information available, for example confirming the person to be above a certain age

which could be useful when the SP is offering adult content or adult services. This

thesis does not cover any such extension.

9.4.5 SSO Operation

Once a user has registered for SSO with both a card issuer and the CMS, he or

she is ready to use the service. Registration of additional information with the

individual SPs is only necessary where something more than a unique identifier is

required, but that registration can erode the user’s privacy and in particular his

or her anonymity. Even when a payment takes place, further user identification or

disclosure of payment source is not required; the CMS could supply the PAN to the

bank. The bank would probably then request the financial PIN to be entered into

the RCA device to generate the card chip’s response to authenticate the transaction.

Where a full name and address is required, then the user could deliberately trigger

that transfer from the card issuer with the benefit of that address having been

independently verified.

When a user first accesses an SP that requires authentication, SSO identifica-

tion and authentication is initiated. That SP could equally be another SSO SP that

trusts this SSO service. The user is prompted for an e-mail address and control is

then passed to the issuing bank via the CMS. The issuing bank gives a challenge

200


directly to the user and that challenge needs to be processed through an RCA device

by the payment card’s chip with the SSO PIN within a relatively short period of

time. When responding, the user is asked whether a secure computer cum networked

device is being used and whether that e-mail pseudonym is to be used for all future

authentications during his or her session on the CS so that the authentication certifi-

cate can be marked and treated accordingly. If the user is not using a secure device

then the certificate is only good for that single authentication and sent directly to the

SP via the CS; the certificate is not stored on the CS for future use. The card issuer

creates a certificate along the lines of the Pashalidis-Mitchell proposal’s PVDE with

the dynamically signed data. The difference being that the attestation certificate is

signed by the issuer using a signing key dedicated to the SSO application which has

a certificate chain to a widely-trusted root CA. Additional use of the financial keys

could increase the risk of compromise and, for example, EMV financial certificates

are more compact than the most commonly used International Telecommunications

Union’s54 X.509 standard format [54, Tables 2, 10 and 11] [103]. The EMV PKI is

also a closed system [54, Chapter 10].

The attestation, signed by the card issuer and with a root back through the

payment association, includes the following details:

• the user’s e-mail address,

• the CMS reference,

• a time stamp that is synchronised with the NTP server,

• the method of authentication,

• an optional nonce from the SP to ensure the liveness of the authenticating

entity, with possibly some non-repudiation and accountability properties55 for54http://www.itu.int/.55This nonce could be a hash or MAC of an important or significant message. The card issuer

could later vouch that the SP’s message footprint was part of the authentication transaction.

201


the more critical transactions, and

• whether the CS is considered to be secure by the cardholder.

It is then for the SP to accept or reject the attestation as presented by the CS.

The CS monitors session state, to detect session breaks, by executing a digitally

signed applet that gets downloaded from the card issuer and started at the first

authentication during a session. The attestation is typically deleted when the user’s

session terminates, unless the user requests otherwise. There should be a maximum

life for any attestation, set by card issuer consensus, to enforce a degree of freshness

and to allow for card issuer key changes over a relatively short and known period

of time. The card issuer also retains an audit trail of all authentication and supple-

mental requests which could aid resolution of any future disputes, particularly when

the attestation includes the SP’s nonce.

After the first authentication and if an attestation certificate is present, the

CS presents the stored attestation and leaves it for the SP to decide whether it is

sufficiently fresh and strong to meet the business need. If not, then a replacement

attestation could be requested by including a nonce in the authentication request,

or the authentication is rejected. Where the user is associated with more than one

e-mail address or more than one payment card or both, which is determined at

the initial authentication prompt, the CS does not allow the stored PAN and e-mail

address combination(s) to be used. Each SSO authentication thereafter prompts the

user to select an e-mail pseudonym and, if there is not already a matching attestation

in place, requires interaction with the card issuer and the PIN to be re-entered. To

reduce the need for manual intervention, it is possible for the user to maintain a

table to match SPs with a credential to be used and at the first authentication for

an attestation to be created for all used e-mail address and PAN combinations that

are within the validating issuer’s remit.

202


The user needs only to be known by his or her e-mail address, unless other

information is consciously supplied to selected SPs, making for a high degree of

privacy. By default the SSO proposal allows the cardholder to remain nameless to

the SP and that is a form of anonymity in terms of the relationship the user has with

the SP. However anonymity in its purest form is difficult because there are several

potential areas of leakage such as: the SP requiring further registration information,

or the choice of e-mail identifier, or the user’s activities once signed on to the SP,

or through the user’s IP address and seeking the help of the user’s ISP to tie that

IP address to an ISP customer, or through the card issuer although this would not

normally happen. All activities that are associated with a given e-mail address could

be linked.

9.4.6 The SSO Protocol

The proposed SSO infrastructure, user registration and operation have all been

described. To summarise, this subsection outlines the proposed SSO protocol. For

brevity it does not cover periphery activities such as: the SSO agent starting and

stopping on the CS, PIN changes, establishing TLS sessions, clock synchronisation,

error conditions and payments.

Preliminary Step 1 User ←→ Issuer. The user applies to an issuing bank

for a chip-based payment card and an RCA device, which are approved and

supplied.

Preliminary Step 2 User −→ Issuer. The user, now a cardholder, requests

the issuing bank to enrol the payment card to use the SSO service. Typi-

cally this is concurrent with preliminary step 1 because, for example, an SSO

symmetric key needs to be added to the card’s chip.

203


Preliminary Step 3 User ←→ Registration Entity. Where the user does not

hold a payment card, or the card is not enrolled to use the SSO service, or

the user does not wish to use his or her payment card for SSO, a registration

entity defines a user id and password.

Preliminary Step 4 Issuer or Registration Entity −→ CMS. The issuer or

registration entity informs the CMS of the registration and either passes on

the cardholder’s primary e-mail address and PAN, or the user’s primary e-mail

address and a link to the entity that can verify the user’s password.

Preliminary Step 5 User←→ CMS. The user registers the mapping between

his or her PAN(s) (or user id) and e-mail address(es). The user demonstrates

capability to use both. The user maps as many one-to-one combinations as

needed and the CMS responds with a reference for each new entry or attempt

to duplicate an entry.

Preliminary Step 6 User −→ CS. Optionally the user maintains a table on

the CS that maps the relationships between e-mail addresses, PANs (or user

id) and SPs. This preliminary step could be completed through a user-friendly

tool as needed and also offered by a prompt during preliminary step 5. An

example four-column table is given below and shows the use of wildcards for

defining SPs. For confidentiality, the CMS reference is used in place of a PAN

and is only needed where an e-mail id has an association with more than one

payment card.

<E-mail #1> <CMS ref. #1> *.hotmail.com <Comments>

<E-mail #1> <CMS ref. #2> *.google.* <Comments>

<E-mail #2> * <Comments>

204


Step 1 CS ←− SP. Authentication request, with optional nonce, stating that

SSO is supported.

Step 2 CS −→ SP. The CS identifies the e-mail account and credential to use

from the table, if present, but otherwise by prompting the user.

If an attestation is present and the SP did not supply a nonce, the attestation

and digital certificates to permit verification are presented to the SP without

reference to the user and SSO proceeds to step 9, otherwise:

– If the user is not enrolled for SSO with a payment card, proceed to step 3.

– If the user is enrolled for SSO with a payment card, proceed to step 4.

Step 3 CS ←→ Verification authority. Control is passed to the verification

authority via the CMS for the user to be authenticated through a user id and

its password, using an authentication protocol of the verification authority’s

choosing. Proceed to step 7.

Step 4 CS ←→ Issuer. Control is passed to the card issuer via the CMS for

the user to be authenticated. A challenge is displayed on the CS which the

user reads.

Step 5 −→ User (behind air gap)←−. The user inserts his or her payment card

into the RCA device and, when prompted, enters the SSO PIN followed by

the card issuer’s challenge. The card chip’s response is displayed on the RCA

device.

Step 6 CS −→ Issuer. User enters the response that is displayed on the RCA

into the CS and that response is sent to the card issuer.

205


Step 7 CS ←− Issuer or verification authority. Once the user is identified and

authenticated, the card issuer or verification authority completes and signs a

time-stamped attestation, indicating the method of authentication and any

optional SP nonce. The attestation is passed to the CS, but only stored if

the user indicates the CS to be secure. The digital certificate chain with

verification keys for the card issuer or verification authority and above is also

sent. The card issuer or verification authority also notes the authenticated

account, the time, the user’s IP address, whether the device is secure and any

nonce in its audit trail.

Step 8 CS ←→ Issuer or verification authority. If the CS is secure and if

present, the CS inspects its table and then asks the card issuer to sign any

other attestation combinations which are also in the issuer’s remit.

Step 9 CS ←→ SP. If the e-mail address is not registered with the SP, the

SP registers the user. When more information is required the SP will send a

message to the CS requesting the information from the user or, if available,

request the user to transfer that information from the issuing bank.

Step 10 CS←→ SP. The SP inspects the attestation, its content, its signature

and signature chain. The SP then takes one of the following three actions to:

– accept the sign-on,

– reject the sign-on, or

– request reauthentication by reinitiating step 1 and including a nonce.

9.4.7 CMS Maintenance and Administration

As with any user-administration system, there are some CMS maintenance activities.

206


When a payment card is replaced or terminated, the CMS needs to update its

records. These changes could be notified to the CMS by the bank, which has all

the necessary details to hand. With online authentication, there is little need for

certificate revocation lists or industry hot card files.

When a user stops using an e-mail address, he or she needs to update the CMS’

records. If this is not done and a new user demonstrates possession of that e-mail

account, then the old records are deleted and the new mapping records are added.

The exposure is low because the old user is no longer able to reauthenticate and the

old user’s financial PIN is no longer able to trigger payments from either the newly

or previously registered card with immediate effect. It is also possible for the CMS

to track e-mail addresses that have not been recently used for authentication and to

send a message to check whether the e-mail account is still active. Changing e-mail

addresses is still cumbersome because the individual SPs need informing if the old

accesses are to be carried forward. Any table on the CS may help identify the SPs

that need to be informed.


As with any application, there are potential threats to this proposal’s smooth op-

eration. The air-gap between the user’s payment card and the CS, and the use of

different PINs and keys to financial transactions, mitigate the risk to the primary

financial application.

207


9.5.1 Issuer Impersonation or Interception

An attacker could impersonate the authentication server, or passively intercept traf-

fic, or actively intercept and forward all traffic between the card issuer and card-

holder for a man-in-the-middle attack. Any captured information could be used to

the attacker’s advantage. Of particular concern, a signed attestation is sent to the

user which could be copied and then used.

Impersonation: This risk is reduced where 2FA is used with just a one-time

challenge and a one-time response flowing between the card issuer and CS, although

a small proportion of users may authenticate with a static user id and password.

However, an attacker impersonating the authentication server is unable to present a

web page over a TLS session that is authenticated with the authentication server’s

digital certificate, or sign a usable attestation; the attacker does not have use of the

authentication server’s private key(s). These anomalies should alert the user.

Interception: The TLS session between the CS and authentication server is con-

figured to encrypt all SSO application data to prevent eavesdropping. The TLS

session is also configured to protect its messages from being tampered with or forged

by adding a message sequence number and a MAC to each of its records. If any

message were to be altered or forged then the protocol is designed to reject any

message with suspicious content or of suspicious origin.

9.5.2 Use of Other User’s Attestation

An attestation could be used by any user that holds a copy. For example, an attacker

may be able to access a CS by using a Trojan Horse program, obtain a copy of the

signed attestation and then use it as if it were his or her own; or a corrupt merchant

may try and re-use one of its authenticating clients’ attestations. The attestation

208


could be used for as long as SPs are willing to accept that attestation without

requiring the user to authenticate afresh.

A countermeasure is to include the user’s IP address in the attestation but this

could prove problematic for users that change their IP address mid-session, such

as a client that opens or closes a Virtual Private Network (VPN) to another ISP

between the attestation being issued and authenticating to an SP. However, asking

users to reauthenticate for SSO when changing IP address is a good practice.


The proposed framework for SSO does not always withstand lapse cardholder prac-

tices. For example, if the card’s PIN is not kept secret and another person who

knows the PIN can make use of the card then all SSO sessions that rely on that

authentication are attributed to the cardholder.

The cardholder agreement should cover lapse cardholder practices from a legal

liability perspective; obtaining evidence to support what actually happened would

be probably difficult. This threat is true of most methods of authentication with

few exceptions: notably biometric authentication.

9.5.4 Leakage of Information

The proposed SSO framework does not identify the user to the SPs, although there

are opportunities for identifying and privacy affecting data to be leaked which are

mentioned in Subsection 9.4.5. The residual threat is that once a user’s privacy

is compromised, it is not possible to take a corrective action to “unread” that in-

formation. The assumption must be that any attacker will just increase his or her

209


knowledge over time and not forget anything.

By changing or using multiple e-mail addresses and PANs, the scope for any

attack can be limited; possibly by using a free, temporary e-mail account and a

TCN when the access is unlikely to be repeated and the threat warrants the effort.

The opportunity for an attacker to monitor network traffic to observe which sites

the cardholder visits is not altered by this proposal.

9.5.5 Availability of the Authentication, CMS and NTP Components

The card issuer is responsible for a publicly-available, real-time service over the

Internet consisting of authentication and shared CMS components. There is also a

real-time NTP service component. Any of these components could fail or operate at

reduced capacity for various reasons, for example a hardware failure, card issuer’s

communications link failure or a DoS attack where the card issuer’s finite resources

are exhausted processing spurious requests from an attacker(s).

• Authentication: when unavailable the SSO service cannot issue new, signed

attestations. Previously issued attestations are still usable and these should

satisfy authentication requests where an attestation is already available on the

CS and that attestation is acceptable to the SP.

• CMS: when unavailable, the SSO service cannot map user PANs to e-mail

addresses and vice versa. This should only affect services that require one

pseudonym to be translated to the other such as during communications to

and from the card issuer. In particular, new authentication requests cannot

be serviced. It would also prevent cardholders registering and specifying how

PANs and e-mail addresses are mapped. All other operations should continue

210


unaffected. DoS attacks by trying to initiate excessive registrations could be

mitigated by requiring the user to retype part of a screen image that cannot

be read through an automated mechanism.

• NTP: when unavailable it would not be possible to use the central clock. In

such situations a compromise is to use the local time on the server making the

NTP request.

An effective control is for the card issuer to have a hot stand-by for all hardware

and software components that could be a single point of failure. A distributed service

could also help alleviate choke points.

9.5.6 Integrity of the Authentication, CMS and NTP Components

The authentication, CMS and NTP components of the SSO service could lose their

integrity and cause service disruption. This could be as a result of accidental or

intentional harm to those components.

• Authentication: This component could cause the greatest disruption to the

SSO service. Generally, an integrity problem would result in unusable attes-

tations being issued, but it is also possible that attestations could be issued

when authentication fails or cardholder attestations could be sent to the wrong

computers. In view of the risks, the service has to be hardened, protected and

monitored.

• CMS: An integrity problem could cause messages to be misrouted and man-

ually authenticating users to be associated with the wrong PAN, therefore

making the authentication fail. The main circumstance where there could be

lasting damage is if the tables that map user e-mail accounts to PANs were to

211


be disclosed to an unauthorised entity, although the scope for financial gain

by the attacker is reduced if the CNP proposals in Chapters 7 and 8 are used.

This service also has to be hardened, protected and monitored.

• NTP: An integrity problem with the central clock can cause back-dated attes-

tations to be issued or attestations to be issued for the future. However post

dated attestations would not be usable should the authentication server change

its signing key. Back-dated attestations would be deemed of higher risk and

may be rejected by SPs. Such problems could be detected by any potentially

affected party checking the NTP service’s clock against its own and issuing an

alert if they are too far adrift.

An effective control for component integrity problems is for a monitoring service

to send in routine requests and compare the response received with the response

expected.

9.5.7 Time of Check to Time of Use

Any authentication only attests identity at that point in time. The older the signed

attestation, the greater the likelihood of compromise.

During an SSO authentication, the SP is advised when an authentication took

place and is given the opportunity to request reauthentication if something more

recent is required. Authentications from terminals that are not trusted by the user

are only used once.

212

9.6 Conclusions

9.5.8 Incomplete Audit Trail

An audit trail entry is only created when the cardholder has opted to use the service.

If an enrolled cardholder chooses not to utilise the service, then those manual

sign-ons are not recorded in the SSO service audit trail.

9.5.9 Strength of Response

The 2FA response sent to the card issuer is a reformatted DES based MAC that

may be truncated. The MAC has a maximum output of 64 bits and this limits the

maximum length of response to 16 digits. A SHA-1 hash for example has a maximum

output of 160 bits, always one-way, does not require a secret key (although using a

secret makes the output harder to attack) and is computationally comparable [17]56.

A hash is not used because the widely-used EMV cards only uses a hash for

digital signatures and SDA cards are not capable of producing digital signatures.

SDA cards may not be able to produce a hash because it is a redundant capability

consuming scarce resources.

9.6 Conclusions

The potential to offer an SSO service for the Web with a chip-based payment card

and the opportunities to rationalise user registration to web SPs have been explored.

The proposed solution could protect the card, the cardholder and the SP(s).56Tested on a specific hand-held device: an iPAQ H3630. A SHA-1 iteration took 5.2 times longer

than a DES iteration, although SHA-1 works with input blocks of 512 bits versus 64 bits for DES.

213


No form of authentication is perfect because that authentication is only assured

at that point in time and its strength is also dependent on other external factors.

The proposed mechanism lets the SP decide whether the presented authentication

is sufficiently strong for the business need.

With this proposal, the user’s privacy can be preserved: the user controls any

release of personal information, the user’s web activities should be harder to link,

there are certain non-repudiation services to protect the user and the potential for

the user to be held accountable to an SP through an independent audit trail.

214

Chapter 10

Cardholder Authentication:TLS Client Authentication

Contents

10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 217

10.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 219

10.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

10.4 The TLS Protocol . . . . . . . . . . . . . . . . . . . . . . . 220

10.4.1 The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 220

10.4.2 The TLS Handshake Protocol . . . . . . . . . . . . . . . . . 222

10.4.3 Keys and Algorithms . . . . . . . . . . . . . . . . . . . . . . 225


10.5.1 The Extended TLS Handshake Protocol . . . . . . . . . . . 229

10.5.2 Authenticating the Client . . . . . . . . . . . . . . . . . . . 233

10.5.3 Other Considerations . . . . . . . . . . . . . . . . . . . . . 235

10.5.4 Security Services . . . . . . . . . . . . . . . . . . . . . . . . 236


10.6.1 Issuer Impersonation or Interception . . . . . . . . . . . . . 238

10.6.2 Leakage of Information . . . . . . . . . . . . . . . . . . . . 239

10.6.3 Financial Exposure . . . . . . . . . . . . . . . . . . . . . . . 239


215

Cardholder Authentication: TLS Client Authentication

10.6.5 Issuer Availability . . . . . . . . . . . . . . . . . . . . . . . 240

10.6.6 Changing IP Address . . . . . . . . . . . . . . . . . . . . . 241

10.6.7 Data on Client and Server . . . . . . . . . . . . . . . . . . . 241

10.6.8 Time of Check to Time of Use . . . . . . . . . . . . . . . . 241

10.6.9 Incomplete Audit Trail . . . . . . . . . . . . . . . . . . . . . 242

10.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Chapters 7 and 8 propose mechanisms that provide cardholder privacy and non-

repudiation security services for CNP payments, and in particular payments made

over the Internet. Chapter 9 carries those security themes forward and proposes a

complementing SSO service for the Web that uses a chip-based payment card for the

two-factor authentication of the user. This chapter proposes a mechanism for client

authentication in a TLS network connection that provides comparable cardholder

privacy and non-repudiation security services.

The TLS protocol is the de facto standard for preventing eavesdropping, tamper-

ing or message forgery for higher-risk Internet communications, for example when

a client terminal is used to make a payment to the merchant’s server. At heart,

TLS is a stateful cryptographic protocol built around a PKI. However TLS is config-

urable; at one extreme it provides little protection and at the other end of the scale

it provides protection against most known threats to an Internet communication. In

practice, the “I” part of PKI is often not available at the client end so only the server

end is authenticated.

This chapter’s proposal is an optional extension to the TLS protocol that dis-

penses with the need for the client’s user to be registered with a PKI certification

authority, and instead uses a payment card to authenticate the user. This facilitates

wider use of the available TLS services and can provide additional security services,

for example: enhanced cardholder privacy and certain non-repudiation services when

216

10.1 Introduction

compared with using PKI.

This proposal is intended to be adaptable for most chip-based payment card sys-

tems but, in keeping with Chapter 9, user authentication is implemented as a gen-

eralised RCA application. Indeed, this chapter could use the authentication services

of the SSO proposal.


10.1 Introduction

Transport Layer Security (TLS) [45] is often associated with providing end-to-end

security between a web browser and a remote web site, but it can and does support

many other applications by intercepting messages between the application’s com-

munication protocol and the lower-level reliable transport protocol: typically TCP.

TLS can even create a tunnel for a whole network stack to form a VPN. The spec-

ifications for TLS or its SSL predecessor have been freely available since 1995 [72]

and there is no significant competitor. From SSLv2, to SSLv3, to TLS 1.0, 1.1 and

1.2 the software has received four specification changes as it goes from strength to

strength.

A web browser often uses the TLS protocol to protect higher-risk communica-

tions, such as the transmission of sign-on credentials or payment card information,

but TLS can also be used to hide content for surreptitious reasons or generally to

avoid accountability. For example: to access illegal content or to circumvent fire-

walls. TLS makes no lasting record of its connections, leaving any burden of proof

to the application’s protocol such as the web browser’s history records. TLS does

not provide an accountability or non-repudiation service.

217


TLS is designed to provide communications security over the Internet and pre-

vent eavesdropping, tampering or message forgery, but the protocol does not nec-

essarily provide sufficient security for all needs. The protocol is configurable and

much of that configuration is the subject of an electronic handshake negotiation

between the user’s client computer and the SP’s server. In the basic state of

“TLS NULL WITH NULL NULL”, TLS provides no security services although that

state is only documented to be used in the initial (handshaking) stage of the pro-

tocol. Encryption of the application data at any stage is optional. It is possible to

follow the TLS protocol, present the user with the reassuring padlock icon and cause

an unsuspecting user to have a false sense of security, bearing out Gollmann’s de-

scription of the fundamental dilemma of computer security: “security-unaware users

have specific security requirements but usually no security expertise” [68, Section

1.2].

Authentication of the server or both entities is possible (and optional) using PKI

techniques. The client can use the server’s certified public key to encrypt a Premas-

ter Secret (PS), or both can use a signed certificate to exchange public Diffie-Hellman

(DH) keys [137], or the client can send a digital signature of the preceding messages

at the end of the handshake protocol and share its digital certificate. However, in

practice the client often does not have an officially-signed digital certificate so only

the server can be authenticated; for various technical, economic, legal and social

reasons, PKI has not really taken off for end-users [112]. Where PKI is used, it

is typically at the expense of privacy; the certificate usually provides the entity’s

name and could provide linkability between otherwise disparate sessions. DH of-

fers the extremes of authentication. An anonymous DH key exchange is possible

where uncertified public keys are exchanged and, if used, can only provide protec-

tion against passive eavesdropping. On the other hand the specifications state that

perfect forward secrecy requires ephemeral DH keys.

218

10.2 Contribution

Although TLS may appear to be a series of options which are negotiated between

the client and server on behalf of their respective user and SP, that negotiation

takes place covertly. The client’s hello message states which of the 37 cipher suite

combinations and 5 TLS releases it supports in its order of preference and whether

the (only) defined compression method is supported. The server makes its selection

known in its hello message or the server issues a handshake failure alert to reject the

offered combinations. Hopefully the server selects the strongest mutually-supported

combination, but the weakest combination could be chosen. The client has most

probably been configured by its software provider with little or no reference to its

user and the server is to a large extent governed by the client’s capabilities over

which the SP has no control.

10.2 Contribution

This chapter’s proposal helps address that fundamental dilemma of computer secu-

rity by helping the client support its TLS authentication and potentially blocking

the use of weak cipher suites. Only the client’s TLS protocol needs altering and

even then it just extends the protocol rather than changes its basic operation.

The client’s user is authenticated by association with a payment card. The card

issuer authenticates its cardholder using its preferred method and vouches to the

web SP’s server that it knows the client so the digital certificate does not expose

the cardholder’s identity. The card issuer also maintains a log of the user’s TLS

sessions which gives accountability for those links and the card issuer can vouch

for any logged TLS session should either party later repudiate there having been a

session.

219


10.3 Scope

This chapter has been researched using the current TLS release, 1.2 [45] (August

2008), although reviewing the security options of the latest production releases of

common browsers on a Windows XP (Service Pack 3) platform shows that only

SSLv3 (1996) and TLS 1.0 (1999) are supported by all, with just one supporting

TLS 1.1 (April 2006)57. The concepts expressed in this proposal could operate with

any release of TLS, although some minor details may be different. For example,

hash algorithm SHA-256 is not supported by the previous releases.

10.4 The TLS Protocol

This section looks at the TLS protocol insofar as it pertains to this proposal.

10.4.1 The TLS Record Protocol

TLS is a layered protocol with the TLS record protocol at the bottom layer. It is

the base protocol to four higher-level layer protocols and for this chapter it is the

higher-layer handshake protocol that is of particular interest because it determines

the cryptographic parameters for any session. Table 10.1 shows the structure of the

TLS record layer fields. Before placing the message that is to be transported in

the protocol, if necessary it is broken into sequential fragments of 214 bytes or fewer

(with header) so as to be inside the protocol’s upper limit. Each fragment is then57Microsoft’s Internet Explorer (8.0) also has SSLv2 (disabled).

http://www.microsoft.com/windows/products/winfamily/ie/default.mspx.Mozilla’s Firefox (3.5.1). http://www.mozilla.com/en-US/firefox/.Opera’s Opera (9.64) also has TLS 1.1 (enabled). http://www.opera.com/.Apple’s Safari (4.0.2) also has SSLv2 (disabled). http://www.apple.com/safari/.Google’s Chrome (2.0) also has SSLv2 (disabled). http://www.google.com/chrome/.

220


optionally compressed. The term protocol message is used to describe a message

chunk that has completed the layer’s fragmentation and compression options.

Table 10.1: TLS record layer fields

Offset Bits Description0 - 7 8 Content type, recorded in binary.

20 = ChangeCipherSpec; 21 = Alert; 22 = Handshake;23 = Application.

8 - 23 16 TLS or SSL version. Two digits, each an unsigned byte.TLS 1.2 = 33; TLS 1.1 = 32; TLS 1.0 = 31; SSLv3 = 30;SSLv2 = 20.

24 - 39 16 Length of protocol message in bytes.40 - . . . Var. Protocol message.Next Var. Optional message authentication code, based on a hash:

16 bytes - MD5; 20 bytes - SHA-1; 32 bytes - SHA-256.Next Var. Padding. (Block ciphers only; ≤ 255 bytes)Next 16 Padding Length. (Where padding is used)

The content type field indicates which of the four higher-layer protocols is the

client for this record protocol message. More than one message of the same content

type may be concatenated to increase the size of the protocol message, provided the

size limit for a message is not exceeded.

The optional MAC is to protect message integrity and discussed in Subsection

10.4.3.

When optional encipherment is used for confidentiality, only the fields in bit 40

and beyond are encrypted: the payload. The 40 header bits are not encrypted. Typ-

ically encipherment and a MAC are both used making it a symmetric authenticate-

then-encrypt method rather than the more-secure vice versa. Due to that encipher-

ment being either a stream cipher or in CBC mode the published vulnerability is

overcome, provided the mode of cipher remains as presently documented [107].

When the handshake protocol completes, its results are fed back to the record

221


layer’s security parameters. Once the security parameters are loaded, the record

layer generates the shared secrets which are re-calculated each time the client or

server send a ChangeCipherSpec protocol message to the other entity. Subsection

10.4.3 looks at how the MAC keys, encryption keys and the IV are calculated.

Not all cipher suites require all secrets, that is: MACs and encryption are optional

and an IV is only used when a block cipher is used for encryption (although an

implementation note states that IVs are currently only generated for implicit nonce

techniques).

10.4.2 The TLS Handshake Protocol

When performing a TLS handshake, the cryptographic parameters have not been

agreed and therefore the record protocol nullifies all cryptographic options. Fig-

ure 10.1 shows the message flow of the full handshake protocol. At minimum, when

a client and server agree to resume a previous session or create a duplicate of an

existing session then only the ClientHello and ServerHello messages need be sent,

followed by both entities sending ChangeCipherSpec and Finished messages. Au-

thentication can be of neither party, both parties or just the server.

The pertinent messages of the TLS handshake are:

HelloRequest is an optional prompt from the server requesting a handshake.

ClientHello is the client’s first message in the handshake and is mandatory. In-

cludes, and of particular interest to this proposal:

• Random. 28 bytes of the client’s choosing.

• Protocol version. The highest TLS or SSL version supported by the client.

• Cipher suites. List of supported cryptographic options, in order of preference.

222


Client Server

HelloRequest�

ClientHello -

ServerHello

Certificate

ServerKeyExchange

CertificateRequest

ServerHelloDone

�

Certificate

ClientKeyExchange

CertificateVerify�� ChangeCipherSpec

Finished

-

�� ChangeCipherSpec

Finished

�

�� Application Data

�� Application Data� -

Key: Mandatory Optional

�� Another Layer

Figure 10.1: TLS handshake protocol

• Session id. Given if the client wishes to try and continue a previous session.

• Extensions. Optionally any extended functionality.

Also includes the time and a list of any supported compression methods.

ServerHello contains the server’s pick of session parameters from the ClientHello

and is also mandatory. Includes, and of particular interest to this proposal:

• Random. 28 bytes of the server’s choosing.

• Protocol version. The highest supported by both the client and the server.

• Cipher suite. The cryptographic options selected by the server.

• Session id. Identity for the session. Old session id used for continued sessions.

• Extensions. The server’s selection from the client’s list (if sent).

Also includes the compression method selected by the server.

223


(Server) Certificate is the server’s PKI certificate and its chain. The message

is mandatory if certificates are to be used for authentication, which is the case for

this proposal. The checking of certificates is at the heart of TLS authentication and

how (or whether) these are checked is beyond the scope of TLS.

ServerKeyExchange is the server’s key exchange information for an anonymous

DH negotiation, or additional information for an ephemeral DH key exchange.

CertificateRequest is sent when a server that is to be authenticated also wishes

to authenticate the client. Contains a list of supported signature algorithms and

sometimes specifies the supported certificate authorities.

ServerHelloDone is a message to complete the server hello phase.

(Client) Certificate is only sent in response to the server’s CertificateRequest

message. Where a certificate or a certificate matching the server’s criteria is not

available an empty message with no attached certificates is returned. The server

may then continue without client authentication or cause the handshake to fail.

The message is otherwise akin to the server’s certificate message.

ClientKeyExchange is the client’s message for setting the PS:

• Public key cryptography: the PS is the two-byte code of the client’s highest

supported TLS version concatenated with 46 random bytes of the client’s choosing.

The secret is encrypted with the server’s public key.

• DH explicit: used when the client’s certificate does not contain the DH public

value and DH is to be used. The DH protocol is then used by each party to construct

the PS using its own private key and the other entity’s public key.

224


• DH implicit: sends an empty payload when DH is to be used and the client’s

certificate holds the public value.

CertificateVerify is sent where a client certificate with signing capabilities has

been previously sent. The client authenticates to the server by digitally signing a

concatenation of all previous handshake messages. The contents are not sent; just

the digital signature.

ChangeCipherSpec and Finished are exchanged to confirm the success of the

key exchange and authentication. The client and then the server send a Change-

CipherSpec message to trigger a fresh set of cryptographic keys which the Finished

message then uses. After this final handshake exchange, application data can then

flow. The Finished message contains a pseudorandom value (see Subsection 10.4.3)

created using the concatenation of the master secret, a “client finished” or “server

finished” label and seeded with a hash of the preceding handshake messages. The

Finished message verifies that the handshake had integrity and was complete.

10.4.3 Keys and Algorithms

With the ClientHello and ServerHello messages, cipher suites(s) are proposed by the

client and one of those is selected by the server. The chosen cipher suite defines an

algorithm for each of the following: key exchange, bulk encryption (also secret key

length), a MAC and a PseudoRandom Function (PRF). Both of the documented

MAC and PRF algorithms are based on hash functions, although cipher suites may

in the future register their own constructs. All keys are calculated using the PRF

that takes in the three random values that are exchanged during the handshake,

thus making the Client Random Value (CRV), the Server Random Value (SRV) and

225


particularly the PS important.

An optional MAC is documented as being generated using an HMAC.

M = HK(G‖X )

Where:

K is the client or server MAC write key, padded by appending 0x00 bytes to

make the key as long as the hash’s input block length.

G is the record’s sequence number.

X is the protocol message: the (optionally compressed) payload data that pre-

cede the MAC in the record protocol.

This is where the specification matters; it is an IETF specification HMAC. Notably

hash algorithm MD5 is not approved by NIST [120], but used for illustrative purposes

by the IETF in both the HMAC and TLS specifications.

The PRF is used to expand a secret, an identifying label and a seed into output

of arbitrary length. It is also based on an HMAC which iterates with self-adjusted

input until enough data are created. In keeping with previous protocol updates,

the cited PRF has again changed. Of note for TLS 1.2, the use of hash algorithm

SHA-256 is documented rather than a combination of SHA-1 and MD5.

A HMAC iterates as necessary to produce the required quantity of data:

PRF(S‖H ‖I ) = HS (Y1‖H ‖I )‖

HS (Y2‖H ‖I )‖

HS (Y3‖H ‖I )‖. . .

where:

S is the chosen secret.

H is a label.

I is the chosen seed.

Y0 = (H ‖I )

Yi = HS (Yi−1)

226


The Master Secret (MS) is computed with three variables: the PS seeded with

the CRV and SRV that are exchanged in the ClientHello and ServerHello messages.

The label is the literal ASCII characters “master secret”. MS is 48 bytes and SHA-

256 produces a 32 byte hash. The first HMAC iteration produces the leading 32

bytes and the leftmost 16 bytes of the second iteration produces the remainder

through truncation of the rightmost bytes:

w = PRF(v‖C‖(r‖s))

where:

w is the master secret: MS.

v is the premaster secret: PS. The secret.

C is the literal: “master secret”. The label.

r is the client random value: CRV. First half of the seed.

s is the server random value: SRV. Second half of the seed.

The Record Protocol’s cipher parameters are computed by expanding the

MS, label “key expansion” and seeded with the CRV and SRV. Six sets of secure

bytes are created with any unused bytes left empty:

• client write MAC key • server write MAC key

• client write encryption key • server write encryption key

• client write IV • server write IV

For example, where the MAC is SHA-256 with 32 byte keys, the cipher is AES-128

with 16 byte keys and no IV, then a SHA-256 based PRF needs three iterations with

no truncation to create a 96 byte key block that is sequentially broken into the keys.

When a ChangeCipherSpec message is sent by either party, the next three iterations

are used.

KB = PRF(w‖C‖(r‖s))

where:

227


KB is the key block.

w is the master secret: MS. The secret.

C is the literal “key expansion”. The label.

r is the client random value: CRV. First half of the seed.

s is the server random value: SRV. Second half of the seed.


This section proposes a TLS extension that introduces a payment card to the client

side of the handshake to facilitate mutual authentication, without requiring the

client to be part of a PKI. Of essence is to continue to protect the client-chosen PS

from disclosure or manipulation, and to allow the client and server to choose their

own random bytes for the CRV and SRV.

The proposed mechanism can be implemented on its own, or with some or all of

the proposals in other chapters. It would be particularly suited to be implemented

with the proposal in Chapter 9, because SSO and TLS client authentication could

be both achieved with one manual authentication.

As with the SSO proposal, the proposed TLS extension could be provided by

the banks as a value-added service that may be chargeable or, more likely for most

cardholders, as a complementary service that is intended to give competitive advan-

tage and increase the use of revenue-earning banking services. Some smaller card

issuers may pool their service or contract the service to a larger issuer.

228


10.5.1 The Extended TLS Handshake Protocol

Figure 10.2 shows the full message flow of the extended handshake protocol. A third

participant is introduced, the payment card issuer, that authenticates its cardholder

cum client and vouches this to the web SP’s server. The protocol does not require

the client to be identified to the server and should the server wish to contact the

client after the session has terminated, then this may be done through the card

issuer using the session identifier as the client’s pseudonym.

Card Issuer Client Server

HelloRequest�� TLS Session

�� TLS Session� -�� AuthenticateClient

�� AuthenticateClient� -�� SuggestedCiphers -

ClientHello -

ServerHello

Certificate

ServerKeyExchange

CertificateRequest

�� ServerHelloDone

�

� � �

�� Certificate - -

ClientKeyExchange�� HashedVerify�

-�� CertificateVerify -�� ChangeCipherSpec

Finished

-

-�

�� AuditLog

�� AuditLog

�� ChangeCipherSpec

Finished

�

�� Application Data

�� Application Data� -

Key: Mandatory Optional

�� Another Layer

Figure 10.2: Extended TLS handshake protocol

229


The pertinent messages of the extended TLS handshake are:

(Only the messages that are added or changed by the extension are described.)

A TLS Session is negotiated between the client and card issuer. For this con-

nection, the card issuer is the server which unilaterally authenticates to the client

through the TLS protocol. The checking of the issuer’s certificate and its chain can

be carried out manually by the cardholder in the next step, and also programmed to

verify that the chain has its root back to the payment association CA. This session

starts before the client negotiates a TLS session with any other server. It can be

triggered by the extended TLS protocol during initiation or started manually by the

user. Starting manually could cause the extension to be temporarily downloaded

and executed.

The AuthenticateClient step runs in the TLS record protocol as an application

type message in the above TLS session. The payment-card holder is authenticated

by the card issuer. Subsection 10.5.2 describes an authentication process.

SuggestedCiphers is the card issuer’s suggestion to the client for key exchange

and other ciphers to be used in conjunction with this proposed extension. During

the cardholder’s TLS handshake with the card issuer, the ClientHello message lists

the cipher suites that the client supports. The card issuer retains the list and returns

a subset of that list after the client has authenticated. The signature algorithms

extension is coded to list the supported algorithms and potentially weak cipher

suites could be removed from the main and extension lists of ciphers. Both signa-

ture extension algorithm components must be supported by both the client and the

card issuer; the card issuer can determine the supported hashes by looking at the

supported MACs and the signature algorithms from the supported key exchange ci-

230


phers. The client retains the returned list for ClientHello messages to other servers.

Of the supported ciphers, all variants of non-ephemeral DH key exchanges are re-

moved leaving just the basic null cipher which is needed for TLS handshakes, all

ephemeral DH ciphers and RSA. Anonymous DH key exchanges are not included

because this proposal is about identification. Non-ephemeral DH key exchanges are

excluded because only the certificate holder knows the DH private key and the pro-

posed extension deals with clients that are not supported by PKI; the certificate

presented by the client is the card issuer’s certificate (see client certificate step) and

the proposal does not want the card issuer to know or to be able to calculate the

PS.

Using the TLS specification notation, the SuggestedCiphers message is a variable

length vector of between 2 and 216 − 2 bytes that lists the suggested cipher suites.

It is an application type message:

struct { CipherSuite cipher suites< 2 .. 216 − 2 >; } SuggestedCiphers;

CertificateRequest is only sent when the server wishes to authenticate the client.

If received, the client replaces the 40-bit “22 handshake” type header (see Table 10.1)

with a 40-bit “23 application” type header and forwards it to the card issuer. Should

the server request a certificate containing a static (non-ephemeral) DH key then a

fatal handshake failure alert is issued.

(Client) Certificate is only sent in response to the server’s CertificateRequest

message. The card issuer sends its own signing certificate and other certificates in

its chain. The certificate is dedicated to this TLS authentication application and

could have a short-term expiry date to allow frequent change: possibly every few

days. The client buffers the Certificate message until the ServerHelloDone message

is received and then replaces the TLS application header with a handshake header

and forwards it to the server. The Certificate message is stored by the client for

231


future use, but only while the TLS session between client and card issuer remains

open, during which time incoming CertificateRequest messages need not be passed

back to the card issuer.

HashedVerify is an application TLS message from the client to the card issuer

and contains the hash of a concatenation of all handshake messages that have flowed

between the client and server from the ClientHello to the message preceding this

message. The contents are not sent; just the hash from the algorithm listed in

the card issuer’s certificate. The server’s IP address and the server’s session id are

appended to the message so that these details may be recorded in the audit trail

(see below).

The message in TLS specification notation:

struct {

MessageHash message hash;

ServerIP server ip;

SessionID session id;

} HashedVerify;

CertificateVerify is an application TLS message from the card issuer to the client

and completes the digital signature on the HashedVerify message’s message hash by

applying the signature algorithm to the hash. If received, the client replaces the TLS

application header with a handshake header and forwards it to the server. The server

can verify the card issuer’s signature.

The AuditLog message is sent by the client to the card issuer when a client sends

or receives a ChangeCipherSpec message or a Finished message, provided a TLS link

is open between the card issuer and client but irrespective of whether the card issuer

232


signed the CertificateVerify message. The AuditLog message includes the triggering

message’s name (for example: Finished), the server’s IP address and the session id.

The card issuer stores the sent information, preceded by the date, the time, the

client identifier used in the AuthenticateClient step and the client’s IP address.

The message in TLS specification notation:

struct {

MessageName message name;

ServerIP server ip;

SessionID session id;

} AuditLog;

Each line of the log contains:

Date‖Time‖client id‖message name‖client ip‖server ip‖session id

Entries in the audit trail are also created when the card issuer processes an Authen-

ticateClient message or CertificateVerify message. Server ip and session id are left

blank with an entry triggered by an AuthenticateClient message.

10.5.2 Authenticating the Client

Before any TLS handshake uses the proposed extension, the cardholder’s client de-

vice initiates a TLS session with the card issuer and, once complete, the client

authenticates to the card issuer through an application protocol message(s). This

subsection cites 2FA with a chip-based payment card that is housed in an RCA de-

vice, so that the card does not make physical contact with the cardholder’s network

connected device. The method of authentication can be adapted to suit other au-

thentication mechanisms or an SSO protocol, ideally the SSO protocol proposed in

Chapter 9 which also uses a chip-based payment card for authentication. As noted

in Subsection 9.3.2.7, banks are particularly adept at identifying their customers

which involves far more background and identity checks than normally undertaken

233


by a web SP.

A chip-based payment card and an RCA device represent a portable method

of authentication that is suitable for worldwide deployment and, if used for this

proposal, in most cases would not create an extra id or password for the cardholder

to remember. As outlined in Subsection 9.4.4 of the SSO proposal, before a person

can use the extended TLS service, he or she has to apply to an issuing bank for

a payment card, an RCA device and request that the card is enrolled for the TLS

service.

Once the TLS session with the card issuer has been initiated and if the SSO

proposal is not used for authentication, the cardholder is prompted for an identifier

(not the card number, although a TCN could be used provided the number of avail-

able TCNs are not depleted through increased use. See Subsection 7.5.2). If the

identifier is known to the issuer, the identifier is mapped to a PAN and the issuer

responds with a challenge that needs to be processed through an RCA device by the

participating payment card’s chip, and the cardholder’s PIN needs to be entered.

That PIN could be the card’s financial PIN or a PIN that has been set up especially

for this service along the same lines as the SSO PIN: the TLS PIN (see Subsec-

tion 9.4.2). A relatively short period of time is allowed for authentication. When

responding, the user is asked whether a secure computer cum networked device is

being used; the card issuer could recognise a user’s usual IP address to save always

asking. If the user is not using a secure device then that TLS session only processes

one CertificateVerify operation per AuthenticateClient step; the card issuer’s cer-

tificate is not stored on the client for future use and the session id is only stored

in volatile storage, although the session with the card issuer is kept open to allow

logging to the audit trail. For a secure device, the user needs only authenticate to

the card issuer once for this TLS protocol extension: just after initiating a TLS


234


In the extended TLS protocol, the cardholder is identified and authenticated

to the card issuer and the card issuer identifies itself to the server(s) through its

digital certificate and authenticates by signing. Should the server wish to know

the identity of, or information about, the cardholder then that is for the server’s

application rather than the TLS protocol. After a TLS session has been completed,

the client can be traced through the card issuer by quoting the server’s IP address,

the TLS session id and the date when the session took place. The administrative

processes covering the disclosure of PII are beyond the scope of this thesis.

For the more critical transactions, the server is recommended to start with a

ChangeCipherSpec message. This not only changes the session secrets but also

causes an entry to be written in the card issuer’s audit trail.

The client maintains session state, to detect any session breaks on the link with

the card issuer, by executing a digitally signed applet that gets downloaded from the

card issuer and started when the cardholder authenticates. The card issuer’s certifi-

cate is typically deleted when the user’s session terminates, unless the user requests

otherwise. There should be a maximum life for any session or session resumption

with the card issuer: 24 hours would be in keeping with the TLS specifications.

10.5.3 Other Considerations

As an extension, the proposal does not need to be implemented or used; it is at

the client user’s discretion. Once the TLS session has been opened with the card is-

suer, the card issuer intercepts the TLS protocol at 4 points: the CertificateRequest,

CertificateVerify, ChangeCipherSpec and Finished messages. Other extensions im-

plemented through the ClientHello and ServerHello messages [24] continue to oper-

ate because the extended component of those messages is not affected. The Secure

Remote Password (SRP) Protocol for TLS Authentication [150], for example, is

235


triggered by a new cipher suite value and, in keeping with other new cipher suite

values, continues to be supported provided the card issuer does not block it. Indeed,

the availability of this proposal’s mechanism could be communicated by the client

to the server through a new cipher suite value, but that would restrict usability of

this extension to both configured clients and servers. This proposal is designed to

operate without requiring changes at the server end and to be potentially compatible

with older releases of TLS.

Along similar lines to the SSO proposal, future extensions beyond the proposed

TLS extension could include making certified contextual information available to

the server, for example the cardholder’s address for delivery of goods or cardholder’s

age which could be useful when the SP is offering adult content or adult services.

It could also be possible for the cardholder to instruct the card issuer to make

a payment to the merchant and be given a digitally signed receipt or payment

voucher to present to the merchant, rather than keying in payment card details

into a potentially hostile web page. The merchant could be identified by using a

concatenation of the 6-byte acquirer identifier and 15-byte merchant identifier58 [55,

Annex A1] which the merchant quotes in a request for payment that the cardholder

reviews and, if approved, forwards to the card issuer. For these additional services,

the cardholder could reauthenticate over the open TLS session with the card issuer

and again use an RCA device. This authentication evidences possession of the

payment card and knowledge of the card’s applicable PIN. The card issuer already

knows the cardholder’s payment card information.

10.5.4 Security Services

In comparison with using PKI for client authentication, this proposed extension to

TLS provides the following security service enhancements:58Also called a card acceptor number or acquirer reference number [11, Subsection 6.3.5].

236


• Authentication. In difference, this proposal requires the cardholder to authen-

ticate to the card issuer rather than the server. The card issuer then vouches for

knowing the client’s identity. This keeps the cardholder’s identification and authen-

tication data out of the server’s reach.

• Privacy. Provided the cardholder takes no counteractive action, the user can

be anonymous to the server. Only the card issuer needs to know the cardholder’s

identity. The session id is the cardholder’s pseudonym for the session and when that

session breaks the server cannot link it to other sessions other than by (potentially)

the user’s IP address (which could also leak identity if the merchant were to collude

with the cardholder’s ISP).

• Accountability. The card issuer makes an entry in its audit trail each time it au-

thenticates a client, its certificate is sent to the client, a hash is signed, a handshake

completed or the client changes it cipher specification. These user activities can be

audited and both the cardholder and server cannot repudiate any logged actions (al-

though this may strain the trust that the cardholder must have in the card issuer).

Audited events are evidence of a connection rather than evidence of an application

action within that connection.


Wagner and Schneier carried out a detailed technical analysis of the cryptographic

strength of the SSL 3.0 protocol [165] and concluded that in general SSL provides

excellent security against eavesdropping and passive attacks, but the specifications

should be updated to warn of some potential active attacks.

They added that the record layer protocol addresses the fairly standard problems

that have received much attention in cryptographic and security literature [164].

However the handshake protocol has several vulnerabilities and worrisome features,

237


but these are only troublesome when active attacks are a concern and even then are

not universal weaknesses.

TLS 1.2 has not materially changed the observations, although some concerns

have been addressed such as by moving to a standardised HMAC.

This section looks at the threats that are introduced or affected by this proposal.

10.6.1 Issuer Impersonation or Interception

An attacker could impersonate the card issuer’s server, or passively intercept traffic,

or actively intercept and forward all traffic between the card issuer’s server and the

cardholder’s client for a man-in-the-middle attack. Any captured information could

be used to the attacker’s advantage, for example: impersonating the cardholder to

web SPs.

Impersonation: This risk is mitigated by using 2FA for the cardholder, with

just a one-time challenge and a one-time response flowing between the cardholder’s

client and the card issuer’s server. However, an attacker impersonating the card

issuer’s server is unable to present a web page containing the challenge over a TLS

session that is authenticated by the card issuer being able to read the PS that has

been encrypted with the card issuer’s certified public key, and unable to complete a

CertificateVerify message; the attacker does not have use of the card issuer’s private

key(s). These anomalies should alert the user.

Interception: The TLS session between the cardholder’s client and the card

issuer’s server is configured to encrypt all application data to prevent eavesdropping.

The TLS session is also configured to protect its messages from being tampered with

or forged by adding a message sequence number and a MAC to each of its records.

238


If any message were to be altered or forged, then the TLS protocol is designed to

reject any message with suspicious content or of suspicious origin.

10.6.2 Leakage of Information

The cardholder is not identified to the web SPs’ servers by this proposed TLS exten-

sion. However, the card issuer knows its customer and the TLS connections he or

she makes using the proposed service. In the event of a dispute, this not only allows

the card issuer to evidence whether a site was visited using the proposed service, but

it also gives the card issuer an insight to the user’s browsing habits and interests.

That information could be used for other purposes.

The card issuer should meet its data protection obligations by requiring the

cardholder to opt-in to the service and consent to the parameters for processing

his or her data. This agreement is binding on the card issuer unless there is an

overriding reason to do otherwise: a court order for example.

10.6.3 Financial Exposure

One of the three cited methods of authentication is with a payment card and using

its financial PIN. Even with a challenge and response mechanism, more frequent

use of a PIN gives more occasions for disclosure or attack.

This proposal’s preferred implementation is to merge authentication with the

SSO proposal of Chapter 9. It is also possible to use a PIN just for this TLS

extension.

239



The cited methods of authentication, with a payment card, do not always withstand

lapse cardholder practices. If the card’s PIN is not kept secret and another person

who knows the PIN can make use of the card, then all TLS sessions that rely on

that authentication are attributed to the cardholder.

The cardholder agreement should cover this situation from a legal liability per-

spective; obtaining evidence to show what really happened would be difficult. This

type of weakness is true of most methods of authentication with few exceptions:

notably biometric authentication.

10.6.5 Issuer Availability

The card issuer provides a publicly-available real-time service over the Internet. The

service could fail or operate at reduced capacity for various reasons, for example a

hardware failure, a card issuer’s communications link failure or a DoS attack where

the card issuer’s finite resources are exhausted processing spurious requests from an

attacker. When unavailable, TLS sessions with the card issuer cannot be opened or

used; AuthenticateClient, CertificateVerify and AuditLog messages cannot be sent

to the card issuer for the audit trail.

The most effective control is for the card issuer to have a hot stand-by for, or

duplication of, all hardware and software components that could be a single point

of failure. Operating as a distributed service could also help alleviate choke points.

A problem at the client end stops all TLS activity and therefore solely a matter for

the cardholder. Audit trail data that cannot be sent could be buffered on the client

until the card issuer’s server is available, provided the client remains active and the

data remain in storage. The client could also warn its user.

240


10.6.6 Changing IP Address

The audit trail captures the client’s IP address and this could change mid-session.

For example, a client could open or close a VPN to another ISP during any TLS

session.

The card issuer also logs the client’s id which does not change, so changing IP

address only causes a cosmetic problem for the audit trail.

10.6.7 Data on Client and Server

TLS only protects data when they are being transported and not when they are

sitting on the client or server.

The proposal has no affect on this scope.

10.6.8 Time of Check to Time of Use

Any authentication only attests identity at that point in time. Between the card

issuer authenticating the client and the CertificateVerify message, the client’s user

may have changed. For example, this could be due to the cardholder vacating the

client and leaving the client terminal active or when an Internet Cafe session is

terminated by the session provider without giving the user time to close his or her


Both risks should be mitigated by the cardholder adopting good practices and

using the service as intended. Specifically: locking the terminal when not in use and

stating the computer cum networked device not to be secure when that is the case

241


and asked by the card issuer.

10.6.9 Incomplete Audit Trail

An audit trail entry is only created when the cardholder has opted to use the service

and remains connected to the card issuer.

If the cardholder chooses to avoid using the service, then TLS sessions during

that time are not recorded in the audit trail.

10.7 Conclusions

A portable mechanism for using a chip-based payment card to authenticate a client

during a TLS handshake has been proposed. Using this extended service is optional;

it does not replace TLS, just enhances it. All of the TLS security services associated

with mutual authentication are maintained but in addition the client is afforded

greater privacy from the server through cardholder anonymity, the use of the session

id as a pseudonym and the unlinkability of disparate sessions. However an out-

of-band action by the cardholder or card issuer could compromise the cardholder’s

privacy. The most important TLS activities are logged; making both the cardholder

and SP accountable for those links and able to evidence the use of the link should

there be a dispute.

This proposal offers an alternative to PKI, which has not reached out to support

end users in any great numbers. The proposal does not require cardholders to

go through any additional administrative steps to be identified because banks are

already required to know their customers. No form of authentication is perfect

because any authentication only validates at that point in time. The continued

242

10.7 Conclusions

strength of authentication is also dependent on other external factors, most notably

cardholder practices.

243

Part IV

Conclusions

244

Chapter 11

Conclusions and Further Research

Contents

11.1 Summary and Conclusions . . . . . . . . . . . . . . . . . . 245

11.2 Opportunities for Further Research . . . . . . . . . . . . 248

This chapter presents the overall conclusions of this thesis and suggests some

opportunities for further research.

11.1 Summary and Conclusions

This thesis looks at the security of chip-based payment cards from the cardholder’s

standpoint and researches how the cardholder’s privacy and non-repudiation inter-

ests can be served. If privacy were to mean a loss of accountability there would

be regulatory issues which would scotch the practical nature of any proposal. Also,

non-repudiation could counteract privacy. This thesis is a fine balance between

theoretical possibility and acceptability.

The main contribution of this thesis is to propose an independent and novel set

of six complementing modular solutions. One, some or all six of these can be selected

to meet the cardholder’s specific needs, whilst respecting the needs of others that

245


have a vested interest in the payment process. Most notably: the card issuers and

regulatory requirements.

The traditional CP method of payment is considered as are CNP payments, par-

ticularly Internet payments which are increasingly popular with both consumers and

criminals. From a privacy and non-repudiation perspective it is the payment account

details, any personally identifiable information and the transaction footprints that

matter. For an Internet payment the privacy and non-repudiation security services

have to be provided for the whole session, including signing-on and the protection

of information passing between the client and server end points over a potentially

insecure communications link.

CP payments take advantage of the card’s proximity; this is how chip cards are

designed to be used and make CNP payments an evident afterthought. Making any

detailed proposal requires an analysis of how data are processed. CP payments and

CNP payments need different techniques to achieve a common goal.

For enhancing the privacy properties of a payment, Chapters 5 and 7 propose

mechanisms that replace the card’s account number and the cardholder’s name with

just a temporary number that the card issuer can match to the cardholder. From

a payment perspective, at and after the point of payment only the card issuer and

cardholder know who made a given payment and only they can link that payment

to the cardholder’s other payments. The main transaction flow is not affected, such

as cardholder verification and the authentication of the card’s data. Chapter 5

proposes a mechanism for CP payments and Chapter 7 proposes a mechanism for

CNP payments. The payment card is an active participant in a CP payment and

a passive participant in a CNP payment; these different approaches to involvement

do not lend themselves to a single solution.

Non-repudiation requires a different mechanism and again one proposal is for

246

11.1 Summary and Conclusions

CP payments and one is for CNP payments. For CP payments, Chapter 6 proposes

leaving one of three types of cryptographic mark on the payment card’s chip for the

most recent payments. Each mechanism has it merits making the choice a balance

of: usability for the cardholder, cardholder privacy, point of processing overhead

and storage space on the chip. Leaving a cryptographic mark on a card’s chip for a

CNP payment is difficult, hence Chapter 8 takes a different tack by using a TTP to

store the evidence of participation: finger minutiae, a frequently used biometric.

CNP payments are a particular challenge and also need any sign-on to the mer-

chant and the connection between the cardholder and merchant to preserve the

cardholder’s privacy and non-repudiation security properties: session authentica-

tion is of particular interest. Chapters 9 and 10 propose an SSO mechanism and

an extension to the widely-used TLS protocol to provide client authentication for

both proposals with a payment card. These proposals draw on the thorough regis-

tration process that card issuers have to undertake before they issue a person with

a payment card. Although there is no direct benefit to the card issuers in providing

this service, it does represent an opportunity for the card issuer to offer a value-

added and complementary service that is intended to give competitive advantage

and increase the use of revenue-earning banking services.

When put together, these proposals provide privacy, non-repudiation and other

associated security services that are primarily of benefit to the cardholder, but also

bring benefit to the other entities in the payment process. All of the mechanisms have

been designed as add-ons that do not affect the operation of the underlying payment

process or computer protocols. It is the card issuers that bear the brunt of losses

from card fraud for which the cardholder or merchant cannot be held responsible.

Any mechanism that enhances cardholder accountability should help stem the card

issuers’ losses.

247


11.2 Opportunities for Further Research

The more one researches payment card infrastructures, opportunities to provide

further support for the cardholders’ interests emerge. Further research could include:

• Removing the need to keep a PIN secret when typing it into a public PIN entry

device by having the cardholder use an RCA device and card to influence,

calculate and display a temporary PIN number. That allocation could include

restrictions, such as a maximum transaction value or period of validity. The

cardholder could either use the RCA device when standing next to the PIN

entry device or request a number in advance and remember it. Other side-uses

include the ability to delegate ATM withdrawals to a third party and contain

the risk that it would otherwise pose.

• Researching an automated non-repudiation service that holds Internet pay-

ments in escrow pending the completion of a transaction. The service could

be provided by any TTP that is independent of, and acceptable to, both the

cardholder and merchant. Payment is made to the TTP at the point of con-

tract and the funds released to the merchant once the contract completes.

The agent that delivers the physical goods or otherwise monitors for the fund

release criteria being reached triggers the payment to the merchant. This

could offer cardholder privacy with respect to the merchant because the TTP

rather than the merchant needs to know how the purchase is funded and could

potentially liaise with the entity that delivers any physical goods.

• Identifying non-payment applications where entity authentication is important

and authenticating the user is problematic, for example: electronic voting.

Payment cards are an evolving technology with chip cards not yet fully deployed,

most notably the United States still has to adopt the otherwise widely-used EMV

248

11.2 Opportunities for Further Research

specification payment cards. The EMV specifications are not using the most ad-

vanced cryptography; they are a DES, SHA-1 and RSA based solution. The spec-

ifications will change and the existing specifications will be stretched to fit new

technologies. Contact-less cards with built-in RCA devices are likely near-future

developments. This and other developments open a whole swathe of opportunities

for research.

Finally, none of the mechanisms proposed in this thesis has been the subject of

a test implementation. Testing requires specialised facilities and, for most mech-

anisms, logical changes to protected areas of the card’s chip and the card issuer’s

RCA device. Although testing would not give complete assurance for the proposals,

it would quantify the ease of implementation and help identify any areas that a

theoretical review could not see.

249

Bibliography

[1] Carlisle Adams and Steve Lloyd. Understanding PKI: Concepts, Standards,

and Deployment Considerations. Addison-Wesley, 2nd edition, November 2002.

ISBN: 978-0672323911.

[2] Admon ehf. Implementation of PKI Iceland (PKI-IS). Press release, Admon,

November 2008. http://www.admon.is/userfiles/PKI%20Iceland.pdf,

accessed on 10th August 2009.

[3] American National Standards Institute. ANSI X9.52:1998. Triple Data En-

cryption Algorithm Modes of Operation. ANSI, 1998.

[4] Ross J. Anderson. Why cryptosystems fail. Communications of the ACM

(CACM), 37(11):32–40, November 1994.

[5] Ross J. Anderson. Security Engineering: A Guide to Building Dependable

Distributed Systems. John Wiley and Sons, Inc., 2nd edition, April 2008. ISBN:

978-0470068526.

[6] Ross J. Anderson, Mike Bond, and Steven Murdoch. Chip and spin. Computer

Security Journal, 22(2):1–6, 2006.

[7] Andrews & Arnold Ltd. Application to work as Barclays PINSentry card

reader. http://aa.gg/free/barclays-pinsentry.c, accessed on 29th April

2009, 2006.

250

[8] APACS Administration Ltd. Plastic cards in the UK and how we used them

in 2007. Key facts and figures, APACS, 2008. http://www.apacs.org.uk/

resources_pu blications/card_facts_and_figures.html, accessed on 10th

March 2009.

[9] APACS Administration Ltd. 2008 fraud figures announced by APACS. Press

release, APACS, March 2009. http://www.apacs.org.uk/09_03_19.htm, ac-

cessed on 12th August 2009.

[10] APACS Administration Ltd. Standard 70 – Book 1. Card Acceptor to Acquirer

Interface Standards. Business Rules for Card Processing. APACS, April 2009.


Interface Standards. Messages, Data Elements and Code Values for Real-time

Systems. APACS, April 2009.


Interface Standards. Messages, Data Elements and Code Values for Post-event

Systems. APACS, April 2009.


Interface Standards. Communications. APACS, April 2009.


Interface Standards. Security and Key Management. APACS, April 2009.


Interface Standards. Data Port Interface. APACS, April 2009.


Interface Standards. Terminal Identities. APACS, April 2009.

[17] Patroklos G. Argyroudis, Raja Verma, Hitesh Tewari, and Donal O’Mahony.

Performance analysis of cryptographic protocols on handheld devices. In Pro-

ceedings of the 3rd IEEE International Symposium on Network Computing

251

and Applications (NCA 2004), pages 169–174. IEEE, NJ, USA, August 2004.

ISBN: 0-7695-2242-4.

[18] Mohammed Assora, James Kadirire, and Ayoub Shirvani. A Web transac-

tion security scheme based on disposable credit card numbers. International

Journal of Electronic Security and Digital Forensics (IJESDF), 1(2):146–155,

January 2007.

[19] BBC News. Operation Ore: Can the UK cope? http://news.bbc.co.uk/1/

hi/uk/2652465.stm, accessed on 10th March 2009, January 2003.

[20] Giampaolo Bella and Lawrence C. Paulson. Accountability protocols: For-

malized and verified. ACM Transactions on Information and System Security

(TISSEC), 9(2):138–161, May 2006.

[21] Edward Bellamy. Looking Backward: 2000-1887. Signet Classics, 1888. ISBN:

978-0451527639, reprinted in 2000.

[22] Mihir Bellare, Ran Canetti, and Hugo Krawczyk. Keying hash functions for

message authentication. In Neal Koblitz, editor, Advances in Cryptology. Pro-

ceedings of the 16th Annual International Cryptology Conference (CRYPTO

’96), volume 1109, pages 1–15. Springer-Verlag, LNCS, August 1996. ISBN:

978-3540615125.

[23] Bharat Book Bureau. Premium company profile: Citigroup Inc. http://www.

bharatbook.com/productdetail.asp?id=76020, accessed on 8th September

2009, February 2008.

[24] Simon Blake-Wilson, Magnus Nystrom, David Hopwood, Jan Mikkelsen, and

Tim Wright. RFC 4366 – Transport layer security (TLS) extensions. Internet

Engineering Task Force, April 2006.

252

[25] Nicholas Bohm, Ian Brown, and Brian Gladman. Electronic commerce: Who

carries the risk of fraud? The Journal of Information, Law and Technology

(JILT), issue 3, October 2000.

[26] Mike Bond and Piotr Zielinski. Decimalisation table attacks for PIN crack-

ing. Technical report UCAM-CL-TR-560, University of Cambridge Computer

Laboratory, February 2003.

[27] David J. Boyd. Enhancing the non-repudiation properties of EMV payment

cards. In Sanjay Goel, editor, Proceedings of the 3rd Annual Symposium on

Information Assurance (ASIA ’08): The Academic Track of the 11th Annual

New York State Cyber Security Conference, pages 63–70, June 2008.

[28] David J. Boyd. Enhancing the non-repudiation properties of Internet pay-

ments through a third dimension. In Kamel Adi, Mourad Debbabi, and Luigi

Logrippo, editors, Proceedings of the 2nd Workshop on Practice and Theory of

IT Security (PTITS 2008), pages 33–39, January 2008.

[29] David J. Boyd. Single sign-on to the Web with an EMV card. In Waleed W.

Smari and William McQuay, editors, Proceedings of the 2008 International

Symposium on Collaborative Technologies and Systems (CTS 2008), pages

112–120. IEEE, NJ, USA, May 2008. ISBN: 978-1424422487.

[30] David J. Boyd. Towards a private and anonymous EMV payment application.

In John Haggerty and Madjid Merabti, editors, Proceedings of the 3rd Confer-

ence on Advances in Computer Security and Forensics (ACSF 2008), pages

53–59, July 2008. ISBN: 978-1902560205.

[31] David J. Boyd. A pragmatic approach to temporary payment card numbers.

International Journal of Electronic Security and Digital Forensics (IJESDF),

2(3):253–268, July 2009.

253

[32] David J. Boyd. TLS client handshake with a payment card. In Proceedings

of the 23rd IEEE International Parallel and Distributed Processing Symposium

(IPDPS 2009). IEEE, NJ, USA, May 2009. ISBN: 978-1424437504.

[33] David Chaum. The dining cryptographers problem: Unconditional sender and

recipient untraceability. Journal of Cryptology, 1(1):65–75, March 1988.

[34] David Chaum. Achieving electronic privacy. Scientific American, pages 96–

101, August 1992.

[35] CitiGroup Inc. Citi® identity theft solutions. https://www.citicards.com/

cards/wv/detail.do?screenID=700, accessed on 18th March 2009.

[36] David D. Clark and David R. Wilson. A comparison of commercial and mili-

tary computer security policies. In Proceedings of the 1987 IEEE Symposium

on Security and Privacy (S&P ’87), pages 184–194. IEEE, NJ, USA, April

1987.

[37] Donald S. Clark. In the matter of The TJX Companies, Inc., a corporation.

Complaint C-4227, United States of America Federal Trade Commission, July

2008. http://www.ftc.gov/os/caselist/0723055/080801tjxcomplaint.

pdf, accessed on 20th August 2009.

[38] Roger Clarke. The Mondex value-card scheme. A mid-term report. Chip-Based

Payment Schemes: Stored-Value Cards and Beyond, September 1996.

[39] Sebastian Claußand Stefan Schiffner. Structuring anonymity metrics. In Pro-

ceedings of the 2nd ACM workshop on Digital Identity Management (DIM ’06),

pages 55–62. ACM, New York, NY, USA, November 2006. ISBN: 1-595935479.

[40] Eric K. Clemons, David C. Croson, and Bruce W. Weber. Reengineering

money: The Mondex stored value card and beyond. In Proceedings of the 29th

Annual Hawaii International Conference on System Sciences (HICSS 1996),

volume 4, pages 254–261. IEEE, CA, USA, January 1996. ISBN: 0-818673249.

254

[41] Computing. Halifax wins legal ruling on chip-and-PIN security.

http://www.computing.co.uk/computing/news/2243596/judge-rules-fa

vour-halifax-atm, accessed on 12th August 2009, June 2009.

[42] Council of Europe. Convention for the Protection of Human Rights and Fun-

damental Freedoms as Amended by Protocol No11. Registry of the European

Court of Human Rights, September 2003.

[43] Defense Advanced Research Projects Agency. RFC 793 – Transmission control

protocol. Internet Engineering Task Force, September 1981.

[44] Tim Dierks and Christopher Allen. RFC 2246 – The TLS protocol. Version

1.0. Internet Engineering Task Force, January 1999.

[45] Tim Dierks and Eric Rescorla. RFC 5246 – The transport layer security (TLS)

protocol – Version 1.2. Internet Engineering Task Force, August 2008.

[46] Whitfield Diffie and Martin E. Hellman. New directions in cryptography. IEEE

Transactions on Information Theory, 22(6):644–654, November 1976.

[47] Saar Drimer and Steven Murdoch. Keep your enemies close: Distance bound-

ing against smart card relay attacks. In Proceedings of the 16th USENIX

Security Symposium (Security ’07). USENIX Association, August 2007.

[48] Saar Drimer, Steven J. Murdoch, and Ross J. Anderson. Optimised to fail:

Card readers for online banking. In R. Dingledine and P. Golle, editors,

Financial Cryptography and Data Security. Proceedings of the 13th Interna-

tional Conference on Financial Cryptography and Data Security (FC09), vol-

ume 5628, pages 184–200. Springer-Verlag, LNCS, July 2009. ISBN: 978-

3642035487.

[49] Wesley M. Eddy. RFC 4987 – TCP SYN flooding attacks and common miti-

gations. Internet Engineering Task Force, August 2007.

255

[50] EMVCo LLC. Integrated Circuit Card, Specifications for Payment Systems.

Version 4.1. Book 2 – Security and Key Management. EMV, May 2004.

[51] EMVCo LLC. Specification Update Bulletin No19. EMV, May 2004.

[52] EMVCo LLC. EMV Card Personalization Specification. Version 1.1. EMV,

July 2007.


Version 4.2. Book 1 – Application Independent ICC to Terminal Interface

Requirements. EMV, June 2008.


Version 4.2. Book 2 – Security and Key Management. EMV, June 2008.


Version 4.2. Book 3 – Application Specification. EMV, June 2008.


Version 4.2. Book 4 – Cardholder, Attendant, and Acquirer Interface Require-

ments. EMV, June 2008.

[57] Encyclopædia Britannica Inc. Encyclopædia Britannica. Encyclopædia Bri-

tannica (UK) Ltd., revised 2007. ISBN: 978-1593392925.

[58] EURO Kartensysteme GmbH. Answers to some frequently asked questions on

GeldKarte. http://www.geldkarte.de/_www/en/pub/geldkarte/service_

navigation/faq.php, accessed on 11th March 2009.

[59] EURO Kartensysteme GmbH. GeldKarte home page (English). http://www.

geldkarte.de/_www/en/pub/geldkarte/geldkarte_users.php, accessed on

11th March 2009.

[60] EURO Kartensysteme GmbH. Paying online with your GeldKarte. Secure

Internet payments. http://www.geldkarte.de/_www/en/pub/geldkarte/

geldkarte_users/paying/internet.php, accessed on 11th March 2009.

256

[61] European Committee for Banking Standards. Overview of European electronic

purse products. Technical report TR102. Version 4.0, September 2003.

[62] The European Parliament and the Council of the European Union. Directive

95/46/EC: The Protection of Individuals with Regard to the Processing of

Personal Data and on the Free Movement of Such Data. The Official Journal

of the European Union, October 1995.

[63] The European Parliament and the Council of the European Union. Directive

2005/60/EC: Third EU Money Laundering Directive. The Official Journal of

the European Union, October 2005.

[64] Uriel Feige, Amos Fiat, and Adi Shamir. Zero knowledge proofs of identity.

In Proceedings of the 19th Annual ACM Symposium on Theory of Computing

(STOC 1987), pages 210–217. ACM, New York, NY, USA, May 1987. ISBN:

978-0897912211.

[65] Finextra Research. MasterCard passes 300 million mark for EMV cards

shipped. http://www.finextra.com/fullpr.asp?id=20267, accessed on 12th

March 2009, March 2008.

[66] Riccardo Focardi, Flaminia L. Luccio, and Graham Steel. Blunting differential

attacks on PIN processing APIs. In Proceedings of the 14th Nordic Conference

on Secure IT Systems. Springer-Verlag, LNCS, October 2009. To appear.

[67] Ed Gerck. Overview of certification systems: X.509, CA, PGP and SKIP. In

The Black Hat Briefings ’99, July 1999.

[68] Dieter Gollmann. Computer Security. John Wiley and Sons, Inc., July 2003.

ISBN: 0-471978442.

[69] The Guardian. Operation Ore flawed by fraud. http://www.guardian.co.

uk/technology/2007/apr/19/hitechcrime.money, accessed on 12th March

2009, April 2007.

257

[70] Halifax (Bank of Scotland plc.). Chip and PIN - everything you need to

know. http://www.halifax.co.uk/creditcards/chipandpinfaqs.asp, ac-

cessed on 12th August 2009, 2009.

[71] Edward R. Henry. Classification and Uses of Finger Prints. George Routledge

and Sons, Ltd., London, 1900.

[72] Kipp E. B. Hickman. The SSL protocol. Netscape Standards Documentation,

February 1995.

[73] HSBC Bank plc. Card security. http://www.hsbc.co.uk/1/2/personal/cre

dit-cards/security;jsessionid=0000IMhpgi1JbxaKM1za3MgSjzb:11j74l

ld0, accessed on 12th August 2009, 2009.

[74] The Independent. No evidence against man in child porn inquiry who “killed

himself”. http://www.independent.co.uk/news/uk/crime/no-evidence-a

gainst-man-in-child-porn-inquiry-who-killed-himself-509120.html,

accessed on 12th March 2009, October 2005.

[75] The International Bar Association (IBA), Anti-Money Laundering Forum.

The lawyer’s guide to legislation and compliance – Africa – Equatorial

Guinea. http://www.anti-moneylaundering.org/africa/Equatorial_Gui

nea.aspx, accessed on 12th March 2009, February 2007.

[76] International Business Machines Corporation (IBM). Product block cipher

system for data security. US Patent 3962539, US Patent and Trademark Office,

June 1976.

[77] International Business Machines Corporation (IBM). Message verification and

transmission error detection by block chaining. US Patent 4074066, US Patent

and Trademark Office, February 1978.

[78] International Business Machines Corporation (IBM). z/OS V1R9.0-V1R10.0.

Cryptographic Services. ICSF Overview. SA22-7519-09. IBM, September 2007.

258

[79] International Organization for Standardization. ISO 7498-2:1989. Information

Processing Systems – Open Systems Interconnection – Basic Reference Model

– Part 2: Security Architecture. ISO, February 1989.

[80] International Organization for Standardization. ISO 9564-1:2002. Banking

– Personal Identification Number (PIN) Management and Security – Part 1:

Basic Principles and Requirements for Online PIN Handling in ATM and POS

Systems. ISO, May 2002.

[81] International Organization for Standardization. ISO 9564-3:2003. Banking –

Personal Identification Number Management and Security – Part 3: Require-

ments for Offline PIN Handling in ATM and POS Systems. ISO, November

2003.

[82] International Organization for Standardization. ISO 16609:2004. Banking –

Requirements for Message Authentication Using Symmetric Techniques. ISO,

February 2004.

[83] International Organization for Standardization. ISO/TR 9564-4:2004. Bank-

ing – Personal Identification Number (PIN) Management and Security – Part

4: Guidelines for PIN Handling in Open Networks. ISO, March 2004.

[84] International Organization for Standardization and International Electrotech-

nical Commission. ISO/IEC 10181-4:1997. Information Technology – Open

Systems Interconnection – Security Frameworks for Open Systems: Non-

Repudiation Framework. ISO and IEC, April 1997.


nical Commission. ISO/IEC 13888-3:1997. Information technology – Security

techniques – Non-repudiation – Part 3: Mechanisms using asymmetric tech-

niques. ISO and IEC, November 1997.

259


nical Commission. ISO/IEC 9798-1:1997. Information Technology – Security

Techniques – Entity Authentication – Part 1: General. ISO and IEC, July

1997.


nical Commission. ISO/IEC 13888-2:1998. Information technology – Security

techniques – Non-repudiation – Part 2: Mechanisms using symmetric tech-

niques. ISO and IEC, April 1998.



Techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms

Using a Block Cipher. ISO and IEC, December 1999.



Techniques – Digital Signature Schemes Giving Message Recovery – Part 2:

Integer Factorization Based Mechanisms. ISO and IEC, October 2002.



Techniques – Message Authentication Codes (MACs) – Part 2: Mechanisms

Using a Dedicated Hash-Function. ISO and IEC, June 2002.


nical Commission. ISO/IEC 13888-1:2004. IT security techniques – Non-

repudiation – Part 1: General. ISO and IEC, June 2004.


nical Commission. ISO/IEC 18031:2005. Information Technology – Security

Techniques – Random Bit Generation. ISO and IEC, November 2005.

260


nical Commission. ISO/IEC 19794-2:2005. Information Technology – Biomet-

ric Data Interchange Formats – Part 2: Finger Minutiae Data. ISO and IEC,

September 2005.


nical Commission. ISO/IEC 7816-4:2005. Identification Cards – Integrated

Circuit Cards – Part 4: Organization, Security and Commands for Inter-

change. ISO and IEC, January 2005.



Techniques – Digital Signatures with Appendix – Part 3: Discrete Logarithm

Based Mechanisms. ISO and IEC, November 2006.


nical Commission. ISO/IEC 7812-1:2006. Identification Cards – Identification

of Issuers – Part 1: Numbering System. ISO and IEC, October 2006.


nical Commission. ISO/IEC 7813:2006. Information Technology – Identifica-

tion Cards – Financial Transaction Cards. ISO and IEC, June 2006.



Techniques – Digital Signature Schemes Giving Message Recovery – Part 3:

Discrete Logarithm Based Mechanisms. ISO and IEC, September 2006.



Techniques – Digital Signatures with Appendix – Part 1: General. ISO and

IEC, April 2008.

261



Techniques – Digital Signatures with Appendix – Part 2: Integer Factorization

Based Mechanisms. ISO and IEC, April 2008.



Techniques – Evaluation Criteria for IT Security – Part 2: Security Functional

Components. ISO and IEC, August 2008.


nical Commission. ISO/IEC 19794. Information Technology – Biometric Data

Interchange Formats – Parts 1-10. ISO and IEC, various dates.

[103] International Telecommunication Union. ITU Recommendation X.509. Infor-

mation technology – Open Systems Interconnection – The Directory: Public-

key and attribute certificate frameworks. ITU, November 2008.

[104] Yukio Itakura, Masaki Hashiyada, Toshio Nagashima, and Shigeo Tsujii. Pro-

posal on personal identifiers generated from the STR information of DNA.

International Journal of Information Security, 1(3):149–160, November 2002.

[105] Blake Ives and Michael Earl. Mondex International: Reengineering money.

Case Study CRIM CS97/2, London Business School, 1997.

[106] Auguste Kerckhoff. La cryptographie militaire. Journal des Sciences Mili-

taires, IX:5–38 and 161–191, January and February 1883.

[107] Hugo Krawczyk. The order of encryption and authentication for protecting

communications (or: How secure is SSL?). In Joe Kilian, editor, Advances in

Cryptology. Proceedings of the 21st Annual International Cryptology Confer-

ence (CRYPTO 2001), volume 2139, pages 310–331. Springer-Verlag, LNCS,

August 2001. ISBN: 978-3-540-42456-7.

262

[108] Hugo Krawczyk, Mihir Bellare, and Ran Canetti. RFC 2104 – HMAC: Keyed-

hashing for message authentication. Internet Engineering Task Force, February

1997.

[109] Yingjiu Li and Xinwen Zhang. Securing credit card transactions with one-time

payment scheme. Elsevier. Science Direct. Electronic Commerce Research and

Applications, 4(4):413–426, Winter 2005.

[110] Liberty Alliance Project. Strong authentication. http://www.projectlib

erty.org/liberty/strategic_initiatives/strong_authentication, ac-

cessed on 12th March 2009, 2005.

[111] John Linn. RFC 1421 – Privacy enhancement for Internet electronic mail: Part

I – Message encryption and authentication procedures. Internet Engineering

Task Force, February 1993.

[112] Javier Lopez, Rolf Oppliger, and Gunther Pernul. Why have public key infras-

tructures failed so far? Internet Research: Electronic Networking Applications

and Policy, 15(5):544–556, 2005.

[113] Hans P. Luhn. Computer for verifying numbers. US Patent 2950048, US

Patent and Trademark Office, August 1960.

[114] Olivier Markowitch, Dieter Gollmann, and Steve Kremer. On fairness in ex-

change protocols. In Pil Joong Lee and Chae Hoon Lim, editors, Information

Security and Cryptology. Proceedings of the 5th International Conference on

Information Security and Cryptology (ICISC 2002), volume 2587, pages 451–

464. Springer-Verlag, LNCS, November 2002. ISBN: 978-3540007166.

[115] The Metropolitan Police. Fraud alert - ATM (cash machine) fraud. http://

www.met.police.uk/fraudalert/section/atm_fraud.htm, accessed on 20th

August 2009, 2009.

263

[116] David L. Mills. RFC 1305 – Network time protocol (version 3). Specification,

implementation and analysis. Internet Engineering Task Force, March 1992.

[117] Atsuko Miyaji. Another countermeasure to forgeries over message recovery

signature. IEICE Transactions on Fundamentals of Electronics, Communica-

tions and Computer Sciences, E80-A(11):2192–2200, November 1997.

[118] National Biometric Security Project. 2007 annual report on the state

of biometric standards. http://www.nationalbiometric.org/docs/2007_

annual_report_on_the_state_of_biometric_standards.pdf, accessed on

12th March 2009, April 2007.

[119] National Biometric Security Project. Published standards relevant to bio-

metrics. http://biometricsinternational.org/downloads/documents/

publishedstandards.pdf, accessed on 12th March 2009, August 2008.

[120] National Institute of Standards and Technology (NIST). Cryptographic al-

gorithm validation program (CAVP). http://csrc.nist.gov/groups/STM/

cavp/index.html, accessed on 18th March 2009.

[121] National Institute of Standards and Technology (NIST). Federal Information

Processing Standards (FIPS) Publication 46-3 – Reaffirmed – Data Encryption

Standard (DES). NIST, October 1999.


Processing Standards (FIPS) Publication 180-3 – Secure Hash Standard (SHS).

NIST, October 2008.


Processing Standards (FIPS) Publication 198-1 – The Keyed-Hash Message

Authentication Code (HMAC). NIST, July 2008.

264

[124] The New York Times. Credit card processor says some data was stolen. http:

//www.nytimes.com/2009/01/21/technology/21breach.html, accessed on

20th August 2009, January 2009.

[125] Kaisa Nyberg and Rainer A. Rueppel. Message recovery for signature schemes

based on the discrete logarithm problem. Designs, Codes and Cryptography,

7(1-2):61–81, January 1996.

[126] Orbiscom Ltd. Do “virtual” card numbers represent a growing market?

Press release, Orbiscom, September 2006. http://www.orbiscom.com/

presscentre.php?presssection=news51, accessed on 10th March 2009.

[127] Oxford University Press. The Oxford English Dictionary. Clarendon Press,

2nd edition, March 1989. ISBN: 978-0198611868.

[128] Andreas Pashalidis and Chris Mitchell. Using EMV cards for single sign-on. In

Sokratis K Katsikas, Stefanos Gritzalis, and Javier Lopez, editors, Public Key

Infrastructure. Proceedings of the 1st European PKIWorkshop: Research and

Applications. (EuroPKI 2004), volume 3093, pages 205–217. Springer-Verlag,

LNCS, June 2004. ISBN: 978-3-540-22216-3.

[129] PayLife Bank GmbH. Quick wertkarten. http://www.quick.at/plb/open

cms/de/Home/Ueber_Quick/Karten_mit_Quick_Funktion/Quick-Wertkart

en/index.html, accessed on 13th March 2009.

[130] Payment Card Industry Security Standards Council LLC. Payment Card In-

dustry (PCI) – Data Security Standard, version 1.2. PCI-SSC, October 2008.

[131] PayPal, Inc. Name-Value Pair API Developer Guide. PayPal, November

2008. https://cms.paypal.com/cms_content/US/en_US/files/developer

/PP_NVPAPI_DeveloperGuide.pdf, accessed on 13th March 2009.

[132] Andreas Pfitzmann and Marit Hansen. Anonymity, unlinkability, undetectabil-

ity, unobservability, pseudonymity, and identity management – A consolidated

265

proposal for terminology (version 31). Technical report, Dresden University

of Technology, February 2008. http://dud.inf.tu-dresden.de/literatur/

Anon_Terminology_v0.31.doc, accessed on 13th March 2009.

[133] Andreas Pfitzmann and Marit Kohntopp. Anonymity, unobservability, and

pseudonymity – A proposal for terminology (version 8). In Hannes Feder-

rath, editor, Designing Privacy Enhancing Technologies. Proceedings of the

International Workshop on Design Issues in Anonymity and Unobservability.

(2000), volume 2009, pages 1–9. Springer-Verlag, LNCS, July 2000. ISBN:

978-3540417249.

[134] Porvoo Group. International Porvoo Group seminar in Reykjavik, 26-

27 May 2005: Developing electronic identity is a pan-European challenge.

Press release, Population Register Centre, June 2005. http://porvoo7.

fjarmalaraduneyti.is/media/Porvoo7/PRESS_RELEASE_Porvoo7.doc, ac-

cessed on 10th August 2009.

[135] Privacy International. Mondex decision letter (from Office of Fair Trad-

ing). http://www.pi.greennet.org.uk/issues/mondex/mondex_response.

html, accessed on 13th March 2009, June 1996.

[136] Daniele Quercia and Stephen Hailes. MOTET: Mobile transactions using elec-

tronic tickets. In Proceedings of the 1st IEEE/CreateNet International Confer-

ence on Security and Privacy for Emerging Areas in Communication Networks

series. (SecureComm 2005), pages 374–383. IEEE, NJ, USA, September 2005.

ISBN: 978-0769523699.

[137] Eric Rescorla. RFC 2631 – Diffie-Hellman key agreement method. Internet

Engineering Task Force, June 1999.

[138] Ron Rivest. RC4 source code. Cyberpunks Anonymous Mailing, September

1994. http://cypherpunks.venona.com/date/1994/09/msg00304.html, ac-

cessed on 17th July 2008.

266

[139] Ron Rivest, Adi Shamir, and Len Adleman. A method for obtaining digi-

tal signatures and public-key cryptosystems. Communications of the ACM

(CACM), 21(2):120–126, February 1978.

[140] Ron L. Rivest, Adi Shamir, and Len M. Adleman. RSA cryptographic al-

gorithm. US Patent 4405829, US Patent and Trademark Office, December

1977.

[141] Ronald L. Rivest and Burt Kaliski. Encyclopedia of Cryptography and Security:

RSA Problem, pages 532–536. Springer-Verlag Inc., Secaucus, NJ, USA, 1st

edition, August 2005. ISBN: 978-0387234731.

[142] RSA Laboratories. DES challenge III. Questions and answers, RSA, January

1999. http://www.rsa.com/rsalabs/node.asp?id=2112, accessed on 13th

March 2009.

[143] RSA Security. Isracard partners with Cyota to eliminate online fraud. Press

release, RSA, August 2000. http://www.rsa.com/press_release.aspx?id=

6834, accessed on 13th March 2009.

[144] RSA Security. RSA security to acquire Cyota; creates leading provider of

layered authentication solutions. Press release, RSA, December 2005. http://

www.rsa.com/press_release.aspx?id=6316, accessed on 13th March 2009.

[145] Aviel D. Rubin and Rebecca N. Wright. Off-line generation of limited-use

credit card numbers. In Paul F Syverson, editor, Financial Cryptography.

Proceedings of the 5th International Conference on Financial Cryptography

(FC01), volume 2339, pages 196–209. Springer-Verlag, LNCS, February 2001.

ISBN: 978-3540440796.

[146] Bruce Schneier and John Kelsey. Cryptographic support for secure logs on

untrusted machines. In The 7th USENIX Security Symposium Proceedings,

267

pages 53–62. USENIX Press, Berkeley, CA, USA, January 1998. ISBN: 978-

1880446928.

[147] The Senate and House of Representatives of the United States of America

in Congress. H. R. 3162: Uniting and Strengthening America by Providing

Appropriate Tools Required to Intercept and Obstruct Terrorism Act (USA

PATRIOT ACT) (2001). Federal Register, October 2001.

[148] Adi Shamir. SecureClick: a Web payment system with disposable credit card

numbers. In Paul F Syverson, editor, Financial Cryptography. Proceedings

of the 5th International Conference on Financial Cryptography (FC01), vol-

ume 2339, pages 232–242. Springer-Verlag, LNCS, February 2001. ISBN: 978-

3540440796.

[149] Silicon.com. Shell’s £1m chip and PIN fraud ‘an inside job’. http://www.si

licon.com/research/specialreports/idmanagement/0,3800011361,3915

8743,00.htm, accessed on 20th August 2009, May 2006.

[150] David Taylor, Tom Wu, Nikos Mavrogiannopoulos, and Trevor Perrin. RFC

5054 – Using the secure remote password (SRP) protocol for TLS authentica-

tion. Internet Engineering Task Force, November 2007.

[151] The Telegraph. Chip and pin scam ‘has netted millions from British shoppers’.

http://www.telegraph.co.uk/news/newstopics/politics/lawandorder/

3173346/Chip-and-pin-scam-has-netted-millions-from-British-shop

pers.html, accessed on 20th August 2009, October 2008.

[152] UK Act of Parliament. Trade Descriptions Act (1968). The Stationery Office

Limited, May 1968.

[153] UK Act of Parliament. Data Protection Act (1998). The Stationery Office

Limited, July 1998.

268

[154] UK Act of Parliament. Human Rights Act (1998). The Stationery Office

Limited, November 1998.

[155] UK Statutory Instrument. Statutory Instrument No2157: The Money Laun-

dering Regulations (2007). The Stationery Office Limited, December 2007.

[156] Population Division of the Department of Economic and Social Affairs of the

United Nations Secretariat. World population prospects: The 2008 revision.

Highlights. United Nations, 2009. http://www.un.org/esa/population/

publications/wpp2008/wpp2008_text_tables.pdf, accessed on 18th March

2009.

[157] VeriSign. Maximizing site visitor trust using extended validation SSL. White

paper, VeriSign Inc, February 2007. https://www.verisign.com/static/

DEV040122.pdf, accessed on 4th September 2009.

[158] Visa Europe. Dynamic passcode authentication. overview guide. http://www.

visaeurope.com/documents/merchant/dynamicpasscodeauthentication.

pdf, accessed on 13th March 2009, 2006.

[159] Visa Europe. Visa’s innovative PIN card pilot brings step change to tackling

CNP fraud. News release, Visa, June 2008. http://www.visaeurope.com/

pressandmedia/newsreleases/press363_pressreleases.jsp, accessed on

13th March 2009.

[160] Visa Inc. Payment Card Industry: PIN Security Requirements. Version

2.0. Visa, January 2008. https://partnernetwork.visa.com/vpn/global/

retrieve_document.do?documentRetrievalId=322, accessed on 13th March

2009.

[161] Visa International Service Association. Common Personalization – Technical

Requirements for Visa Smart Debit and Credit (VSDC). Version 1.3.1. Visa,

May 2004.

269

[162] Visa International Service Association. Transaction Acceptance Device Guide.

Version 1.0. Visa, September 2008. https://partnernetwork.visa.com/vpn

/global/retrieve_document.do?documentRetrievalId=10174, accessed on

13th March 2009.

[163] Visa International Service Association. Visa approved, Visa smart debit credit

(VSDC) chip cards. https://partnernetwork.visa.com/vpn/global/retr

ieve_document.do?documentRetrievalId=69, accessed on 13th March 2009,

March 2009.

[164] Victor L. Voydock and Stephen T. Kent. Security mechanisms in high-level

network protocols. ACM Computing Surveys, 15(2):135–171, June 1983.

[165] David Wagner and Bruce Schneier. Analysis of the SSL 3.0 protocol. In

Doug Tygar, editor, Proceedings of the 2nd USENIX Workshop on Electronic

Commerce, pages 29–40. USENIX Association, November 1996. ISBN: 978-

1880446836.

[166] John D. Woodward, Katharine W. Webb, Elaine M. Newton, Melissa A.

Bradley, and David Rubenson. Army Biometric Applications: Identifying

and Addressing Sociocultural Concerns. Rand Arroyo Center, 2001. ISBN:

0-833029851.

[167] WorldPay Ltd. Submitting Transactions in the Redirect Model. Version 1.

WorldPay, 2007. http://www.worldpay.com/support/kb/pdf/rhtml.pdf,

accessed on 13th March 2009.

[168] Jianying Zhou and Dieter Gollmann. A fair non-repudiation protocol. In

Proceedings of the 1996 IEEE Symposium on Security and Privacy (S&P ’96),

pages 55–61. IEEE, NJ, USA, May 1996. ISBN: 0-818674172.

270

e-payments: cardholder privacy and non-repudiation · number of fraudulent payments made with falsi...

Documents