Rationale for Microsoft's "MiniDriver"

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Rationale for Microsoft's "MiniDriver"

Anders Rundgren
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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rationale for Microsoft's "MiniDriver"

Alon Bar-Lev
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.

On Sun, Aug 14, 2011 at 7:20 AM, Anders Rundgren
<[hidden email]> 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
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rationale for Microsoft's "MiniDriver"

Anders Rundgren
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.

Anders

> On Sun, Aug 14, 2011 at 7:20 AM, Anders Rundgren
> <[hidden email]> 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
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rationale for Microsoft's "MiniDriver"

Douglas E. Engert
In reply to this post by Anders Rundgren


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
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rationale for Microsoft's "MiniDriver"

Martin Paljak-4

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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rationale for Microsoft's "MiniDriver"

Douglas E. Engert
In reply to this post by Anders Rundgren


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
>> <[hidden email]>  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
>>> [hidden email]
>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rationale for Microsoft's "MiniDriver"

Anders Rundgren
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
>>> <[hidden email]>  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
>>>> [hidden email]
>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>
>>
>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel