Global Sign certificate and Vista x64

We have just bought a Global Sign certificate for signing kernel driver for
Vista x64. Unfortunately the signed PnP driver doesn’t load in Vista x64
using the same signing process that instead works with a VeriSign
certificate (obviously using the correct cross cert).

Comparing the properties of the certificates I can see some differences :

VeriSign (working) has:

  • Key Usage: Digital Signature (80)
  • Enhanced Key Usage: Code Signing (1.3.6.1.5.5.7.3.3)

GlobalSign (not working) has:

  • Key Usage: Digital Signature, Non Repudiation, Key Enciphermment, Data
    Enciphermment (F0)
  • Enhanced Key Usage:

    Can someone confirm that the GlobalSign certificates are valid for kernel
    driver signing for Vista x64 ?
    If yes, are the certificate properties above correct ?

    The strange thing is that the command “signtool verify /kp /v” (from WDK
    6000) verifies correctly the signed driver, but the PnP driver always fails
    to load with the error 39.

    Any idea ?

    Thanks

    ----
    Verifying: eusk3usb-uns.cat
    SHA1 hash of file: 5748775984EB4544BF978236BF1F3CD3B8E431C1
    Signing Certificate Chain:
    Issued to: Microsoft Code Verification Root
    Issued by: Microsoft Code Verification Root
    Expires: 01/11/2025 14.54.03
    SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

    Issued to: GlobalSign Root CA
    Issued by: Microsoft Code Verification Root
    Expires: 23/05/2016 18.10.51
    SHA1 hash: 3EEB2750A199F5E7B6A8952430BE5062FE04E9E5

    Issued to: GlobalSign Primary Object Publishing CA
    Issued by: GlobalSign Root CA
    Expires: 27/01/2014 12.00.00
    SHA1 hash: 987FD000DCB121517D72453EE5176EB92B1363B9

    Issued to: GlobalSign ObjectSign CA
    Issued by: GlobalSign Primary Object Publishing CA
    Expires: 27/01/2014 11.00.00
    SHA1 hash: 4A19146D67BD20843A3A0713587557BF519213CC

    Issued to: Eutronsec S.p.A.
    Issued by: GlobalSign ObjectSign CA
    Expires: 26/02/2008 9.17.21
    SHA1 hash: CD3C208E3EDCAE27411437DF153363DA74427D69

    The signature is timestamped: 28/02/2007 14.23.08
    Timestamp Verified by:
    Issued to: Thawte Timestamping CA
    Issued by: Thawte Timestamping CA
    Expires: 01/01/2021 0.59.59
    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

    Issued to: VeriSign Time Stamping Services CA
    Issued by: Thawte Timestamping CA
    Expires: 04/12/2013 0.59.59
    SHA1 hash: F46AC0C6EFBB8C6A14F55F09E2D37DF4C0DE012D

    Issued to: VeriSign Time Stamping Services Signer
    Issued by: VeriSign Time Stamping Services CA
    Expires: 04/12/2008 0.59.59
    SHA1 hash: 817E78267300CB0FE5D631357851DB366123A690

    Successfully verified: eusk3usb-uns.cat

    Number of files successfully Verified: 1
    Number of warnings: 0
    Number of errors: 0

    -----------------------------------------------------------------------------------

    Confidentiality Clause: This message is for the designated recipient(s)
    only and may be privileged.
    If you are not the intended addressee you must not disclose, diffuse, copy
    this communication. If you have received this in error, please notify the
    sender and delete the message as soon as possible.
    Whilst we maintain virus checks, we accept no liability for viruses
    introduced from this e-mail.

They are the only ones I found with a website which makes mention of it.
http://www.globalsign.com/digital_certificate/objectsign/index.cfm

The problem is I have not been able from anyone from this company to respond
in any way to my questions. It looks like Verisign is the only way to go but
I don’t know what my chances are as a European ISV to get a certificate off
them. I must admit I have not been able to talk with any of the other
companies issuing certificates either which has raised my conspiracy
awareness flag.

Trying to get a certificate has been nothing short of a copulating inferno
so far. I think I’ll just tell my users to boot with Driver signing
enforcement disabled. If now only the rest of the world would follow…

/Daniel

