Where to create the certificate 9??

Dear All,

Through my analysis I found the following & have some doubts in it, could someone help me out by clarifying it:

  1. Since am using default windows driver ( USBER.SYS )its not required to sign it. Correct me if am wrong.

  2. So just to avoid the Windows warning, my inf needs to be signed. As i already selfsigned my inf at my machine(pc), am i allowed to redistribute it?

  3. Or Should the certificates be generated only in the clients machine to whom i am going to give the driver package not in my machine where i am developing?No restriction from my customer end to install my cert…

You can not sign an INF (only the CATalog that contains its checksum).
Please read up about KMCS.

Why are you refusing to accept the advice that has been given, and continue to violate the certification of your code? Why not simply purchase a certificate from a qualified CA? The only way I have ever seen the test certificate work is in a development environment where both end machines have Visual Studio and the WDK installed. So I guess you could do that. Require your customers to purchase an MSDN Pro subscription that provides both of those products. Buy the god damned certificate already.

If you’re installing on a 64 bit platform, the inbox version of usbser.sys is already signed, else it would not have install/load. If you mess with any part of the usbser package, like build it from the WDK source, then it is no longer signed and you’re back to square one — go buy a certificate.

Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

On Apr 11, 2012, at 12:36 AM, xxxxx@gmail.com wrote:

Dear All,

Through my analysis I found the following & have some doubts in it, could someone help me out by clarifying it:

  1. Since am using default windows driver ( USBER.SYS )its not required to sign it. Correct me if am wrong.

  2. So just to avoid the Windows warning, my inf needs to be signed. As i already selfsigned my inf at my machine(pc), am i allowed to redistribute it?

  3. Or Should the certificates be generated only in the clients machine to whom i am going to give the driver package not in my machine where i am developing?No restriction from my customer end to install my cert…


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=ListServer

On 11-Apr-2012 15:31, Gary Little wrote:

Why are you refusing to accept the advice that has been given, and
continue to violate the certification of your code? Why not simply
purchase a certificate from a qualified CA?

Because a cert in these conditions would not be a good investment: a new
unknown cert won’t silence all Windows popups; and
usbser.sys is already signed by Microsoft.
On the other hand, elevation is anyway required to install the driver,
thus users must trust the OP’s installer to run as admin.
So it is tempting to use the admin privileges to return the favor
to the users and save them a mouse click.

The procedure used in libwdi project is described here:
http://ow.ly/acSGz

That text IMHO completely answers the OP’s question: why generation
of self-signed cert on the target machine is preferred over distribution
of a ready cert from security POV.
All OP needs is to read carefully and understand.

Regards
– pa

On Wed, Apr 11, 2012 at 9:03 PM, Pavel A wrote:
> On 11-Apr-2012 15:31, Gary Little wrote:
>>
>> Why are you refusing to accept the advice that has been given, and
>> continue to violate the certification of your code? Why not simply
>> purchase a certificate from a qualified CA?
>
>
> Because a cert in these conditions would not be a good investment: a new
> unknown cert won’t silence all Windows popups; and
> usbser.sys is already signed by Microsoft.

Actually this is also recommended by Microsoft in some cases.
http://libusb.6.n5.nabble.com/WHQL-Testing-Agreement-and-GPLv3-conflicts-tp3335877p3337666.html

(libusb0.sys is GPL so no WHQL based on WLK license, Microsoft
recommends the customer to use self-sign).

Read the whole thread and you will see that Chris successfully achieved
his goal. And I believe this prompts Pete to write libwdi. And the thread
also makes us to use BSD as the main license option for libusbK (with
GPL as the 2nd option for people who really like GPL).
http://libusbk.sourceforge.net/UsbK3/index.html


Xiaofan

Thanks for that, Mr. Chen. A very interesting thread indeed.

The basic issue – and the proposed self-signing solution – DOES seem to be counter to the whole intent of driver signing, however. “I want to install my unsigned driver, using a randomly generated certificate, so the user isn’t told he’s installing an unsigned driver.” To repeat what I said, oh, six thousand messages ago… One of the fundamental reasons for kernel mode code signing is to unambiguously identify the origin of an entire package of “stuff” that includes code that’ll be loaded into kernel-mode on your system. So, *regardless* of whether your driver can ever be signed by WHQL, *somebody* should be signing the driver so the user knows (a) the driver package was not tampered with, and (b) who put the package together. The user should then make their OWN decision about whether to trust the package creator.

