Quantcast

Driver package signing

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Driver package signing

sethuuraman
Dear Experts,

      I just started involving in Windows Driver Development, very freshly. And struggling a lot to finish my task.

It would really the greatest help if somebody take interest to answer my below questions. My questions would be pretty big but all will be binary answers(yes or no).

1. I am done developing an INF file with the windows default or native driver USBSER.SYS (CDC ACM MOdel) for my device.Its working fine too...
  

2.my driver installation should be a Software First Installaion or PNP installation. To do that, i am using DPInst.exe in my Installation Package. Its working fine but with windows signing warnings. I am intended to avoid these warnings. I am seriously struggling here with the following questions.
 
       2.1. My inf is working fine and i am using only the windows default driver(USBSER.sys) in the inf. In this case, is it required to sign the default sys file? Or Is it already Signed? Or Is signing not required?
 
       2.2.I have understood that Signing the driver binaries(SYS,DLL,...) and Signing the driver package(inf) are completely different. Also, the signing warning(Windows can't verify the the publisher of the software) occurs only because of my unsigned inf and not because of the driver?Am i wrong?
       2.3 To avoid the above said warning, by assuming USESER.SYS doesn't require any signing, i selfsigned or test signed my inf file in the following way as mentioned at http://www.itninja.com/question/guide-to-signing-unsigned-drivers.

# creted .cat file using Inf2cat.exe
Inf2Cat.exe /driver:"<Path of the inf>"

# created certificate using makecert.exe
MakeCert.Exe -r -pe <path to .cer file you want to generate> -n CN=<certificate name> -sv <path to .pvk file you want to generate> -len 2048

      2.4) As per the MS DDK Documentation, the test signing or Self Signing is done without PVK... Am i wrong in the last step?


But here i created the PVK also?  

# Create Software Publisher's Certificate (SPC) from our certificate
Cert2Spc.Exe <path to .cer file> <path to .spc file>
 
# Create a .pfx file
pvk2pfx.exe -pvk <path of .pvk file created earlier> -pi <password> -spc "<path of .pfx to be stored>

# Sign the catalog file
signtool.exe sign /f "<path of .pfx file>" /p <password> /t http://timestamp.comodoca.com/authenticode /v "<cat file to be signed>"

# Installed the certificate in local machine
certmgr.exe /add "<path of the certificate created>" /s /r localMachine root
certmgr.exe /add "<path of the certificate created>" /s /r localMachine trustedPublishers


3. I am successuly created cert file and now, not getting any warnings during installation with DPInst.My critical question here is, can i distribute or publish this signed certificate that i created ?? i.e Can i install my self signed certificate in my clients machine ( is it legal to distribute my signed certificate for commercial use).
Please condsider that there won't be any objection from my client side where i want to install the certificate.
As for as my concerned, i am self signing only the INF file and not sys file, Here i need to really concern only about Microsoft policy on redistribution not to bother about my clients approval?

4.Seems that certmgr.exe is not distibutable and help me in providing the alternative tool or code to import the certificate?



could You please consider to answer it too :

My another aim is to create a Automatic Dial-up network connection as soon as the driver is installed as how the 3G Data Card/Modem's(USB Modem) are working. A new Dial Up Connection will be created automatically whenever the USB modem is plugged in, with the driver installed in the PC.
I heard that CDC ECM/CDC EEM models could be helpful, however there are no defualt or Native drivers for ECM/EEM models from microsoft.Am i wrong?

In this case,Should the driver to be developed on our own to achieve my intention(creating a dial up connection)? Or Are Anyother drivers available?




------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Xiaofan Chen
On Mon, Apr 9, 2012 at 10:12 PM, Sethuraman R <[hidden email]> wrote:
> Dear Experts,
>
>       I just started involving in Windows Driver Development, very freshly.
> And struggling a lot to finish my task.

This mailing list may be the wrong list for you.

This is the best list for Windows driver development.
http://www.osronline.com/showlists.cfm?list=ntdev

> It would really the greatest help if somebody take interest to answer my
> below questions. My questions would be pretty big but all will be binary
> answers(yes or no).
>
> 1. I am done developing an INF file with the windows default or native
> driver USBSER.SYS (CDC ACM MOdel) for my device.Its working fine too...

So this is not related to libusb-win32, right?

> 2.my driver installation should be a Software First Installaion or PNP
> installation. To do that, i am using DPInst.exe in my Installation Package.
> Its working fine but with windows signing warnings. I am intended to avoid
> these warnings. I am seriously struggling here with the following questions.
>
>        2.1. My inf is working fine and i am using only the windows default
> driver(USBSER.sys) in the inf. In this case, is it required to sign the
> default sys file? Or Is it already Signed? Or Is signing not required?

The sys file is signed, but not the driver package which include
the inf file. So there will be warnings.

>        2.2.I have understood that Signing the driver binaries(SYS,DLL,...)
> and Signing the driver package(inf) are completely different. Also, the
> signing warning(Windows can't verify the the publisher of the software)
> occurs only because of my unsigned inf and not because of the driver?Am i
> wrong?
>        2.3 To avoid the above said warning, by assuming USESER.SYS doesn't
> require any signing, i selfsigned or test signed my inf file in the
> following way as mentioned at
> http://www.itninja.com/question/guide-to-signing-unsigned-drivers.
>
> # creted .cat file using Inf2cat.exe
> Inf2Cat.exe /driver:"<Path of the inf>"
>
> # created certificate using makecert.exe
> MakeCert.Exe -r -pe <path to .cer file you want to generate> -n
> CN=<certificate name> -sv <path to .pvk file you want to generate> -len 2048
>
>       2.4) As per the MS DDK Documentation, the test signing or Self Signing
> is done without PVK... Am i wrong in the last step?
>
>
> But here i created the PVK also?
>
> # Create Software Publisher's Certificate (SPC) from our certificate
> Cert2Spc.Exe <path to .cer file> <path to .spc file>
>
> # Create a .pfx file
> pvk2pfx.exe -pvk <path of .pvk file created earlier> -pi <password> -spc
> "<path of .pfx to be stored>
>
> # Sign the catalog file
> signtool.exe sign /f "<path of .pfx file>" /p <password> /t
> http://timestamp.comodoca.com/authenticode /v "<cat file to be signed>"
>
> # Installed the certificate in local machine
> certmgr.exe /add "<path of the certificate created>" /s /r localMachine root
> certmgr.exe /add "<path of the certificate created>" /s /r localMachine
> trustedPublishers
>
>
> 3. I am successuly created cert file and now, not getting any warnings
> during installation with DPInst.My critical question here is, can i
> distribute or publish this signed certificate that i created ?? i.e Can i
> install my self signed certificate in my clients machine ( is it legal to
> distribute my signed certificate for commercial use).
>
> Please condsider that there won't be any objection from my client side where
> i want to install the certificate.
> As for as my concerned, i am self signing only the INF file and not sys
> file, Here i need to really concern only about Microsoft policy on
> redistribution not to bother about my clients approval?