wrote in message news:xxxxx@ntdev…
> Can someone confirm that the GlobalSign certificates are valid for kernel
> driver signing for Vista x64 ?
> If yes, are the certificate properties above correct ?

We have a GlobalSign ObjectSign certificate. “Code Signing” is
explicitly mentioned in the purpose list of this certificate.

Did you use the CertMgr tool from the WDK to check the certificate?

I noticed that with CertMgr you can edit the “Enhanced Key Usage” list.
Default seems to have everything enabled, but please check!

Can someone confirm that the GlobalSign certificates are valid for kernel
driver signing for Vista x64 ?

  • I can confirm that the GlobalSign certificate is valid for signing a
    CAT file for installation of a Kernel-Mode Driver on Vista64.

  • I can confirm the certificate chain looks the same like yours.
    (Even if it is not strictly necessary, I have all driver binaries
    signed. No extra cost and everyone can check the SYS files.)

  • Sorry, I cannot confirm that Vista64 would load the signed driver
    during boot. (Our driver is a standard USB PnP-Driver.)

If yes, are the certificate properties above correct ?

As far as I can see, yes - given that you can edit the “Enhanced Key
Usage” flags.

Another thing happened today: for whatever reason this morning my
ceritificate was missing from my PCs certificate store.
Very Weird! Any idea, anyone?
(No, I did NOT export-delete it or something. The only thing I can
remember I did is give permission to a Windows Update.
…hmm, better keep that PFX around…)

> They are the only ones I found with a website which makes mention of it.

http://www.globalsign.com/digital_certificate/objectsign/index.cfm

That’s where I ordered ours.

The problem is I have not been able from anyone from this company to respond
in any way to my questions. It looks like Verisign is the only way to go but

You don’t talk to GlobalSign but to your local “Registration Authority”.

Trying to get a certificate has been nothing short of a copulating inferno
so far. I think I’ll just tell my users to boot with Driver signing
enforcement disabled. If now only the rest of the world would follow…

Calm down. I can understand how you feel - first the problem of finding
what certificate actually to use, then lots of steps to follow to comply
to the MS certification routine, then signing itself needs
trial-and-error, then I had to convert the certificate into a CER file
so that signtool would actually use it, then I found out that it still
does not use it until I import it into “My” system certification store,
and use a CER file for the cross-certificate (it does not want to take
that from the system store, beats me why)… lots of fun.

And then you have to explain to your colleagues, why “Device Manager”
still displays “Driver not signed.” (Because your driver does not have
a WHQL signature.) Uff!

But once the signing batch works, it works.

The actual getting of a certificate was relatively easy for me - I
discovered that GlobalSIgn has a “Registration Authority” very close to
our company HQ.
So I could just talk to them on the phone, that helped and made
everything afterwards pretty quick and painless.

Of course these people can_not help you with actual USE of your
certificate, but Microsoft has a lot of documentation about the signing
process on the WHDC site.

-H

> Of course these people can_not help you with actual USE of your

certificate, but Microsoft has a lot of documentation about the signing
process on the WHDC site.

That’s exactly the problem. They have loads of misleading rubbish on their
website about kernel mode driver signing. They have loads of different
cra.py signing tools scattered across DDKs, SDKs and microsoft.com. Kernel
mode signature verification behaves differently on every version of Windows
since Win2000. Obviously, people at Microsoft just do not know what they are
doing when it comes to driver digital signatures. The only thing that stands
is WHQL/Verisign monopoly.

“Hagen Patzke” wrote in message news:xxxxx@ntdev…
>> They are the only ones I found with a website which makes mention of it.
>> http://www.globalsign.com/digital_certificate/objectsign/index.cfm
>
> That’s where I ordered ours.
>
>> The problem is I have not been able from anyone from this company to
>> respond in any way to my questions. It looks like Verisign is the only
>> way to go but
>
> You don’t talk to GlobalSign but to your local “Registration Authority”.
>
>> Trying to get a certificate has been nothing short of a copulating
>> inferno so far. I think I’ll just tell my users to boot with Driver
>> signing enforcement disabled. If now only the rest of the world would
>> follow…
>
> Calm down. I can understand how you feel - first the problem of finding
> what certificate actually to use, then lots of steps to follow to comply
> to the MS certification routine, then signing itself needs
> trial-and-error, then I had to convert the certificate into a CER file so
> that signtool would actually use it, then I found out that it still does
> not use it until I import it into “My” system certification store, and use
> a CER file for the cross-certificate (it does not want to take that from
> the system store, beats me why)… lots of fun.
>
> And then you have to explain to your colleagues, why “Device Manager”
> still displays “Driver not signed.” (Because your driver does not have a
> WHQL signature.) Uff!
>
>
> But once the signing batch works, it works.
>
>
> The actual getting of a certificate was relatively easy for me - I
> discovered that GlobalSIgn has a “Registration Authority” very close to
> our company HQ.
> So I could just talk to them on the phone, that helped and made everything
> afterwards pretty quick and painless.
>
> Of course these people can_not help you with actual USE of your
> certificate, but Microsoft has a lot of documentation about the signing
> process on the WHDC site.
>
> -H
>

