[Clips] Contactless payments and the security challenges

[R.A. Hettinga]

--- begin forwarded text


 Delivered-To: [EMAIL PROTECTED]
 Date: Sun, 18 Sep 2005 10:39:58 -0400
 To: Philodox Clips List <[EMAIL PROTECTED]>
 From: "R.A. Hettinga" <[EMAIL PROTECTED]>
 Subject: [Clips] Contactless payments and the security challenges
 Reply-To: [EMAIL PROTECTED]
 Sender: [EMAIL PROTECTED]

 



 Principia

 The Membership Organisation For IT Professionals
 A division of the National Computing Centre


 Contactless payments and the security challenges

 David Birch reports on the latest developments in contactless payment
 systems and reviews the associated security implications.

  The announcement of schemes such as MasterCard's Paypass, American Express
 ExpressPay and Visa's contactless initiatives is a sign that contactless
 smart cards are moving out of mass transit (e.g. London's Oyster card) and
 into the mass market. Indeed, Datamonitor have forecast that the market for
 these 'payment tokens' will grow at 47 per cent per annum over the next
 five years [1]. The international payment schemes' interest is obvious. At
 a time when it's hard to explain to a consumer why a contact smart card
 (such as the 'chip and PIN' payment cards being deployed around the world)
 is better than a magnetic stripe card, payment tokens immediately
 differentiate themselves by offering a completely different (and
 significantly more convenient) consumer experience.

  Why? Because the token needs only to be waved close to the terminal. In
 many cases, it will work fine while still in a bag or briefcase providing
 it is close enough to the terminal. The distance depends on the type of
 device used; the type of 'proximity interface' chip being discussed in this
 article will work up to a few centimetres from the terminals.

  With advances in chip and antenna technology, payment tokens now have
 almost identical functionality to contact smart cards, including high
 strength cryptographic functions, and can even be in a 'dual interface'
 package sporting both contact and contactless interfaces. RFID technology,
 while new to consumer payments, has actually been out in the field for some
 time. Mass transit was one of the driving sectors. Operators in Hong Kong,
 London, Paris, Washington and Taipei, amongst others, already have millions
 of tokens in place using the same technology and many other cities are
 planning similar schemes. Their switch to RFID based tokens has three main
 drivers:
*   Lower lifetime cost of ownership - for commercial use, the
 initial cost of RFID readers is already price comparable to motorised
 contact readers. The elimination of all moving parts, however,
 significantly improves reliability and operational reader life reducing the
 overall life cycle cost of ownership. The inherent vandal proof properties
 are also ideal for unattended vending or payments, delivering overall
 improved system availability.

*   Faster transaction times - for historical reasons, and because 
of
 their origin in the mass transit sector (which needs high throughput at
 gates), the interfaces to RFID chips are many times faster than the
 interfaces to chip contact smart cards.

*   Flexible form factors - as it operates remotely from the reader,
 the physical size and shape of the token is unimportant. Many tokens come
 in the traditional bank card form; others have been built into consumer
 goods like Swatch watches, pagers or key fobs.


  So momentum is building, and even industry observers historically bullish
 about using tokens for payment (e.g. the author [2]) have been surprised by
 the speed of deployment. The reason might be that while the rational
 reasons for choosing tokens for payments (e.g. speed, lifetime cost of
 ownership) are good, the irrational reason is even better; they're
 interesting, particularly because of the flexible form factor.

  Of the various forms factors noted above, two token-carrying devices seem
 to stand out; the key fob and the mobile phone. Whether you are waving your
 keys at a petrol pump before you fill up your car or in Burger King to pay
 for your meal, using the bunch of keys you already have in your hand
 instead of getting out your wallet makes this a clear proposition. But we
 all have our mobile phones with us all the time as well, and the phone
 (unlike the keys) can be used to manage the payment account in various
 ways, a synergy that is sure to be exploited.

  Nokia have said that they think payment tag technology is better than
 Bluetooth or Infra-red for mobile payments [3] and, in Japan, NTT DoCoMo
 and Sony have formed a joint venture (FeliCa Networks) to develop a version
 of the Sony FeliCa contactless chip for embedding into mobile phones and to
 operate the FeliCa platform for m-commerce [4]. For many consumers, this
 will be the ultimate in convenience because the phone provides the
 communications link for 

Re: Clearing sensitive in-memory data in perl

[Greg Black]

On 2005-09-18, Ian G wrote:
> Greg Black wrote:

>> The problem is bad programmers.
> 
> No, the problem is good programmers.  When K & R
> wrote C in the early 70s

K & R did not write C, they wrote a book about C.  R was the
creator of the language, with some inspiration and collaboration
from some others at Bell Labs, mainly Ken Thompson.  For the
history, see DMR's paper "The Development of the C Language" at
.

Re the book, BWK wrote the descriptive part and DMR wrote the
appendix that described the language.  Not surprisingly, BWK's
part has most of the real errors (as distinct from typos).

> , programming was a real
> heavy duty science, and K & R were in a place
> which was one of the meccas of the art.  They
> wrote a language for not only good programmers,
> but for great programmers.

Dennis wrote C for Ken (and for his own amusement).  It was
adopted by other people at Bell when they saw how useful it was
and escaped for the same reason.

> Their world is not the world we live in

Indeed it's not.  In particular, our world has bad guys and
cheap, powerful hardware with no constraints on memory or
particular needs for efficiency.

If somebody like Ritchie sat down today to write a new language
to replace C, then it would indeed be different and people with
real work to do might even switch to it.  But not one language
that has appeared since C is as useful and every language that
has appeared since then has had significant disadvantages in
comparison.  The only languages that strike me as being in any
way comparable are the Lisp family -- but they are useless for
system programming, and so people like me tend to stick to C
since it can do everything.  (Of course, I use other languages
as well; but C is the basis of everything I do.)

> PS: if one is forced to use C, what is the best
> recommendation for string / array processing?

One is never /forced/ to use C.  One chooses the tools to best
do the job.  One day, I'll package up my string library, which
would then be my recommendation.  As it is now, it's used in
quite a few places where I have consulted (since working with
software teams almost always involves teaching them to use C
effectively).  The only string library that I'm aware of that's
freely available is Dan Bernstein's stralloc[1] library and its
array library[2] successor:

  [1] http://cr.yp.to/lib/stralloc.html
  [2] http://cr.yp.to/lib/array.html

These both have disadvantages common to all DJB code: weird
licensing, unreadable style, and somewhat fanatic admiration of
his own work in preference to all other work.  However, for
somebody wanting some ideas for implementation of their own
library, these might make a useful starting point.

Bear in mind that, even though we are not all Ritchies, those of
us who work with software can learn to use sharp tools if we
take the time to do it and put in the work required.  If that's
really too much, then there are always buses that need drivers.

Greg

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]