For legal questions, ask a lawyer.

I am not a lawyer. On the other hand, it is in general okay for
corporate IT department to deploy such certificates to their
client machines. But again, the legal and IT department in
your client need to evaluate the situation.

Read this whole thread about this situation as well.
http://libusb.6.n5.nabble.com/WHQL-Testing-Agreement-and-GPLv3-conflicts-td3335877.html

> 4.Seems that certmgr.exe is not distibutable and help me in providing the
> alternative tool or code to import the certificate?

You can look at libwdi.
http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Main_Page

> could You please consider to answer it too :
>
> My another aim is to create a Automatic Dial-up network connection as soon
> as the driver is installed as how the 3G Data Card/Modem's(USB Modem) are
> working. A new Dial Up Connection will be created automatically whenever the
> USB modem is plugged in, with the driver installed in the PC.
> I heard that CDC ECM/CDC EEM models could be helpful, however there are no
> defualt or Native drivers for ECM/EEM models from microsoft.Am i wrong?
>
> In this case,Should the driver to be developed on our own to achieve my
> intention(creating a dial up connection)? Or Are Anyother drivers available?

Please ask in the OSR ntdev list. Thanks.


--
Xiaofan

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Xiaofan Chen
On Mon, Apr 9, 2012 at 11:06 PM, Xiaofan Chen <[hidden email]> wrote:

>> could You please consider to answer it too :
>>
>> My another aim is to create a Automatic Dial-up network connection as soon
>> as the driver is installed as how the 3G Data Card/Modem's(USB Modem) are
>> working. A new Dial Up Connection will be created automatically whenever the
>> USB modem is plugged in, with the driver installed in the PC.
>> I heard that CDC ECM/CDC EEM models could be helpful, however there are no
>> defualt or Native drivers for ECM/EEM models from microsoft.Am i wrong?
>>
>> In this case,Should the driver to be developed on our own to achieve my
>> intention(creating a dial up connection)? Or Are Anyother drivers available?
>
> Please ask in the OSR ntdev list. Thanks.
>

This is because I do not know the answer and this has nothing
to do with libusb-win32.


--
Xiaofan

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Pete Batard-2
In reply to this post by sethuuraman
Hi,

On 2012.04.09 15:12, Sethuraman R wrote:
>         2.1. My inf is working fine and i am using only the windows
> default driver(USBSER.sys) in the inf. In this case, is it required to
> sign the default sys file? Or Is it already Signed? Or Is signing not
> required?

Binary drivers that come from the Windows OS are already signed, though,
unlike non Windows signed drivers, the signature may not be displayed
when right clicking. But unless you use your own custom version, you
should not have to sign this file.

>         2.2.I have understood that Signing the driver
> binaries(SYS,DLL,...) and Signing the driver package(inf) are completely
> different.

Indeed. One will prevent you from using the driver altogether, unless
running Windows in test mode, and the other determines whether users are
prompted with a warning during driver installation.

> Also, the signing warning(Windows can't verify the the
> publisher of the software) occurs only because of my unsigned inf and
> not because of the driver?

Yes.

>         2.3 To avoid the above said warning, by assuming USESER.SYS
> doesn't require any signing, i selfsigned or test signed my inf file in
> the following way as mentioned at
> http://www.itninja.com/question/guide-to-signing-unsigned-drivers.
>
> # creted .cat file using Inf2cat.exe
> Inf2Cat.exe /driver:"<Path of the inf>"

You may also want to have a look at the Signed Cat file part of the
libwdi signed driver walkthrough [1]. You may want to append a /os:
option there, depending on your target OSes.

> # created certificate using makecert.exe
> MakeCert.Exe -r -pe <path to .cer file you want to generate> -n
> CN=<certificate name> -sv <path to .pvk file you want to generate> -len
> 2048

You may also want to have a look at this post from libusb-win32, where I
did something similar [2].

>        2.4) As per the MS DDK Documentation, the test signing or Self
> Signing is done without PVK... Am i wrong in the last step?
>
> But here i created the PVK also?

In a PKI implementation, you always need a private key, so one always
exists. You can't create a self-signing certificate without a private key.

> # Create Software Publisher's Certificate (SPC) from our certificate
> Cert2Spc.Exe <path to .cer file> <path to .spc file>
>
> # Create a .pfx file
> pvk2pfx.exe -pvk <path of .pvk file created earlier> -pi <password> -spc
> "<path of .pfx to be stored>
>
> # Sign the catalog file
> signtool.exe sign /f "<path of .pfx file>" /p <password> /t
> http://timestamp.comodoca.com/authenticode /v "<cat file to be signed>"
>
> # Installed the certificate in local machine
> certmgr.exe /add "<path of the certificate created>" /s /r localMachine root
> certmgr.exe /add "<path of the certificate created>" /s /r localMachine
> trustedPublishers

As long as you have a pfx that matches your self-signed certificate, and
you install the cert in root and trustedPublishers, you should be OK for
validation of the driver package. Be mindful that this needs to be done
from an elevated command prompt.

The trick not to get the driver package prompt is to have the public key
of your self-signed credential in root and trustedPublishers, and to
sign the inf package with the matching private key.