cristalink wrote:

That’s exactly the problem. They have loads of misleading rubbish on their
website about kernel mode driver signing. They have loads of different
cra.py signing tools scattered across DDKs, SDKs and microsoft.com. Kernel
mode signature verification behaves differently on every version of Windows
since Win2000.

Well, true, Signability.exe is buggy, makecat is not really usable
(because you don’t get all the information Signability or Inf2cat add)
and in gerneral the amount of tools is confusing.

And I still do not understand why SignTool only works for me when I
added our cert to a System Store but the cross-certificate only works
when taken from an external file. More twiddling to be done…sigh…

Obviously, people at Microsoft just do not know what they are
doing when it comes to driver digital signatures.

Some certainly do, but I’m missing a complete tool strategy that
supports developers with understandable, easy-to-use tools to make
certification storage, handling and use easier.

The only thing that stands is WHQL/Verisign monopoly.

As far as I have experienced they opened up to other CAs.
With my GlobalSign cert I was able at least to sign the WDM kernel
driver CAT properly.
On W2003Server I even get “valid Authenticode signature”. Whoo-hoo!

Well, if I was part in a Logo program and got the certificate from
Microsoft directly (or a countersigned one from them), I would not care
if it is from Verisign or someone else.

Or are there other restrictions I am overlooking here?

>> Obviously, people at Microsoft just do not know what they are doing when

> it comes to driver digital signatures.

Some certainly do, but I’m missing a complete tool strategy that supports
developers with understandable, easy-to-use tools to make certification
storage, handling and use easier.

Some probably do, but for us developers/users this does not matter. Those
who make decisions certainly don’t. Have a look at
http://www.microsoft.com/whdc/winlogo/drvsign/drvsign_perOS.mspx. How
possibly could one with adequate knowledge come up with such a mess?

> The only thing that stands is WHQL/Verisign monopoly.

As far as I have experienced they opened up to other CAs.
With my GlobalSign cert I was able at least to sign the WDM kernel driver
CAT properly.
On W2003Server I even get “valid Authenticode signature”. Whoo-hoo!

Well, if I was part in a Logo program and got the certificate from
Microsoft directly (or a countersigned one from them), I would not care if
it is from Verisign or someone else.

Or are there other restrictions I am overlooking here?

I might have overlooked something, but to open an account with WHQL you can
use a Verisign certificate only. So what’s the point in getting a
certificate from another provider when you already pay Verisign a half a
grand a year?

Authenticode seems completely useless for anything but drivers using a
custom setup class. According to
http://download.microsoft.com/download/3/4/f/34fa7f0d-92d6-4265-80b2-1541789699a9/Authenticode.doc,
Authenticode is only for the drivers not qualifying for Windows Logo.
Anyway, a customer needs to install your Authenticode certificates to the
trusted store first.

----drvsign_perOS.mspx:
<Authorities certificate store, the user is asked whether they want to trust
the publisher. Otherwise, the user is warned that the driver is unsigned and
not trustworthy>>.

---- Authenticode.doc
<vendors to sign driver packages in the trusted publisher certificates
store>>

It would be great if somebody could explain what the above means, and how it
could possibly make any sense.

Why would the publisher’s certificate go to “Trusted Root Certification
Authorities certificate store”?!

If the publisher’s certificate is already in “trusted publisher certificates
store” then why would Microsoft want to ask the customer again whether the
latter trusts the publisher?

