Re: [opensc-devel] Rationale for Microsoft's "MiniDriver"
On 2011-08-16 17:33, Douglas E. Engert wrote: > > > On 8/14/2011 10:40 AM, Anders Rundgren wrote: >> On 2011-08-14 08:59, Alon Bar-Lev wrote: >>> There had been always unified API: PKCS#11. >>> Well, at Microsoft environment there was CryptoAPI Provider. >>> The good about the CryptoAPI is that it allowed enough flexibility so >>> that, for example, you could have created a generic CryptoAPI provider >>> on-top of PKCS#11. >>> >>> In the MiniDriver, Microsoft advanced too far. It created a dependency >>> between Microsoft specific data and on-card implementation. It also >>> created a dependency between configuration and card content. >>> >>> So now, instead of providing a single API (PKCS#11) and a single >>> bridge for Microsoft environment (CryptoAPI Provider->PKCS#11) you >>> need to work much harder. >>> >>> Alon. >> >> PKCS #11 is great as a "user" API. >> >> As the foundation for an online provisioning API it seems more limited. >> RedHat do not use PKCS #11 in their DogTag Card Management System >> for this reason although they support a limited set if cards. >> >> The reason for bringing this up is that suddenly the interest for creating >> a browser-based provisioning system has even reached Google (!) and then >> the question about middleware is popping up. I'm less optimistic that >> you can create a useful system which can be used by consumers >> without doing something creative in the lower layers as well. >> >> Microsoft is (based on "indirect" information...), also working on a new >> enrollment system which builds on the MiniDriver. > > But which browsers? IE can use the minidriver, FireFox can use NSS that > uses PKCS#11. Apple has is CDSA. I am not sure what newer Android or > WebOS browsers can use. > > This paper offers some more insight and a creative approach: > > http://w2spconf.com/2009/papers/s4p4.pdf SConnect represents a card vendor approach. I doubt SConnect actually withstands a thorough security analysis. Connecting to a smart card from untrusted browser code seems like an even worse idea than Microsoft's "CertEnroll". KeyGen2/SKS represents an issuer-oriented scheme where the "card" is slightly downplayed in favor for the identity ecosystem. Anders > >> >> Anders >> >>> On Sun, Aug 14, 2011 at 7:20 AM, Anders Rundgren >>> wrote: Writing card drivers is quite difficult. That's why Microsoft introduced the "MiniDriver". The driver model has been very successful for printers since printers have widely different characteristics. Cryptographic operations OTOH leave very little (if any) room for variations. Although cards may differ in features, using unified high-level APIs like the MiniDriver this will either be hard to access or more likely: Never be utilized. Open question: Since the MiniDriver gives a unified card API, wouldn't it be easier defining a FIXED API/DRIVER and rather let the cards adapt to that? Certifying a gazillion third-party drivers including multiple card versions doesn't appear to be a particularly swift project. With a fully unified card API you can target all cards with a fairly simple test-suite and delegate the certification to the card vendors. This should dramatically improve system reliability which always has been a weak point, particularly for consumer computers. Anders ___ 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 >> >> > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] pkcs11-helper-1.09 released
Hello, pkcs11-helper-1.09 is available. Fixed issue introduced in 1.08 related to OpenSSL engine signature. ChangeLog 2011-08-16 - Version 1.09 * Do not retry if CKR_BUFFER_TOO_SMALL and none NULL target. * Fixup OpenSSL engine's rsa_priv_enc to use RSA size output buffer. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Rationale for Microsoft's "MiniDriver"
On 8/14/2011 10:40 AM, Anders Rundgren wrote: > On 2011-08-14 08:59, Alon Bar-Lev wrote: >> There had been always unified API: PKCS#11. >> Well, at Microsoft environment there was CryptoAPI Provider. >> The good about the CryptoAPI is that it allowed enough flexibility so >> that, for example, you could have created a generic CryptoAPI provider >> on-top of PKCS#11. >> >> In the MiniDriver, Microsoft advanced too far. It created a dependency >> between Microsoft specific data and on-card implementation. It also >> created a dependency between configuration and card content. >> >> So now, instead of providing a single API (PKCS#11) and a single >> bridge for Microsoft environment (CryptoAPI Provider->PKCS#11) you >> need to work much harder. >> >> Alon. > > PKCS #11 is great as a "user" API. > > As the foundation for an online provisioning API it seems more limited. > RedHat do not use PKCS #11 in their DogTag Card Management System > for this reason although they support a limited set if cards. > > The reason for bringing this up is that suddenly the interest for creating > a browser-based provisioning system has even reached Google (!) and then > the question about middleware is popping up. I'm less optimistic that > you can create a useful system which can be used by consumers > without doing something creative in the lower layers as well. > > Microsoft is (based on "indirect" information...), also working on a new > enrollment system which builds on the MiniDriver. But which browsers? IE can use the minidriver, FireFox can use NSS that uses PKCS#11. Apple has is CDSA. I am not sure what newer Android or WebOS browsers can use. This paper offers some more insight and a creative approach: http://w2spconf.com/2009/papers/s4p4.pdf > > Anders > >> On Sun, Aug 14, 2011 at 7:20 AM, Anders Rundgren >> wrote: >>> Writing card drivers is quite difficult. That's why Microsoft introduced >>> the "MiniDriver". >>> >>> The driver model has been very successful for printers since printers have >>> widely different characteristics. Cryptographic operations OTOH leave very >>> little (if any) room for variations. >>> >>> Although cards may differ in features, using unified high-level APIs like >>> the MiniDriver this will either be hard to access or more likely: Never be >>> utilized. >>> >>> Open question: Since the MiniDriver gives a unified card API, wouldn't it >>> be easier defining a FIXED API/DRIVER and rather let the cards adapt to >>> that? Certifying a gazillion third-party drivers including multiple card >>> versions doesn't appear to be a particularly swift project. >>> >>> With a fully unified card API you can target all cards with a fairly simple >>> test-suite and delegate the certification to the card vendors. This should >>> dramatically improve system reliability which always has been a weak point, >>> particularly for consumer computers. >>> >>> Anders >>> >>> ___ >>> 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 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] Rationale for Microsoft's "MiniDriver"
On Aug 16, 2011, at 6:16 , Douglas E. Engert wrote: >> With a fully unified card API you can target all cards with a fairly simple >> test-suite and delegate the certification to the card vendors. This should >> dramatically improve system reliability which >> always has been a weak point, particularly for consumer computers. > > True, if the card vendors could agree on one. http://xkcd.com/927/ -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Rationale for Microsoft's "MiniDriver"
On 8/13/2011 11:20 PM, Anders Rundgren wrote: > Writing card drivers is quite difficult. That's why Microsoft introduced the > "MiniDriver". > > The driver model has been very successful for printers since printers have > widely different characteristics. Cryptographic operations OTOH leave very > little (if any) room for variations. > > Although cards may differ in features, using unified high-level APIs like the > MiniDriver this will either be hard to access or more likely: /Never be > utilized/. > > Open question: Since the MiniDriver gives a unified card API, wouldn't it be > easier defining a FIXED API/DRIVER and rather let the cards adapt to that? > Certifying a gazillion third-party drivers > including multiple card versions doesn't appear to be a particularly swift > project. Is this really an OpenSC question? There are cards out there by many vendors. They could, if they wanted to, do what you suggest but they continue to write their own drivers. OpenSC also provides a mini-driver for the cards supported by OpenSC. This bypasses the PKCS#11 and supports the PKCS#15 cards (and emulated PKCS#15 cards). PKCS#15 if more of a standard that many card vendors have adopted and Microsoft could have too. But early on they developed their own smart card, then tried to standardize around it, thus the confusing CAPI, CNG and its minidriver. As a side note, Microsoft with Windows 7, does provide a built in minidriver for at least the PIV card. Thus no 3rd party drivers including OpenSC is needed to use a PIV card. There are 15 appreved PIV cards, from 6 vendors: http://fips201ep.cio.gov/apl.php So this could be what you are looking for, but the PIV is not designed to be provisioned over the network. > > With a fully unified card API you can target all cards with a fairly simple > test-suite and delegate the certification to the card vendors. This should > dramatically improve system reliability which > always has been a weak point, particularly for consumer computers. True, if the card vendors could agree on one. > > Anders > > > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert 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] PIN caching problems with pkcs11-helper 1.08
Thanks for your report and testing! 2011/8/16 Jonatan Åkerlind : > On fre, 2011-08-12 at 23:20 +0300, Alon Bar-Lev wrote: >> Jonatan, >> Can you please try the attached patch and see if it helps? >> Thanks! > ... >> >> seems to work fine, will continue testing during the day. This is on >> an >> AMD64 architecture if it makes any difference. So far i have only >> entered my PIN code once at startup of my vpn session, the session has >> renegotiated a few times now. >> >> /Jonatan > > Been using it for a day now and so far I haven't seen any problem. Works > fine for me. > > /Jonatan > > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] PCSC spy tool: should I include it in the pcsc-lite distribution?
Hello, I am working on a new way to log/spy PCSC calls. The two previous methods [1, 2] are not satisfying because of their limitations. My question: should I include the spy layer in the standard pcsc-lite archive or as a distinct project? Pros of the merge: - PCSC spy layer available in packages (as with OpenSC and pkcs11-spy) and then easy to use - no need to create a new package for GNU/Linux distribution. The PCSC spy library should/could be included in the libpcsclite-dev package Cons of the merge: - more code in the archive - not yet ready for all the platforms pcsc-lite is targeting What do you think? Thanks [1] http://ludovicrousseau.blogspot.com/2010/08/pcsc-api-spy-for-gnu-systems.html [2] http://ludovicrousseau.blogspot.com/2011/01/pcsc-api-spy-another-way.html -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIN caching problems with pkcs11-helper 1.08
On fre, 2011-08-12 at 23:20 +0300, Alon Bar-Lev wrote: > Jonatan, > Can you please try the attached patch and see if it helps? > Thanks! ... > > seems to work fine, will continue testing during the day. This is on > an > AMD64 architecture if it makes any difference. So far i have only > entered my PIN code once at startup of my vpn session, the session has > renegotiated a few times now. > > /Jonatan Been using it for a day now and so far I haven't seen any problem. Works fine for me. /Jonatan ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