By going the LibUsbK route, the developer is deliberately thwarting this and denying the user the opportunity to be certain of the origin and content of their driver software package. I’m having trouble believing this is a service to the user community, even when done in the name of “convenience.”

Peter
OSR

On Thu, Apr 12, 2012 at 12:42 AM, wrote:
> Thanks for that, Mr. Chen. ?A very interesting thread indeed.
>
> The basic issue – and the proposed self-signing solution –
> DOES seem to be counter to the whole intent of driver signing,
> however. ?“I want to install my unsigned driver, using a randomly
> generated certificate, so the user isn’t told he’s installing an
> unsigned driver.” ?To repeat what I said, oh, six thousand messages ago…

I agree with you here.

> One of the fundamental reasons for kernel mode code signing is
> to unambiguously identify the origin of an entire package of “stuff”
> that includes code that’ll be loaded into kernel-mode on your system.
> So, regardless of whether your driver can ever be signed by WHQL,
> somebody should be signing the driver so the user knows (a) the
> driver package was not tampered with, and (b) who put the package
> together. ?The user should then make their OWN decision about
> whether to trust the package creator.

Yes I agree with you here. On the other hand, if the corporate
IT department deploys their own certificates to their user’s machine
(which is fine, in such a controlled environment), then it is another story.

> By going the LibUsbK route,

Not libusbk’s route, but libwdi’ route.

Take note libusbK is not libwdi. libwdi is Pete Batard’s project. libusbK
is developed by Travis (current developer of libusb-win32 as well) and
I am the co-admin of libusb-win32 and libusbK, helping Travis. Yes
libusb-win32 and libusbK installer use libwdi but we do not enable the
feature in our installer.

> the developer is deliberately thwarting
> this and denying the user the opportunity to be certain of the origin
> and content of their driver software package. ?I’m having trouble
> believing this is a service to the user community, even when done
> in the name of “convenience.”

I myself do not quite like this feature of libwdi to be enabled
by default. Even in the case libwdi’s Zadig, this is an option
feature that users can enable or disable.


Xiaofan

On Thu, Apr 12, 2012 at 12:42 AM, wrote:
> Thanks for that, Mr. Chen. ?A very interesting thread indeed.
>

Yes it is interesting but it is a bit long. So this one may be
most relevant if people here do not have the patience to
read the whole thread.
http://libusb.6.n5.nabble.com/WHQL-Testing-Agreement-and-GPLv3-conflicts-tp3335877p3339296.html

You can see that this has been discussed in OSR list before.
http://www.osronline.com/showthread.cfm?link=193826


Xiaofan

On Wed, Apr 11, 2012 at 9:03 PM, Pavel A wrote:
> The procedure used in libwdi project is described here:
> http://ow.ly/acSGz
>
> That text IMHO completely answers the OP’s question: why generation
> of self-signed cert on the target machine is preferred over distribution of
> a ready cert from security POV.
> All OP needs is to read carefully and understand.

So you agree with Pete Batard (libwdi author) that auto-generated self-signed
cert on the target machine is preferred over distribution of a ready cert from
security POV. I think that depends on where the “ready cert” comes from.

A ready cert from a CA (well-known ones like Verisign or GlobalSign or
corporate’ own CA) can identify who signs the package. That is the
important thing here.

Of course if the “ready cert” comes from a person from no-where
then that is a problem.

That is why I suggest the OP to get WHQL as the best option
and use a recognized CA as the 2nd option.
http://libusb.6.n5.nabble.com/Driver-package-signing-tp5627421p5632445.html


Xiaofan

>http://libusb.6.n5.nabble.com/WHQL-Testing-Agreement-and-GPLv3-conflicts-

Why use GPLv3? why not GPLv2?


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

On Thu, Apr 12, 2012 at 11:45 AM, Maxim S. Shatskih
wrote:
>>http://libusb.6.n5.nabble.com/WHQL-Testing-Agreement-and-GPLv3-conflicts-
>
> Why use GPLv3? why not GPLv2?

GPL v2 is also not okay in this case. I personally like new BSD much
better than GPL v2/v3 or LGPL v2/v3. That is why we choose BSD as
the main license for the new libusbK project.

libusb-win32 is a legacy project we took over from others. We can
switched it from GPL v3 to v2 but it does not help in this case. I’d
prefer to switch to BSD. But we have the new libusbK project so
it does not matter too much that libusb-win32 kernel driver
will remain as GPL (the DLL is LGPL).