> 3. I am successuly created cert file and now, not getting any warnings
> during installation with DPInst.

So far so good.

> My critical question here is, can i
> distribute or publish this signed certificate that i created ?? i.e Can
> i install my self signed certificate in my clients machine ( is it legal
> to distribute my signed certificate for commercial use).

Absolutely. Distribution of the *public* key, which is what is meant to
get installed in the client's security store through a certificate, is
no concern at all and has no legal implication whatsoever (even if you
export it to Iran or something). Many software developers, including
Microsoft of course, export public keys in one way or another, be it for
root certification authorities, and no special concern needs to be taken
to do so. And the same would be true for the private key as well, since
public and private key are usually symmetric, provided it wasn't a very
bad idea to distribute a private key.

Just make sure that you distribute a certificate (i.e. a container with
the public key only - typically a .cer on Windows) and not a credential
(container with both the private and public key - typically a .pfx), as
making your private key available would allow anyone to sign and get
malicious software installed that validates against your public key,
which is not what you want.

> Please condsider that there won't be any objection from my client side
> where i want to install the certificate.

As long as you ensure that your private key remains private and out of
reach from malicious users, installing your certificate on the client's
side shouldn't be a concern.

> 4.Seems that certmgr.exe is not distibutable and help me in providing
> the alternative tool or code to import the certificate?

Travis has developed a dpscat utility for libusbK that may be of help.
You can find it in the binary directory of the latest libusbK [3].

Regards,

/Pete

PS: Sorry for not answering your original e-mail on the libwdi mailing
list. I got confused about the message asking to disregard.

[1]
https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Signed_driver_walkthrough#Creating_a_signed_cat_file
[2] https://sourceforge.net/mailarchive/message.php?msg_id=27223654
[3] https://sourceforge.net/projects/libusbk/files/libusbK-beta/3.0.5.10/

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

sethuuraman
Dear Pete & Xiaofan,

Sometimes, words can't be really used to express what we really feel. This might be the very simple clarifications for others, but being a novice its so helpful to me in many ways.

This is the reply that we have been waiting for....

Thanks,
Sethu..........

Pete,

On Mon, Apr 9, 2012 at 8:50 PM, Pete Batard <[hidden email]> wrote:
Hi,

On 2012.04.09 15:12, Sethuraman R wrote:
>         2.1. My inf is working fine and i am using only the windows
> default driver(USBSER.sys) in the inf. In this case, is it required to
> sign the default sys file? Or Is it already Signed? Or Is signing not
> required?

Binary drivers that come from the Windows OS are already signed, though,
unlike non Windows signed drivers, the signature may not be displayed
when right clicking. But unless you use your own custom version, you
should not have to sign this file.

>         2.2.I have understood that Signing the driver
> binaries(SYS,DLL,...) and Signing the driver package(inf) are completely
> different.

Indeed. One will prevent you from using the driver altogether, unless
running Windows in test mode, and the other determines whether users are
prompted with a warning during driver installation.

> Also, the signing warning(Windows can't verify the the
> publisher of the software) occurs only because of my unsigned inf and
> not because of the driver?

Yes.

>         2.3 To avoid the above said warning, by assuming USESER.SYS
> doesn't require any signing, i selfsigned or test signed my inf file in
> the following way as mentioned at
> http://www.itninja.com/question/guide-to-signing-unsigned-drivers.
>
> # creted .cat file using Inf2cat.exe
> Inf2Cat.exe /driver:"<Path of the inf>"

You may also want to have a look at the Signed Cat file part of the
libwdi signed driver walkthrough [1]. You may want to append a /os:
option there, depending on your target OSes.

> # created certificate using makecert.exe
> MakeCert.Exe -r -pe <path to .cer file you want to generate> -n
> CN=<certificate name> -sv <path to .pvk file you want to generate> -len
> 2048

You may also want to have a look at this post from libusb-win32, where I
did something similar [2].

>        2.4) As per the MS DDK Documentation, the test signing or Self
> Signing is done without PVK... Am i wrong in the last step?
>
> But here i created the PVK also?

In a PKI implementation, you always need a private key, so one always
exists. You can't create a self-signing certificate without a private key.

> # Create Software Publisher's Certificate (SPC) from our certificate
> Cert2Spc.Exe <path to .cer file> <path to .spc file>
>
> # Create a .pfx file
> pvk2pfx.exe -pvk <path of .pvk file created earlier> -pi <password> -spc
> "<path of .pfx to be stored>
>
> # Sign the catalog file
> signtool.exe sign /f "<path of .pfx file>" /p <password> /t
> http://timestamp.comodoca.com/authenticode /v "<cat file to be signed>"
>
> # Installed the certificate in local machine
> certmgr.exe /add "<path of the certificate created>" /s /r localMachine root
> certmgr.exe /add "<path of the certificate created>" /s /r localMachine
> trustedPublishers

As long as you have a pfx that matches your self-signed certificate, and
you install the cert in root and trustedPublishers, you should be OK for
validation of the driver package. Be mindful that this needs to be done
from an elevated command prompt.

The trick not to get the driver package prompt is to have the public key
of your self-signed credential in root and trustedPublishers, and to
sign the inf package with the matching private key.

> 3. I am successuly created cert file and now, not getting any warnings
> during installation with DPInst.

So far so good.

> My critical question here is, can i
> distribute or publish this signed certificate that i created ?? i.e Can
> i install my self signed certificate in my clients machine ( is it legal
> to distribute my signed certificate for commercial use).

Absolutely. Distribution of the *public* key, which is what is meant to
get installed in the client's security store through a certificate, is
no concern at all and has no legal implication whatsoever (even if you
export it to Iran or something). Many software developers, including
Microsoft of course, export public keys in one way or another, be it for
root certification authorities, and no special concern needs to be taken
to do so. And the same would be true for the private key as well, since
public and private key are usually symmetric, provided it wasn't a very
bad idea to distribute a private key.

