Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
On 2012-02-19 19:11, Peter Stuge wrote: Anders Rundgren wrote: You didn't hear my presentation at FOSDEM 2012 but it was about creating a token with a standard API so that you would as a customer be able to just plug it in. This is an advantage of USB P11. In Windows 8 and later there doesn't even have to be a driver installed, since WinUSB comes with the operating system already and can be loaded automatically if the device follows some Microsoft-invented USB extensions. Only one PKCS#11 DLL is neccessary, and nothing more. I don't know what USB P11 is, can you send me a pointer? Although PKCS #11 is good it is not particularly popular on Windows. It is essentially only Mozilla who insists on not supporting the native Windows crypto system. SUN/Oracle have managed to do 3(!) major Java releases (5,6,7) without PKCS #11 support for Win-64. They have though added support for Crypto-API. The total confusion on the *NIX side regarding crypto subsystem haven't been particularly beneficial for PKCS #11 either. Regarding my token-project it has no direct ties to PKCS #11; it is closer to the NXP GP-chip which is powering Google's Wallet. The reason for this is that PKCS #11 doesn't have a interface supporting secure remote provisioning, something which absolutely necessary in the mobile phone world. I have stretched this notion to include connected tokens as well with a hope reaching the critical mass needed for establishing a de-facto standard. it seems that NIST's PIV would be good choice It would be a much better candidate if there was not such a thick layer of components involved which serve little to no purpose. If you talk about the actual card standard I have no idea what you are referring to. It looks quite simple to me. If you OTOH refer to the OpenSC implementation, this is something that PIV isn't responsible for. Anyway, I know that the PIV vendors verify their cards against Microsoft's driver and that is IMO the way to go. In principle I do not argue strongly against PIV, I generally agree with your observations. But it would be nice to try to do even better. :) That is what my project is all about but that is hardly an alternative for Feitian at this stage. Anders //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] Upgrading aPass2003 Firmware to PIV
Anders Rundgren wrote: I don't know what USB P11 is, can you send me a pointer? It's my old idea of implementing PKCS#11 directly over USB. Issues have been pointed out, and they would have to be solved of course. Although PKCS #11 is good it is not particularly popular on Windows. It is essentially only Mozilla who insists on not supporting the native Windows crypto system. SUN/Oracle have managed to do 3(!) major Java releases (5,6,7) without PKCS #11 support for Win-64. They have though added support for Crypto-API. The same USB device could support Crypto-API primitives too. Regarding my token-project it has no direct ties to PKCS #11; it is closer to the NXP GP-chip which is powering Google's Wallet. The reason for this is that PKCS #11 doesn't have a interface supporting secure remote provisioning, something which absolutely necessary in the mobile phone world. Provisioning is indeed outside PKCS#11 and could be done in some other, also convenient, way. USB is really easy to use. I have stretched this notion to include connected tokens as well with a hope reaching the critical mass needed for establishing a de-facto standard. I fear that you are ahead of your time. :\ Adam Dunkels implemented the internet of things many years ago, but I don't even have IPv6. Things are changing, but still slowly. it seems that NIST's PIV would be good choice It would be a much better candidate if there was not such a thick layer of components involved which serve little to no purpose. If you talk about the actual card standard I have no idea what you are referring to. It looks quite simple to me. If you OTOH refer to the OpenSC implementation, this is something that PIV isn't responsible for. Actually neither, I refer to the entire stack of software required for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. Anyway, I know that the PIV vendors verify their cards against Microsoft's driver and that is IMO the way to go. If there's a superior alternative Microsoft may well catch up at some point. They did with USB. But it would be nice to try to do even better. :) That is what my project is all about but that is hardly an alternative for Feitian at this stage. Also agree. I'm also not suggesting Feitian to pick up on my idea. If they do that's perfectly fine and totally awesome, but I'm keeping the idea alive only because *I* think it is good and would like to try it out. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
[Ludovic, Please see below.] On 2/19/2012 7:30 AM, Peter Stuge wrote: Peter Stuge wrote: Please advise: 1) How to push a patch from GITHUB to OpenSC staging directory. In two or three sentences. I would do: One-time setup: a. Create Gerrit account and add username and public SSH key b. git clone from github which has the patch c. cd into cloned dir d. Install commit-msg hook scp -p -P 8882 www.opensc-project.org:hooks/commit-msg .git/hooks/ e. git remote add gerrit ssh://www.opensc-project.org:8882/OpenSC.git f. git config remote.gerrit.push HEAD:refs/for/master For each patch: 1. Make the current branch equal to OpenSC GitHub + the patch (git rebase) 2. Check that the patch has a Change-Id, if not, git commit --amend -C HEAD 3. git push gerrit In case multiple commits belong together in the same logical change or that they depend on each other, then the current branch should have all these commits following the last commit of OpenSC GitHub. This is my prefered way. I just found confirmation of my guess that a pull request sent to OpenSC GitHub will also arrive into Gerrit. So if already using GitHub then that is probably the easiest way. I am new to Gerrit too, but it looks like if 2 code reviews give a +1, the code will be advanced. See: https://www.opensc-project.org/codereview/ I can use my Google OpenID to Sign In, and today did a code review on: Change I51630a84: Cleanup PKCS15 PIV Card PIN flags This is a change I submitted in December, and Victor gave it a +1 So today I gave it a +1, (As I am the only PIV developer I figure I can review my own code) Looks good to me, but someone else must approve But this does not look like it is the same as Looks good to me, approved https://www.opensc-project.org/codereview/#admin,group,7 says Ludovic and Martin are the two members of the Integrators group. I might assume Ludovic and Martin are in the Administrator group, but I can not see that. https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy says: Git write access is granted to those who GetInvolved with OpenSC development and ... This would imply that there is no intent to keep write access controlled, but it might be controlled today based on the Gerrit access control. Ludovic, Can you verify if you are in the Gerrit Administrator's group? and are any of the other people listed on the GetInvolved page listed as integrators, or admins? //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Douglas E. Engert wrote: I am new to Gerrit too, All right! I'm by no means an expert, but I have been using it in several projects for a while, where I also helped with issues during the migration, so please feel free to ask any questions. but it looks like if 2 code reviews give a +1, the code will be advanced. See: https://www.opensc-project.org/codereview/ Need Code Review +2 means that one +2 review is neccessary. 2x +1 is not equivalent. I can use my Google OpenID to Sign In, and today did a code review on: Change I51630a84: Cleanup PKCS15 PIV Card PIN flags Thanks! Although since it is your patch it is perhaps a bit redundant, since you have likely reviewed your patch locally before sending it anyway. This is a change I submitted in December, and Victor gave it a +1 So today I gave it a +1, (As I am the only PIV developer I figure I can review my own code) I expect every developer to review their own code locally, already before pushing to Gerrit. The fact that you're the PIV expert is inconvenient to formalize a set of rules for, so it's something integrators will simply have to keep in the back of their head, as they look at individual changes. Looks good to me, but someone else must approve But this does not look like it is the same as Looks good to me, approved Indeed, the latter is a +2 code review. https://www.opensc-project.org/codereview/#admin,group,7 says Ludovic and Martin are the two members of the Integrators group. Right, this means that they are able to submit or integrate changes from Gerrit into the OpenSC repository on GitHub, by selecting +2 Looks good to me, approved during review, and clicking the Publish and Submit button, which is available in the web interface. Ludovic: Keep in mind that selecting +2 and clicking Publish Comments is *not* sufficient to integrate that change. Gerrit is a young tool still. :) I personally strongly prefer the SSH interface. If I was an integrator, I could have included your change with the command: ssh -p 8882 www.opensc-project.org gerrit review 51630a844e8e95e7108cb1966c5f3e21b93a463b --code-review +2 -s The hash after the review command is the patch set commit hash. Combination of Change-Id and patch set number should also work, i.e. ssh -p 8882 www.opensc-project.org gerrit review I51630a84,1 --code-review +2 -s although I haven't had success with this anywhere yet. (May be due to old an buggy versions of Gerrit!) https://www.opensc-project.org/opensc/wiki/DevelopmentPolicy says: Git write access is granted to those who GetInvolved with OpenSC development and ... This would imply that there is no intent to keep write access controlled, but it might be controlled today based on the Gerrit access control. Gerrit behaves just like a Git repository, and for those more comfortable with GitHub it's also possible to fork OpenSC there and work from that. Git write access is almost nonsensical because Git allows everyone to write everywhere. Ludovic, Can you verify if you are in the Gerrit Administrator's group? and are any of the other people listed on the GetInvolved page listed as integrators, or admins? Integrators is only Martin and Ludovic, hence those are the ones who can currently include Gerrit changes into OpenSC on GitHub. Now for the third time, I'm sure that everyone who used to have repository write access will also quickly be added to the Integrator group if they mention their account name or ID and someone in the Administrators group is around. If only Martin is admin, then I guess there's a bit of a wait state, but that's not really such a big deal, because it doesn't block further work in any way. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
On 2012-02-20 21:40, Peter Stuge wrote: Anders Rundgren wrote: I don't know what USB P11 is, can you send me a pointer? It's my old idea of implementing PKCS#11 directly over USB. Issues have been pointed out, and they would have to be solved of course. Maybe you would like to have an STM32F215-based token? 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES It may happen this year. Anders Although PKCS #11 is good it is not particularly popular on Windows. It is essentially only Mozilla who insists on not supporting the native Windows crypto system. SUN/Oracle have managed to do 3(!) major Java releases (5,6,7) without PKCS #11 support for Win-64. They have though added support for Crypto-API. The same USB device could support Crypto-API primitives too. Regarding my token-project it has no direct ties to PKCS #11; it is closer to the NXP GP-chip which is powering Google's Wallet. The reason for this is that PKCS #11 doesn't have a interface supporting secure remote provisioning, something which absolutely necessary in the mobile phone world. Provisioning is indeed outside PKCS#11 and could be done in some other, also convenient, way. USB is really easy to use. I have stretched this notion to include connected tokens as well with a hope reaching the critical mass needed for establishing a de-facto standard. I fear that you are ahead of your time. :\ Adam Dunkels implemented the internet of things many years ago, but I don't even have IPv6. Things are changing, but still slowly. it seems that NIST's PIV would be good choice It would be a much better candidate if there was not such a thick layer of components involved which serve little to no purpose. If you talk about the actual card standard I have no idea what you are referring to. It looks quite simple to me. If you OTOH refer to the OpenSC implementation, this is something that PIV isn't responsible for. Actually neither, I refer to the entire stack of software required for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. Anyway, I know that the PIV vendors verify their cards against Microsoft's driver and that is IMO the way to go. If there's a superior alternative Microsoft may well catch up at some point. They did with USB. But it would be nice to try to do even better. :) That is what my project is all about but that is hardly an alternative for Feitian at this stage. Also agree. I'm also not suggesting Feitian to pick up on my idea. If they do that's perfectly fine and totally awesome, but I'm keeping the idea alive only because *I* think it is good and would like to try it out. //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] Upgrading aPass2003 Firmware to PIV
On 2/20/2012 3:41 PM, Anders Rundgren wrote: On 2012-02-20 21:40, Peter Stuge wrote: Anders Rundgren wrote: I don't know what USB P11 is, can you send me a pointer? It's my old idea of implementing PKCS#11 directly over USB. Issues have been pointed out, and they would have to be solved of course. Maybe you would like to have an STM32F215-based token? 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES It may happen this year. Anders I have not tried this, but check out this token too: http://www.goldkey.com/usb-smart-card-with-piv.html Built-in PIV Support Basic functionality and support for PIV cards and tokens already exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions. It does not say what what the Linux support is, but I bet it is OpenSC. Although PKCS #11 is good it is not particularly popular on Windows. It is essentially only Mozilla who insists on not supporting the native Windows crypto system. SUN/Oracle have managed to do 3(!) major Java releases (5,6,7) without PKCS #11 support for Win-64. They have though added support for Crypto-API. The same USB device could support Crypto-API primitives too. Regarding my token-project it has no direct ties to PKCS #11; it is closer to the NXP GP-chip which is powering Google's Wallet. The reason for this is that PKCS #11 doesn't have a interface supporting secure remote provisioning, something which absolutely necessary in the mobile phone world. Provisioning is indeed outside PKCS#11 and could be done in some other, also convenient, way. USB is really easy to use. I have stretched this notion to include connected tokens as well with a hope reaching the critical mass needed for establishing a de-facto standard. I fear that you are ahead of your time. :\ Adam Dunkels implemented the internet of things many years ago, but I don't even have IPv6. Things are changing, but still slowly. it seems that NIST's PIV would be good choice It would be a much better candidate if there was not such a thick layer of components involved which serve little to no purpose. If you talk about the actual card standard I have no idea what you are referring to. It looks quite simple to me. If you OTOH refer to the OpenSC implementation, this is something that PIV isn't responsible for. Actually neither, I refer to the entire stack of software required for CCID, APDUs, PKCS#15 and translation to PKCS#11 or CryptoAPI. Anyway, I know that the PIV vendors verify their cards against Microsoft's driver and that is IMO the way to go. If there's a superior alternative Microsoft may well catch up at some point. They did with USB. But it would be nice to try to do even better. :) That is what my project is all about but that is hardly an alternative for Feitian at this stage. Also agree. I'm also not suggesting Feitian to pick up on my idea. If they do that's perfectly fine and totally awesome, but I'm keeping the idea alive only because *I* think it is good and would like to try it out. //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 -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
Dear Peter, It's my old idea of implementing PKCS#11 directly over USB. Issues have been pointed out, and they would have to be solved of course. Feitian offers two ranges of products: CCID (ePass2003 and other products) and HID over USB (ePass2001 and other products). At Gooze, we have HID over USB products in stock (around 100 unused tokens) but we did not released them as they were incompatible with OpenSC. Under Windows, it seems that HID over USB range of products can be used without drivers, just over USB. Under Linux, a small proprietary USB framework is needed. If this is what you mean, you may be interested in testing these HID products. Just write me a private email and I can send you one of these tokens. IMHO, CCID is superior as it is really plug-and-play under all systems. Of course, CCID is needed, but it could be installed under all systems by default. The last versions of libccid with udev really rocks. Pure plug-and-play never exists, you always need an underlying library. libccid is that library. I agree PIN provisioning is really an issue. But if you think of Android, there could be an application available from Android store to do this job. What we need is: * Cheap hardware available worldwide, with onlines sales. * A common framework under all systems, this is OpenSC. * Compatibility with all systems, including Linux, Mac, Windows and Android. * A growing user base. * A growing developer base. A common strategy is to be able to answer Yes to all questions and needs. With OpenSC, you can say YES to Windows, Mac, Linux and soon Android. You can say YES and ship tokens to most countries. Remember crypto is a restricted market and you need authorizations to be able to ship. From my point of view, I would be more in favor of an Android phone acting as a CCID device overs some secure wireless link over OpenSC. GOOZE will soon release crypto chips for Android and this will become one of our target project. We have the demo chips in stock. As usual, we will offer free crypto chips for Android to hackers requesting it. The only reason why Apple removed smartcard support is that (in my opinion) it may be working secretly on a new iPhone replacing smartcards and offering secure payment. The target for new OpenSC developments should be smart phones. We may discuss that in a few weeks after governance issues in OpenSC are improved. All we need is to move forward. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu 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] Upgrading aPass2003 Firmware to PIV
Anders Rundgren wrote: It's my old idea of implementing PKCS#11 directly over USB. Issues have been pointed out, and they would have to be solved of course. Maybe you would like to have an STM32F215-based token? 160 MHz, 128K RAm 1M Flash, USB HS, True RNG, AES It may happen this year. That's nice, although I'm not crazy about stm32. I tend toward NXP LPC. But so far, the closest to what I want and which is available is Gnuk: http://www.fsij.org/gnuk/ ..which also uses stm32. The development situation for stm32 in particular for USB is not amazing it seems. I haven't looked very deep in the datasheets yet. Gnuk implements CCID and so on in order to be interoperable with software stacks (in particular GnuPG) *today* but like you I'm focusing less on the right now and more on the right way for the future. :) The nice part about Gnuk is that it has all the primitives in place, even if it is only a slow software implementation, so I would really only have to focus on the protocol/API, which actually is exactly what I want. :) //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
Douglas E. Engert wrote: I have not tried this, but check out this token too: http://www.goldkey.com/usb-smart-card-with-piv.html Built-in PIV Support Basic functionality and support for PIV cards and tokens already exists in Microsoft Windows®, Mac OS® X, and many Linux® distributions. It does not say what what the Linux support is, but I bet it is OpenSC. I like the mechanical design very much, but not really the other aspects of the product; closed, they favor key escrow, and talk about their Master Token products raises some question marks which I believe will never be answered by the company. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC write access to main trunk, discussion
Le lundi 20 février 2012 à 22:31 +0100, Peter Stuge a écrit : Integrators is only Martin and Ludovic, hence those are the ones who can currently include Gerrit changes into OpenSC on GitHub. Now for the third time, I'm sure that everyone who used to have repository write access will also quickly be added to the Integrator group if they mention their account name or ID and someone in the Administrators group is around. If only Martin is admin, then I guess there's a bit of a wait state, but that's not really such a big deal, because it doesn't block further work in any way. This is where I don't quite agree. The notion of trust is more interesting than the notion of code purity. If you trust a small group of 5/6 main developers to have discussions before writing +2, this is fairly enough. I am worried that some people might ALWAYS argue that a code is not pure-enough and this leads to endless flame wars. Free software is a collaborative process where we improve the code base, just like in ISO-9001 (release software, describe bug, fix bug, improve). This is a circular process. Collaborative commits means more bugs. But also more beta-testers, more beta testers and more users and in the end a better project. This is life. Let me take an image: if you ask you wife to have surgery for a perfect body before marriage, you won't go very far. On the converse, I am in favor of a collaborative approach based on trust. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu 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] Upgrading aPass2003 Firmware to PIV
Hi! Jean-Michel Pouré - GOOZE wrote: It's my old idea of implementing PKCS#11 directly over USB. Issues have been pointed out, and they would have to be solved of course. Feitian offers two ranges of products: CCID (ePass2003 and other products) and HID over USB (ePass2001 and other products). Don't get me started on HID. :) The libusb FAQ http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass tries to give an overview of the considerations for using HID. Executive summary is that it's a bad idea if you want to run on anything but Windows, and even there it may not be a very good idea because you have to re-implement some features which USB otherwise offers your protocol design for free. At Gooze, we have HID over USB products in stock (around 100 unused tokens) but we did not released them as they were incompatible with OpenSC. Under Windows, it seems that HID over USB range of products can be used without drivers, just over USB. Do you know how it is used by CryptoAPI and/or PKCS#11 applications? Under Linux, a small proprietary USB framework is needed. Proprietary? You know that I think that's the wrong approach. :) The FAQ page mentions HIDAPI which can be used to communicate with HID class devices in some cases, but if portability is a concern, it should be clear from the FAQ page that using HID is not the best choice anyway. If this is what you mean, Sorry, no, it's not. What I have in mind is to implement the actual PKCS#11 API directly over USB, as far as that is possible. Again, issues have been pointed out with doing this, but I still think it's worth a shot. IMHO, CCID is superior as it is really plug-and-play under all systems. So much software is running which is completely unneccessary. I agree that CCID has sufficient usability, but it is by far not the best that can be done. Pure plug-and-play never exists, It does, actually. At least in Windows and Linux pure plug-and-play would be possible with my USB P11 idea, but I believe also in other systems. As always with PKCS#11 it would be neccessary to point applications to the correct PKCS#11-provider file (.dll or .so) but still I find the idea worth exploring. What we need is: * Cheap hardware available worldwide, with onlines sales. Yes, and the logistics of this can be tricky, but as you know with some volume it can indeed be done. And if the solution is good enough I think the volume will come. * A common framework under all systems, this is OpenSC. I'd be much happier without any framework at all actually. * Compatibility with all systems, including Linux, Mac, Windows and Android. Yes, the portability is important. iOS would also be nice, but well that may be pushing one's luck. :p From my point of view, I would be more in favor of an Android phone acting as a CCID device overs some secure wireless link over OpenSC. As you probably know, anything wireless is a quite significant attack vector. No secure transactions there please. But with a cable maybe. However, Android devices so far do not have a strong history of local IO either coming in or going out. :\ This can change along with market demands of course, but it raises the barrier for development. GOOZE will soon release crypto chips for Android What kind of chips? How do they connect? The only reason why Apple removed smartcard support is that (in my opinion) it may be working secretly on a new iPhone replacing smartcards and offering secure payment. Yes, I think this is a common belief, and I don't think it's wrong. The target for new OpenSC developments should be smart phones. Much of OpenSC doesn't really apply in smartphones, but I agree that smartphones may be very relevant security devices. //Peter pgpLnKnaGHQ64.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] Upgrading aPass2003 Firmware to PIV
Dear Peter, http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass I wron't discuss as I don't know if improving HID for GNU/Linux is really time consuming. Do you know how it is used by CryptoAPI and/or PKCS#11 applications? CSP and PKCS#11. Just contact me privately and I can ship you a free HID token for testing. As you are the wizard of libusb, you may be able to judge and maybe find a solution to communicate with the tokens. I have your address in Berlin, is this still the same? Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu 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] USB token firmware
Jean-Michel Pouré - GOOZE wrote: http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass I wron't discuss as I don't know if improving HID for GNU/Linux is really time consuming. Hopefully you read the page anyway to find out about the considerations for HID. It may still be relevant even if the HID token is a little older. The HIDAPI library created by Alan Ott is as easy to use as it gets for HID class devices with Linux. The Linux kernel since a long time offers an API which can be used without any drivers and also without libusb, but the API has limited capabilities, and depending on the device they may not be sufficient. Then it will be neccessary to use libusb instead, and udev must be configured to allow the user to disable the kernel HID class driver. I believe HIDAPI now supports not only using libusb but also the kernel API. Do you know how it is used by CryptoAPI and/or PKCS#11 applications? CSP and PKCS#11. OK! Yes, then the idea is similar to mine, except I do not like to use HID in order to reduce portability issues. HID has advantages for Windows but is more complicated everywhere else. (It can even be impossible on Mac OS X. Apple changed the policy for replacing the kernel HID driver in 10.6.) Just contact me privately and I can ship you a free HID token for testing. As you are the wizard of libusb, you may be able to judge and maybe find a solution to communicate with the tokens. No need for token, but thanks for the offer! :) The code that already supports the device is instead what I would look at. Is it available online? //Peter pgp48aJSg2TtO.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] USB token firmware
Le mardi 21 février 2012 à 00:44 +0100, Peter Stuge a écrit : No need for token, but thanks for the offer! :) The code that already supports the device is instead what I would look at. Is it available online? Sorry, it is not publicly available. I am confused about this discussion, because at first you ask us to flash the ePass2003 with another firmware, then we tell you that Feitian HID tokens are already available and you are not interested because ... kernel driver is not perfect under Linux. At GOOZE, we stick to CCID. Good luck with your project. I hope that we will be able to collaborate more on OpenSC main branch without being too picky on solutions. Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu 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] USB token firmware
Jean-Michel Pouré - GOOZE wrote: No need for token, but thanks for the offer! :) The code that already supports the device is instead what I would look at. Is it available online? Sorry, it is not publicly available. You mentioned that one component is the small proprietary HID code for Linux and that part is of course not available, but it seemed like the other parts might be? Or did I misunderstand? Can you say more about the software on Linux for that token? I am confused about this discussion, because at first you ask us to flash the ePass2003 with another firmware, Oh, no that was Anders' suggestion. Maybe that's the confusion. I agree with him that as far as existing card/token standards go, PIV is indeed likely to be well and widely supported, but I don't have any opinion on changing the ePass2003 firmware. then we tell you that Feitian HID tokens are already available and you are not interested because ... kernel driver is not perfect under Linux. I'm not interested in having yet another token laying around. :) But I am however interested in the protocol! And I would look at the Linux software situation for that HID token and I would maybe also be able to find improvements. I just don't need the token to do that. At GOOZE, we stick to CCID. I think this is smart, especially if the Feitian HID token is an older product and no new HID token is planned. Good luck with your project. Thanks! The idea was always only about a protocol optimized for security, usability and portability, and it still needs rd, so please don't get the impression that I am trying to make someone else use it before I have shown that it works. I hope that we will be able to collaborate more on OpenSC main branch without being too picky on solutions. Don't worry, as you know I'm not a significant contributor. //Peter pgpTj3I69Q1It.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] USB token firmware
Peter Stuge wrote: You mentioned that one component is the small proprietary HID code for Linux and that part is of course not available, but it seemed like the other parts might be? Or did I misunderstand? I think I did. I read your email again to check. Can you say more about the software on Linux for that token? From your email it seems that the software for Linux may be completely proprietary. In that case it is of course difficult for me to make any suggestions. Is there any protocol documentation? //Peter pgpe8tVL9l885.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] Upgrading aPass2003 Firmware to PIV
On 2012-02-20 23:23, Jean-Michel Pouré - GOOZE wrote: snip IMHO, CCID is superior as it is really plug-and-play under all systems. Of course, CCID is needed, but it could be installed under all systems by default. The last versions of libccid with udev really rocks. Pure plug-and-play never exists, you always need an underlying library. libccid is that library. Jean-Michel, I'm not following you here. CCID (as I understand it) only defines an USB communication protocol/class, not how for example how to do an RSA signature. When I look into my W7 installation I note that when I attach my ePass2003 token to it, there is a driver from EnterSafe. That doesn't look particularly universal to me. In addition, in order to do something useful with the token I had to install a specific ePass2003 management program. It worked great BTW! Don't get me wrong but from a *customer perspective* it would have been much better if all this software was a part of a platform's smart card support. My guess is that the smart card industry can't do that which is one of the motivations behind my SKS/KeyGen2 project. Upgrading ePass2003 to PIV is an intermediary step. I believe the management part unfortunately is largely undefined in PIV but maybe somebody else know better? Douglas? snip Cheers, Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