Xiaofan

sethu raman wrote:

  1. Since am using default windows driver ( USBER.SYS )its
    not required to sign it. Correct me if am wrong.

  2. So just to avoid the Windows warning, my inf needs
    to be signed. As i already selfsigned my inf at my machine(pc),
    am i allowed to redistribute it?

Here’s what I’d like to know after all these years. Why isn’t there an inbox INF that matches USB\Class_02&Subclass_02 (or whatever; in other words, the compatible IDs for CDC ACM) which loads usbser.sys?

As a result every single person who ever made a USB modem had to go write their own INF, which means they can’t silent install out of the box.

I guess part of the reason is because all of the monkey business with AT commands, baud rates and everything else is tied to it, but I mean, come on, make some reasonable assumptions and throw something in there and put these people out of their misery.

I mean, this has been going on for over what, ten years now? And now “sethu raman” here is going around asking people how to force install his bogus test certificate to get around driver signing warnings. And so it continues…

On Thu, Apr 12, 2012 at 11:54 AM, wrote:
> sethu raman wrote:
>
>> 1) Since am using default windows driver ( USBER.SYS )its
>> not required to sign it. Correct me if am wrong.
>>
>> 2) So just to avoid the Windows warning, my inf needs
>> to be signed. As i already selfsigned my inf at my machine(pc),
>> am i allowed to redistribute it?
>
> Here’s what I’d like to know after all these years.
>?Why isn’t there an inbox INF that matches USB\Class_02&Subclass_02
> (or whatever; in other words, the compatible IDs for CDC ACM)
> which loads usbser.sys?

Indeed this is a very good question to Microsoft. The other
OS like Linux and Mac OS X can load CDC-ACM device
automatically without the hassle like Windows.

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.

Reference:
http://www.cygnal.org/ubb/Forum9/HTML/000945.html

Two famous bugs of usbser.sys which prevents IAD device
with CDC-ACM as one of the function from working properly
for Windows XP SP2 (hot fixes included in SP3).
http://www.cygnal.org/ubb/Forum9/HTML/000945.html
http://support.microsoft.com/kb/918365/en-us
http://support.microsoft.com/kb/935892/en-us

And maybe this is the main reason that why majority of the
USB to serial converter vendors (FTDI, Prolific, Silicon Labs, etc)
do not use uses custom class device and develop their own driver
for it. One exception is Microchip who is a new comer to this
market. Its device is a USB Composite Device (HID and
CDC-ACM, using the inbox HID driver and the usbser.sys driver).

> As a result every single person who ever made a USB modem
> had to go write their own INF, which means they can’t silent install
> out of the box.

Probably this is a good to have feature for Windows 8 and
future Windows 7 service packs. Windows 8 has the nice
Windows compatible ID feature for WinUSB, maybe it
is good to have good inbox class driver for CDC-ACM.
Ref: http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=WCID_devices

> I guess part of the reason is because all of the monkey
> business with AT commands, baud rates and everything else is
> tied to it, but I mean, come on, make some reasonable assumptions
> and throw something in there and put these people out of their misery.
>


Xiaofan

Hi Xiaofan,

As Peter V. reminded, the purpose of signing is “identify the origin of an
entire
package of “stuff” that includes code that’ll be loaded into kernel-mode on
your system.”

I am not a security specialist in any way and cannot tell how tight is
the libwdi solution, but from a “common sense” POV it looks good
enough when software vendors do not sign their driver packages.

In case when the driver binary is signed with a *real* KMCS cert, and the
vendor’s wrapper
“setup.exe” signed with a real (possibly different) *authenticode* cert -
authenticode signature identifies the whole bundle to users, before they
grant “setup.exe” permission to do *everything* with their system.
KMCS signature identifies the binaries.

What remains is the driver package level, and requirement to sign that with
WHQL is a burden.
Libwdi has a method to remove it, and skip nagging users when the package
is staged to the driver store, altogether.
This has even more value when you install a complex product containing many
driver packages at once.

This IMHO clearly explains implementation details *to specialists*, and the
intent to everybody else.

We see that vendors are not inclined to WHQL their packages, no matter how
hard Microsoft pushes.
I did not say that WHQL isn’t good… but certain things just will be done
as the “industry” wants it.

Regards,
– pa

