headers
Sethuraman R | 9 Apr 2012 16:12
Picon

Driver package signing

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
Libusb-win32-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Permalink | Reply |
headers
Xiaofan Chen | 9 Apr 2012 17:06
Picon

Re: Driver package signing

On Mon, Apr 9, 2012 at 10:12 PM, Sethuraman R <sethuuraman <at> gmail.com> 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
Permalink | Reply |
headers
Xiaofan Chen | 9 Apr 2012 17:08
Picon

Re: Driver package signing

On Mon, Apr 9, 2012 at 11:06 PM, Xiaofan Chen <xiaofanc <at> gmail.com> 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
Permalink | Reply |
headers
Pete Batard | 9 Apr 2012 17:20
Picon
Gravatar

Re: Driver package signing

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
Permalink | Reply |
headers
Sethuraman R | 9 Apr 2012 18:27
Picon

Re: Driver package signing

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 <pete <at> akeo.ie> 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
Libusb-win32-devel <at> lists.sourceforge.net
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
Libusb-win32-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Permalink | Reply |
headers
Xiaofan Chen | 11 Apr 2012 12:53
Picon

Re: Driver package signing

On Tue, Apr 10, 2012 at 12:27 AM, Sethuraman R <sethuuraman <at> gmail.com> 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
Permalink | Reply |
headers
Sethuraman R | 11 Apr 2012 11:56
Picon

Re: Driver package signing

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 <pete <at> akeo.ie> 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
Libusb-win32-devel <at> lists.sourceforge.net
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
Libusb-win32-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Permalink | Reply |
headers
Xiaofan Chen | 11 Apr 2012 12:48
Picon

Re: Driver package signing

On Wed, Apr 11, 2012 at 5:56 PM, Sethuraman R <sethuuraman <at> gmail.com> 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
Permalink | Reply |
headers
Sethuraman R | 11 Apr 2012 13:26
Picon

Re: Driver package signing

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 <xiaofanc <at> gmail.com> wrote:
On Wed, Apr 11, 2012 at 5:56 PM, Sethuraman R <sethuuraman <at> gmail.com> 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
Libusb-win32-devel <at> lists.sourceforge.net
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
Libusb-win32-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Permalink | Reply |
headers
Xiaofan Chen | 11 Apr 2012 15:20
Picon

Re: Driver package signing

On Wed, Apr 11, 2012 at 7:26 PM, Sethuraman R <sethuuraman <at> gmail.com> 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
Permalink | Reply |
headers
Xiaofan Chen | 12 Apr 2012 05:49
Picon

Re: Driver package signing

On Wed, Apr 11, 2012 at 9:20 PM, Xiaofan Chen <xiaofanc <at> gmail.com> wrote:
> On Wed, Apr 11, 2012 at 7:26 PM, Sethuraman R <sethuuraman <at> gmail.com> 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
Permalink | Reply |
headers
Pete Batard | 12 Apr 2012 13:05
Picon
Gravatar

Re: Driver package signing

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
Permalink | Reply |
headers
Xiaofan Chen | 12 Apr 2012 13:50
Picon

Re: Driver package signing

On Thu, Apr 12, 2012 at 7:05 PM, Pete Batard <pete <at> akeo.ie> 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
Permalink | Reply |
headers
Pete Batard | 12 Apr 2012 14:42
Picon
Gravatar

Re: Driver package signing

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
Permalink | Reply |
headers
Xiaofan Chen | 12 Apr 2012 15:23
Picon

Re: Driver package signing

On Thu, Apr 12, 2012 at 8:42 PM, Pete Batard <pete <at> akeo.ie> 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
Permalink | Reply |
headers
Sethuraman R | 12 Apr 2012 15:50
Picon

Re: Driver package signing

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 <at> 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 <xiaofanc <at> gmail.com> wrote:
On Thu, Apr 12, 2012 at 8:42 PM, Pete Batard <pete <at> akeo.ie> 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
Libusb-win32-devel <at> lists.sourceforge.net
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
Libusb-win32-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Permalink | Reply |
headers
Sethuraman R | 12 Apr 2012 16:44
Picon

