Sure… the user gets no pop-up. The user also has no idea if the driver package was hacked. Great engineer trade-off there.
Peter
OSR
Xiaofen Chen wrote:
On the other hand, the quality of usbser.sys, at least for
the earlier version (very buggy), may have something to
do with this decision.
Well, I see it from the other viewpoint: if it loaded automatically for any USB modem device, MSFT would be so overwhelmed by complaints (dying on zero length packets, slow performance, no/broken support for composite devices, etc.) that they would have had to get their act together and fix it. Imagine if mass storage or HID support worked so poorly?
What ended up happening is that it remained this relatively obscure piece of code that was “sort of” inbox (you needed INF voodoo to unpack it from Driver.cab), “sort of” worked, and spawned a huge cottage industry (MCCI and others) of people who went off and made much better versions.
I guess it doesn’t really matter any more; seems like most folks are just supplying NDIS drivers these days to tether cell phones or data cards, and nobody really makes data calls any more. Problem solved…
On Fri, Apr 13, 2012 at 2:18 AM, wrote:
>
> I guess it doesn’t really matter any more; seems like most
> folks are just supplying NDIS drivers these days to tether
> cell phones or data cards, and nobody really makes data
> calls any more. ?Problem solved…
Not really for things like USB to Serial Converter. CDC-ACM
is a choice for them and many people have a MCU application
where they could use CDC-ACM and usbser.sys and not
to use dedicated chip like FTDI/Prolific/Silabs since the
USB MCU also does other things.
–
Xiaofan
> What remains is the driver package level, and requirement to sign that with
WHQL is a burden.
Install your cert to Local Machin/Trusted Publishers as a part of your install script. Ask the user the proper questions.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>days to tether cell phones or data cards, and nobody really makes data calls any more.
Lot’s of cheap GSM/3G and EV-DO modems are using serial emulation.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
On 4/12/2012 3:09 PM, Pavel A. wrote:
“Hagen Patzke” wrote in message
> news:xxxxx@ntdev…
>> On 4/12/2012 2:35 PM, Pavel A. wrote:
>>> I did not say that WHQL isn’t good… but certain things just will be
>>> done as the “industry” wants it.
>> …until MS “pulls the plug”. Let’s wait and see.
>
> Nope. The time when MS could “pull the plug”, is now history, to the
> better or not.
Please read up about platform security, Pavel.
As an exercise for the reader:
- Explain in two sentences how MS could secure its certificate-based
driver and system component installer system.
- Extra points if you explain how to use a “trusted boot path” to keep
access control on a given platform.
>> Libwdi offers a method (I don’t know whether Pete Batard invented it or
> borrowed from other project) to avoid this popup by automatic installation
> of one-time certs - and save money (part of which vendors could donate to
> support the project
Sure… the user gets no pop-up. The user also has no idea if the driver
package was hacked. Great engineer trade-off there.Peter
OSR
Hi, I’m the author of libwdi. If you see an engineer trade-off, I would invite you to take a closer look at what libwdi does, especially the following, which is actually the page that “Issuer Statement” button of the certificates libwdi installs sends users to:
https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Certification_Practice_Statement
As posted elsewhere, I also hope the crude diagram below will explain what libwdi does when it comes to trust, and why, since trust is always delegated, and the certificates involved are basically the same as they end up with a public CA, it is most certainly no worse than signing a driver package using a public CA certificate.
* libwdi chain of trust for an official libwdi app:
Zadig (official libwdi application)
|
- <----- “Trusted” by a public CA (dev cert issued by public CA)
|
/
Zadig (in elevated mode): installation of self signed certificates in trustedPublisher/root, with a one-time only private key that is generated on the end-user platform and discarded after use
|
|
/
certificate in the Windows cert store
/\
|
|
driver package installation, signed with the one-time private key above
* chain of trust for a driver package signed with a public CA
root certificate from public CA in the Windows cert store
/\
|
- <------ “Trusted” by public CA
|
developer cert issued by public CA
/\
|
|
driver package installation, signed with the end user private key matching the end user cert issued by public CA.
As long as you are using a libwdi application that is trusted, which is the case of the digitally signed official ones, then the chain of trust ends with a public CA in both cases. If not, then since the libwdi app needs to run elevated to install certs, it’s already game over.
The only way for a driver package installed by libwdi to be hacked, is for someone to first run an application in elevated mode that will be doing something malicious, and that did not come from the libwdi developers (since official libwdi applications only install driver files that are embedded in the app, never from an external source, and this whole content is signed). Therefore, the whole point of being able to install a malicious driver package using libwdi is moot - if you’re doing that, then you already tricked the user into running a non trusted app in elevated mode.
As to whether a developer certificate that was issued to the libwdi developers is less trustworthy than a certificate that was used to another group of people to sign a driver package, this is also a moot point. In all fairness, with libwdi being FLOSS, you’re more likely to be able to figure out if the driver packages being installed by it are malicious than by trusting someone you never met, whom Verisign or GlobalSign deemed trustworthy when they issued the cert.
Also note that what libwdi does and what the OP wants to do, while similar in some aspects, are not the same thing. But I would say that if you can ascertain trust with regards to the installation of a self-signed certificate, which is the actual part that matters, then due to the transitive nature of this trust, the driver package you installed is no less trustworthy than one that was signed using public CA credentials.
The problem is not that there is no chain of trust, but that the chain of
trust does not include the author of the code that will run in KM. Sure it
is a convenience for those distributing to rely on your guarantee that their
code is fine, but will you be financially liable for any damages caused by
bugs in their code? I didn’t think so.
wrote in message news:xxxxx@ntdev…
> Libwdi offers a method (I don’t know whether Pete Batard invented it or
> borrowed from other project) to avoid this popup by automatic
> installation
> of one-time certs - and save money (part of which vendors could donate to
> support the project
Sure… the user gets no pop-up. The user also has no idea if the driver
package was hacked. Great engineer trade-off there.Peter
OSR
Hi, I’m the author of libwdi. If you see an engineer trade-off, I would
invite you to take a closer look at what libwdi does, especially the
following, which is actually the page that “Issuer Statement” button of the
certificates libwdi installs sends users to:
https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Certification_Practice_Statement
As posted elsewhere, I also hope the crude diagram below will explain what
libwdi does when it comes to trust, and why, since trust is always
delegated, and the certificates involved are basically the same as they end
up with a public CA, it is most certainly no worse than signing a driver
package using a public CA certificate.
* libwdi chain of trust for an official libwdi app:
Zadig (official libwdi application)
|
- <----- “Trusted” by a public CA (dev cert issued by public CA)
|
/
Zadig (in elevated mode): installation of self signed certificates in
trustedPublisher/root, with a one-time only private key that is generated on
the end-user platform and discarded after use
|
|
/
certificate in the Windows cert store
/\
|
|
driver package installation, signed with the one-time private key above
* chain of trust for a driver package signed with a public CA
root certificate from public CA in the Windows cert store
/\
|
- <------ “Trusted” by public CA
|
developer cert issued by public CA
/\
|
|
driver package installation, signed with the end user private key matching
the end user cert issued by public CA.
As long as you are using a libwdi application that is trusted, which is the
case of the digitally signed official ones, then the chain of trust ends
with a public CA in both cases. If not, then since the libwdi app needs to
run elevated to install certs, it’s already game over.
The only way for a driver package installed by libwdi to be hacked, is for
someone to first run an application in elevated mode that will be doing
something malicious, and that did not come from the libwdi developers (since
official libwdi applications only install driver files that are embedded in
the app, never from an external source, and this whole content is signed).
Therefore, the whole point of being able to install a malicious driver
package using libwdi is moot - if you’re doing that, then you already
tricked the user into running a non trusted app in elevated mode.
As to whether a developer certificate that was issued to the libwdi
developers is less trustworthy than a certificate that was used to another
group of people to sign a driver package, this is also a moot point. In all
fairness, with libwdi being FLOSS, you’re more likely to be able to figure
out if the driver packages being installed by it are malicious than by
trusting someone you never met, whom Verisign or GlobalSign deemed
trustworthy when they issued the cert.
Also note that what libwdi does and what the OP wants to do, while similar
in some aspects, are not the same thing. But I would say that if you can
ascertain trust with regards to the installation of a self-signed
certificate, which is the actual part that matters, then due to the
transitive nature of this trust, the driver package you installed is no less
trustworthy than one that was signed using public CA credentials.
On 2012.04.13 23:02, m wrote:
The problem is not that there is no chain of trust, but that the chain
of trust does not include the author of the code that will run in KM.
Sure it is a convenience for those distributing to rely on your
guarantee that their code is fine, but will you be financially liable
for any damages caused by bugs in their code? I didn’t think so.
Why should I?
The libwdi installation is for unmodified drivers binaries that have
been produced by Microsoft (WinUSB) or by the libusb-win32 or libusbK
authors, that are digitally signed with Authenticode, and that are
obtained through channels that are trustworthy (but even if they
weren’t, someone would have to tamper with the signing to make the files
look legit).
Moreover I actually don’t have any issue personally vouching for the
libusb-win32 or libusbK drivers that I embed in official libwdi apps,
since I am closely involved with their authors (who, I can guarantee,
will not try to shift liability onto libwdi in case their drivers have
an issue), and these drivers are 100% FLOSS. As a matter of fact, I have
more trust in those than in WinUSB, as I have no insight on the
production of the latter or whether its content may present a security
risk (exploit, etc.).
Therefore if a bug were to be found in Microsoft’s WinUSB, or the
libusb-win32/libusbK drivers, it would take a very incompetent lawyer
(or a very biased judge) to assert that I am liable when all I did was
produce and sign an app that ensured the installation of the
*unmodified* signed driver binaries exactly as I got them.
Thus, I must stress out that the official libwdi apps do not install any
random driver, and that, contrary to your assertion, it’s isn’t going to
guarantee that the driver code from someone other than Microsoft or
Travis Robinson (the current main author of libusb-win32/libusbK), is
supposed to be trustworthy.
Now, libwdi also offers the possibility to produce apps that install a
driver package of your choice, but then it’s up to the driver’s author,
or someone who trusts them, to sign their own libwdi app, as I have no
involvement whatsoever in that activity (apart from producing part of
the source used to produce the app under a license that explicitly
states no liability)
Finally, as an FYI, the only element libwdi adds to the official signed
binary drivers above, and which can easily be verified through the
source, is an inf that is generated on the fly. This is actually one of
the main reason for installing self-signed certs, since a CA one is
useless for on-the-fly driver package production on an end-user’s machine.
Regards,
/Pete
On Sat, Apr 14, 2012 at 7:09 AM, Pete Batard wrote:
> Finally, as an FYI, the only element libwdi adds to the official signed
> binary drivers above, and which can easily be verified through the source,
> is an inf that is generated on the fly. This is actually one of the main
> reason for installing self-signed certs, since a CA one is useless for
> on-the-fly driver package production on an end-user’s machine.
That on-the-fly part is where I have problem with.
Some would argue that WHQL is not always possible and even a
good CA cert cost money and it is a pain to sign the driver packages
for the developers of the driver packages. That is all correct. And
I believe that is why Microsoft provides the means of self-signing and
it is no problem to use self-signing using a CA cert or libwdi’s on-the-fly
approach for the developers (or other controlled environment like
testing environment, corporate IT deployment using its own CA).
The problem comes from using this method to distribute to the general
public, in that case, a question should be asked before installing the
certificate, silent install (libwdi’s approach) might not be a good
thing here…
Many people here argued that WHQL is the only official way
for silent install to the general public. I believe that the pop-up
warning (red one for unsigned and less scary one for the
publisher warning) is there for good reasons for non-WHQL
driver packages.
–
Xiaofan
On 2012.04.14 01:33, Xiaofan Chen wrote:
The problem comes from using this method to distribute to the general
public, in that case, a question should be asked before installing the
certificate, silent install (libwdi’s approach) might not be a good
thing here…
Not at all. The application has been trusted to run as elevated by the
user, who is supposed to have verified that the publisher of the app was
vetted by a trustworthy entity (in this case the Certum CA, since this
is where I obtained my signing certificate from).
As I tried to explain in the diagram, in terms of trust, it makes very
little difference whether you trust an application that was signed with
a public CA and that installs self-signed certificate to validate a
driver package it produces, or a driver package that was signed by a
public CA.
And from the moment you trust the app, you implicitly trust it not to do
something malicious (else you really shouldn’t trust it to run
elevated), which means that you implicitly trust that, should it
installs self signed certificates, these will pose no threat to the
system, which libwdi goes great length to make sure is the case (please
read the CPS statement at [1] )
The whole concept of trust is based on delegation, so whether you trust
an app that installs self signed certs for driver package validation,
and that was itself signed by credentials from a public CA, or you trust
a driver package that was signed by credentials from a public CA, it
makes no difference.
But if you say there is a difference, then you are implying that creator
of an app that was signed with a public CA is somehow less trustworthy
that the creator of a driver package that was signed with a public CA.
That makes no sense!
This whole point is summarized in the CPS as follows:
“because the certificates can only be installed from an application
running in elevated mode, which means that the end-user first has to
indicate that he or she trusts the application operation, we consider
that the user also provides consent for the installation of certificates
in the trusted stores”
Many people here argued that WHQL is the only official way
for silent install to the general public. I believe that the pop-up
warning (red one for unsigned and less scary one for the
publisher warning) is there for good reasons for non-WHQL
driver packages.
I disagree. If you want to use Microsoft’s WinUSB driver files to access
a generic USB device and let an allegedly trustworthy application (since
signed by a public CA) create a harmless inf for you, then, unless that
app does a silent cert install, you end up in the ridiculous situation
where a driver package, that only contains Microsoft certified binaries,
is flagged by Microsoft as something that could be harmful. This makes
no sense: on one hand Microsoft provides a *generic* USB driver and on
the other hand, they make sure that, should a user actually want to use
it in a *generic* fashion (i.e. against a random USB device) Windows
will flag the driver package as potentially harmful.
Regards,
/Pete
On Sat, Apr 14, 2012 at 9:39 AM, Pete Batard wrote:
> On 2012.04.14 01:33, Xiaofan Chen wrote:
>> Many people here argued that WHQL is the only official way
>> for silent install to the general public. I believe that the pop-up
>> warning (red one for unsigned and less scary one for the
>> publisher warning) is there for good reasons for non-WHQL
>> driver packages.
>
>
> I disagree. If you want to use Microsoft’s WinUSB driver files to access a
> generic USB device and let an allegedly trustworthy application (since
> signed by a public CA) create a harmless inf for you, then, unless that app
> does a silent cert install, you end up in the ridiculous situation where a
> driver package, that only contains Microsoft certified binaries, is flagged
> by Microsoft as something that could be harmful. This makes no sense: on one
> hand Microsoft provides a generic USB driver and on the other hand, they
> make sure that, should a user actually want to use it in a generic fashion
> (i.e. against a random USB device) Windows will flag the driver package as
> potentially harmful.
Please remember that the WinUSB driver packages contain more than
winusb.sys (the co-installers actually) since it also needs other things
like inf file. So that driver package is not considered as “only
containing Microsoft certified binaries”. The inf file may well be
able to carry more binaries (e.g.: we can distribute libusb-1.0.dll
and libusbk.dll along with WinUSB.sys and winusb.dll with an
inf file).
The situation here is the same, usbser.sys is the inbox driver (signed)
but not the driver package, so there is a warning. In the case of
usbser.sys, Microsoft can make it as a class driver and no more
warnings.
In the case of WinUSB, it is more problematic. The “WCID device”
you coined is one of the improvement in Windows 8 to make it
more useful, but only to those USB device with the modified
firmware to have the Microsoft OS descriptors.
–
Xiaofan
On 2012.04.14 02:50, Xiaofan Chen wrote:
On Sat, Apr 14, 2012 at 9:39 AM, Pete Batard wrote:
>> On 2012.04.14 01:33, Xiaofan Chen wrote:
>>> Many people here argued that WHQL is the only official way
>>> for silent install to the general public. I believe that the pop-up
>>> warning (red one for unsigned and less scary one for the
>>> publisher warning) is there for good reasons for non-WHQL
>>> driver packages.
>>
>>
>> I disagree. If you want to use Microsoft’s WinUSB driver files to access a
>> generic USB device and let an allegedly trustworthy application (since
>> signed by a public CA) create a harmless inf for you, then, unless that app
>> does a silent cert install, you end up in the ridiculous situation where a
>> driver package, that only contains Microsoft certified binaries, is flagged
>> by Microsoft as something that could be harmful. This makes no sense: on one
>> hand Microsoft provides a generic USB driver and on the other hand, they
>> make sure that, should a user actually want to use it in a generic fashion
>> (i.e. against a random USB device) Windows will flag the driver package as
>> potentially harmful.
>
> Please remember that the WinUSB driver packages contain more than
> winusb.sys (the co-installers actually) since it also needs other things
> like inf file. So that driver package is not considered as “only
> containing Microsoft certified binaries”.
Well, with the preceding statement, the implication is of course that
there is an extra inf (and cat, but a cat can hardly be considered as
harmful since, unless I’m mistaken, you can’t exactly gain control of a
system with a malicious cat) in the driver package, and that the inf is
as trustworthy as the binaries themselves since it would have been
created either by the end user against their random USB device or an
application that they trust. The co-installer DLLs are signed, so do
fall in the category of Microsoft certified binaries.
> The inf file may well be
> able to carry more binaries (e.g.: we can distribute libusb-1.0.dll
> and libusbk.dll along with WinUSB.sys and winusb.dll with an
> inf file).
I think the idea that a package that contains only signed binaries and
an inf that was created by a trusted source should be flagged as
potentially harmful is rather preposterous, which is what I am
commenting about.
> In the case of WinUSB, it is more problematic. The “WCID device”
> you coined is one of the improvement in Windows 8 to make it
> more useful, but only to those USB device with the modified
> firmware to have the Microsoft OS descriptors.
Indeed. It will be quite limited and, while an advocate of WCID [1], I
have my doubts about its ability to become widespread even if Windows 8
is a success. And as long as WinUSB doesn’t provide support for
isochronous and other items, it won’t be much help, as you will need to
use libusb-win32 or libusbK, which Windows will of course not natively
provide support for…
Regards,
/Pete
[1]
https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=WCID_devices
This is just about as close to completely missing my point as I can imagine.
“Pete Batard” wrote in message news:xxxxx@ntdev…
On 2012.04.13 23:02, m wrote:
The problem is not that there is no chain of trust, but that the chain
of trust does not include the author of the code that will run in KM.
Sure it is a convenience for those distributing to rely on your
guarantee that their code is fine, but will you be financially liable
for any damages caused by bugs in their code? I didn’t think so.
Why should I?
The libwdi installation is for unmodified drivers binaries that have
been produced by Microsoft (WinUSB) or by the libusb-win32 or libusbK
authors, that are digitally signed with Authenticode, and that are
obtained through channels that are trustworthy (but even if they
weren’t, someone would have to tamper with the signing to make the files
look legit).
Moreover I actually don’t have any issue personally vouching for the
libusb-win32 or libusbK drivers that I embed in official libwdi apps,
since I am closely involved with their authors (who, I can guarantee,
will not try to shift liability onto libwdi in case their drivers have
an issue), and these drivers are 100% FLOSS. As a matter of fact, I have
more trust in those than in WinUSB, as I have no insight on the
production of the latter or whether its content may present a security
risk (exploit, etc.).
Therefore if a bug were to be found in Microsoft’s WinUSB, or the
libusb-win32/libusbK drivers, it would take a very incompetent lawyer
(or a very biased judge) to assert that I am liable when all I did was
produce and sign an app that ensured the installation of the
*unmodified* signed driver binaries exactly as I got them.
Thus, I must stress out that the official libwdi apps do not install any
random driver, and that, contrary to your assertion, it’s isn’t going to
guarantee that the driver code from someone other than Microsoft or
Travis Robinson (the current main author of libusb-win32/libusbK), is
supposed to be trustworthy.
Now, libwdi also offers the possibility to produce apps that install a
driver package of your choice, but then it’s up to the driver’s author,
or someone who trusts them, to sign their own libwdi app, as I have no
involvement whatsoever in that activity (apart from producing part of
the source used to produce the app under a license that explicitly
states no liability)
Finally, as an FYI, the only element libwdi adds to the official signed
binary drivers above, and which can easily be verified through the
source, is an inf that is generated on the fly. This is actually one of
the main reason for installing self-signed certs, since a CA one is
useless for on-the-fly driver package production on an end-user’s machine.
Regards,
/Pete
On 14 April 2012 20:44, m wrote:
>
>
> This is just about as close to completely missing my point as I can imagine.
So you are saying that people who want to repackage WinUSB as their
driver should either:
- develop their own USB driver instead?
- get Microsoft to produce their driver package (i.e. WHQL always,
since public CA wouldn’t help here either), as Microsoft is the one
who crafted WinUSB?
I think you are missing the point that libwdi is targeting generic
driver installations, i.e. ones where it would be infeasible to have
everybody go through WHQL to produce a driver package, because the
device is not meant to be known beforehand. The main aim is allowing
people to develop USB applications that can access an USB device that
is not necessarily known beforehand in a generic manner. Even
Microsoft seems to recognize that they have a problem there, as they
introduced WCID in Windows 8. Do you have a solution to that problem,
or do you consider that letting end-users accept the installation of a
driver package that can be anything, since it wouldn’t be signed, is
better than the installation of a driver package that was signed and
produced in a trusted environment, even if it wasn’t signed by
Microsoft.
Also, I could very well create my own branch of libusb-win32 and
libusbk, and sign these drivers as my own. I’m not doing that, since I
have complete trust that Travis Robinson will do a job that is at
least as trustworthy as the one I’d do, therefore I am delegating my
trust here. For what is worth, Travis and I are participating in the
same effort, and could be considered as working for the same company,
and furthermore, as Xiaofan can confirm, the previous Authenticode
signing certificate that was used the libusb-win32 driver was in my
name.
I stated that I was pretty much endorsing these drivers as my own code
in official libwdi apps, and if Travis didn’t sign them, there’s a
good chance I would be the one doing so, which pretty much dismisses
your whole point.
Regards,
/Pete
On 13-Apr-2012 14:24, Hagen Patzke wrote:
Please read up about platform security, Pavel.
As an exercise for the reader:
- Explain in two sentences how MS could secure its certificate-based
driver and system component installer system.
One sentence will do? mainly by patching existing bugs.
http://technet.microsoft.com/en-us/security/bulletin/ms12-024
My apologies. yes, I’ve written that I don’t understand platform
security, but let’s not take this too literally 
– pa
On Sun, Apr 15, 2012 at 4:21 AM, Pete Batard wrote:
> On 14 April 2012 20:44, m wrote:
>>
>>
>> This is just about as close to completely missing my point as I can imagine.
>
> So you are saying that people who want to repackage WinUSB as their
> driver should either:
> - develop their own USB driver instead?
> - get Microsoft to produce their driver package (i.e. WHQL always,
> since public CA wouldn’t help here either), as Microsoft is the one
> who crafted WinUSB?
I think this is not the question here.
> I think you are missing the point that libwdi is targeting generic
> driver installations, i.e. ones where it would be infeasible to have
> everybody go through WHQL to produce a driver package, because the
> device is not meant to be known beforehand. The main aim is allowing
> people to develop USB applications that can access an USB device that
> is not necessarily known beforehand in a generic manner. Even
> Microsoft seems to recognize that they have a problem there, as they
> introduced WCID in Windows 8. Do you have a solution to that problem,
> or do you consider that letting end-users accept the installation of a
> driver package that can be anything, since it wouldn’t be signed, is
> better than the installation of a driver package that was signed and
> produced in a trusted environment, even if it wasn’t signed by
> Microsoft.
WinUSB is fine, libusb-win32 and libusbk are fine as well as a
generic USB driver.
The issue in this discussion is actually regarding the pop-up warning.
libwdi solved the problem using its method without the need of WHQL.
My question is whether it is really worth (or even helpful) to suppress
the warning using libwdi’s method.
The pop-up is just a warning and winusb can still be used. Same
for the OP’s case, usbser.sys can still be used, there is just a
warning.
++++++++++ from libwdi wiki ++++++++++++
http://ow.ly/acSGz
“From version 1.1.0, if you are installing a driver on Vista or later versions
of Windows, libwdi attempt to generate and self-sign driver package,
and then mark the certificate used for the signing process as trusted,
by installing it in the system stores, in order to avoid further security
prompts during the driver installation.
During that process, libwdi will copy two autogenerated certificates to the
Root (Trusted Root Certification Authorities) and Trusted Publisher system
certificate stores.”
“While the installation of certificates into these stores, without asking the
end user, may sound like questionable practice, please understand that
none of these certificate actually introduce a security liability as nobody,
not even the authors of libwdi, have the ability to reuse these certificates
in order to mark malicious software as trusted.
This is because:
The private key for the certificate is generated at runtime, on the end user
machine, and is not accessible to anybody else but the libwdi application
that does the signing process for a limited time only after the driver package
has been signed, the private key is destroyed.
This effectively means that the certificate is a one-time use only, and cannot
be used for anything but to validate driver package that was signed by libwdi,
that one time. As a matter of fact, even if you re-install the exact
same device
using the same driver, libwdi has to generate a brand new certificate (and a
new temporary private key), and replace the old one, because it is
impossible to reuse it.”
+++++++++++++++++++++++++
I am not an expert in security but hopefully the experts here can check
the security with libwdi’s approach. It may well be okay based on
your explanation, at least on Zadig.
My viewpoint is consistent with my view last time.
http://libusb.6.n5.nabble.com/WHQL-Testing-Agreement-and-GPLv3-conflicts-tp3335877p3339207.html
“On the other hand, the above method is mainly meant for developers
or big organizations. If you want to release the driver package
to the general public and do not want to have a security prompt,
then WHQL is still the only way.”
> Also, I could very well create my own branch of libusb-win32 and
> libusbk, and sign these drivers as my own. I’m not doing that, since I
> have complete trust that Travis Robinson will do a job that is at
> least as trustworthy as the one I’d do, therefore I am delegating my
> trust here. For what is worth, Travis and I are participating in the
> same effort, and could be considered as working for the same company,
> and furthermore, as Xiaofan can confirm, the previous Authenticode
> signing certificate that was used the libusb-win32 driver was in my
> name.
Yes I can confirm that Pete is the one who bought the digital certificate
for the initial libusb0.sys binary. Later we got the donation and now the
cert for libusb0.sys and libusbk.sys is under Travis’ name.
> I stated that I was pretty much endorsing these drivers as my own code
> in official libwdi apps, and if Travis didn’t sign them, there’s a
> good chance I would be the one doing so, which pretty much dismisses
> your whole point.
Okay, so with your explanation, let’s assume Zadig is not really
a problem since it only deals with three signed driver (winusb.sys,
libusb0.sys and libusbk.sys). I still have the following doubts.
The issue in this discussion is actually regarding the pop-up warning.
libwdi “solved” the problem using its method without the need of WHQL.
My question is whether it is really worth (or even helpful) to suppress
the warning using libwdi’s method.
And my view is still that using self-signing and install certs to the trusted
store (using or not using libwdi’s approach) is mainly meant for developers
or big organizations. If you want to release the driver package to the
general public and do not want to have a security pop-up, then WHQL is
still the only sanctioned way to go. If WHQL is not possible, accept the
fact that there will be a pop-up about publisher (if you signed with a
CA cert).
–
Xiaofan
Hi All,
What Microsoft Policy says on distributing Test certificate?? Is it Legal or Illeagal??
can some one confirm it, As am seeing mixed response from the experts??
Dear Paval,
Does Microsoft restricts test signing a driver package and distribution??
If not what does the link says, could you please explain a bit more???
On Sun, Apr 15, 2012 at 5:02 PM, Pavel A wrote:
> On 13-Apr-2012 14:24, Hagen Patzke wrote:
>
>> Please read up about platform security, Pavel.
>>
>
> As an exercise for the reader:
>> - Explain in two sentences how MS could secure its certificate-based
>> driver and system component installer system.
>>
>
> One sentence will do? mainly by patching existing bugs.
>> http://technet.microsoft.com/en-us/security/bulletin/ms12-024
>>
>
> My apologies. yes, I’ve written that I don’t understand platform security,
> but let’s not take this too literally
> – pa
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.**cfm?name=ListServerhttp:
></http:>
On 2012.04.16 06:31, Xiaofan Chen wrote:
The issue in this discussion is actually regarding the pop-up warning.
Which is exactly what I am trying to answer.
I am trying to demonstrate that libwdi’s silencing of the warning is no
less secure or than the silencing of the same warning when someone
produces their own driver package and signs it using a public CA
certificate. I’ve been spending a great deal of time trying to explain
why it is the case, by making you understand that what matters here is
that the chain of trust isn’t broken, that the two chains of trusts
(libwdi’s and driver package signed by a public CA) are equivalent in
terms of of security and features, and that they both end up with a
similar public CA.
I think we can simplify this discussion if you or anybody else can
answer which of the following points they don’t think hold true, so that
I can try to point (again) out why this isn’t the case:
- Do you see the chain of trust from libwdi being broken anywhere?
- Do you see the public CA used in the signing of official libwdi
applications (the ones that only embed WinUSB, libusb-win32 and libusbk,
which I endorse as my own drivers), as less valid than the public CA
used in the signing of a regular driver package? - Do you see the chain of trust from libwdi as providing less security
or features than the one offered by a regular (non WHQL) signed driver
package?
If you can’t point out any actual issues with the above, then you must
acknowledge that libwdi’s security is at least as good as the one from a
regular signed driver package.
libwdi solved the problem using its method without the need of WHQL.
My question is whether it is really worth (or even helpful) to suppress
the warning using libwdi’s method.
If the trust you obtain there is the same as the trust you get from
installing a regular signed driver package (and I tried to demonstrate
that it is) then I very much believe that it is both worth and helpful
to suppress the warning, because end users have as much a reason to
trust the driver package produced by libwdi then as they have to trust a
regular signed package. In both case end users can feel reasonably safe
in trusting that the driver package (and the application that creates it
and installs self-signed certs, in the case of libwdi) will not attempt
to do anything malicious, because both chains of trust end with a
similar public CA that has vetted the author to be trustworthy and that
also has the ability to revoke trust and make that fact known to end
users (provided they have an internet connection).
I am not an expert in security but hopefully the experts here can check
the security with libwdi’s approach.
As I stated to you elsewhere, I dealt with security matters for quite a
few years, so I’m not exactly that green on the subject. The libwdi
solution was designed with preserving security in mind and not, as many
seem to believe, in a “I don’t understand the security warning but it’s
an annoyance - let’s suppress it”. The documentation and processes that
libwdi uses are there for all to check, and so far the only replies I
have seen can only be qualified as FUD (“engineering trade off”, “who’s
gonna be held liable?”), which I think stem more from people not having
looked at what libwdi *actually* does than deliberate mischief.
However, the assertion that, by silencing that warning, libwdi is doing
a lesser job in terms of security than a driver package signed using a
public CA is very damaging, since the process was designed to provide
the same level of security and trust, and I have yet to see anyone
coming with acceptable evidence to back up such a claim.
Okay, so with your explanation, let’s assume Zadig is not really
a problem since it only deals with three signed driver (winusb.sys,
libusb0.sys and libusbk.sys). I still have the following doubts.My question is whether it is really worth (or even helpful) to suppress
the warning using libwdi’s method.
I tried to answer that in the form of: “unless you believe that the
trust chain from Zadig is broken, or that the public CA credentials used
to sign Zadig are of lesser trust than the public CA credentials one
would use to sign a driver package, the only logical answer to that
question is that it is as worth (or helpful) as the suppressing of the
same warning on a regular (non WHQL) driver package”.
And my view is still that using self-signing and install certs to the trusted
store (using or not using libwdi’s approach) is mainly meant for developers
or big organizations.
Then in that case, the installation of a regular driver package signed
by a public CA is also mainly meant for developers or big organizations.
It’s simple logic. You can’t discredit one method and say the other is
OK, when both are providing the same level of security and trust (and at
last, you seem to be agreeing that they might, which I will construe as
some form of progress). Either both are OK, or none.
If you want to release the driver package to the
general public and do not want to have a security pop-up, then WHQL is
still the only sanctioned way to go. If WHQL is not possible, accept the
fact that there will be a pop-up about publisher (if you signed with a
CA cert).
If we’re talking about WHQL, then in that case neither signing of a
regular driver package or libwdi are acceptable, and I don’t exactly
have a problem with some people choosing to see it that way (how much
trust you have in signed driver packages that weren’t produced by
Microsoft is your own business). That is, as long as they also
acknowledge that the trust provided by an official libwdi app or from a
regular signed driver package is equivalent, and therefore dismiss both
equally.
But they shouldn’t force others, who want to leverage a method that
Microsoft apparently deems trustworthy enough, into only using WHQL. As
long as Microsoft hasn’t declared WHQL as the “one true way” and removed
the possibility of installing a non WHQL driver package outside of test
mode, they seem to acknowledge that WHQL is not meant to apply to everybody.
Regards,
/Pete