“Xiaofan Chen” wrote in message news:xxxxx@ntdev…
> On Wed, Apr 11, 2012 at 9:03 PM, Pavel A wrote:
>> The procedure used in libwdi project is described here:
>> http://ow.ly/acSGz
>>
>> That text IMHO completely answers the OP’s question: why generation
>> of self-signed cert on the target machine is preferred over distribution
>> of
>> a ready cert from security POV.
>> All OP needs is to read carefully and understand.
>
> So you agree with Pete Batard (libwdi author) that auto-generated
> self-signed
> cert on the target machine is preferred over distribution of a ready cert
> from
> security POV. I think that depends on where the “ready cert” comes from.
>
> A ready cert from a CA (well-known ones like Verisign or GlobalSign or
> corporate’ own CA) can identify who signs the package. That is the
> important thing here.
>
> Of course if the “ready cert” comes from a person from no-where
> then that is a problem.
>
> That is why I suggest the OP to get WHQL as the best option
> and use a recognized CA as the 2nd option.
> http://libusb.6.n5.nabble.com/Driver-package-signing-tp5627421p5632445.html
>
>
> –
> Xiaofan

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.

“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.
– pa

On Thu, Apr 12, 2012 at 9: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.

This one I completely agree. Take note that Microsoft needs
to support its own test engineers and big corporates.

Ref: http://www.osronline.com/showthread.cfm?link=193826
Ref: http://libusb.6.n5.nabble.com/WHQL-Testing-Agreement-and-GPLv3-conflicts-td3335877i20.html#a3339296


Xiaofan

On Thu, Apr 12, 2012 at 8:35 PM, Pavel A. wrote:
> Hi Xiaofan,
>
> As Peter V. reminded, the purpose of signing is “identify the origin of an
> entire package of “stuff” that includes code that’ll be loaded into
> kernel-mode on your system.”

I agree.

> I am not a security specialist in any way and cannot tell how tight is
> the libwdi solution, but from a “common sense” POV it looks good
> enough when software vendors do not sign their driver packages.

I am not even a programmer myself and only knows a little about
C and about USB. You can call me a USB hobbyist. I am a
hardware engineer by profession and have only written a few
embedded assembly and C programs less than 4KB for work.

> In case when the driver binary is signed with a real KMCS cert,
> and the vendor’s wrapper
> “setup.exe” signed with a real (possibly different) authenticode cert -
> authenticode signature identifies the whole bundle to users, before they
> grant “setup.exe” permission to do everything with their system.
> KMCS signature identifies the binaries.

Yes that is the case of usbser.sys and the one libwdi deals with
(say libusb0.sys and libusbk.sys and winusb.sys, all are signed
so that they can be loaded to 64bit Windows Vista/7/etc).

> What remains is the driver package level, and requirement to sign
> that with WHQL is a burden.

Yes in some cases WHQL can be considered as a burden and
sometimes not even possible (e.g.: in the case of a GPL v2/v3
open source kernel driver) . But to sign that package with a
cert is not that expensive and not really a big burden.

> Libwdi has a method to remove it, and ?skip nagging users when
> the package is staged ?to the driver store, altogether.
> This has even more value when you install a complex product
> containing many driver packages at once.

Yes I think libwdi’s approach may be quite good for those
controlled environment.

>
>



The “we” above is a one man shop…

> This IMHO clearly explains implementation details to specialists, and the
> intent to everybody else.

Yes it looks quite good. The issue is that if you compare the approach
of signing with a cert from a well-known CA and the libwdi approach,
which one do you prefer?

To put it more blunt, do you trust an unknown developer named
Pete Batard more or VeriSign/GlobalSign?

> We see that vendors are not inclined to WHQL their packages, no matter how
> hard Microsoft pushes. I did not say that WHQL isn’t good… but certain things
> just will be done as the “industry” wants it.

That one I agree. But the middle ground is good for many cases (sign
with a CA cert). And many end users do not have problems with the
red warnings either with those unsigned driver packages (but with
KMCS signed binary kernel driver).

Take note CA certs does give some degree of confidence to identify
who the signer is and the certs can be revoked if the signer does
something bad.

libwdi’s approach does have its own merit and Pete has done a
great job in libwdi. However, I do not quite agree with you that
his approach is better than a CA cert.

Quoting Doron here.
http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/28b936d8-22b5-40dd-b16c-8da5f4828bee

