Lyal,
Agreed that I have not dealt with the situation where the card is in
a set-top box and the 'cardholder' is holding, not a card, but a
remote control unit. Two observations:
1. There are some in that section of the industry who say that you
should have two cards, one being the traditional conditional access
TV card and the other being your payment card. The idea is that you
leave the conditional access card in the set top box, and you insert
the payment card in the handheld remote control unit. Behind this is
the principle that the access control card belongs to the person
responsible for the set top box, but the payment card is personal to
the cardholder and thus he or she must keep close personal control of
that card at all times. So I put the payment card into the handheld
only when I want to make a payment. The coming (perhaps) of multi-app
cards conflicts with this philosophy.
2. A more difficult concept is that of the 'trusted' device. Clearly,
a PC is not trustworthy in this application, because it is too easy
to load into it software that can be used for fraud. The set-top box,
however, is supplied by the TV service provider, certified by him as
suitable for the job, and therefore should be trusted not to be
hackable - or, at least, if it is hacked, the TV service provider
will be very keen to track down and deal with the hacker. So this
says that I can trust the set top box to handle my card in a secure
manner, but I cannot trust the PC. So I can put my multi-app card
into the set top box, sit back with the remote control, and book
pay-per-view that is charged to the card in the slot in the set top
box, and feel confident that I am not being ripped off (unless the
boxing match is fixed).
As for tamper-resistance in GSM phones, I think that is happening.
The problem at the moment is that the phones are now so small that
they cannot take a full size ID-1 card, and the power consumption
(same problem as with your observation on payment cards in TV
remotes) limits in the EMV spec are 50 mA at 5V for the payment card.
Now GSM max current consumption is 10 mA, but payment cards need a
crypto processor, and some payment cards in current (sic) production
take all of that 50 mA. New designs for multi-app cards are running
at 10 mA max at 3V, which is more like what EMV want. That suggests
that a multi-app SIM (ID-000 size) could hold the phone SIM app and
the EMV app, but EMV refuse to bend the low level part of their spec
to allow for different platforms, and they are not even ISO
compliant (yet).
(Sorry, haven't replied direct to the Bull postings yet - will do so
soon.)
Peter
PS Why do all the students that I know want to go to Oz for a year
when they finish college? In my day a summer vac spent in Europe was
the height of our ambition. Then came package holidays to Yugoslavia,
and life was not simple any more.
------------------------------------------------------
> From: "Lyal Collins" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Subject: RE: RE : [OCF] Basic question
> Date: Tue, 23 Mar 1999 07:55:31 +1100
> Importance: Normal
> This is an interesting discussion, as is the list at times.
>
> I have 2 comments/questions:
>
> One issue which Peter's proposal, although sound, does not seem to
> address is the move toward separation of pin pad and reader.
> ie there are cases where Smartcard power requirements can make a
> TV-like remote control too heavy or an unacceptable shape.
> Insteaed, the smartcard is in a Set Top box, operated by wireless
> or infrared.
> The explosion in resources devoted to Bluetooth, Home Network
> Alliances and like technologies etc increase the likelihood that
> PIN pad and reader will not be co-located in all cases.
>
> Peter's conceptual model may also make some transactions models in
> existence obsolete e.g mobile phone handsets as authorisation
> terminals.
> Does anyone know of any work underway to merge financial industry
> tamper-resistance to such devices ?
>
> Cheers,
> Lyal
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > [EMAIL PROTECTED]
> > Sent: Tuesday, March 23, 1999 7:09 AM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: RE : [OCF] Basic question
> >
> >
> > Jeng-min, I think your question far from being stupid.
> > Peter's proposal
> > implies a pinpad able to interpret some answer APDU
> > coming from the card
> > (amount validated by the card), which means that
> > specific softwares must be
> > loaded into the pinpad. This is not very far from what
> > is expected from a
> > complete EFT/POS terminal.
> >
> > Peter speaks, as an alternative possibility, of a
> > LCD-diplay on the card.
> > This is technically possible, but banks are requiring
> > very low prices for
> > customer cards, and this is not yet compatible with on
> > card display.
> >
> > To answer Peter: secure complete EFT/POS terminals for
> > point of sales are
> > not so expensive (compared to PC). The average current
> > prices are in the
> > range 500-1000 US dollars. The price has not been a
> > blocking factor in the
> > countries where smart cards have been massively
> > deployed, like France. I
> > don't think UK or US retailers are poorer than french ones....
> >
> > Secure opaque PinPads for e-commerce with a SET like
> > software inside, are
> > already proposed with an average price in the range
> > 100-300 US dollars. The
> > same kind of terminals connected to PC is also available
> > to be used by
> > physicians for healthcare cards.
> >
> > Jean-Paul
> >
> >
> >
> >
> >
> > [EMAIL PROTECTED] on 03/21/99 11:34:32 PM
> >
> > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > cc: (bcc: Jean-Paul Billon/US/BULL)
> > Subject: RE : [OCF] Basic question
> >
> >
> >
> > Content-type: text/plain; charset=iso-8859-1
> > Content-transfer-encoding: quoted-printable
> >
> >
> >
> > May I ask some stupid questions:
> > 1. How does the card obtain direct confirmation from the
> > cardholder to
> > verify that the amount of the transaction is correct? Is
> > there any glob=
> > al
> > standard (ISO or ANSI) or de facto standard describing
> > about this? And,=
> > how
> > does the card display transaction value on display of so
> > called PIN pad=
> > ? In
> > our design, we have to download device applications (in
> > correspondent t=
> > o
> > card applications) into PIN pad to handle these keypad
> > inputs and displ=
> > ay
> > outputs via monitoring the commands to/from card, is
> > this manner correc=
> > t?
> > 2. In my understanding, patents didn't protect concepts
> > or ideas. So, w=
> > e
> > should not mind a USA organization holds patents that
> > may include this
> > concept, the important things are the methods that
> > implement the concep=
> > ts,
> > is that right?
> > Jeng-Ming Duann
> >
> >
> > -----Original Message-----
> > From: Peter W Tomlinson [SMTP:[EMAIL PROTECTED]]
> > Sent: Saturday, March 20, 1999 12:11 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [OCF] Basic question
> > Following the discussions in the Open Card Forum this
> > week, and after
> > consulting a few other people in the industry, the
> > following is an
> > attempt to describe more clearly the concept for a low
> > cost secure
> > method to implement a debit/credit terminal. This
> > concept is intended
> > to be applied to the personal home e-commerce situation
> > (PC or TV set
> > top box), small office e-commerce situation, PC-based
> > till system, and
> > large networked supermarket till systems.
> >
> > The principles behind this concept are:
> > 1. The card obtains direct confirmation from the
> > cardholder to verify
> > that the amount of the transaction is correct
> > 2. The card then authenticates the transaction record
> > 3. The equipment used to transmit the transaction record
> > (including
> > perhaps storing it for a while before forwarding it)
> > must be reliable
> > but need not be tamper proof and need not be tamper evident
> >
> > The result of all this is that, if the transaction proceeds, the
> > customer gets assurance that the value transferred is
> > correct. The
> > organisations processing the transaction (retailer,
> > acquirer, etc)
> > must on their part shoulder responsibility for processing those
> > transactions reliably and without tampering - and the
> > risk to them is
> > regarded as an insurable risk, so the quality levels for their
> > equipment are set as a tradeoff between the cost to the equipment
> > owner and the commercial risk to the payment schemes, to
> > banks, to the
> > acquirer, and to the merchant. Where the transaction is first
> > processed in a PC owned by the cardholder or used by him
> > in a personal
> > capacity, it is likely that we are dealing with an Internet
> > transaction or something similar. In this case, the
> > cardholder takes
> > responsibility for following the transaction through to the stage
> > where a commercial service provider (e.g. ISP, merchant web site,
> > acquirer) takes over responsibility - he should expect to see a
> > confirmation message or receipt, and he should compare
> > that with the
> > value transfer that he authorised.
> >
> > The proposal is that the user card be handled in a
> > separate unit which
> > is a secure keypad plus card reader/writer plus display
> > - let us call
> > this the PIN pad for convenience. The design of this PIN
> > pad must be
> > such that the only route to the display is from the
> > card, and the only
> > route from the keypad is to the card. Thus the
> > transaction message
> > creation process includes the following sequence:
> > 1. Terminal equipment sends message to card giving
> > transaction value
> > 2. Card displays transaction value on display
> > 3. Cardholder verifies (by pressing a ?es?key) or rejects (by
> > pressing a ?ancel?key or doing nothing) the transaction
> >
> > If ?es? the card authenticates the transaction message
> > and sends it
> > off to the next stage (local store, remote store, acquirer)
> >
> > The only route from the transaction processing equipment
> > (e.g. from a
> > PC to which the PIN pad is connected) to the display is
> > via the card.
> > To display a message from the PC, a display command is
> > sent to the
> > card. Interlocks in the card prevent the display command
> > from being
> > used to cause a fake transfer confirmation request to be
> > displayed to
> > the cardholder in place of the true confirmation request from the
> > card. When there is no card in the reader/writer, display shows
> > ?nsert card? As there will be a microcontroller in the
> > PIN pad, it
> > can also display a small number of other system messages
> > (e.g. s/w
> > version number displayed for a short time after power on).
> >
> > Note that there are now designs of card which
> > incorporate flexible
> > LCD-style displays, and these could be used to provide
> > an alternative
> > realisation of this concept.
> >
> > Now the payment processing functions previously carried
> > out by ?evel
> > 2?software in a monolithic terminal are, in this scenario, more
> > likely to be carried out in a back office system (e.g.
> > supermarkets),
> > a combination of web browser and web server (standard open system
> > e-commerce configuration), or a proprietary system
> > running partly in
> > the user? PC and partly at a remote site. The argument being put
> > forward here includes the thesis that such payment
> > processing systems
> > do not need be type approved, but are allowed to carry
> > an imprimatur
> > if they have been type approved. The worst that they can
> > do is lose or
> > corrupt a transaction; the best that they can do is
> > provide new styles
> > of payment processing.
> >
> > The EMV schemes are required, as part of this payment method, to
> > provide management services for the issued card base,
> > even through
> > third party software and systems which are not type approved.
> > Management here includes security key management (a
> > service which it
> > is believed is not currently provided), card
> > blacklisting and card
> > blocking.
> >
> > The cost of a volume manufactured secure PIN pad unit of the type
> > described here is expected to be under 30 USD. The
> > physical concept is
> > already produced by several manufacturers and used, for
> > example, by
> > Proton for Internet transactions - but whether the internal
> > organisation of these existing units is as required here
> > is unknown,
> > but it is unlikely to be what we require.
> >
> > The cards themselves need internal software to a level beyond the
> > current EMV V3.1.1 (which itself has moved beyond the
> > V3.0 UKIS cards
> > which are just starting to roll out here in the UK). The
> > cards need to
> > move on from being just an electronic form of a mag
> > stripe card to
> > being a true intelligent microprocessor card, providing
> > all the secure
> > functions required for debit/credit.
> >
> > Note that, from my brief introduction to this concept on
> > the OCF, a
> > message has reached me to the effect that a USA
> > organisation holds
> > patents that may include this concept.
> > Peter Tomlinson
> > Iosis, 4 Sommerville Road, Bristol BS7 9AA, UK
> > Phone +44 117 924 9231, fax +44 117 924 9233
> > Email [EMAIL PROTECTED], web www,iosis.co.uk
> > Visit the OpenCard Framework's WWW site at
> http://www.opencard.org/ for=
>
> access to documentation, code, presentations, and OCF
> announcements.
> -------------------------------------------------------------------
> ----=
> ----
> --
> To unsubscribe from the OCF Mailing list, send a mail to
> "[EMAIL PROTECTED]" with the word "unsubscribe" in the
> BODY=
> of
> the
> message.
> Visit the OpenCard Framework's WWW site at http://www.opencard.org/
> for=
>
> access to documentation, code, presentations, and OCF
> announcements.
> -------------------------------------------------------------------
> ----=
> ----
> --
> To unsubscribe from the OCF Mailing list, send a mail to
> "[EMAIL PROTECTED]" with the word "unsubscribe" in the
> BODY=
> of
> the
> message.
>
>
> =
>
>
> Visit the OpenCard Framework's WWW site at http://www.opencard.org/
> for
> access to documentation, code, presentations, and OCF
> announcements.
> -------------------------------------------------------------------
> ----------
> To unsubscribe from the OCF Mailing list, send a mail to
> "[EMAIL PROTECTED]" with the word "unsubscribe" in the
> BODY of the
> message.
>
> Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for
> access to documentation, code, presentations, and OCF announcements.
> -----------------------------------------------------------------------------
> To unsubscribe from the OCF Mailing list, send a mail to
> "[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of the
> message.
>
>
Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for
access to documentation, code, presentations, and OCF announcements.
-----------------------------------------------------------------------------
To unsubscribe from the OCF Mailing list, send a mail to
"[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of the
message.