Just make sure that you distribute a certificate (i.e. a container with
the public key only - typically a .cer on Windows) and not a credential
(container with both the private and public key - typically a .pfx), as
making your private key available would allow anyone to sign and get
malicious software installed that validates against your public key,
which is not what you want.

> Please condsider that there won't be any objection from my client side
> where i want to install the certificate.

As long as you ensure that your private key remains private and out of
reach from malicious users, installing your certificate on the client's
side shouldn't be a concern.

> 4.Seems that certmgr.exe is not distibutable and help me in providing
> the alternative tool or code to import the certificate?

Travis has developed a dpscat utility for libusbK that may be of help.
You can find it in the binary directory of the latest libusbK [3].

Regards,

/Pete

PS: Sorry for not answering your original e-mail on the libwdi mailing
list. I got confused about the message asking to disregard.

[1]
https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Signed_driver_walkthrough#Creating_a_signed_cat_file
[2] https://sourceforge.net/mailarchive/message.php?msg_id=27223654
[3] https://sourceforge.net/projects/libusbk/files/libusbK-beta/3.0.5.10/

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

sethuuraman
In reply to this post by Pete Batard-2
Dear Pete,

I haver also aised a question in MSDN forum and got a reply like, I should go through WHQL, do i want to?? Please find the below link for discussions:

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



Regards,
Sethu


On Mon, Apr 9, 2012 at 8:50 PM, Pete Batard <[hidden email]> wrote:

Hi,

On 2012.04.09 15:12, Sethuraman R wrote:
>         2.1. My inf is working fine and i am using only the windows
> default driver(USBSER.sys) in the inf. In this case, is it required to
> sign the default sys file? Or Is it already Signed? Or Is signing not
> required?

Binary drivers that come from the Windows OS are already signed, though,
unlike non Windows signed drivers, the signature may not be displayed
when right clicking. But unless you use your own custom version, you
should not have to sign this file.

>         2.2.I have understood that Signing the driver
> binaries(SYS,DLL,...) and Signing the driver package(inf) are completely
> different.

Indeed. One will prevent you from using the driver altogether, unless
running Windows in test mode, and the other determines whether users are
prompted with a warning during driver installation.

> Also, the signing warning(Windows can't verify the the
> publisher of the software) occurs only because of my unsigned inf and
> not because of the driver?

Yes.

>         2.3 To avoid the above said warning, by assuming USESER.SYS
> doesn't require any signing, i selfsigned or test signed my inf file in
> the following way as mentioned at
> http://www.itninja.com/question/guide-to-signing-unsigned-drivers.
>
> # creted .cat file using Inf2cat.exe
> Inf2Cat.exe /driver:"<Path of the inf>"

You may also want to have a look at the Signed Cat file part of the
libwdi signed driver walkthrough [1]. You may want to append a /os:
option there, depending on your target OSes.

> # created certificate using makecert.exe
> MakeCert.Exe -r -pe <path to .cer file you want to generate> -n
> CN=<certificate name> -sv <path to .pvk file you want to generate> -len
> 2048

You may also want to have a look at this post from libusb-win32, where I
did something similar [2].

>        2.4) As per the MS DDK Documentation, the test signing or Self
> Signing is done without PVK... Am i wrong in the last step?
>
> But here i created the PVK also?

In a PKI implementation, you always need a private key, so one always
exists. You can't create a self-signing certificate without a private key.

> # Create Software Publisher's Certificate (SPC) from our certificate
> Cert2Spc.Exe <path to .cer file> <path to .spc file>
>
> # Create a .pfx file
> pvk2pfx.exe -pvk <path of .pvk file created earlier> -pi <password> -spc
> "<path of .pfx to be stored>
>
> # Sign the catalog file
> signtool.exe sign /f "<path of .pfx file>" /p <password> /t
> http://timestamp.comodoca.com/authenticode /v "<cat file to be signed>"
>
> # Installed the certificate in local machine
> certmgr.exe /add "<path of the certificate created>" /s /r localMachine root
> certmgr.exe /add "<path of the certificate created>" /s /r localMachine
> trustedPublishers

As long as you have a pfx that matches your self-signed certificate, and
you install the cert in root and trustedPublishers, you should be OK for
validation of the driver package. Be mindful that this needs to be done
from an elevated command prompt.

The trick not to get the driver package prompt is to have the public key
of your self-signed credential in root and trustedPublishers, and to
sign the inf package with the matching private key.

> 3. I am successuly created cert file and now, not getting any warnings
> during installation with DPInst.

So far so good.

> My critical question here is, can i
> distribute or publish this signed certificate that i created ?? i.e Can
> i install my self signed certificate in my clients machine ( is it legal
> to distribute my signed certificate for commercial use).

Absolutely. Distribution of the *public* key, which is what is meant to
get installed in the client's security store through a certificate, is
no concern at all and has no legal implication whatsoever (even if you
export it to Iran or something). Many software developers, including
Microsoft of course, export public keys in one way or another, be it for
root certification authorities, and no special concern needs to be taken
to do so. And the same would be true for the private key as well, since
public and private key are usually symmetric, provided it wasn't a very
bad idea to distribute a private key.

Just make sure that you distribute a certificate (i.e. a container with
the public key only - typically a .cer on Windows) and not a credential
(container with both the private and public key - typically a .pfx), as
making your private key available would allow anyone to sign and get
malicious software installed that validates against your public key,
which is not what you want.

> Please condsider that there won't be any objection from my client side
> where i want to install the certificate.

As long as you ensure that your private key remains private and out of
reach from malicious users, installing your certificate on the client's
side shouldn't be a concern.

> 4.Seems that certmgr.exe is not distibutable and help me in providing
> the alternative tool or code to import the certificate?

Travis has developed a dpscat utility for libusbK that may be of help.
You can find it in the binary directory of the latest libusbK [3].

Regards,

/Pete

PS: Sorry for not answering your original e-mail on the libwdi mailing
list. I got confused about the message asking to disregard.

