MUSCLE utility for driver function verify
Title: ªÅ¥Õ Hello, We are developing the SmartCard reader driver from PCMCIA port. Follow MUSCLE current spec, CT-API. Now we want get some utility for function call verify. Can you tell me where can I get this utility. Thanks
Re: MUSCLE utility for driver function verify
"Randy Chen (TP)" wrote: Hello, We are developing the SmartCard reader driver from PCMCIA port. Follow MUSCLE current spec, CT-API. Now we want get some utility for function call verify. Can you tell me where can I get this utility. Thanks Name: Blank Bkgrd.gif Blank Bkgrd.gifType: GIF Image (image/gif) Encoding: base64 I don't have the answer to your question, but what is this "Blank Bkgrd.gif" picture that is attached to the message ? -- Olivier Jeannet - e-Payment solutions I prefer not running 32 bit extensions for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition. *** 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 pcsc and opencard
Christophe, Thanks for that very informative response, it was just what I was looking for. Michael. *** 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 security changes in pcsc-lite
Hello, Now that pcsc-lite has stabilized I will be doing some unnoticed modifications from the applications point of view to improve security. I will continue to use Sun RPC but without portmapper and using AF_UNIX Unix Domain sockets so that transactions only occur on the local machine. This will make it use of IPC not RPC. RPC was useful in the beginning to do debugging on remote machines but it is flawed in security and I don't like using portmapper anyway. SCARDCONTEXT will no longer be a 32 bit value. It will be a struct containing an application identifier. The application identifier will consist of a 1024 bit key that will be negotiated at SCardEstablishContext using a voting protocol key distribution. This key will then be shared by the app and the server and will be used to encrypt APDU's sent. SCARDHANDLE will now be a struct containing a connection id and reader id. The connection id will be 128 - 1024 bits to make it difficult to session wedge by guessing the hCard value like it was previously. Each command will have a trailing checksum. SCardGetStatusChange SCardStatus SCardListReaders will now receive instant notification of smartcard and usb and pcmcia insertions and removals. This will be done by copying a public portion (states) of the reader database to a shared segment which any application may read. No longer will there be any forked processes for GetStatusChange and an app can thread this call as much as they want. This shared segment will be read only. These functions will be strictly on the client side. I will begin some work (Unix Domain portion) now and will release next week. The encryption and keys and instant notification will be done by December 28. This will create greater security and a much better performing resource manager and will limit the attacks done on the subsystem to random guessing of keys which will be nearly impossible in the amount of time that a handle is active. The behavior will remain the same, besides gaining a few extra CPU cycles on your machine and some memory. Let me know your thoughts on this. Best Regards, Dave David Corcoran Purdue University 1008 Cherry Lane West Lafayette, IN 47906 [EMAIL PROTECTED] 765 - 427 - 5147http://www.linuxnet.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 cyberflex sdk for linux
The linux sdk was there two weeks ago, but now I can't find it. Maybe it has been removed now that Danny is gone. You can put most of it together yourself except for mksolo and the class files. The Readme is still there and describes what was in the sdk: http://www.cyberflex.slb.com/Support/cyberflex_linux_readme.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 cyberflex sdk for linux
On Tue, Nov 14, 2000 at 06:04:56PM -0500, Jim Rees wrote: The linux sdk was there two weeks ago, but now I can't find it. Maybe it has been removed now that Danny is gone. You can put most of it together yourself except for mksolo and the class files. The Readme is still there and describes what was in the sdk: http://www.cyberflex.slb.com/Support/cyberflex_linux_readme.html I found these the other day after poking around some. so anyway, don't I *need* mksolo related classes in order to build cardlets with the Cyberflex Access 00 cards? thanks for responding so quickly. -joe *** 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 cyberflex sdk for linux
On Tue, Nov 14, 2000 at 06:04:56PM -0500, Jim Rees wrote: The linux sdk was there two weeks ago, but now I can't find it. Maybe it has been removed now that Danny is gone. You can put most of it together yourself except for mksolo and the class files. The Readme is still there and describes what was in the sdk: http://www.cyberflex.slb.com/Support/cyberflex_linux_readme.html I found these the other day after poking around some. so anyway, don't I *need* mksolo related classes in order to build cardlets with the Cyberflex Access 00 cards? Yes, you do. Class files are necessary to compile .java to .class, and mksolo is necessary to convert .class to .bin. -- Concentration .. Naomaru Itoi *** 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 ***