When a customer downloads my user mode
software, they can see the package is signed by my company. They don’t need
to pre-install my certificates. Why are those stupid rules for drivers then?



“Hagen Patzke” wrote in message news:xxxxx@ntdev…
> cristalink wrote:
>> That’s exactly the problem. They have loads of misleading rubbish on
>> their website about kernel mode driver signing. They have loads of
>> different cra.py signing tools scattered across DDKs, SDKs and
>> microsoft.com. Kernel mode signature verification behaves differently on
>> every version of Windows since Win2000.
>
> Well, true, Signability.exe is buggy, makecat is not really usable
> (because you don’t get all the information Signability or Inf2cat add) and
> in gerneral the amount of tools is confusing.
>
> And I still do not understand why SignTool only works for me when I added
> our cert to a System Store but the cross-certificate only works when taken
> from an external file. More twiddling to be done…sigh…
>
>> Obviously, people at Microsoft just do not know what they are doing when
>> it comes to driver digital signatures.
>
> Some certainly do, but I’m missing a complete tool strategy that supports
> developers with understandable, easy-to-use tools to make certification
> storage, handling and use easier.
>
> > The only thing that stands is WHQL/Verisign monopoly.
>
> As far as I have experienced they opened up to other CAs.
> With my GlobalSign cert I was able at least to sign the WDM kernel driver
> CAT properly.
> On W2003Server I even get “valid Authenticode signature”. Whoo-hoo!
>
> Well, if I was part in a Logo program and got the certificate from
> Microsoft directly (or a countersigned one from them), I would not care if
> it is from Verisign or someone else.
>
> Or are there other restrictions I am overlooking here?
>

> ----drvsign_perOS.mspx:

<> Authorities certificate store, the user is asked whether they want to trust
> the publisher. Otherwise, the user is warned that the driver is unsigned and
> not trustworthy>>.
>
> ---- Authenticode.doc
> <> vendors to sign driver packages in the trusted publisher certificates
> store>>
>
> It would be great if somebody could explain what the above means, and how it
> could possibly make any sense.

Surprisingly, I can. It helps to have been an admin for some time… :slight_smile:

> Why would the publisher’s certificate go to “Trusted Root Certification
> Authorities certificate store”?!

Administrators can install drivers, may they be signed or not.

Users without administrator rights might need to install something too
- think of PnP USB drivers.

(E.g. you need to install the driver for every USB connector you have on
your system. It usually happens “automagically”, but nevertheless the
driver needs to be installed.)

If an Administrator places the publisher’s certificate in the trusted
store, an “ordinary” user can install the driver.

Why the “Trusted Root Certification Authorities certificate store”?

To be trusted, a certificate needs to be in a “trusted certification
path” (= have a valid signature from a trusted authority “above”, and
also this authority up the chain until a “trusted root certificate” is
found).

So it makes sense to install a “trusted certificate” in the “trusted
root certificate store” if you don’t know anything about the path.

> If the publisher’s certificate is already in “trusted publisher certificates
> store” then why would Microsoft want to ask the customer again whether the
> latter trusts the publisher?

If it is not WHQL signed (and thus implicitly trusted) they give the
customer with standard user rights a chance to deny installation of a
driver.

The wording might not be splendid, but I actually appreciate having the
choice.

> When a customer downloads my user mode
> software, they can see the package is signed by my company. They don’t need
> to pre-install my certificates. Why are those stupid rules for drivers then?

(a) You need only to pre-install the certificates if you want to give a
user without admin rights the option to install a (PnP-)driver for a
device. (If they have admin rights, of course nothing has to be done.)

(b) User mode software cannot crash the machine (at least not so
easily, according to Microsoft). It usually just terminates itself if it
does something wrong. Kernel software (and most drivers are) CAN crash
the machine. Very easily.

(c) A corrupt (read: malicious) driver can easily intercept and forge
everything that is security-relevant on your system. So it is not only
about system stability, but also about security.
User mode software running under non-administrator rights can not
access and/or damage critical system/security relevant files, registry
entries, etc.

And big organisations actually do give only user rights to their
employees. :slight_smile:

Is it a bit clearer now?