[1]
https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Signed_driver_walkthrough#Creating_a_signed_cat_file
[2] https://sourceforge.net/mailarchive/message.php?msg_id=27223654
[3] https://sourceforge.net/projects/libusbk/files/libusbK-beta/3.0.5.10/

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Xiaofan Chen
On Wed, Apr 11, 2012 at 5:56 PM, Sethuraman R <[hidden email]> wrote:
> Dear Pete,
>
> I haver also aised a question in MSDN forum and got a reply like, I should
> go through WHQL, do i want to?? Please find the below link for discussions:
>
> http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/28b936d8-22b5-40dd-b16c-8da5f4828bee
>

Going through WHQL is of course the best option if you can
spare the money. No warning at all.

2nd better option is to at least have a class 3 code signing
certificate and sign the driver package. There will still be
a warning about the publisher but much less intrusive.

On the other hand, if you have a controlled environment, then it is
okay to use your own cert. But it is still good to check with
your clients whether they are willing to go for the previous
two options. 2nd option is not expensive at all.


--
Xiaofan

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Xiaofan Chen
In reply to this post by sethuuraman
On Tue, Apr 10, 2012 at 12:27 AM, Sethuraman R <[hidden email]> wrote:
> Dear Pete & Xiaofan,
>
> Sometimes, words can't be really used to express what we really feel. This
> might be the very simple clarifications for others, but being a novice its
> so helpful to me in many ways.
>
> This is the reply that we have been waiting for....

BTW, please avoid posting to both libwdi and libusb-win32
mailing list. I believe most of the people here do not
subscribe to libwdi mailing list and will get problem posting
to libwdi mailing list. Thanks.

--
Xiaofan

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

sethuuraman
In reply to this post by Xiaofan Chen
Dear Xiaofan,

There is no problem from our cutomer end.
There is only one question Xiaofan, and hope this will be the final one, and my query is

As done in libwdi should i do the certificate signing process in end customers machine? or is it possible to do the signing process in my machine and just install the signed certificate in clients machine (DISTRIBUTION)??

Regards,
Sethu

On Wed, Apr 11, 2012 at 4:18 PM, Xiaofan Chen <[hidden email]> wrote:
On Wed, Apr 11, 2012 at 5:56 PM, Sethuraman R <[hidden email]> wrote:
> Dear Pete,
>
> I haver also aised a question in MSDN forum and got a reply like, I should
> go through WHQL, do i want to?? Please find the below link for discussions:
>
> http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/28b936d8-22b5-40dd-b16c-8da5f4828bee
>

Going through WHQL is of course the best option if you can
spare the money. No warning at all.

2nd better option is to at least have a class 3 code signing
certificate and sign the driver package. There will still be
a warning about the publisher but much less intrusive.

On the other hand, if you have a controlled environment, then it is
okay to use your own cert. But it is still good to check with
your clients whether they are willing to go for the previous
two options. 2nd option is not expensive at all.


--
Xiaofan

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Xiaofan Chen
On Wed, Apr 11, 2012 at 7:26 PM, Sethuraman R <[hidden email]> wrote:

> Dear Xiaofan,
>
> There is no problem from our cutomer end.
> There is only one question Xiaofan, and hope this will be the final one, and
> my query is
>
> As done in libwdi should i do the certificate signing process in end
> customers machine? or is it possible to do the signing process in my machine
> and just install the signed certificate in clients machine (DISTRIBUTION)??
>

Yes you can sign in your own machine and then distribute the
certificates to the client machines.


--
Xiaofan

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Xiaofan Chen
On Wed, Apr 11, 2012 at 9:20 PM, Xiaofan Chen <[hidden email]> wrote:

> On Wed, Apr 11, 2012 at 7:26 PM, Sethuraman R <[hidden email]> wrote:
>> Dear Xiaofan,
>>
>> There is no problem from our cutomer end.
>> There is only one question Xiaofan, and hope this will be the final one, and
>> my query is
>>
>> As done in libwdi should i do the certificate signing process in end
>> customers machine? or is it possible to do the signing process in my machine
>> and just install the signed certificate in clients machine (DISTRIBUTION)??
>
> Yes you can sign in your own machine and then distribute the
> certificates to the client machines.
>

Pete Batard explains in his libwdi page why he thinks that
installation of certificates into these stores, without asking the
end user is okay in the case of libwdi because of the way libwdi
works even though this may sound like questionable practice

http://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Faq#What_are_these_.22USB.5CVID_.23.23.23.23.26PID_.23.23.23.23.5B.26MI_.23.23.5D_.28Autogenerated.29.22_certificates_that_libwdi_installs_in_the_Trusted_certificate_stores.3F