Re: Driver package signing

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 <sethuuraman <at> gmail.com> 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 <at> 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 <xiaofanc <at> gmail.com> wrote:
On Thu, Apr 12, 2012 at 8:42 PM, Pete Batard <pete <at> akeo.ie> 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
Libusb-win32-devel <at> lists.sourceforge.net
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
Libusb-win32-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel
Permalink | Reply |
headers
Pete Batard | 12 Apr 2012 17:59
Picon
Gravatar

Re: Driver package signing

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
Permalink | Reply |
headers
Xiaofan Chen | 13 Apr 2012 01:55
Picon

Re: Driver package signing

On Thu, Apr 12, 2012 at 11:59 PM, Pete Batard <pete <at> akeo.ie> wrote:
> 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).

We all agree with this one.

To the OP, if you considered your client  environment
a controlled one (corporate IT) and I do not see a problem
of deploying self-signed driver package. You can either use
a CA cert or using a toy cert or using libwdi's approach of
generating the cert on the fly on such controlled environment
(or a testing machine).

--

-- 
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
Permalink | Reply |
headers
Xiaofan Chen | 13 Apr 2012 01:56
Picon

Re: Driver package signing

Since I am the admin, I will close this thread. No more
post to this thread.

--

-- 
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
Permalink | Reply |
headers
Pete Batard | 12 Apr 2012 17:47
Picon
Gravatar

Re: Driver package signing

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
Permalink | Reply |
headers
Pete Batard | 12 Apr 2012 17:55
Picon
Gravatar

Re: Driver package signing

On 2012.04.12 14:23, Xiaofan Chen wrote:
> On Thu, Apr 12, 2012 at 8:42 PM, Pete Batard<pete <at> akeo.ie>  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
Permalink | Reply |
headers
Xiaofan Chen | 13 Apr 2012 01:38
Picon

Re: Driver package signing

On Thu, Apr 12, 2012 at 11:55 PM, Pete Batard <pete <at> akeo.ie> wrote:
> On 2012.04.12 14:23, Xiaofan Chen wrote:
>> On Thu, Apr 12, 2012 at 8:42 PM, Pete Batard<pete <at> akeo.ie>  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...
>

libusb-win32 driver installer does not have this feature built-in
(automatic install the certificates). So does libusbk driver
installer by default.

And libusbk driver installer actually
uses limit feature of libwdi since it uses dpinst as the
real driver installer. It does offer the driver package an
option to use dpscat using similar features of libwdi since
libwdi's approach is good in a controlled environment
and it has its own merits. So there are places which
this feature is good to have.

--

-- 
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
Permalink | Reply |
headers
Xiaofan Chen | 13 Apr 2012 01:53
Picon

Re: Driver package signing

On Thu, Apr 12, 2012 at 11:55 PM, Pete Batard <pete <at> akeo.ie> wrote:
> On 2012.04.12 14:23, Xiaofan Chen wrote:
>> On Thu, Apr 12, 2012 at 8:42 PM, Pete Batard<pete <at> akeo.ie>  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.
>
> 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.

That is the whole problem. And not only you could do that, someone
know how to use libwdi can do that as well.

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

I believe the chances of someone creating a libwdi based driver
installer with malicious code is actually higher. With the libwdi
apporach, the end user may not know if the driver packages
are hacked or not and if hacked do not know who generates
the hacked package...

With a CA cert, there is a reasonable confidence that the
signer is indeed the signer.

And to be very blunt, if you ask people out there, do they trust a
guy named Pete Batard more or GlobalSign more?

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

This one agree.

All in all, 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.

You can have further discussions in the OSR list. Please do not
post to this libusb-win32 thread any more and I think people
are bored of this kind of ideology discussion.

--