“Hagen Patzke” wrote in message news:xxxxx@ntdev…
> Why the “Trusted Root Certification Authorities certificate store”?
>
> To be trusted, a certificate needs to be in a “trusted certification path”
> (= have a valid signature from a trusted authority “above”, and also this
> authority up the chain until a “trusted root certificate” is found).
>
> So it makes sense to install a “trusted certificate” in the “trusted root
> certificate store” if you don’t know anything about the path.

Hagen, do not mix the “Trusted Root Certification Authorities” and “Trusted
Publishers” stores.

http://www.microsoft.com/whdc/winlogo/drvsign/drvsign_perOS.mspx suggests
placing the publisher’s certificate into TRCA: <certificate is in the Trusted Root Certification Authorities certificate
store, the user is asked whether they want to trust the publisher.
Otherwise, the user is warned that the driver is unsigned and not
trustworthy>>

The Trusted Root Certification Authorities (TRCA) certificate store, by
definition, should contain only TRUSTED Certification Authorities’
certificates. The publisher’s certificate should not be placed into TRCA as
http://www.microsoft.com/whdc/winlogo/drvsign/drvsign_perOS.mspx suggests.
It’s just a plain documentation bug in the best case. See
http://msdn2.microsoft.com/en-us/library/aa906279.aspx for info about TRCA.

> So it makes sense to install a “trusted certificate” in the “trusted root
> certificate store” if you don’t know anything about the path.
>

This statement is truly amazing. Why would anyone in their right mind
install a certificate from an unknown source into TRCA? This would
essentially legitimate all certificates issued by that unknown source.

>> If the publisher’s certificate is already in “trusted publisher
>> certificates
>> store” then why would Microsoft want to ask the customer again whether
>> the
>> latter trusts the publisher?
>
> If it is not WHQL signed (and thus implicitly trusted) they give the
> customer with standard user rights a chance to deny installation of a
> driver.
>

I am a customer and I sometimes install drivers on my machine. I don’t
understand why company M[icrosoft] marks all software originated from
whoever but signed by some WHQL, whatever that acronym means, trustworthy by
default without my consent. At the same time the same company M marks all
software from all other companies not trustworthy, unless that software is
signed by some WHQL and Verisign and nothing else. This is a rethorical
question. Don’t bother to answer.

> The wording might not be splendid, but I actually appreciate having the
> choice.

EXACTLY. I would appreciate having the choice, too. I want all software
signed my Microsoft to produce by default the same warning prompts as the
software signed by any other non-Microsoft company, so that I could make my
choice.

> (b) User mode software cannot crash the machine (at least not so easily,
> according to Microsoft). It usually just terminates itself if it does
> something wrong. Kernel software (and most drivers are) CAN crash the
> machine. Very easily.

Really? Are you saying that one cannot easily write a piece of user mode
software which, once started with administrative rights, cannot screw up the
machine completely?!

So the question remains: How are drivers principally different from user
mode software running under an admin account, so that the drivers need to
be signed by Microsoft+Verisign, but the user mode software can be signed by
anyone+any trusted CA?

> User mode software running under non-administrator rights can not access
> and/or damage critical system/security relevant files, registry entries,
> etc.

That’s smart. Good point. Where did I say otherwise?

>
> Is it a bit clearer now?

Sorry, no.

Thanks!

