Re: [Muscle] Licensing query
Le Tuesday 01 March 2005 à 12:20:41, Peter D'Costa a écrit: > Hi all, Hello, > Would it be possible to use a proprietary IFDHandler (having a > proprietary license) along with the PCSClite package? > > I understand that the PCSClite package is having a BSD license. Would > this setup have legal implications? In fact some proprietary drivers are already available. In 2001 I made a license status [1] on the drivers available on [2]. The pcsc-lite license allows you to provide a proprietary driver. But I strongly _not_ recommand it. Bye, [1] http://archives.neohapsis.com/archives/dev/muscle/2001-q4/0188.html [2] http://musclecard.com/sourcedrivers.html -- Dr. Ludovic Rousseau[EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. -- ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] removal of ccid usb reader ==> need to restart pcscd ?
Le Tuesday 01 March 2005 à 15:26:38, Serge Koganovitsch a écrit: > When using 'pcscd -f' I get a SIGSEGV in get_ccid_usb_interface() whenever > I remove the CCID reader. That's why I had to restart pcscd ... This is a know bug corrected (I hope) in the CVS version of the CCID driver. I think the bug is in libusb since the crash occurs in one of its functions. You can either use the CVS version of the CCID driver or downgrade your libusb library. Bye, -- Dr. Ludovic Rousseau[EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. -- ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] help needed getting JCOP20 working with muscle
Karsten Ohme a écrit : Benoit Auquier wrote: hi, I have successfully loaded the applet on my engineering sample JCOP20 using eclipse and the JCOPtools , but after that , i tried to use this card under linux using the packages found on www.linuxnet.com , but got nothing to work properly. Pcscd work and my card reader is recognised . card insertion/removal is shown in the logs , but every program i tried said " no tokens " or "unrecognised token". what can i do to get it working ? You have inserted the ATR in the configuration file for your plugin? if you mean the file Info.plist , yes , i did You have formated the card using MuscleTool? no , because muscletool won't compile . it complains about undefined references to msc*. I tried to add the header files in the include path but it didn't fix If the above steps are successful, it should work. thank you for your help Bye, Karsten ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] support for all readers with a PIN pad
Martin Paljak wrote: What reader are you using ? I use the Kobil Kaan Professional reader. For this reader I have to use the dwControl for SCardControl of 0x003100dc. On Tue, 01 Mar 2005 14:16:29 +0100, Karsten Ohme <[EMAIL PROTECTED]> wrote: Hello, I have ported the PKCS#11 module, the MCardPlugin and the MuscleCard Applet to support my card terminal which has a pin pad and display. So I can enter the PIN with it. I asked this question maybe in a similar way some time ago. I use for the PC/SC command SCardControl and the CT-BCS standard. I got the answer that the special parameter for the SCardControl function is proprietary for each card terminal. Is there an easy possibility to support all readers with a pin pad and display? A solution would be a configuration file. But this should be contained in the configuration file for pcsclite. Bye, Karsten ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] removal of ccid usb reader ==> need to restart pcscd ?
When using 'pcscd -f' I get a SIGSEGV in get_ccid_usb_interface() whenever I remove the CCID reader. That's why I had to restart pcscd ... pegasus:~# gdb /usr/sbin/pcscd core.12171 GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) Core was generated by `pcscd -f'. Program terminated with signal 11, Segmentation fault. warning: current_sos: Can't read pathname for load map: Input/output error Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0 Reading symbols from /lib/libusb-0.1.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libusb-0.1.so.4 Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libdl.so.2 Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libc.so.6 Reading symbols from /lib/ld-linux.so.2... (no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/ifdok_cm4040_lnx-1.1.0.so...done. Loaded symbols for /usr/lib/ifdok_cm4040_lnx-1.1.0.so Reading symbols from /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so.0.9.2...done. Loaded symbols for /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so.0.9.2 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 #0 0x4198ea42 in get_ccid_usb_interface () from /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so.0.9.2 (gdb) bt #0 0x4198ea42 in get_ccid_usb_interface () from /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so.0.9.2 #1 0x4198e845 in CloseUSB () from /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so.0.9.2 #2 0x4198c0aa in IFDHCloseChannel () from /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Linux/libccid.so.0.9.2 #3 0x08056afd in IFDCloseIFD () #4 0x08051a31 in RFUnInitializeReader () #5 0x0805073e in RFRemoveReader () #6 0x08055db2 in HPRemoveHotPluggable () #7 0x08055944 in HPEstablishUSBNotifications () #8 0x41177ca3 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #9 0x410f09ba in clone () from /lib/tls/i686/cmov/libc.so.6 Regards, Serge ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] support for all readers with a PIN pad
What reader are you using ? On Tue, 01 Mar 2005 14:16:29 +0100, Karsten Ohme <[EMAIL PROTECTED]> wrote: > Hello, > > I have ported the PKCS#11 module, the MCardPlugin and the MuscleCard > Applet to support my card terminal which has a pin pad and display. So I > can enter the PIN with it. I asked this question maybe in a similar way > some time ago. I use for the PC/SC command SCardControl and the CT-BCS > standard. I got the answer that the special parameter for the > SCardControl function is proprietary for each card terminal. > Is there an easy possibility to support all readers with a pin pad and > display? A solution would be a configuration file. But this should be > contained in the configuration file for pcsclite. > > Bye, Karsten > ___ > Muscle mailing list > Muscle@lists.musclecard.com > http://lists.drizzle.com/mailman/listinfo/muscle > -- Martin Paljak - consultant [EMAIL PROTECTED] - Gmail http://martin.paljak.pri.ee/ - web +372.5156495 - phone ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] help needed getting JCOP20 working with muscle
Benoit Auquier wrote: hi, I have successfully loaded the applet on my engineering sample JCOP20 using eclipse and the JCOPtools , but after that , i tried to use this card under linux using the packages found on www.linuxnet.com , but got nothing to work properly. Pcscd work and my card reader is recognised . card insertion/removal is shown in the logs , but every program i tried said " no tokens " or "unrecognised token". what can i do to get it working ? You have inserted the ATR in the configuration file for your plugin? You have formated the card using MuscleTool? If the above steps are successful, it should work. Bye, Karsten ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] .Net remoting channel, muscle://
Scott, The future of the two combatting visions is IMO only to a limited extent a security issue. The commercial issues are currently much worse. Unfortunately neither side has currently much to offer but misery. I'm trying to raise a political movement for getting a functional client solution because it seems that this is needed. In "my camp" that means trying to get _governments_ to agree on an open multi-ID solution. That is, it is the end-user (or the end-user's employer) that should "own" the "ID-container" not the government, bank or operator. The "card camp" is much associated with the financial industry that also takes pride in locking customers in the same way as operators do. Anders - Original Message - From: "Scott Guthery" <> To: "MUSCLE" ; "MUSCLE" Sent: Monday, February 28, 2005 22:40 Subject: RE: [Muscle] .Net remoting channel, muscle:// Anders: 1) The telecoms -- including Telia I''ll wager -- regularly download SIM applets with Cardholder PIN authorization so not only is there no "user in the loop" but the operators can read and send back to themselves whatever you put on your phone or in your SIM without you ever knowing it and regardless of what protection you think you've put on it. There are parts of the world where this is known as identity theft. 2) If you've ever tried to build a J2ME application you'd know that there is no evidence whatsoever that Nokia or Motorola creates better code than Microsoft or IBM. At least Microsoft asks you if you want the update. The handset manufacturers in collusion with the operators just push it to your handset whether you like it or not. And you want me to trust these people? Cheers, Scott -Original Message- From: [EMAIL PROTECTED] on behalf of Anders Rundgren Sent: Sun 2/27/2005 4:05 PM To: MUSCLE Cc: Subject: Re: [Muscle] .Net remoting channel, muscle:// Another, somewhat related thought experiment: http://web.telia.com/~u18116613/TheUniversalAccessControlCard.pdf Anders R - Original Message - From: "Peter Williams" <[EMAIL PROTECTED]> To: "MuscleCard Mailing List" Sent: Sunday, February 27, 2005 05:14 Subject: [Muscle] Re: .Net remoting channel, muscle:// Lets go a bit further with the thought experiment about muscle applets, and libmusclecard APDU plugins, in the world of .NET smartcards, TPMs, and offcard applications implemented as .NET assemblies. Assume a smartcard manufacturer uses ".NET chip" - one whose microcode natively performs the MSIL instruction set. That is, there is a common language runtime and API library, implemented in MSIL, executing customer-generated MSIL assemblies natively. Perhaps, the chip even has its microcode optimized for MSIL. Assume, now, that MSIL assemblies have pre- and post-loading security properties like JavaCards - wherein a user-generated but pre-loaded assembly might subclass the CLR runtime's own behavior - to add a crypto service provider, for one example, add a .NET remoting channel, for another, and configure the channel's data security scheme for national requirements, in a yet third option. Assume now that Intel, AMD and Sony/Hitachi add three items to their motherboard chipsets: the bus support for TCPA delegation controls, a secure storage compartment whose control is delegated to the TPM, and an MSIL interpreter that creates another hardware compartment - one that sandboxes the Pentium's own emulation of an MSIL machine from non-managed OS and traditional Bios and ACPI/"monitoring" code. Lets also assume Transmeta similarly field download new microcode to their chips, also, to the same effect, with a TPM function built in, perhaps. Assume Sony motivate this with a DRM pitch, and next generation DVD writers come with DSPs suitably equipped for enforcing these issues, at the codec level. Lets assume now that the TPM plays the role it was always intended to perform (and I remember seeing some of the very first silicon masks in 1997) - limit access to critical hardware functions to only managed code ((i.e. _emulated MSIL_ code, today) . And now lets assume that a .Net smartcard supports PCSC v2 service enumeration interfaces and hosts a .NET implementation of the muscle applet (with Indigo-binary-encoded soap apdu formatter, working with a similar APDU serialization module in a new libmusclecard plug-in). Perhaps, now we can put 2 and 2 together, and see if it makes 4. Lets assume that the .NET Framework v2 applies the new ipc:// channel for all communications between the managed code on the local host and the muscle applet on the .NET smartcard access over an untrusted CCID USB link - whose ((*) some how tobetrusted ) enumeration process registers the card as an OS-managed system resource. This would allow conventional Intel-motherboard/Microsoft-OS system cooperation to treat the card as a local device, and thus the ipc:// channel can facilitate remoting, given the code security architecture could treat this as a _local_ system data t
[Muscle] support for all readers with a PIN pad
Hello, I have ported the PKCS#11 module, the MCardPlugin and the MuscleCard Applet to support my card terminal which has a pin pad and display. So I can enter the PIN with it. I asked this question maybe in a similar way some time ago. I use for the PC/SC command SCardControl and the CT-BCS standard. I got the answer that the special parameter for the SCardControl function is proprietary for each card terminal. Is there an easy possibility to support all readers with a pin pad and display? A solution would be a configuration file. But this should be contained in the configuration file for pcsclite. Bye, Karsten ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] .Net remoting channel, muscle://
Anders Rundgren wrote: You are absolutely right! The question is then: Will it happen? How and why? That is of course impossible to know at this stage but I can imagine that there will be operators that will market "untangled" subscriptions. Actually the whole phone market is in a giant transformation when the services are on the Internet rather than in the regulated "phone nets". And then comes things like WLAN, VoIP, Skype etc. that totally changes the fundamentals of the business. My guess is that big organizations will not accept that their employees use expensive operator- controlled lines if they already have a working WLAN. I went through an interesting paradigm shift in this area recently. Last December, I bought a Motorola v710 phone and extended my contract with Verizon for 2 more years [1] to get the subsidized price on the phone. Well, this phone was advertised as having everything anyone could ever want - PDA, calendar, contact list, Bluetooth, camera, MP3 player, TF (small version of SD) card slot, you name it, the phone was advertised to have it. So, I get the phone home and find out some disturbing things. One is that the Bluetooth implementation on the phone only lets me use a headset for audio and use the Bluetooth as a modem - no object transfer of things like contact lists, data files, etc... Verizon has disabled those Bluetooth features for "security reasons" [2]. The camera on the phone sucks. I mean, it really sucks - my cheap 640X480 Intel webcam takes better pictures than this 1.2MP camera. The phone can not play ringtones off of the TF card, only from the phone's (limited) internal memory. A recent firmware update from Verizon even disables transferring audio files from the TF card to the phone's internal memory, so that YOU HAVE TO PAY VERIZON FOR EACH RINGTONE YOU WANT TO DOWNLOAD INTO THE PHONE. I guess this is also for "security" reasons. So, I look into what it would take to write my own software for the phone - well, all code that goes into the phone needs to be signed for the particular phone *AND* you need to pay a per-copy license fee to get your copy signed. Qualcom just loves this (the phone is based on BREW, which, if you replace the "B" with the letters "SC" you'll understand what Qualcom and Verizon are doing to the customers). OK, enough is enough - the hassles of a closed, proprietary phone are just not worth it to me, so I went out and bought an HP iPAQ - it's got WiFi and Bluetooth, a 1.2MP camera, an MP3 player, an SD card slot, and, best of all, no restrictions on data transfer between storage devices or the network, it works on the WiFi networks that are in the places that I want to use it, and the cost of software development for it is almost zero. I'm waiting for the day that there will be a big revolution in this country (US) when people will finally get fed up with the strong-arm tactics of the cellular carriers and the idiocy of having multiple, incompatible cellular systems. mike [1] Verizon has very good cellular coverage where I live, and so as strictly a radio cellular carrier, they are fine for my needs. I just wish they would keep their fingers out of my phone's firmware. [2] The "security" of their bottom line, not any "security" in the technical sense, especially since other carriers that have deployed the v710 don't have such restrictions on it's feature set. ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
[Muscle] help needed getting JCOP20 working with muscle
hi, I have successfully loaded the applet on my engineering sample JCOP20 using eclipse and the JCOPtools , but after that , i tried to use this card under linux using the packages found on www.linuxnet.com , but got nothing to work properly. Pcscd work and my card reader is recognised . card insertion/removal is shown in the logs , but every program i tried said " no tokens " or "unrecognised token". what can i do to get it working ? ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
Re: [Muscle] .Net remoting channel, muscle://
Michael Bender wrote: >This is why we need to have legislation to breakup the stranglehold >that carriers have on phones, and to make cell phones a true >commodity where the marketplace determines the features, just as >we have with regular old POTS phones today. You are absolutely right! The question is then: Will it happen? How and why? That is of course impossible to know at this stage but I can imagine that there will be operators that will market "untangled" subscriptions. Actually the whole phone market is in a giant transformation when the services are on the Internet rather than in the regulated "phone nets". And then comes things like WLAN, VoIP, Skype etc. that totally changes the fundamentals of the business. My guess is that big organizations will not accept that their employees use expensive operator- controlled lines if they already have a working WLAN. Anders Rundgren member of TrustedComputingGroup ___ Muscle mailing list Muscle@lists.musclecard.com http://lists.drizzle.com/mailman/listinfo/muscle