-- 
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
Permalink | Reply |
headers
Pete Batard | 13 Apr 2012 12:32
Picon
Gravatar

Re: Driver package signing

On 2012.04.13 00:53, Xiaofan Chen wrote:
> On Thu, Apr 12, 2012 at 11:55 PM, Pete Batard<pete <at> akeo.ie>  wrote:
>> On 2012.04.12 14:23, Xiaofan Chen wrote:
>>> On Thu, Apr 12, 2012 at 8:42 PM, Pete Batard<pete <at> akeo.ie>    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.
>>
>> 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.
>
> That is the whole problem. And not only you could do that, someone
> know how to use libwdi can do that as well.

Yeah, just like anyone who the end-user lets run an application in 
elevated mode can do that.

Let me repeat that for you, because I don't think you understand the 
concept of trust:
- As soon as you run an application as elevated, it's game over, 
regardless of whether the application installs a certificate or not. It 
doesn't matter whether someone knows how to use libwdi or not: if the 
user trusted them to run as elevated and the app is malicious, then the 
user is screwed. And the only way a libwdi app can install certs is if 
it runs elevated.
- This is why you are supposed to establish trust before you run an app 
that runs elevated, and this is why the official libwdi apps just don't 
go around asking the user: "Self-signed by Pete Batard - trust me!" but 
instead "Signed with a developer certificate issued by a *known* CA to 
Pete Batard, who did verify that the person is who they say they are and 
will revoke trust if required".
- Thus, when an official libwdi application installs certificate, you 
have already a chain of trust that is as good as the one you'd install 
with a driver package signed using an certificate from GlobalSign or 
another CA (GlobalSign themselves don't "sign" things - see below). That 
is unless you want to consider that because it is less well known CA, 
Certum is not as trustworthy as Verisign or GlobalSign, which is ridiculous.

> I believe the chances of someone creating a libwdi based driver
> installer with malicious code is actually higher.

Not at all, for the simple LOGICAL reason that to use libwdi to do 
something malicious in that respect you must get the user to run your 
app as elevated. You can't install certs otherwise. And if the user did 
that, there's really no point bothering with certs - you're already 
running code that you devised (since, because of the trust chain from 
official libwdi apps, it obviously was not signed by the original libwdi 
developer) and that run elevated. Why then would you bother installing a 
certificate, that sees its private key discarded, to run more elevated code?

You're basically saying that someone would break into a bank vault to 
change the lock, so that they can access the vault later on. Apart from 
Hollywood, such a scenario makes no sense: if your goal is trusted 
elevated access, which would be the one you seek from installing 
malicious certs, and you plan to somehow reuse libwdi for that, then by 
the time you get the self-signed cert installed, you're already elevated 
so it's already game over.

> With the libwdi
> apporach, the end user may not know if the driver packages
> are hacked or not and if hacked do not know who generates
> the hacked package...

If they have been hacked, then the hack came from a non-official 
malicious libwdi app that run in elevated mode. If that's the case, the 
hacking of a driver package is really the least of your problems...

> With a CA cert, there is a reasonable confidence that the
> signer is indeed the signer.

And with an official libwdi app, there is EQUAL reasonable confidence 
that the certificates installed are not malicious, because the app was 
signed using a certificate issued by a CA cert.

> And to be very blunt, if you ask people out there, do they trust a
> guy named Pete Batard more or GlobalSign more?

Well, let me be blunt then: This statement clearly shows a complete lack 
of understanding of how trust works.

First of all, Globalsign only issue *individual* certificates, so when 
you sign an app or a driver package, you don't get "Signed by 
GlobalSign", but instead "Signed by X, who was vetted by GlobalSign when 
the certificate was issued"... exactly the same as what you get when you 
run an official libwdi application such as Zadig, and for pretty much 
the same purpose: confirm that data (driver package or app) that was 
created by person X was not tampered further down the line.

So your question *actually* is: "Do they trust a guy named Pete Batard, 
vetted by GlobalSign or some other guy vetted by GlobalSign?"

You have to realize that GlobalSign are not behind you when you sign 
anything, so it's not because something bears the stamp of a certificate 
issued by a known CA (which is also the case of Zadig), that it's more 
trustworthy than another.

Therefore I can only assume that you still don't understand what libwdi 
does when it comes to certificate installation, and you somehow are 
under the assumption that it installs self-signed certificates that bear 
the name of a single individual or something.

Maybe a diagram will help. To make it even more explicit, I will pretend 
that the developer signing certificate I got is from GlobalSign instead 
of Certum, since it doesn't matter one bit.

Official libwdi chain of trust:

Zadig
   |
   + <----- "Trusted" by GlobalSign (dev cert issued by GlobalSign)
   |
  \/
Zadig (in elevated mode): installation of one-time only self signed 
certificates, with a private key that cannot be reused
  |
  |
  \/
certificate in the Windows cert store
  /\
  |
  |
driver package installation, signed with the one-time private key above

Driver package signed by GlobalSign chain of trust:

root certificate from GlobalSign in the Windows cert store
  /\
  |
  + <------ "Trusted by GlobalSign
  |
developer cert issued by GlobalSign
  /\
  |
  |
driver package installation, signed with the end user private key 
matching the end user cert issued by GlobalSign.

In both case, you end up with the same level of trust, because it's no 
more difficult to obtain a cert from GlobalSign to create a malicious 
libwdi app than to obtain one to create a malicious driver package.

The whole concept of a trust chain is based on the prospect that trust 
is a transitive property. As such, what an official (signed) libwdi app 
does with regards to driver package installation is no less trustworthy 
than using a driver package that was signed using a certificate that was 
issued by GlobalSign. And in either case, you end up with a GlobalSign 
issued certificate at the end of your chain of trust.

> All in all, 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.

Except those are not points. Those are facts, which you refuse to 
acknowledge as such, and very damagingly so.

> You can have further discussions in the OSR list. Please do not
> post to this libusb-win32 thread any more and I think people
> are bored of this kind of ideology discussion.

Feel free to delete this post all you want and consider the thread 
closed. It doesn't change facts that your considerations about the 
security risks are erroneous and that you are spewing damaging nonsense.

If you still see as an ideological matter, then please spend some more 
time analysing the whole security concept of the official Zadig app, and 
the way it installs certificates. I've done what I could to try to bring 
you up to speed with that, but there's only so much I can do if you have 
already *decided* that libwdi could not be anything else but less 
trustworthy than your preferred choice.

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
Permalink | Reply |
headers
Xiaofan Chen | 13 Apr 2012 14:13
Picon

Re: Driver package signing

On Fri, Apr 13, 2012 at 6:32 PM, Pete Batard <pete <at> akeo.ie> wrote:
> On 2012.04.13 00:53, Xiaofan Chen wrote:
>> You can have further discussions in the OSR list. Please do not
>> post to this libusb-win32 thread any more and I think people
>> are bored of this kind of ideology discussion.
>
> Feel free to delete this post all you want and consider the thread
> closed. It doesn't change facts that your considerations about the
> security risks are erroneous and that you are spewing damaging nonsense.
>

I think it is fare to give you the right to express your opinion
one last time. But it is too long and I have better things to
do. In any case, no need to convince me since I am not
a security expert and you are not either. You can go to
OSR list and convince the experts there.

Now the thread is really closed.

--

-- 
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
Permalink | Reply |
headers
Xiaofan Chen | 14 Apr 2012 04:52
Picon

Re: Driver package signing

On Fri, Apr 13, 2012 at 8:13 PM, Xiaofan Chen <xiaofanc <at> gmail.com> wrote:
> In any case, no need to convince me since I am not
> a security expert and you are not either. You can go to
> OSR list and convince the experts there.
>

For those who are not bored about the discussion, you
can follow here.
http://www.osronline.com/showthread.cfm?link=223734

--

-- 
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
Permalink | Reply |

Gmane