“Hagen Patzke” wrote in message news:xxxxx@ntdev…
>> ----drvsign_perOS.mspx:
>> <>> Authorities certificate store, the user is asked whether they want to
>> trust
>> the publisher. Otherwise, the user is warned that the driver is unsigned
>> and
>> not trustworthy>>.
>>
>> ---- Authenticode.doc
>> <>> by
>> vendors to sign driver packages in the trusted publisher certificates
>> store>>
>>
>> It would be great if somebody could explain what the above means, and how
>> it
>> could possibly make any sense.
>
> Surprisingly, I can. It helps to have been an admin for some time… :slight_smile:
>
>> Why would the publisher’s certificate go to “Trusted Root Certification
>> Authorities certificate store”?!
>
> Administrators can install drivers, may they be signed or not.
>
> Users without administrator rights might need to install something too -
> think of PnP USB drivers.
>
> (E.g. you need to install the driver for every USB connector you have on
> your system. It usually happens “automagically”, but nevertheless the
> driver needs to be installed.)
>
> If an Administrator places the publisher’s certificate in the trusted
> store, an “ordinary” user can install the driver.
>
>
> Why the “Trusted Root Certification Authorities certificate store”?
>
> To be trusted, a certificate needs to be in a “trusted certification path”
> (= have a valid signature from a trusted authority “above”, and also this
> authority up the chain until a “trusted root certificate” is found).
>
> So it makes sense to install a “trusted certificate” in the “trusted root
> certificate store” if you don’t know anything about the path.
>
>
>> If the publisher’s certificate is already in “trusted publisher
>> certificates
>> store” then why would Microsoft want to ask the customer again whether
>> the
>> latter trusts the publisher?
>
> If it is not WHQL signed (and thus implicitly trusted) they give the
> customer with standard user rights a chance to deny installation of a
> driver.
>
> The wording might not be splendid, but I actually appreciate having the
> choice.
>
>
>> When a customer downloads my user mode
>> software, they can see the package is signed by my company. They don’t
>> need
>> to pre-install my certificates. Why are those stupid rules for drivers
>> then?
>
> (a) You need only to pre-install the certificates if you want to give a
> user without admin rights the option to install a (PnP-)driver for a
> device. (If they have admin rights, of course nothing has to be done.)
>
> (b) User mode software cannot crash the machine (at least not so easily,
> according to Microsoft). It usually just terminates itself if it does
> something wrong. Kernel software (and most drivers are) CAN crash the
> machine. Very easily.
>
> (c) A corrupt (read: malicious) driver can easily intercept and forge
> everything that is security-relevant on your system. So it is not only
> about system stability, but also about security.
> User mode software running under non-administrator rights can not access
> and/or damage critical system/security relevant files, registry entries,
> etc.
>
>
> And big organisations actually do give only user rights to their
> employees. :slight_smile:
>
>
> Is it a bit clearer now?
>

cristalink wrote:

The Trusted Root Certification Authorities (TRCA) certificate store, by
definition, should contain only TRUSTED Certification Authorities’
certificates.

Absolutely my opinion.
I just stated what I glanced from the documentation and the system
behaviour - call it the “observerd MS intent”.

The publisher’s certificate should not be placed into TRCA as
http://www.microsoft.com/whdc/winlogo/drvsign/drvsign_perOS.mspx suggests.

If you have a signed driver that you want your (non-admin) users to be
able to install, is it enough to have it in the Trusted Publisher CS?
It should be, of course. But does it work?

This statement is truly amazing. Why would anyone in their right mind
install a certificate from an unknown source into TRCA? This would
essentially legitimate all certificates issued by that unknown source.

Of course it could open a gaping security hole. But if I remember
correctly, it is the only chance to get a more-or-less silent install.
(This seems in line with the former MS policy of “Make it work.”
Security came second. And convenience is what users actually want.)

On the other hand - if you trust a company to provide a signed driver
for the core of your system, they can be assumed to be trusted to also
provide e.g. applications. Or even certificates.

I am a customer and I sometimes install drivers on my machine. I don’t
understand why company M[icrosoft] marks all software originated from
whoever but signed by some WHQL, whatever that acronym means, trustworthy by
default without my consent.

(Rhetorical / mocking / funny question:)
Hmmm… beats me… do they possibly get any money for it?
Or is a WHQL signature free? :wink:

On the other hand - you already trust M[company] to provide an operating
system that you entrust vital (e.g. business) information to be handled
correctly by.

What proof have you got that your (e.g. confidential) information is
kept confidential? And not sent by the OS to the XXX, YYY or ZZZ
government authority?

Then you can also trust them to decide - after some reasonable testing -
to sign a driver from a third party company and thus give you a “silent”
installation archive.

I want all software
signed my Microsoft to produce by default the same warning prompts as the
software signed by any other non-Microsoft company, so that I could make my
choice.

Not possible. Example: happily installing on a fresh system (aka IPL):

“New device MOUSE detected. … MOUSE driver is signed by M[company].
Do you trust this company? [OK] [CANCEL]”

…which then fails because you don’t have a mouse driver for the mouse
you use to klick onto the [OK] button. Nor a keyboard driver… :wink:

Really? Are you saying that one cannot easily write a piece of user mode
software which, once started with administrative rights, cannot screw up the
machine completely?!

If you start something as Administrator, of course you can.

If you pull the trigger of a loaded and armed weapon, of course you can
shoot yourself in the foot.