“Sure! Happy to do it: Get yourself a proper Class 3 Code Signing Certificate
and use it to sign your driver. It’s as simple as that. The whole
point of the
kernel-mode code signing program is that Kernel mode modules need to be
identified as to their origin. The way you do this is by getting a
Class 3 Code
Signing Certificate. It costs a few hundred dollars. Pay for it,
find somebody
else to pay for it, find somebody who has a legitimate certificate who’ll sign
your driver, or give up distributing your driver. It’s really that simple.”


Xiaofan

Please consider these logical understandings:

  1. Microsoft is happy to provide an option to the users even to ignore the warnings whatsoever, if the user is ready.

  2. Also, Microsoft accepts the driver installation with Trusted Publishers warning , if the approval is from the end user.

It clearly indicates that the control is with the end user and no other security factors are concerned at all from

Microsoft.
I will clearly tell my user that why i am asking them to install this certificate and they are willing to go with me…

  1. And in my case, i am using only the Microsoft’s Native Driver and am just trying to avoid the issue with PnP installation

in Windows Xp, as stated below.

Microsoft implemented two different scenario in two different versions.

After installing the driver at first time, If i unplug and re-insert the device in another port , windows finds the

correspongding inf from INF ROOT directory and tried to load but it fails due to the error 1168(not sure whether its a

intended error or a bug in xp).

Below is my setupApi.log :

[2012/03/28 21:56:18 1180.3 Driver Install]
#-019 Searching for hardware ID(s): usb\vid_1234&pid_2345&rev_1234,usb\vid_1234&pid_2345
#-018 Searching for compatible ID(s): usb\class_02&subclass_02&prot_00,usb\class_02&subclass_02,usb\class_02
#-198 Command line processed: C:\WINDOWS\system32\services.exe
#I022 Found “USB\VID_1234&PID_2345” in C:\WINDOWS\inf\oem48.inf; Device: “USB MY DEVICE”; Driver: “USB MY DEVICE”;
Provider: “s COMPANY”; Mfg: “S COMPANY”; Section name: “MY”.
#I087 Driver node not trusted, rank changed from 0x00000001 to 0x00008001.
#I023 Actual install section: [MY.NT]. Rank: 0x00008001. Effective driver date: 04/22/2008.
#-166 Device install function: DIF_SELECTBESTCOMPATDRV.
#I063 Selected driver installs from section [MY] in “c:\windows\inf\oem48.inf”.
#I320 Class GUID of device remains: {4D36E978-E325-11CE-BFC1-08002BE10318}.
#I060 Set selected driver.
#I058 Selected best compatible driver.
#-166 Device install function: DIF_INSTALLDEVICEFILES.
#I124 Doing copy-only install of “USB\VID_1234&PID_2345\7&1234E19F&1&2”.
#-011 Installing section [MY.NT] from “c:\windows\inf\oem48.inf”.
#E358 An unsigned or incorrectly signed file “c:\windows\inf\oem48.inf” for driver “USB MY DEVICE” blocked (server install).

Error 1168:
Element not found.
#E122 Device install failed. Error 1168: Element not found.
#E157 Default installer failed. Error 1168: Element not found.


So, i am restricting the user to use the single USB port to avoid multiple installations and am not able to achieve pnp mode

of installation.

4.Howcome, the windows accepted the same inf at first installation and not loading from the precompilation installation at

later point of time?

But in later versions of windows,it can load the driver even if its unsigned and am not prompted to install the driver more

than once.So pnp installation is successfully working.

Note : The pnp installation through DPInst.exe With self signed certifiacte for inf alone (not for drivers) is working fine

in all the versions of Windows including windows xp.

Can anybody from microsoft say something that could be so solid?

FYI : POSTED IN xxxxx@lists.sourceforge.net ALSO.

“Xiaofan Chen” wrote in message news:xxxxx@ntdev…

> The issue is that if you compare the approach
> of signing with a cert from a well-known CA and the libwdi approach,
> which one do you prefer?
>
> To put it more blunt, do you trust an unknown developer named
> Pete Batard more or VeriSign/GlobalSign?

>
> libwdi’s approach does have its own merit and Pete has done a
> great job in libwdi. However, I do not quite agree with you that
> his approach is better than a CA cert.

Of course I prefer a well-known CA, and only that for KMCS.
But the point is that a cert even from well-known CA needs to be introduced
to Windows once,
and this causes an extra popup.
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
:slight_smile:

IIRC, the OP’s problem is exactly that popup.

Regards,
– pa