FinRead was launched at a CEN/ISSS Workshop meeting, and it was aimed at the financial payment market. Since the idea came from France, debit card use was first in their minds, credit cards next - the project name came from FINancial card READer. In payment card terms, the intention is to extend to 'cardholder not present' transactions the same guarantees that are at present only available when the transaction is face to face between merchant and customer - these guarantees tend to be of more use to the merchant than to the customer, but in the end the customer will benefit.
But all that we were presented with at the launch was the proposal that this card "reader" concept be adopted into a European specification - for the financial market. It wasn't until after lunch (and a bottle of Belgian beer each) that Philip Andreae and I started asking who was intending to use it and in what kind of network architecture. The French came clean: it was to be used for secured end to end transactions directly between a financial card and the card issuer's server. The methodology was for the user first to carry out an online transaction with a merchant. When it came to the payment stage, the user's terminal (usually a PC, of course) would tell the FinRead reader how much to transfer and for whose benefit, and the reader would pass this information through to the card. The card then asks the FinRead reader to obtain confirmation from the user (by way of PIN and a 'Yes' on the keypad, following display of the amount, etc, on the reader's display). If the user says 'Yes', the card contacts its issuer's server via the reader and terminal (PC), and carries out a secure financial transaction. The important function here is the card and remote server mutually authenticating each other, and then securely transferring the amount to be paid, etc. Once the payment transaction has been made, the card issuer's server sends a message to the merchant's server to confirm payment. The problem here is that the card issuer must also be the holder of the cardholder's account. Now there are a lot of hoops to jump through here, because the assumption made is that only banks (or their financial card issuing subsidiaries) will be issuing these cards, and that breaks down once we start to think about a generalised multi-application card - maybe we have to say that the card application carries out the financial transaction with the payment application's issuer. And there is that tricky business of merchant acquirers who handle the collection and forwarding of all the offline card transaction messages - the French do not use that methodology. But I'm more concerned here with the problems caused by attempting to adapt the Finread concept to a more general environemnt, problems which others contributing to this thread have picked up. The FinRead concept depends upon three pre-requisites: 1. The existence of a trusted organisation (the financial account provider, who is also the issuer of the financial application on the card), an organisation which is bound to honour transactions properly made and repudiate those dishonestly made. 2. The ability of the card to contact the payment server, at any time, from anywhere - you have got to use the internet. 3. The ability of the card to generate and then present, on the FinRead display, the information to be authenticated, and do so in a form that the cardholder can understand and be reasonably expected to be able to say 'Yes' or 'No' to. Thus it is no good sending 10K bytes of binary informatiion to the card for signing... If you want to use FinRead to securely handle multiple functions on behalf of multiple "merchants" (types of server operator), then downloading applets into the FinRead device is no use - the card has to be in charge, so the card has to have in it applications (and security keys) appropriate to every server that it is expected to work with. Merely putting TCP/IP in the card (as some have suggested) doesn't seem to me to be the whole of the answer, because everything that gets loaded into the card must be trusted and be loaded from a trusted source using a secure protocol. Current experience seems to me to be that this secure loading of a trusted application is possible, but in practice works so slowly that it is not practical over a dial-up line (after all, Multos has available to it a post-issuance application download network, but it needs a broadband link to give acceptable download times). And, yes, there is always risk, but the card application issuer must take most of it, which means have a programme to continually update the security mechanisms in order to keep ahead of the game. Maybe I have killed this topic now. All I have really done is expand Michael Gile's succinct statement. Peter T Bristol UK ----- Original Message ----- From: "Jason Barkeloo" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, March 06, 2002 3:47 AM Subject: MUSCLE So is that what the FinRead > specs are designed to do? > > jb > > > > From: Michael Gile ([EMAIL PROTECTED]) > Date: Mon Jan 21 2002 - 16:27:57 CST > > The security problem with smart cards is not key recovery. It is the fact > that the smart card must rely on a standard PC (or other insecure host) for > input and output. > > For example, say we have a smart card with a signing application that will > sign arbitrary data from the host PC (an oracle). The attacker no longer > needs access to the key, only an application that can send data to the card. > Even when adding authorization to the key usage (for example a PIN), an > attacker needs only access to the insecure host machine and can then recover > the PIN itself or send bogus data to be signed. > > The solution to the smart card attacks above is to add a secure > communication channel to some special purpose server through which only > encrypted data is ever transmitted outside the card, or provide a more > robust mechanism to the user that can be used for secure input and allows > more storage and computing power on the card itself. > > Regards, > > Michael Gile > Wave Systems Corp. > [EMAIL PROTECTED] > [EMAIL PROTECTED] > *************************************************************** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***************************************************************