(If the OS is buggy, you can also do this without Admin rights. :slight_smile: )

So the question remains: How are drivers principally different from user
mode software running under an admin account, so that the drivers need to
be signed by Microsoft+Verisign, but the user mode software can be signed by
anyone+any trusted CA?

As far as I understand M[company], user mode software is supposed to
ususally run in user mode (surprise!), without ADMIN or SYSTEM rights.

Be careful with spreading this reasonable argument.
Otherwise it might be that in the next M[company] OS release “Admin”
accounts can only start WHQL signed software packages.

With DRM enforcement I see this actually coming in the not too far future.

Thanks for the nice conversation. -H

> If you have a signed driver that you want your (non-admin) users to be

able to install, is it enough to have it in the Trusted Publisher CS?

No, I don’t care about non-admin users not being able to install drivers,
and never did. I was always referring to admins.

Of course it could open a gaping security hole. But if I remember
correctly, it is the only chance to get a more-or-less silent install.

At what cost? It is absolutely unacceptable for me to ask my customers to
mess with certificates. I’d rather tolerate the “unsigned” warning.

Besides, it is relatively easy to install an unsigned driver silently
anyway, without interfering with signature checking. Don’t ask me how, I
won’t tell.

(This seems in line with the former MS policy of “Make it work.”
Security came second. And convenience is what users actually want.)

Unfortunately, this is too far from being convenient. What’s easier - click
Continue Anyway or install a certificate?

On the other hand - if you trust a company to provide a signed driver for
the core of your system, they can be assumed to be trusted to also provide
e.g. applications. Or even certificates.

Not at all. For example, Microsoft is a big company. Different projects are
done by different people. People also tend to change with time. If I
installed an application from a company, it does not mean I trust them in
any way. Most likely, I simply did not have a choice. For the last years, I
prefer to install apps on virtual machines. This gives me some sense of
security with the inherently unsecure OS.

Another trouble is, I might trust Microsoft when it comes to THEIR OWN
software. But I definitely do not trust company X the software of which is
signed by Microsoft and installs silently. Essentially, Microsoft endorses
third party software it has little knowledge of, and allows silent install
of such software. IMHO, it’s a major breach of security.

(Rhetorical / mocking / funny question:)
Hmmm… beats me… do they possibly get any money for it?
Or is a WHQL signature free? :wink:

No, it is not. Both Microsoft and Verisign are getting money. But I have to
admit Microsoft is better. They take less money for more. Verisign takes
much more for nothing, just because they have a monopoly agreement with
Microsoft.

On the other hand - you already trust M[company] to provide an operating
system that you entrust vital (e.g. business) information to be handled
correctly by.

I don’t trust them. But I have no other choice.

What proof have you got that your (e.g. confidential) information is kept
confidential? And not sent by the OS to the XXX, YYY or ZZZ government
authority?

Then you can also trust them to decide - after some reasonable testing -
to sign a driver from a third party company and thus give you a “silent”
installation archive.

I would like to minimize the risks. If I have a dubious inherely unsecure OS
installed, it does mean it won’t be any worse if I additionally install
loads of other rubbish.

> I want all software signed my Microsoft to produce by default the same
> warning prompts as the software signed by any other non-Microsoft
> company, so that I could make my choice.

Not possible. Example: happily installing on a fresh system (aka IPL):

See above. There’s

  1. Software from Microsoft signed by Microsoft which comes with the
    operating system. If I agreed to install OS, I don’t need any futher
    warnings.
  2. Software from third parties signed by Microsoft which comes with OS. OK,
    I agree that that rubbish can be installed silenly, even though I won’t use
    99.999% of it.
  3. Software from Microsoft signed by Microsoft, which comes separately from
    OS, like Windows Updates etc. Currently, I have to agree to the terms before
    installing it - that’s OK.
  4. Software (drivers) from third parties signed by Microsoft, which comes
    separately from OS. Under no circumstances it should be able to install
    silently. According to Microsoft, currently this software can be silently
    installed.

As far as I understand M[company], user mode software is supposed to
ususally run in user mode (surprise!), without ADMIN or SYSTEM rights.