(or  http://ow.ly/acSGz if the above does not work)

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

I think Pete has a point. On the other hand, I do not quite agree
with this approach myself.

Some may argue that generation of self-signed cert on the target
machine using the method of libwdi can be considered even
better than 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 most of the people in OSR will suggest you to buy
a cert from a well-known CA or go through WHQL if possible.

--
Xiaofan

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Pete Batard-2
On 2012.04.12 04:49, Xiaofan Chen wrote:
> Some may argue that generation of self-signed cert on the target
> machine using the method of libwdi can be considered even
> better than 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's not entirely true.

To summarize the problem, the issue here is security and ensuring that
the security on an end-user machine has not been reduced in any way
after the installation of a certificate.

The certificates installed for driver package validation are very high
privileges one, meaning that if a malicious user ever got hold of the
private key associated with such a certificate, they would then be in a
position to silently install malicious software by making it seen as
trusted. This is a very dangerous scenario, which, if you install
certificates on an end-user machine, you must consider as your main
security risk.

Therefore the problem boils down to making sure the private key is as
protected as can be, and can not be leaked.

Now, in that respect, it actually doesn't matter that much whether the
private key was issued by a well known CA or was created on your own,
because, while CAs are trusted to be secured enough not to let malicious
users access the private keys they generate on their servers, they still
need to provide you with the private key they generated in one form or
another, that you can use to sign items such as driver packages, which
will therefore exist on your machine and that you then need to protect.

Thus, whether the key was generated on your machine of from a CA doesn't
change the issue that you still end up with a private key that you need
to keep from unauthorized access.

The libwdi solution is to generate a one-time only private key, on the
end-user's machine, that is discarded it as soon as the driver package
and certificate have been installed (since only the public key is needed
for driver verification afterwards). With the private key destroyed, it
of course becomes impossible to get anything else but the original
driver package validated, and thus the end-user's machine security is
left unchanged. And even if a malicious hacker intercepted the API calls
and stored the private key (but they'd probably already need to have
compromised the machine, so the whole point would seem moot), they would
only be able to get software trusted on that specific machine and not
any other.

> That is why most of the people in OSR will suggest you to buy
> a cert from a well-known CA or go through WHQL if possible.

Going through WHQL is actually another solution to keeping the private
key private. In this case, because Microsoft does the actual drive
package signing, the private key is kept by Microsoft on their own
servers, so the whole problem of securing your private key from prying
eyes is taken away from you.

Regards,

/Pete

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Xiaofan Chen
On Thu, Apr 12, 2012 at 7:05 PM, Pete Batard <[hidden email]> wrote:

> On 2012.04.12 04:49, Xiaofan Chen wrote:
>> Some may argue that generation of self-signed cert on the target
>> machine using the method of libwdi can be considered even
>> better than 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's not entirely true.
>
> To summarize the problem, the issue here is security and ensuring that
> the security on an end-user machine has not been reduced in any way
> after the installation of a certificate.
>
> The certificates installed for driver package validation are very high
> privileges one, meaning that if a malicious user ever got hold of the
> private key associated with such a certificate, they would then be in a
> position to silently install malicious software by making it seen as
> trusted. This is a very dangerous scenario, which, if you install
> certificates on an end-user machine, you must consider as your main
> security risk.
>
> Therefore the problem boils down to making sure the private key is as
> protected as can be, and can not be leaked.

Yes that is one aspect. In any case, the private key is important.

You still forget the oher aspect, who the signer is. With a certificate
from a well-known CA, we have reasonable confidence that the
one who signs the codes are really the one.

Say Travis signed libusb0.sys with the GlobalSign certificate
and the cert will comes with his name on it. We will reasonably
know that the guy who sign libusb0.sys is really Travis.

> Now, in that respect, it actually doesn't matter that much whether the
> private key was issued by a well known CA or was created on your own,
> because, while CAs are trusted to be secured enough not to let malicious
> users access the private keys they generate on their servers, they still
> need to provide you with the private key they generated in one form or
> another, that you can use to sign items such as driver packages, which
> will therefore exist on your machine and that you then need to protect.
>
> Thus, whether the key was generated on your machine of from a CA doesn't
> change the issue that you still end up with a private key that you need
> to keep from unauthorized access.
>
> The libwdi solution is to generate a one-time only private key, on the
> end-user's machine, that is discarded it as soon as the driver package
> and certificate have been installed (since only the public key is needed
> for driver verification afterwards). With the private key destroyed, it
> of course becomes impossible to get anything else but the original
> driver package validated, and thus the end-user's machine security is
> left unchanged. And even if a malicious hacker intercepted the API calls
> and stored the private key (but they'd probably already need to have
> compromised the machine, so the whole point would seem moot), they would
> only be able to get software trusted on that specific machine and not
> any other.

libwdi's solution of course has it own merits. But the goal the
whole KMCS idea is to be able to identify the signer and the
certificate will expire in certain time and can be revoked
if the signer did something wrong.

libwdi's solution does not have such feature.

>> That is why most of the people in OSR will suggest you to buy
>> a cert from a well-known CA or go through WHQL if possible.
>
> Going through WHQL is actually another solution to keeping the private
> key private. In this case, because Microsoft does the actual drive
> package signing, the private key is kept by Microsoft on their own
> servers, so the whole problem of securing your private key from prying
> eyes is taken away from you.

Some actually argue that WHQL is the only way in most
cases (other than the controlled environment like a test
machine or a corporate IT network or an embedded system).

To me libwdi is good for those controlled environment to help
the developer to deploy solutions to those controlled environment
(since certmgr.exe is not redistributable). However, I still have
reservation myself on using libwdi to deploy the driver to
end users (without them knowing it). That being said, if
the developer/user knows what he is doing, then I do not have a real
problem either.


--
Xiaofan

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Pete Batard-2
On 2012.04.12 12:50, Xiaofan Chen wrote:
> You still forget the oher aspect, who the signer is.

Well, in the case of libwdi, the signer is the current user (or rather
the elevated current user, as the installation of the cert requires
elevation), as authenticated by Windows.

But agreed that the second part of PKI is trust, which includes
revocation. The assumption here is that the deployment of the
self-signed certificate would be done from a trusted party (eg. domain
admin) who would have checked the certificate.

But please read further, as I don't think revocation is invoked in any
way once the driver package is installed, which makes the whole point of
revocation on driver package installation rather moot.

> With a certificate
> from a well-known CA, we have reasonable confidence that the
> one who signs the codes are really the one.

Except this confidence is currently mostly based on money and little
else. What a CA will mostly tell you was that someone was rich enough to
afford buying a certificate from them and possibly that they once
resided at an address that could be verified. But they won't be able to
tell if the person is a malicious user or not any better than a domain
admin who received a self-signed certificate from a third party.

If anything, there's more chance than a Windows domain administrator
would provide a better validation of the self-signed cert they are going
to deploy, by inquiring on who the person who generated it is and
meeting them face to face.

> Say Travis signed libusb0.sys with the GlobalSign certificate
> and the cert will comes with his name on it. We will reasonably
> know that the guy who sign libusb0.sys is really Travis.

Or that it could be any person who registered as Travis Robinson, which
wouldn't be that difficult to fake, or someone who managed to steal
Travis' credential.
I'd be be very mindful of trusting a CA too much, when there are
countless examples of why the level of trust you can have in a CA will
only go as far...

> libwdi's solution of course has it own merits. But the goal the
> whole KMCS idea is to be able to identify the signer and the
> certificate will expire in certain time and can be revoked
> if the signer did something wrong.

Provided that the end-user machine is connected to the internet and that
the CA has been alerted that something was amiss, which usually occurs
some time after the damage is done.

Revocation is not a bulletproof vest. Stuxnet apparently did a lot of
damage before Realtek and Verisign realized that something was amiss
[1]. You may be able to reduce damage after that through revocation, but
by then the malicious developer would long have obtained what they
wanted and moved on (or used a different signing cert since you still
haven't revoked the driver executable). And in our case, revocation
checks are only done once, during the driver package installation, so
they hardly matter. If you deploy 10000 Verisign approved certificate
for a driver package one day, and Verisign revokes them the next, the
driver will still run just the same.

> libwdi's solution does not have such feature.

Because it doesn't need to. Also please don't confuse the signing of a
driver package, which equates a user clicking yet on the "Do you want to
install this driver?" and signing of the driver executable itself. One
could still produce an unsigned package and get users infected if it all
boils down to them clicking yes or no.

As far as I know, the revocation checks are only performed once, when
you install the driver package. After that the driver will still work no
driver the state of revocation of the certificate that signed the driver
package. It's only when you reinstall the driver package that it will
matter, which is expected to be an infrequent operation at best.

So revocation is actually irrelevant with regards to the merits of the
libwdi solution, even more so as the libwdi driver package certificate
relies on trusting only the actual user of a specific machine, rather
than a third party.

> However, I still have
> reservation myself on using libwdi to deploy the driver to
> end users (without them knowing it).

If you do, then I don't think you understand what libwdi does when it
installs a driver package, and why revocation shouldn't matter. The only
revocation that matters is the one from the driver executable itself,
which is already well catered for, through a completely different
certificate, and something that libwdi doesn't touch. If a driver is
deemed malicious and needs to be revoked, then the executable signing
certificate is the one that should be revoked, and as such, whether
installed through libwdi or not, the end result is exactly the same. If
you only revoke the driver package cert, as a malicious user, I can
easily obtain a new valid a cert from Verisign or someone else to
produce a new driver package (it's a simple software development cert -
very loose background checks), and continue the cycle, so you haven't
really mitigated anything.

Regards,

/Pete

[1]
http://threatpost.com/en_us/blogs/verisign-revokes-certificate-used-sign-stuxnet-malware-071710

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Xiaofan Chen
On Thu, Apr 12, 2012 at 8:42 PM, Pete Batard <[hidden email]> wrote:
> On 2012.04.12 12:50, Xiaofan Chen wrote:
>> However, I still have reservation myself on using libwdi to deploy
>> the driver to end users (without them knowing it).
>
> If you do, then I don't think you understand what libwdi does when it
> installs a driver package, and why revocation shouldn't matter.

Let's just say we are very different people when it comes to the
perception about the world and I respectfully disagree with your
points about CA and about the libwdi approach.

And in reality you can try to go to the OSR list and convince
the driver experts there that your approach in libwdi is better.
Yes there are people who agree with you, but there are many
who do not agree and say buying a class 3 code signing
from a CA is better (WHQL is even better but cost more
money and time).

Ref: http://www.osronline.com/showthread.cfm?link=223734
Ref: http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/28b936d8-22b5-40dd-b16c-8da5f4828bee
Ref: http://www.osronline.com/showthread.cfm?link=193826

--
Xiaofan

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

sethuuraman
Hi Pete,

       I have seen a response from Microsoft team for the queries posted and their suggestion to go for a test signing process as Libwdi performs. I also hope that your Libwdi implementation is based on his reply.

Ref:( search the keyword -" Wyse, Chris <chris.wyse@wi...> - 2011-01-13 13:42 "  at the below link)

http://sourceforge.net/mailarchive/message.php?msg_id=27019186

Can we consider the above said suggestion from MS team as a kind of approval to proceed with Self Signing?


On Thu, Apr 12, 2012 at 6:53 PM, Xiaofan Chen <[hidden email]> wrote:
On Thu, Apr 12, 2012 at 8:42 PM, Pete Batard <[hidden email]> wrote:
> On 2012.04.12 12:50, Xiaofan Chen wrote:
>> However, I still have reservation myself on using libwdi to deploy
>> the driver to end users (without them knowing it).
>
> If you do, then I don't think you understand what libwdi does when it
> installs a driver package, and why revocation shouldn't matter.

Let's just say we are very different people when it comes to the
perception about the world and I respectfully disagree with your
points about CA and about the libwdi approach.

And in reality you can try to go to the OSR list and convince
the driver experts there that your approach in libwdi is better.
Yes there are people who agree with you, but there are many
who do not agree and say buying a class 3 code signing
from a CA is better (WHQL is even better but cost more
money and time).

Ref: http://www.osronline.com/showthread.cfm?link=223734
Ref: http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/28b936d8-22b5-40dd-b16c-8da5f4828bee
Ref: http://www.osronline.com/showthread.cfm?link=193826

--
Xiaofan

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

sethuuraman
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.....

3. 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 http://www.osronline.com/cf.cfm?PageURL=showLists.cfm?list=ntdev ALSO.

On Thu, Apr 12, 2012 at 7:20 PM, Sethuraman R <[hidden email]> wrote:
Hi Pete,

       I have seen a response from Microsoft team for the queries posted and their suggestion to go for a test signing process as Libwdi performs. I also hope that your Libwdi implementation is based on his reply.

Ref:( search the keyword -" Wyse, Chris <chris.wyse@wi...> - 2011-01-13 13:42 "  at the below link)

http://sourceforge.net/mailarchive/message.php?msg_id=27019186

Can we consider the above said suggestion from MS team as a kind of approval to proceed with Self Signing?



On Thu, Apr 12, 2012 at 6:53 PM, Xiaofan Chen <[hidden email]> wrote:
On Thu, Apr 12, 2012 at 8:42 PM, Pete Batard <[hidden email]> wrote:
> On 2012.04.12 12:50, Xiaofan Chen wrote:
>> However, I still have reservation myself on using libwdi to deploy
>> the driver to end users (without them knowing it).
>
> If you do, then I don't think you understand what libwdi does when it
> installs a driver package, and why revocation shouldn't matter.

Let's just say we are very different people when it comes to the
perception about the world and I respectfully disagree with your
points about CA and about the libwdi approach.

And in reality you can try to go to the OSR list and convince
the driver experts there that your approach in libwdi is better.
Yes there are people who agree with you, but there are many
who do not agree and say buying a class 3 code signing
from a CA is better (WHQL is even better but cost more
money and time).

Ref: http://www.osronline.com/showthread.cfm?link=223734
Ref: http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/28b936d8-22b5-40dd-b16c-8da5f4828bee
Ref: http://www.osronline.com/showthread.cfm?link=193826

--
Xiaofan

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel



------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Pete Batard-2
In reply to this post by sethuuraman
On 2012.04.12 14:50, Sethuraman R wrote:
> Hi Pete,
>
>         I have seen a response from Microsoft team for the queries
> posted and their suggestion to go for a test signing process as Libwdi
> performs. I also hope that your Libwdi implementation is based on his reply.

The thread was mostly about licensing (and how Microsoft continues to be
very unfriendly to some FLOSS licenses). The libwdi implementation,
while using some of the info highlighted here and elsewhere, is mostly
about the issue of having to sign driver packages that are generated on
the fly, which is a different matter from yours. But libwdi also offers
the option to install user provided certificate, for pre-built driver
packages [1].

In the case of pre-built packages and user provided drivers, the libwdi
implementation makes no distinction between self-signed and CA
certificates, so the choice is up to the user.

Regards,

/Pete

[1]
https://sourceforge.net/apps/mediawiki/libwdi/index.php?title=Usage#struct_wdi_options_install_cert


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Pete Batard-2
In reply to this post by Xiaofan Chen
On 2012.04.12 14:23, Xiaofan Chen wrote:

> On Thu, Apr 12, 2012 at 8:42 PM, Pete Batard<[hidden email]>  wrote:
>> On 2012.04.12 12:50, Xiaofan Chen wrote:
>>> However, I still have reservation myself on using libwdi to deploy
>>> the driver to end users (without them knowing it).
>>
>> If you do, then I don't think you understand what libwdi does when it
>> installs a driver package, and why revocation shouldn't matter.
>
> Let's just say we are very different people when it comes to the
> perception about the world and I respectfully disagree with your
> points about CA and about the libwdi approach.

And yet, if I'm not mistaken, you use it for libusb-win32 and libusbk
driver package installation...

Granted the problem could be seen as different (we need to create driver
packages on the fly), but if you don't see the libwdi approach as
trustworthy, then you may want to follow through and disable the feature
in the libusb-win32 and libusbK installers, by letting users decide for
themselves whether they want to trust a driver package or not. I make
the option very easy to toggle in the wdi_prepare_driver() options.

Or can something that is OK for driver packages generated on the fly not
apply for pre-built ones?

> And in reality you can try to go to the OSR list and convince
> the driver experts there that your approach in libwdi is better.

Maybe I'll do that, knowing that the only issue to be considered is the
trustworthiness of a driver package that is generated and signed by a
100% open source application, which, in the case of the Zadig installer,
is also digitally signed by (hopefully) a trustworthy CA.

Yeah, if I wanted to, I could introduce malicious code there, just like,
if I wanted to, I could get a valid CA certificate to do produce a
malicious driver package. And in either case, the expectation is that
eventually someone will spot that something is amiss with the same end
result (the Zadig app certificate is revoked or the driver package cert
is revoked). In all likelihood, since checking the behaviour of a FLOSS
app and the driver package it produces is a lot easier than just
checking the behaviour of a driver package, you're probably better off
with libwdi, because that's the only choice where you actually have the
ability to validate the entire chain of trust rather than rely on blind
trust in a CA. And when it comes to blind trust, you may want to
remember that CAs aren't exactly immune to being hacked, especially as
they are of course a most valuable target [1]. The article says that
GlobalSign may have been broken into as well, so there's an actual
possibility that someone could have produced a signed yet malicious
libusb0.sys driver that looks as trustworthy as the existing one...

In other words, and as I stated previously, CA certificates are far from
being an entirely bulletproof solution.

> Yes there are people who agree with you, but there are many
> who do not agree and say buying a class 3 code signing
> from a CA is better (WHQL is even better but cost more
> money and time).

Don't mix the advantages of WHQL for testing of a driver with trust in a
driver package. It's obviously better to go through WHQL because then
you go through a rigorous process of getting your driver tested. And
that's really what you are paying for here.

As to the trust process, I already answered above.

And yeah, I saw the older posts when I introduced the libwdi feature,
since they're the ones that gave me the idea that there could exist an
equally secure alternate way. In these threads, you can't exactly count
the advice of people having a vested interest in WHQL, such as Doron
Holan, as being totally impartial. As to his advice of "find(ing)
somebody who has a legitimate certificate who'll sign your driver
(package)", it should really send shivers down the spine of anybody who
has security in mind.

I'm sure Doron implied someone trustworthy, and also that one should
follow up any signing process done through a third party with checks
that the content wasn't altered, but casually advising people to go find
a random person who will sign data in your stead kind of breaks the
whole point of thetrust process. At best, you end up with someone who
didn't actually create the data and who may have no idea about its
content, indicating that the data is trustworthy. Ouch!

Regards,

/Pete


[1]
http://arstechnica.com/security/news/2011/09/comodo-hacker-i-hacked-diginotar-too-other-cas-breached.ars

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Driver package signing

Pete Batard-2
In reply to this post by sethuuraman
On 2012.04.12 15:44, Sethuraman R wrote:
>    It clearly indicates that the control is with the end user and no
> other security factors are concerned at all from

This is the part I agree with as well. Unlike what is the case for the
driver executable themselves, Microsoft does leave the choice of
trusting a driver package to the user, which can be seen as a transitive
property that has already been answered when the same user decided to
grant elevation to an application that requested the privilege in order
to install self-signed certificates (especially if that application is
signed itself).

Regards,

/Pete

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Libusb-win32-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
12
Loading...