MUSCLE Linux based device for financial transaction
Dear Friends, I am not a technical person, though I have a degree in Computer Science and engineering. For a long time I have been working on rural development projects includinng micro-finance in India. I read all your messages of struggling to get smart card integrated with Linux software. I admire your efforts to do that very much. They are of great value in bringing in product of Linux based device for financial transactions. I need application packages for financial transactions including smart card integration for my requirement. My Company BASIX is leader in Micro-finance in rural India. It lends, accepts deposits and carry out insurance for life. We are looking for linux based backend financial plateform and frontend payment solutions. Please let me know if there are such packages available and who provides the follow up services. with warm regards, Subodh _ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Linux Login with RSA SmartCards
On Thu, 7 Jun 2001, Carlos Prados wrote: Hi, --- David Corcoran [EMAIL PROTECTED] wrote: Definitely. The interface exported must be a subset of the available functionality or else someone could write a worm which does a Verify Key function incorrectly and blocks cards where services are available. Even worst. If you leave your card with your private PGP key in the reader and the smartcard is accesible to anybody over the net, somebody could connect to it, and write signed messages with your private key, read your private e-mail... You can design your application so that whenever a signature (or decryption) operation is to be performed, a PIN code should be presented, the operation performed, and the authentication state reset. That's how it's done with the French banking applications. The card in itself doesn't reset the authentication state after the operation, but the payment terminals must do it. He only needs your PIN, that he can get by snooping the network, or donig trial and error. Trial and error is not a valid attack, as the card usually disables the code as soon as 3 bad code guesses have been presented. Since you can enhance the PIN length, guessing the PIN in 3 tries is difficult. -- Erwann ABALEA [EMAIL PROTECTED] RSA PGP Key ID: 0x2D0EABD5 - ``There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded.'' Mark Twain *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Linux Login with RSA SmartCards
On Fri, 8 Jun 2001, Dr S N Henson wrote: Carlos Prados wrote: Again, I would pay more athention to local security. Why is the file /tmp/.pcscrx world writtable? isn't this a security hole? On the subject of security... As may be apparent I've only just got my setup working and I've not examined things in any detail. I did notice a few things which might be cause for concern. Consider a Netscape PKCS#11 module. In this application the connection to the reader may need to be kept open for an extended period of time (typically the whole browser session) and may not be closed cleanly. As we are all painfully aware its not entirely unknown for a browser to crash. For the PKCS#11 part, there's a solution: just use random session numbers, and close all the sessions if you detect at least 3 invalid session numbers... That way, the application can crash, but trying to attach to this previous session and keep the authenticated state would be difficult. -- Erwann ABALEA [EMAIL PROTECTED] RSA PGP Key ID: 0x2D0EABD5 - A computer is a state machine. Threads are for people who can't program state machines. Alan Cox in a discussion about the threads and the Linux scheduler *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
AW: MUSCLE Linux Login with RSA SmartCards
-Ursprüngliche Nachricht- Von: Erwann ABALEA [mailto:[EMAIL PROTECTED]] Gesendet am: Freitag, 8. Juni 2001 12:07 An: [EMAIL PROTECTED] Betreff: Re: MUSCLE Linux Login with RSA SmartCards You can design your application so that whenever a signature (or decryption) operation is to be performed, a PIN code should be presented, the operation performed, and the authentication state reset. That's how it's done with the French banking applications. The card in itself doesn't reset the authentication state after the operation, but the payment terminals must do it. Hi, it's possibly interesting, that cards exist, where the access condition expires automatically after the operation is completed. This is how our German Digital Signature Law compliant card works. (No, it isn't a JavaCard.) The advantage is, that you don't have to rely on a good-natured terminal. http://crypto.mchh.siemens.de/produkte/smartcards.asp?lang=eng Guido Treutwein Siemens ICN ISA TNA 21 [EMAIL PROTECTED] *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Linux Login with RSA SmartCards
Hi Guido, Does Siemens have JavaCards?? If so, could you give-me infos about they?? Thanks a lot. [ ]´s Luciano da Silva Coelho [EMAIL PROTECTED] Sun Certified Programmer for JAVA2 Sun Certified Instructor for JAVA2 Diretor de Tecnologia e-Sec Tecnologia em Segurança de Dados www.esec.com.br - Original Message - From: Treutwein Guido [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 08, 2001 8:36 AM Subject: AW: MUSCLE Linux Login with RSA SmartCards -Ursprüngliche Nachricht- Von: Erwann ABALEA [mailto:[EMAIL PROTECTED]] Gesendet am: Freitag, 8. Juni 2001 12:07 An: [EMAIL PROTECTED] Betreff: Re: MUSCLE Linux Login with RSA SmartCards You can design your application so that whenever a signature (or decryption) operation is to be performed, a PIN code should be presented, the operation performed, and the authentication state reset. That's how it's done with the French banking applications. The card in itself doesn't reset the authentication state after the operation, but the payment terminals must do it. Hi, it's possibly interesting, that cards exist, where the access condition expires automatically after the operation is completed. This is how our German Digital Signature Law compliant card works. (No, it isn't a JavaCard.) The advantage is, that you don't have to rely on a good-natured terminal. http://crypto.mchh.siemens.de/produkte/smartcards.asp?lang=eng Guido Treutwein Siemens ICN ISA TNA 21 [EMAIL PROTECTED] *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: MUSCLE Work Waiting Time question
On 7 June 2001 Carlos Prados wrote Re: MUSCLE Work Waiting Time question Hi, It seems, therefore, that changing the value of Di in the ATR does not change the value of the wwt, but changing the value of Fi does. Is this what the writers of 7816-3:1997 meant? I don't think so, because the wwt required is related to the values of clock sent to the card, the internal structure of the card's CPU and clock processing circuits, and the application algorithm programmed into the card. Changing Fi and Di doesn't change the way that the card runs its application code, and so should not change the wwt - but changing Fi does change the wwt. FI from the card, besides influencing I/O bit rate, also indicates the max clock frequency that the card can be run at. So: FI = 0 (means Fi = 372), Di = 1 gives a bit rate of 9600 in our example, a wwt of 1 sec, and indicates (Table 7) a max clock frequency of 4 MHz (typical for a card run at 3 Volts Vcc) FI = 1 (also means Fi = 372), Di = 1 gives a bit rate of 9600 in our example, a wwt of 1 sec, and indicates (Table 7) a max clock frequency of 5 MHz (typical for a low cost card run at 5 Volts Vcc) FI = 3 (means Fi = 744), Di = 2 also gives a bit rate of 9600 in our example, but changes the wwt to 2 sec, and indicates (Table 7) a max clock frequency of 8 MHz (e.g. for a Hitachi 3109 card as used by rollout spec Mondex in a single application environment) But the reader that I'm ussing provides 3.5712 MHz constant clock rate to the smartcard regardless of the ATR in the card. The clock frequency figures given in the above explanation are the maximum that the card is rated to use. The card can be run at any frequency from 1 MHz up to the maximum indicated by the value of FI indicated in the ATR. It is very rare to find a card reader that can switch frequencies (and in other places I have argued that the combined requirements of 7816-3, EMC regulations, and the desire to protect the reader's interface circuitry from static discharges, make it very difficult to design a reliable and compliant card reader that drives the card at more than 4 MHz). Cards have to be started with a clock frequency (at 5V Vcc) in the range 1 Mhz to 5Mhz, and they start with a clock to I/O bit rate ratio of 372, so 3.5712 Mhz (gives 9600 bps on I/O) or something close to that is typical. What I was showing is that a card that can only be run at up to 5 MHz will, at 3.5712 MHz clock, expect the terminal to grant it a default wwt of 1 sec. But a card that can be run at up to 8 MHz (and whose developer wishes to announce that to the terminal, in case the terminal can switch up to a higher speed) is very likely to issue an ATR that results in the terminal giving it, at 3.5712 MHz, an I/O bit rate of 9600 but a wwt of 2 seconds. If we assume that that card is identical to the other one in all respects except for being rated to run at up to 8 MHz instead of up to 5 MHz, then both cards will execute applications at exactly the same rate when run at the same clock frequency, and therefore both will need the same wwt. This points out an absurdity in 7816-3, but also shows that, when calculating the value of WI to send from the card if you want to change the wwt, you must be careful to use the correct parameters in the equation (if the card sends a value for FI in the ATR, you must use that value in the calculation). So, must I assume that if the clock rate doesn't change I must not change the wwt from the standard 1s value ? No, you choose the wwt value (choose a WI value to send from the card) to give you a long enough wwt to be sure that the card has time to execute the longest path through the code between responses from the card (remember that you can send a procedure byte from the card to reset the wwt timer in the terminal, and sometimes that is a practical solution (e.g. send a NULL), but at other times you may find you have a card whose ROM code will not let you do that). Does this apply to T=1 timeout values, BWT and CWT? BWT and CWT have their own formulae in section 9.5.3 of 7816-3:1997, and their own parameters in the ATR. BWT's formula is very odd: BWT = 11 etu + 2**BWI * 960 * (372/f) sec but CWT depends directly on F/D as well as f: CWT = (11 + 2**CWI) * (F/D) * (1/f) BWI and CWI are upper and lower nibbles from the TB interface byte after the first occurrence of a T=1 value in a TD(2) or later TD byte. wwt extension in T=1 is handled by an S-block request from the card. Who dreamt this up? Mainly the French for T=0 and the Germans for T=1. Vive le Common Market! Peter T Bristol UK *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
MUSCLE applet exchange
Hello, The Applet Exchange: Under the software section of the site I have added a link for the applet exchange which will hold open applets for JavaCards. This will hold the Common Cryptographic Layer (CCL) applet which will be used to talk to JavaCards for authentication in a generic manner. If you have an applet you would like me to place there please let me know. I will also be releasing a new version of pcsc-lite soon which will also work on Solaris and some drivers compiled for Solaris. Regards, Dave *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