You are missing my point. There is user mode software running with admin
privileges and there are drivers. Both types of the software can easily
screw up the machine. Then why are there two different signature policies?
Let’s put it simple. I am a driver developer. And I care about my customers.
I want them to be secure. I want to sign my software and I do so whenever
possible. But for some reason I feel like avoiding and or actively resisting
the driver signing policy being pushed by Microsoft, for as long as I can
and for as long as it’s commercially viable.

Be careful with spreading this reasonable argument.
Otherwise it might be that in the next M[company] OS release “Admin”
accounts can only start WHQL signed software packages.

This will definitely happen if everyone keeps happy silence. I have a small
hope that somebody from Microsoft will read this, and another hope (though
even smaller one) that because of this the things will eventually get
better.

Cheers

“Hagen Patzke” wrote in message news:xxxxx@ntdev…
> cristalink wrote:
>
>> The Trusted Root Certification Authorities (TRCA) certificate store, by
>> definition, should contain only TRUSTED Certification Authorities’
>> certificates.
>
> Absolutely my opinion.
> I just stated what I glanced from the documentation and the system
> behaviour - call it the “observerd MS intent”.
>
>
>> The publisher’s certificate should not be placed into TRCA as
>> http://www.microsoft.com/whdc/winlogo/drvsign/drvsign_perOS.mspx
>> suggests.
>
> If you have a signed driver that you want your (non-admin) users to be
> able to install, is it enough to have it in the Trusted Publisher CS?
> It should be, of course. But does it work?
>
>
>> This statement is truly amazing. Why would anyone in their right mind
>> install a certificate from an unknown source into TRCA? This would
>> essentially legitimate all certificates issued by that unknown source.
>
> Of course it could open a gaping security hole. But if I remember
> correctly, it is the only chance to get a more-or-less silent install.
> (This seems in line with the former MS policy of “Make it work.”
> Security came second. And convenience is what users actually want.)
>
> On the other hand - if you trust a company to provide a signed driver for
> the core of your system, they can be assumed to be trusted to also provide
> e.g. applications. Or even certificates.
>
>
>> I am a customer and I sometimes install drivers on my machine. I don’t
>> understand why company M[icrosoft] marks all software originated from
>> whoever but signed by some WHQL, whatever that acronym means, trustworthy
>> by default without my consent.
>
> (Rhetorical / mocking / funny question:)
> Hmmm… beats me… do they possibly get any money for it?
> Or is a WHQL signature free? :wink:
>
>
> On the other hand - you already trust M[company] to provide an operating
> system that you entrust vital (e.g. business) information to be handled
> correctly by.
>
> What proof have you got that your (e.g. confidential) information is kept
> confidential? And not sent by the OS to the XXX, YYY or ZZZ government
> authority?
>
> Then you can also trust them to decide - after some reasonable testing -
> to sign a driver from a third party company and thus give you a “silent”
> installation archive.
>
>
>> I want all software signed my Microsoft to produce by default the same
>> warning prompts as the software signed by any other non-Microsoft
>> company, so that I could make my choice.
>
> Not possible. Example: happily installing on a fresh system (aka IPL):
>
> “New device MOUSE detected. … MOUSE driver is signed by M[company].
> Do you trust this company? [OK] [CANCEL]”
>
> …which then fails because you don’t have a mouse driver for the mouse
> you use to klick onto the [OK] button. Nor a keyboard driver… :wink:
>
>
>> Really? Are you saying that one cannot easily write a piece of user mode
>> software which, once started with administrative rights, cannot screw up
>> the machine completely?!
>
> If you start something as Administrator, of course you can.
>
> If you pull the trigger of a loaded and armed weapon, of course you can
> shoot yourself in the foot.
>
>
> (If the OS is buggy, you can also do this without Admin rights. :slight_smile: )
>
>
>> So the question remains: How are drivers principally different from user
>> mode software running under an admin account, so that the drivers need
>> to be signed by Microsoft+Verisign, but the user mode software can be
>> signed by anyone+any trusted CA?
>
> As far as I understand M[company], user mode software is supposed to
> ususally run in user mode (surprise!), without ADMIN or SYSTEM rights.
>
>
> Be careful with spreading this reasonable argument.
> Otherwise it might be that in the next M[company] OS release “Admin”
> accounts can only start WHQL signed software packages.
>
> With DRM enforcement I see this actually coming in the not too far future.
>
>
>
> Thanks for the nice conversation. -H
>