Re: [opensc-devel] Add card minidriver base on trunk.
On 02/09/2010 09:04 AM, François Leblanc wrote: Concerning your fixup, I remember you that mingw32 seems not to have winscard.h it's why I've make a complex cardmod.h detection since if you don't have winscard.h you use internal-winscard.h I think the _right_ way in long term would be to clean up internal-winscard.h and submit it for upstream mingw32 inclusion as winscard.h. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
I use mingw-w64 which has winscard.h available. Much better maintained and support both win32 and win64. On Tue, Feb 9, 2010 at 10:50 AM, Kalev Lember ka...@smartlink.ee wrote: On 02/09/2010 09:04 AM, François Leblanc wrote: Concerning your fixup, I remember you that mingw32 seems not to have winscard.h it's why I've make a complex cardmod.h detection since if you don't have winscard.h you use internal-winscard.h I think the _right_ way in long term would be to clean up internal-winscard.h and submit it for upstream mingw32 inclusion as winscard.h. -- Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
No need to change gina, simple configuration will do if the CSP is written properly. On Tue, Feb 9, 2010 at 9:15 AM, Peter Stuge pe...@stuge.se wrote: François Leblanc wrote: For login is still a bit more difficult since you need a domain controller Configured for login with certificats Or something like pGina. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Am Dienstag 09 Februar 2010 10:43:04 schrieb Alon Bar-Lev: No need to change gina, simple configuration will do if the CSP is written properly. but the default GINA still requires (for smart card authentication) that the machine is part of an active directory domain, and that the domain administrator configured smart card authentication (e.g. by using microsoft CA connecting it with AD somehow) - I guess? thus pGina would be a lightwight variant to use with standalone computers? (if it has a smart card plugin. not sure, but the web page and forums look like it is a dead project - not many messsages in quite a while...) documenting a test case for smart card authentication would be nice, even if all that complexity is required with official microsoft products. pGina could still be mentioned as an alternative for different setups. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Oh... If you wish to have LOCAL smartcard login, GINA is the right solution. But I fail to see how it extend security... :) Example... you require smartcard to access the computer, I turn it off and boot from CDROM and access your files. Or... you require smartcard to access the computer, I turn it off and remove the harddrive and read its contents. Local security may be achieved by simply encrypting the disk (with/without) smartcard. Alon. On Tue, Feb 9, 2010 at 12:49 PM, Andreas Jellinghaus a...@dungeon.inka.de wrote: Am Dienstag 09 Februar 2010 10:43:04 schrieb Alon Bar-Lev: No need to change gina, simple configuration will do if the CSP is written properly. but the default GINA still requires (for smart card authentication) that the machine is part of an active directory domain, and that the domain administrator configured smart card authentication (e.g. by using microsoft CA connecting it with AD somehow) - I guess? thus pGina would be a lightwight variant to use with standalone computers? (if it has a smart card plugin. not sure, but the web page and forums look like it is a dead project - not many messsages in quite a while...) documenting a test case for smart card authentication would be nice, even if all that complexity is required with official microsoft products. pGina could still be mentioned as an alternative for different setups. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
I have some fixups to the build. Great Thank you. Can you please send me a usable cardmod.h so I can compile this stuff? I will send you in private way. Also, can we put the .inf and .reg anywhere else but bin? The .reg is not to stay (just for example until we made it by a tool) The .inf is close to opensc-cardmod.dll since the .inf should copy opensc-cardmod.dll To system32. Now If I put opensc-cardmod.dll in system32 and use it this don't work, I guess librairies used by opensc-cardmod.dll are not found in this case even thougth the path is set to the bin directory of opensc. If I use opensc-cardmod directly on bin with other dll this working. Regarding the 32bit and 64bit card modules, we do not compile both 64bit and 32bit especially you don't put the suffix of 64 to the card module. Suffix should be fixed - this for sure, I will handle this. I keep this part separatly since I don't know anything about the 64bit,don't know If it's necessarry... But I am not sure the the SmartCardCardModule64 is indeed 64bit and the SmartCardCardModule is 32bit. Also, how do you support multiple cards in the .inf file? To add a card extend the .inf file like this: [Minidriver.NTx86] %CardDeviceName%=Minidriver32_Install,SCFILTER\CID_00640181010c829000 %CardDeviceName%=Minidriver32_Install,SCFILTER\CID_00640181010c829000 - add your card CID_ provided by windows 7 [AddRegDefault] HKLM, %SmartCardName%,ATR,0x0001,3f,69,00,00,00,64,01,00,00,00,80,90,00 HKLM, %SmartCardName%,ATRMask,0x0001,ff,ff,ff,ff,ff,ff,ff,00,00,00,f0,ff,ff HKLM, %SmartCardName%,Crypto Provider,0x,Microsoft Base Smart Card Crypto Provider HKLM, %SmartCardName%,Smart Card Key Storage Provider,0x,Microsoft Smart Card Key Storage Provider HKLM, %SmartCardName%,8001,0x,%SmartCardCardModule% HKLM, %SmartCardNameToto%,ATR,0x0001,3f,69,00,00,00,64,01,00,00,00,80,90,00 - add your ATR card HKLM, %SmartCardNameToto%,ATRMask,0x0001,ff,ff,ff,ff,ff,ff,ff,00,00,00,f0,ff,ff - Add your ATR Mask HKLM, %SmartCardNameToto%,Crypto Provider,0x,Microsoft Base Smart Card Crypto Provider HKLM, %SmartCardNameToto%,Smart Card Key Storage Provider,0x,Microsoft Smart Card Key Storage Provider HKLM, %SmartCardNameToto%,8001,0x,%SmartCardCardModule% Thanks! Concerning your fixup, I remember you that mingw32 seems not to have winscard.h it's why I've make a complex cardmod.h detection since if you don't have winscard.h you use internal-winscard.h but Cardmod.h still use winscard.h (it's code provided by other ms). Have you an idea best way to handle this? I think about perhaps a symbolic link winscard.h-internal-winscard.h make on build time? What do you think about? Regards, François. smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
François Leblanc wrote: For login is still a bit more difficult since you need a domain controller Configured for login with certificats Or something like pGina. //Peter pgpIS4yXlqXQg.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
On Sat, Feb 6, 2010 at 9:50 AM, Andreas Jellinghaus a...@dungeon.inka.de wrote: Am Freitag 05 Februar 2010 19:51:00 schrieb Alon Bar-Lev: Also, can we put the .inf and .reg anywhere else but bin? doesn't windows install the files if you double-click an inf file (or right-click / install)? it needs to find the files? Ok, currently the CopyFiles sections are empty, but we could put all required dlls etc. there. maybe it would be easiest for windows user to have a flat zip file with all files in the base directory, and the option for the users to double-click the inf file, which then copies all files to some place. (no, I don't have any experience with that,but some drivers are installed that way, aren't they?) The inf file management is very hard to maintain and produce something sane. It great for drivers but not software. I prefer we do all what needed in the install batch file until someone come forward and maintain msi based package. Regarding the 32bit and 64bit card modules, we do not compile both 64bit and 32bit especially you don't put the suffix of 64 to the card module. Suffix should be fixed - this for sure, I will handle this. But I am not sure the the SmartCardCardModule64 is indeed 64bit and the SmartCardCardModule is 32bit. Also, how do you support multiple cards in the .inf file? worst case: one inf file per card. but I hope there is a better way. btw: why don't you export DllMain? I thought it needs to be exported, so it will be found. DllMain is a special symbol, the loader runs this function of every Dll loaded before the main program is run / continues to run. Not sure if that continues to work without the export. As far as I know DllMain is called by the CRT [1] so the DllMain itself much like main should not be exported. [1] http://msdn.microsoft.com/en-us/library/988ye33t%28VS.80%29.aspx ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Am Samstag 06 Februar 2010 10:34:03 schrieb Alon Bar-Lev: The inf file management is very hard to maintain and produce something sane. It great for drivers but not software. I prefer we do all what needed in the install batch file until someone come forward and maintain msi based package. ok. is there any new method to create those? I know nsis installer (creates exe files I think) and wix (horrible complex xml stuff to create msi files - never found out even how to get started). btw: why don't you export DllMain? I thought it needs to be exported, so it will be found. DllMain is a special symbol, the loader runs this function of every Dll loaded before the main program is run / continues to run. Not sure if that continues to work without the export. As far as I know DllMain is called by the CRT [1] so the DllMain itself much like main should not be exported. [1] http://msdn.microsoft.com/en-us/library/988ye33t%28VS.80%29.aspx ah, I thought if it wasn't in the export list, the linker might remove the symbol and maybe even optimize away the whole function. so there is some magic mechanism in the linker (at least for windows dlls) to keep that symbol and function? then fine with me. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
On Sat, Feb 6, 2010 at 12:38 PM, Andreas Jellinghaus a...@dungeon.inka.de wrote: Am Samstag 06 Februar 2010 10:34:03 schrieb Alon Bar-Lev: The inf file management is very hard to maintain and produce something sane. It great for drivers but not software. I prefer we do all what needed in the install batch file until someone come forward and maintain msi based package. ok. is there any new method to create those? I know nsis installer (creates exe files I think) and wix (horrible complex xml stuff to create msi files - never found out even how to get started). I prefer tools that can be used in cross environment. nsis is a good example of such tool. btw: why don't you export DllMain? I thought it needs to be exported, so it will be found. DllMain is a special symbol, the loader runs this function of every Dll loaded before the main program is run / continues to run. Not sure if that continues to work without the export. As far as I know DllMain is called by the CRT [1] so the DllMain itself much like main should not be exported. [1] http://msdn.microsoft.com/en-us/library/988ye33t%28VS.80%29.aspx ah, I thought if it wasn't in the export list, the linker might remove the symbol and maybe even optimize away the whole function. so there is some magic mechanism in the linker (at least for windows dlls) to keep that symbol and function? No magic... there is an entry point of the module called _DllMainCRTStartup, the CRT implements this entry point and eventually calls DllMain, so no symbol can be optimized out. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Hi, Minidriver added. - Move libopensc/opensccm.c to cardmod/cardmod.c - build opensc-cardmod.dll leave it as is, and commit the code you posted. the code can be changed later, when there is an agreement how it can be changed. Unfortunatly I can successfully use env to transmit SCARDHANDLE and SCARDCONTEXT to Libopensc-2.dll so I use registry for now (still to be improved). Things to do, - Review libopensc/reader-pcsc.c to be better and to match needs - Add more pin management (unblocking pin etc...) - Documentations (wiki + code) - make card writeable with it (only read only for now) - and so on... Bests Regards, François smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Am Freitag 05 Februar 2010 14:18:39 schrieb François Leblanc: Hi, Minidriver added. good! note: I removed the Makefile.in. All those files generated by automake, autoconf and libtool are not submitted to svn, as they change, depending on the version of these tools used by each developer, and we are not interested in having these changes in the svn. Users that want a full tar.gz file all such generated files included can download the opensc releases, or the nightly builds from /files/opensc/snapshots/ directory. Unfortunatly I can successfully use env to transmit SCARDHANDLE and SCARDCONTEXT to Libopensc-2.dll so I use registry for now (still to be improved). ah, to transmit the handle from opensc-cardmod.dll to opensc-2.dll? hmm, we could create some backdoor, like a static public variable or some function to set a static variable. but that wouldn't be much nicer either. not sure what the best plan is. Things to do, - Review libopensc/reader-pcsc.c to be better and to match needs - Add more pin management (unblocking pin etc...) - Documentations (wiki + code) - make card writeable with it (only read only for now) - and so on... still a nice start. what works so far? can people read the certificates, login with user pin, authenticate with signature or decrypt emails? did you test with some specific applications? we could create an extra wiki page for testers, where we describe how to setup opensc with card module, and how to test various functionality, for example login with smart card authentication or using explorer or outlook with it. but I guess most test will be difficult, unless people have the necessary infrastructure already. (IIRC smart card authentication needs active directory and a microsoft PKI or something like that?) still it would be nice to document these challanges, as a step to get more people involved. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
note: I removed the Makefile.in. All those files generated by automake, autoconf and libtool are not submitted to svn, as they change, depending on the version of these tools used by each developer, and we are not interested in having these changes in the svn. Ok. Unfortunatly I can successfully use env to transmit SCARDHANDLE and SCARDCONTEXT to Libopensc-2.dll so I use registry for now (still to be improved). ah, to transmit the handle from opensc-cardmod.dll to opensc-2.dll? hmm, we could create some backdoor, like a static public variable or some function to set a static variable. but that wouldn't be much nicer either. not sure what the best plan is. We have to think about the best way to do it. still a nice start. what works so far? can people read the certificates, login with user pin, authenticate with signature or decrypt emails? did you test with some specific applications? So I've successfully read certificats (use command certutil.exe -SCinfo) And sign mails under outloock, I've reached authentification on an internal Website with internet-explorer. For login is still a bit more difficult since you need a domain controller Configured for login with certificats and I don't have one for the moment. I use for now westcos card and only this one it's why cardmod.inf and Cardmod-westcos.reg are not extend to other cards for the moment, they must be adapted for the card you want to use... we could create an extra wiki page for testers, where we describe how to setup opensc with card module, and how to test various functionality, for example login with smart card authentication or using explorer or outlook with it. Yes there are some step to describe to make it more easy... but I guess most test will be difficult, unless people have the necessary infrastructure already. (IIRC smart card authentication needs active directory and a microsoft PKI or something like that?) still it would be nice to document these challanges, as a step to get more people involved. Yes it's the goal. Regards, Andreas Regards François. smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
2010/2/5 François Leblanc francois.lebl...@cev-sa.com: Hi, Minidriver added. I have some fixups to the build. Can you please send me a usable cardmod.h so I can compile this stuff? Also, can we put the .inf and .reg anywhere else but bin? Regarding the 32bit and 64bit card modules, we do not compile both 64bit and 32bit especially you don't put the suffix of 64 to the card module. Suffix should be fixed - this for sure, I will handle this. But I am not sure the the SmartCardCardModule64 is indeed 64bit and the SmartCardCardModule is 32bit. Also, how do you support multiple cards in the .inf file? Thanks! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Committed some stuff build system related, I hope I did not damage your build. One more question... Why don't you use the logging of opensc and implemented your own? 2010/2/5 Alon Bar-Lev alon.bar...@gmail.com: 2010/2/5 François Leblanc francois.lebl...@cev-sa.com: Hi, Minidriver added. I have some fixups to the build. Can you please send me a usable cardmod.h so I can compile this stuff? Also, can we put the .inf and .reg anywhere else but bin? Regarding the 32bit and 64bit card modules, we do not compile both 64bit and 32bit especially you don't put the suffix of 64 to the card module. Suffix should be fixed - this for sure, I will handle this. But I am not sure the the SmartCardCardModule64 is indeed 64bit and the SmartCardCardModule is 32bit. Also, how do you support multiple cards in the .inf file? Thanks! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Am Freitag 05 Februar 2010 19:51:00 schrieb Alon Bar-Lev: Also, can we put the .inf and .reg anywhere else but bin? doesn't windows install the files if you double-click an inf file (or right-click / install)? it needs to find the files? Ok, currently the CopyFiles sections are empty, but we could put all required dlls etc. there. maybe it would be easiest for windows user to have a flat zip file with all files in the base directory, and the option for the users to double-click the inf file, which then copies all files to some place. (no, I don't have any experience with that,but some drivers are installed that way, aren't they?) Regarding the 32bit and 64bit card modules, we do not compile both 64bit and 32bit especially you don't put the suffix of 64 to the card module. Suffix should be fixed - this for sure, I will handle this. But I am not sure the the SmartCardCardModule64 is indeed 64bit and the SmartCardCardModule is 32bit. Also, how do you support multiple cards in the .inf file? worst case: one inf file per card. but I hope there is a better way. btw: why don't you export DllMain? I thought it needs to be exported, so it will be found. DllMain is a special symbol, the loader runs this function of every Dll loaded before the main program is run / continues to run. Not sure if that continues to work without the export. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Ok, to be more clear I suggest opensc-cardmod.dll... good idea. Thank you. Yes dlls must be in Path, the Path can be update at install process. I know you can set the path for users. but can you also set the path for system processes (e.g. the login window)? Oups sorry, of courses you know that, I hope the path is common to all process But this must be checked and confirm. (...) - Update code to transmit SCARDHANDLE and SCARDCONTEXT by env to reader-pcsc.c In first step I keep actual hack code of reader-pcsc.c and if possible change it to reduce duplicate code. leave it as is, and commit the code you posted. the code can be changed later, when there is an agreement how it can be changed. Ok change only env part to make it working. please don't forget to also submit the *.reg file. you posted a binary last time as attachment, please use iconv to convert it from utf-16 to utf-8 first. that way we can see what is inside the file, and windows will still be able to install it with a right-click. I will do. Thanks, Andreas Thank you, François. smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Please send us the licence.rtf so we can check it is LGPL compatible. Thanks Ok, join licence.rtf and other. François License.tar.bz2 Description: Binary data smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Before you can download the CNG SDG you need a live.com/passport account, and sell your soul to microsoft or something like that. Mickey Mouse seems to have done that. inside the SDK there is only cardmod.h, but no example code for writing a cardmod or anything like that. So I guess François wrote everything from scratch. cutpasting single function headers is fine, no copyright on them (too small, and see the exceptions in european copyright law for compatibility). Also full documentation of the interface is available with no strings attached, and implementing the interfaces and structures from such documentation is classic reverse engineering and thus legal AFAIK. The license.rtf covers the whole CNG SDK. It allowes to redistribute some files, but cardmod.h is not one of them. thus everyone compiling opensc with cardmod support will need to download/license the CNG SDK himself. In my opinion, using a plattform header file doesn't taint the software using it, thus the binaries are under LGPL only (no influence via the header file from microsoft). so unless some new unknown template file was used for the driver, I think we are fine copyright wise and can accept the patch without issues. btw: microsoft tells me about cardmod.h: The native card module interface is defined in cardmod.h, which is included in current Windows Vista releases of the Platform SDK. http://msdn.microsoft.com/en-us/magazine/cc163521.aspx so maybe people won't need the CNG SDK. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Andreas Jellinghaus wrote: Before you can download the CNG SDG you need a live.com/passport account, and sell your soul to microsoft or something like that. It requires looking around a bit, but it is possible to create a passport account using any email address. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Am Mittwoch 03 Februar 2010 09:33:11 schrieb François Leblanc: There are a lot of stuff to do to improve this module (documentation, key Managing, writing card and so on) this why I need some help but I can't be helped if nobody can't access the code so It's why I wish to put this base. Moreover It will be more easy for me to improve this once integrated on trunk. ok, fine! * the key handling: IIRC opensc can tell you what keys a card supports, maybe that would be more accurate than claiming those fixed key sizes ??? I saw this: + pKeySizes-dwMinimumBitlen = 512; + pKeySizes-dwDefaultBitlen = 1024; + pKeySizes-dwMaximumBitlen = 16384; in CardQueryKeySizes so I guess tells the caller which key sizes are available? We have that info from the card driver, so we could give detailed information. on the other hand, the CNG interface has min/max/step/default values, but smart cards support usualy only a few special values (e.g. 512,768,1024, 2048), but no other values between those. so we can't match that directly anyway. no worries :) Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Am Mittwoch 03 Februar 2010 10:37:37 schrieb François Leblanc: if you used some sample minicard driver template, we would need to mention that and have a look at its license. but the cng sdk contains nothing like that. if you used no template file, then there is absolutely no problem, nothing to document No I don't use sample code from cng sdk but the documentation of minidriver available on the net. great, that way the current patch is perfectly fine from my point of view (I am not a lawyer etc.). maybe add a small comment at the start of the file, that cardmod.h from CNG SDH or plattform SDK is required, but the file was written from public documentation (which imposes no license restriction). Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
On Feb 3, 2010, at 12:02 , Andreas Jellinghaus wrote: Am Mittwoch 03 Februar 2010 10:37:37 schrieb François Leblanc: if you used some sample minicard driver template, we would need to mention that and have a look at its license. but the cng sdk contains nothing like that. if you used no template file, then there is absolutely no problem, nothing to document No I don't use sample code from cng sdk but the documentation of minidriver available on the net. great, that way the current patch is perfectly fine from my point of view (I am not a lawyer etc.). Things to think about: - Will it be part of OpenSC (a cross-platform smart card library) or a platform specific plugin? - If yes, do we package it with opensc-x.x.x.tar.gz? - If we include a windows minidriver in libopensc tarball, so should the tokend be. Neither can be built or used on other platforms. - I don't like the reader-pcsc.c contents at all. The same problem has been addressed before, with different approaches, see http://itacns.corp.it/hg/itacns/file/adc0b2ceec86/patches/300-env-scardhandle.patch for alternative example. I applied the patch, what can I do with it on a Linux machine? -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
On Feb 3, 2010, at 13:25 , Andreas Jellinghaus wrote: Am Mittwoch 03 Februar 2010 11:50:38 schrieb Martin Paljak: Things to think about: - Will it be part of OpenSC (a cross-platform smart card library) or a platform specific plugin? - If yes, do we package it with opensc-x.x.x.tar.gz? it would be fine with me to do that. I'm not sure it would be the best and only option. - If we include a windows minidriver in libopensc tarball, so should the tokend be. Neither can be built or used on other platforms. also fine with me. the benefit would be: users of opensc API would be in the opensc source repository. we could let the world know, that everyone else should please use the pkcs#11 api instead of libopensc. if we keep card module and tokend seperate, we have to keep the api stable so they will work with the released new and old versions of opensc. It is not about different versioning or anything similar, it is about packaging and source code organization. Consolidating platform components to the opensc svn is good, mungling it down the existing source structure not necessarily so good. as far as I know both are too much involved in opensc internals to port them to pkcs#11 api. You have the correct understanding. - I don't like the reader-pcsc.c contents at all. The same problem has been addressed before, with different approaches, see http://itacns.corp.it/hg/itacns/file/adc0b2ceec86/patches/300-env-scardhan dle.patch for alternative example. well, but that is a restriction handed to us by microsoft windows base CSP right? we need to work with whatever microsoft build, even if we don't like their design. or is there a better way to work with that? The question here is how the feature (pre-opened card handles) is implemented inside libopensc. The interface towards BaseCSP is indeed constant, but the implementation inside libopensc should be reviewed a bit, as there have been other (and alternative) implementations. Current reader-pcsc.c copypaste does not look like a long-term solution. It is like secure messaging - there is no question in how the feature works, but different ideas how and where the encryption is done or keys fetched from. I applied the patch, what can I do with it on a Linux machine? nothing, you need microsoft CNG SDK or plattform SDK to compile the card module for windows. it is only for use with the microsoft base CSP. How do I compile it, where do I download the SDK from? That should be documented in the wiki page for example. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Am Mittwoch 03 Februar 2010 12:50:42 schrieb Martin Paljak: [putting card module in opensc source / tar.gz] I'm not sure it would be the best and only option. so lets discuss alternatives. It is not about different versioning or anything similar, it is about packaging and source code organization. Consolidating platform components to the opensc svn is good, mungling it down the existing source structure not necessarily so good. the diffstat is: configure.ac | 31 etc/opensc.conf.in| 10 src/libopensc/Makefile.am |6 src/libopensc/ctx.c |3 src/libopensc/internal-winscard.h |2 src/libopensc/internal.h |1 src/libopensc/opensccm.c | 1703 ++ src/libopensc/reader-pcsc.c | 358 +++ win32/Makefile.am |4 win32/opensccm.inf| 148 +++ and the *.reg file for win32 that is missing (was posted last time). as far as I can see the modified reader_driver needs to be in libopensc/ and we need the supporting code (configure, internal changes etc.) for it. so there is litte we can do different. the inf and reg files are fine in win32/ directory I think. so the only variable I see is the placement of opensccm.c (and the name for it - cardmod.c is ok for you?). in my opinion a single source file could be placed in a seperate directory. and we can either create a seperate dll that contains this extra code and links opensc-2.dll (or includes it static). but what is best? the extra directory would be fine with me, not a big deal. but an extra dll? I would prefer not to have that, we had already enough trouble with the many dlls we had. so it looks to me like a single dll (opensc-2.dll) with the cardmod included is the better idea. and wether we put the code in an extra directory or not is not a big deal for me, I'm happy with either solution. as far as I know both are too much involved in opensc internals to port them to pkcs#11 api. You have the correct understanding. ok, thanks. The question here is how the feature (pre-opened card handles) is implemented inside libopensc. The interface towards BaseCSP is indeed constant, but the implementation inside libopensc should be reviewed a bit, as there have been other (and alternative) implementations. Current reader-pcsc.c copypaste does not look like a long-term solution. you know that code much better than I do. but didn't the cardmod reader also share a lot of code with pcsc reader driver? IIRC that was the argument for keeping it in that file, and not creating a new reader-cardmod.c file. what do you suggest should be done? and is it ok to commit the patch now and work on it, or does it have to be changed before it gets into svn? How do I compile it, where do I download the SDK from? That should be documented in the wiki page for example. he posted some instructions last time. you need the cardmod.h file from Microsoft CNG Development Kit (plattform SDK might contain it as well), point configure to it, and you are done. to use it use the reg (older windows) or inf (newer windows) files. These contain code for the Westcos cards as far as I understand, and need to be extended to handle other cards as well. btw: François, do you know if several cards can claim one atr? in that case we could claim all cards - the user can modify opensc.conf to remove some drivers, thus opensc will not know the card and hopefully ignore it / leave it to some other software. or can you have only opensc or some other software installed, but never both? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
as far as I know both are too much involved in opensc internals to port them to pkcs#11 api. You have the correct understanding. ok, thanks. I Will try to think about it. The question here is how the feature (pre-opened card handles) is implemented inside libopensc. The interface towards BaseCSP is indeed constant, but the implementation inside libopensc should be reviewed a bit, as there have been other (and alternative) implementations. Current reader-pcsc.c copypaste does not look like a long-term solution. you know that code much better than I do. but didn't the cardmod reader also share a lot of code with pcsc reader driver? IIRC that was the argument for keeping it in that file, and not creating a new reader-cardmod.c file. Yes, first patch included a new reader-opensccm, I give up this way. what do you suggest should be done? and is it ok to commit the patch now and work on it, or does it have to be changed before it gets into svn? How do I compile it, where do I download the SDK from? That should be documented in the wiki page for example. he posted some instructions last time. you need the cardmod.h file from Microsoft CNG Development Kit (plattform SDK might contain it as well), point configure to it, and you are done. to use it use the reg (older windows) or inf (newer windows) files. These contain code for the Westcos cards as far as I understand, and need to be extended to handle other cards as well. Yes for now opensccm-westcos.reg it's a sample for extend to other cards (it can be generating I think by exe tool instand of being write once, like plug your card call : opensc-tool -carmod and use the card under windows). Opensccm.inf is to be extended with all card/atr managed by opensc (one file Will be enougth but require HID give by windows for each kind of card) btw: François, do you know if several cards can claim one atr? in that case we could claim all cards - the user can modify opensc.conf to remove some drivers, thus opensc will not know the card and hopefully ignore it / leave it to some other software. or can you have only opensc or some other software installed, but never both? For exemple, actually, I use Outloock signing email, connect to linux serveur with puttysc and opensc-pkcs11.dll and access to secure website with Firefox (opensc-pkcs11.dll) all with my same card managed by opensc core. (this under windows 7). (When card is in use opensc Connect it with SCARD_SHARE_MODE and work with it) When cardmodule is in use each card managed by opensc (and present in .inf file) that you insert is take in account, reading certificats and put it in store ready to be use by application. Regards, Andreas Regards, François smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Sure, I know the case with windows and BaseCSP and why the driver rocks, if finalized and why it is good and important. But the way it is included and integrated with the rest of OpenSC should be discussed. I don't like the idea of putting it on the same level with libopensc and I don't like the current pcsc driver diff. To see what it does and to be able to change anything, a doc on how to compile it is needed (you probably know it and can put necessary links in the wiki page and save others a hour of googling) Ok, For cross compiling you can refer to http://www.opensc-project.org/pipermail/opensc-devel/2010-January/013162.htm l please, use the latest patch I provide. For CNG : http://www.microsoft.com/downloads/details.aspx?familyid=1ef399e9-b018-49db- a98b-0ced7cb8ff6fdisplaylang=en Regards, François. smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
On Feb 3, 2010, at 14:28 , Andreas Jellinghaus wrote: Consolidating platform components to the opensc svn is good, mungling it down the existing source structure not necessarily so good. the diffstat is: configure.ac | 31 etc/opensc.conf.in| 10 src/libopensc/Makefile.am |6 src/libopensc/ctx.c |3 src/libopensc/internal-winscard.h |2 src/libopensc/internal.h |1 src/libopensc/opensccm.c | 1703 ++ src/libopensc/reader-pcsc.c | 358 +++ win32/Makefile.am |4 win32/opensccm.inf| 148 +++ and the *.reg file for win32 that is missing (was posted last time). as far as I can see the modified reader_driver needs to be in libopensc/ and we need the supporting code (configure, internal changes etc.) for it. so there is litte we can do different. The API used is still PC/SC, just the way the card handle is received is different. so the only variable I see is the placement of opensccm.c (and the name for it - cardmod.c is ok for you?). Yes. in my opinion a single source file could be placed in a seperate directory. and we can either create a seperate dll that contains this extra code and links opensc-2.dll (or includes it static). Yes, see the picture @ http://www.opensc-project.org/opensc/wiki/MiniDriver but what is best? the extra directory would be fine with me, not a big deal. but an extra dll? I would prefer not to have that, we had already enough trouble with the many dlls we had. dll-s are OK if they have a purpose, stuffing many interfaces in a single dll could be useable but not necessarily the best idea. A single interface from a single DLL is the easiest concept to grasp for anyone. The question here is how the feature (pre-opened card handles) is implemented inside libopensc. The interface towards BaseCSP is indeed constant, but the implementation inside libopensc should be reviewed a bit, as there have been other (and alternative) implementations. Current reader-pcsc.c copypaste does not look like a long-term solution. you know that code much better than I do. but didn't the cardmod reader also share a lot of code with pcsc reader driver? IIRC that was the argument for keeping it in that file, and not creating a new reader-cardmod.c file. It is in fact a corner case of the PC/SC driver, not a separate driver. what do you suggest should be done? and is it ok to commit the patch now and work on it, or does it have to be changed before it gets into svn? Things required to implement support for existing card handles provided to minidriver should be done as a) conditional code and/or the module built in a separate pass b) smaller code changes in the current code path. Current amount of copypaste should be reduced and should not be commited. How do I compile it, where do I download the SDK from? That should be documented in the wiki page for example. he posted some instructions last time. you need the cardmod.h file from Microsoft CNG Development Kit (plattform SDK might contain it as well), point configure to it, and you are done. to use it use the reg (older windows) or inf (newer windows) files. These contain code for the Westcos cards as far as I understand, and need to be extended to handle other cards as well. btw: François, do you know if several cards can claim one atr? in that case we could claim all cards - the user can modify opensc.conf to remove some drivers, thus opensc will not know the card and hopefully ignore it / leave it to some other software. or can you have only opensc or some other software installed, but never both? Last time I worked with a minidriver you *had* to have the ATR-s your card is willing to handle in the registry. Installer and registry writer would be necessary. For some reason my build instance did not pick up the cardmod.h file the first two times I tried. The header can not be included in the package for licensing reasons? -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Am Mittwoch 03 Februar 2010 16:37:31 schrieb Martin Paljak: so the only variable I see is the placement of opensccm.c (and the name for it - cardmod.c is ok for you?). Yes. in my opinion a single source file could be placed in a seperate directory. and we can either create a seperate dll that contains this extra code and links opensc-2.dll (or includes it static). Yes, see the picture @ http://www.opensc-project.org/opensc/wiki/MiniDriver ok. hmm, but if we create an extra dll for the card module, the original name opensccm might be better. move the file to cardmod/opensccm.c and create opensccm.dll? is that ok for you. dll-s are OK if they have a purpose, stuffing many interfaces in a single dll could be useable but not necessarily the best idea. A single interface from a single DLL is the easiest concept to grasp for anyone. yes. but it requires that not only windows can load the dll mentioned in the registry, but that this dll can load the other dll it depends on as well. so I guess they all have to be in the path and/or system32 directory (not sure if you can set the path for the logon process, thus I guess system32 or system64 is the place it needs to be. hmm, is the logon process on 64bit windows a 64bit application? then we would need a 64bit card module and depending libraries I guess). you know that code much better than I do. but didn't the cardmod reader also share a lot of code with pcsc reader driver? IIRC that was the argument for keeping it in that file, and not creating a new reader-cardmod.c file. It is in fact a corner case of the PC/SC driver, not a separate driver. what do you suggest should be done? and is it ok to commit the patch now and work on it, or does it have to be changed before it gets into svn? Things required to implement support for existing card handles provided to minidriver should be done as a) conditional code and/or the module built in a separate pass it is! unless you have defined HAVE_CARDMOD_H nothing is changed (except for that small little extra field in one structure). b) smaller code changes in the current code path. Current amount of copypaste should be reduced and should not be commited. sorry, I can't help with that, as I now next to nothing about reader-pcsc.c. can you work with François on that? my preference would be to commit the current code (with other directories / filenames etc.): the changes to existing code are minimal and cutpaste issues can be reduced later without affecting other code. Last time I worked with a minidriver you *had* to have the ATR-s your card is willing to handle in the registry. Installer and registry writer would be necessary. both? ah, ok. let my rephrase my question this way: can you install both a vendors cardmodule and opensc cardmodule at the same time, or would they conflict? we will need to tell people not only how to register opensc as card module, but also how to get rid of those registry keys, if they cause problems for some vendors card module. and maybe also make sure we don't blindly overwrite registry keys, but notice if they already exist and handle that somehow. For some reason my build instance did not pick up the cardmod.h file the first two times I tried. hmm. configure error? can you check config.log for the reasons? The header can not be included in the package for licensing reasons? yes, microsoft doesn't license it for distribution. that is stupid, but well... it should be part of the plattform SDK too, so every normal windows developer with visual C has it already on his disk somewhere. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Andreas Jellinghaus wrote: The header can not be included in the package for licensing reasons? yes, microsoft doesn't license it for distribution. that is stupid, but well... it should be part of the plattform SDK too, Are you sure that the file is not one of the files in the SDK which are in fact freely re-distributable? There is a list of files in the SDK which can be re-distributed. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
Hello, ok. hmm, but if we create an extra dll for the card module, the original name opensccm might be better. move the file to cardmod/opensccm.c and create opensccm.dll? is that ok for you. Ok, to be more clear I suggest opensc-cardmod.dll... dll-s are OK if they have a purpose, stuffing many interfaces in a single dll could be useable but not necessarily the best idea. A single interface from a single DLL is the easiest concept to grasp for anyone. yes. but it requires that not only windows can load the dll mentioned in the registry, but that this dll can load the other dll it depends on as well. so I guess they all have to be in the path and/or system32 directory (not sure if you can set the path for the logon process, thus I guess system32 or system64 is the place it needs to be. hmm, is the logon process on 64bit windows a 64bit application? then we would need a 64bit card module and depending libraries I guess). Yes dlls must be in Path, the Path can be update at install process. b) smaller code changes in the current code path. Current amount of copypaste should be reduced and should not be commited. sorry, I can't help with that, as I now next to nothing about reader-pcsc.c. can you work with François on that? Ok for me if a convenient solution can be find. my preference would be to commit the current code (with other directories / filenames etc.): the changes to existing code are minimal and cutpaste issues can be reduced later without affecting other code. It's my point of view too. Last time I worked with a minidriver you *had* to have the ATR-s your card is willing to handle in the registry. Installer and registry writer would be necessary. both? ah, ok. I don't understand exactly but Installer (.inf file) write registry so in windows 7 You need only installer (a .inf file) and for Vista you need registry writer only... let my rephrase my question this way: can you install both a vendors cardmodule and opensc cardmodule at the same time, or would they conflict? The link betwin a card and a module dll is made by ATR in registry, You provide ATR, ATRMask and CSP to use. I'm not sure but first matching module take the hand on others... we will need to tell people not only how to register opensc as card module, but also how to get rid of those registry keys, if they cause problems for some vendors card module. and maybe also make sure we don't blindly overwrite registry keys, but notice if they already exist and handle that somehow. Oh yes I don't think about that. Regards, Andreas So I plan to: - Move libopensc/opensccm.c to cardmod/cardmod.c - build opensc-cardmod.dll - Update code to transmit SCARDHANDLE and SCARDCONTEXT by env to reader-pcsc.c In first step I keep actual hack code of reader-pcsc.c and if possible change it to reduce duplicate code. Are you agree with this? Martin can you say if it's acceptable for you ? Andreas ? Best Regards, François smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
On Feb 4, 2010, at 09:38 , François Leblanc wrote: So I plan to: - Move libopensc/opensccm.c to cardmod/cardmod.c - build opensc-cardmod.dll Perfect. - Update code to transmit SCARDHANDLE and SCARDCONTEXT by env to reader-pcsc.c I'm not saying that the environment variable approach is the best approach. I'm just saying that there are alternative methods. Martin can you say if it's acceptable for you ? I hope to get to successfully compile the cardmod today so that I could test/provide code instead of just nagging :) -- Martin Paljak http://martin.paljak.pri.ee +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add card minidriver base on trunk.
a few comments from my side: * please change all debug strings to english :) * opensccm is a big cryptik, what about cardmodule or so? (if it is in the opensc source code, we know it relates to opensc, so no need to put opensc in the name) * I guess opensccm.c uses some template from microsoft? please document in the file header to give credit where due. Using a template of a published API for your own code is fine I guess - no copyright/license issue here. Unless of course the template had a copyright header/license attached that says otherwise. * some comments in the code wouln't hurt :) for example why the special handling for winlogon? and how does it work in general: is there a central process loading this module (and apps talking to it with rpc)? or will each app load the module again (thus possible conflicts with more than one app using smart cards)? * the key handling: IIRC opensc can tell you what keys a card supports, maybe that would be more accurate than claiming those fixed key sizes if you want to rename the file, that would be best done before a commit. but all other changes are not important enough, so you could commit the code as is from my point of view. a wiki page with more details would be real nice once the code is commited :) Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
