Greetings all,
We have a boot start driver that loads as a volume filter. I read the
signing relatredMSDN posts, it appears that we need to embed the signature
inside the PE itself (though KernelMustard says that it is not mandatory and
the kernel can parse the cat files, it is just slower).
Any how, here is the sequence of steps I follow:
- sign the PE using signtool
- generate cat files for the package using inf2cat
- sign the cat files with the same cert using signtool again.
- I also deploy the cert to the machine where I want to test, ad add it to
both ‘Personal’ and ‘Trusted Root Certification Authorities’ stores.
- I install the driver, and there is no warning popup about it being
untrusted.
When I try rebooting the machine to see if it really boots up, I find it
doesnt. I goes to recovery options which probably means a boot start driver
failed.
For this exercise I use the TestCertForWDK which comes with the WDK
installation. I have exported it as a PFX and install it on the other
machines.
Disabling driver signature enforcement makes the machine boot up.
So what could be the problem, I have verified that after signtool embeds the
cert inteh PE the size increases.
–
/testsigning on
You have to use bcdedit it turn on testsigning. Check the help for the
exact syntax.
Mark Roddy
On Fri, Mar 12, 2010 at 10:11 AM, amitr0 wrote:
> Greetings all,
>
> We have a boot start driver that loads as a volume filter. I read the
> signing relatredMSDN posts, it appears that we need to embed the signature
> inside the PE itself (though KernelMustard says that it is not mandatory and
> the kernel can parse the cat files, it is just slower).
>
> Any how, here is the sequence of steps I follow:
> 1. sign the PE using signtool
> 2. generate cat files for the package using inf2cat
> 3. sign the cat files with the same cert using signtool again.
> 4. I also deploy the cert to the machine where I want to test, ad add it to
> both ‘Personal’ and ‘Trusted Root Certification Authorities’ stores.
> 5. I install the driver, and there is no warning popup about it being
> untrusted.
>
> When I try rebooting the machine to see if it really boots up, I find it
> doesnt. I goes to recovery options which probably means a boot start driver
> failed.
>
> For this exercise I use the TestCertForWDK which comes with the WDK
> installation. I have exported it as a PFX and install it on the other
> machines.
>
> Disabling driver signature enforcement makes the machine boot up.
>
> So what could be the problem, I have verified that after signtool embeds
> the cert inteh PE the size increases.
>
> –
>
> - amitr0
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>5. I install the driver, and there is no warning popup about it being untrusted.
You may not see any warning messages. You should verify if your driver installed by looking
\Windows\System32\driver for your driver image and also Windows Register settings in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{71A27CDD-812A-11D0-BEC7-08002BE2092F}. It is always a good idea to look for setupapi log files which could tell you exact problem if you have one during installation.
Igor Sharovar
mark,
yes i knew abt test signing ‘on’. that works, my bad, i should have
mentioned it before. my aologies.
but i do not understand why a cert beiing installed as root will still
not work. what is special about the other certs which are used for
actual signing?
more importantly, if i understand this correctly, it is *not*
mandatory to embed the sha1 hash in the pe right? simply having a cat
file signed properly should also work, albeit slow?
if i really have to sign the actual pe, then what is the procedure to
whql? do we need to tell msft specially to resign the pe and
regenerate the cat files and sign them? or is the onus of getting the
pe signed by a competant authority the responsibility of the vendor?
igor,
i did check all of what u mentioned before posting, every thing was
proper. thanks for the tip though, it is easy to forget some of the
steps.
regards,
ab
On 3/12/10, xxxxx@hotmail.com wrote:
>>5. I install the driver, and there is no warning popup about it being
>> untrusted.
> You may not see any warning messages. You should verify if your driver
> installed by looking
> \Windows\System32\driver for your driver image and also Windows Register
> settings in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services and
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{71A27CDD-812A-11D0-BEC7-08002BE2092F}.
> It is always a good idea to look for setupapi log files which could tell you
> exact problem if you have one during installation.
>
> Igor Sharovar
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
amitr0 wrote:
but i do not understand why a cert beiing installed as root will still
not work. what is special about the other certs which are used for
actual signing?
The Win64 KMCS certificate checking (which is what we are talking about
here) is somewhat streamlined, since it’s in a critical path. The
certificate chain in the .cat or .sys must end with the Microsoft code
signing authority. That’s why you have to use a cross-certificate for KMCS.
more importantly, if i understand this correctly, it is *not*
mandatory to embed the sha1 hash in the pe right?
Well, you don’t embed the hash, you embed the whole certificate. The
whole certificate chain, in fact, since it has to include a
cross-certificate.
simply having a cat
file signed properly should also work, albeit slow?
That is my understanding, from the reading.
if i really have to sign the actual pe, then what is the procedure to
whql? do we need to tell msft specially to resign the pe and
regenerate the cat files and sign them? or is the onus of getting the
pe signed by a competant authority the responsibility of the vendor?
WHQL signs the .cat file. Your KMCS PE certificate will still be
there. The .cat signature will allow the package to be installed
without the “unsigned driver” warning. Your PE signature will allow the
driver to be loaded in Win64.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
tim,
thanks so much for clarifying. to summerize this thread (for self and
others benifit)…
- looks like we can have a boot start driver *without* the pe having
the embedded cert. the kernel will still fetch it from the cat albeit
slower.
- this kind of certification is different from normal whql, and the
cert chain must end with an msft cert.
- so we either have to get some trusted auyhority to sign the pe for
us or we have to buy the cert and do it ourselves.
- after which whql process will start, msft in whql, doesnt touch the
pe, they simply sign the cat files for the pe.
hope all of these are correct. and will benifit other similar info
seekers in the future.
regards
ab.
On 3/13/10, Tim Roberts wrote:
> amitr0 wrote:
>> but i do not understand why a cert beiing installed as root will still
>> not work. what is special about the other certs which are used for
>> actual signing?
>>
>
> The Win64 KMCS certificate checking (which is what we are talking about
> here) is somewhat streamlined, since it’s in a critical path. The
> certificate chain in the .cat or .sys must end with the Microsoft code
> signing authority. That’s why you have to use a cross-certificate for KMCS.
>
>> more importantly, if i understand this correctly, it is not
>> mandatory to embed the sha1 hash in the pe right?
>
> Well, you don’t embed the hash, you embed the whole certificate. The
> whole certificate chain, in fact, since it has to include a
> cross-certificate.
>
>> simply having a cat
>> file signed properly should also work, albeit slow?
>>
>
> That is my understanding, from the reading.
>
>> if i really have to sign the actual pe, then what is the procedure to
>> whql? do we need to tell msft specially to resign the pe and
>> regenerate the cat files and sign them? or is the onus of getting the
>> pe signed by a competant authority the responsibility of the vendor?
>>
>
> WHQL signs the .cat file. Your KMCS PE certificate will still be
> there. The .cat signature will allow the package to be installed
> without the “unsigned driver” warning. Your PE signature will allow the
> driver to be loaded in Win64.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
amitr0 wrote:
- this kind of certification is different from normal whql, and the
cert chain must end with an msft cert.
Yes. KMCS signing can only be done with a Class 3 Code Signing
Certificate from the very short list of certificate authorities for
which Microsoft has provided a cross-signing cert. This includes
Verisign, GlobalSign, GeoTrust, and one or two others. You can’t just
use any old certificate.
- so we either have to get some trusted auyhority to sign the pe for
us or we have to buy the cert and do it ourselves.
I’m not aware of any third parties doing driver signing.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>1. sign the PE using signtool
Cross-sign with MS’s cert. Also note that there is a limited choice for cert authorities for these signatures.
Also note that “set testsigning on” is a must if you want to test-sign the .SYS this way.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> 1. looks like we can have a boot start driver *without* the pe having
> the embedded cert. the kernel will still fetch it from the cat albeit
> slower.
No. A boot start driver must have an embedded signature that includes
the Microsoft cross-certificate. The loader doesn’t have access to the
catalog database, so it can’t verify the signature using the CAT file.
John McNamee wrote:
> 1. looks like we can have a boot start driver *without* the pe having
> the embedded cert. the kernel will still fetch it from the cat albeit
> slower.
No. A boot start driver must have an embedded signature that includes
the Microsoft cross-certificate. The loader doesn’t have access to
the catalog database, so it can’t verify the signature using the CAT
file.
I don’t think this is correct. Do you have a reference for that, or
direct experience that reinforces it? The Microsoft KMCS documentation
certainly says “boot-start drivers must be embedded signed”, but that is
always followed by a note saying that doing so speeds up the boot
process. The implication to me is that a catalog-signed boot-start
driver will work, but is a very bad idea because of the performance hit.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
You may very well be right about cat signed drivers, what I am missing is
why embedded signatures are a problem.
Mark Roddy
On Mon, Mar 15, 2010 at 12:50 PM, Tim Roberts wrote:
> John McNamee wrote:
> > > 1. looks like we can have a boot start driver without the pe having
> > > the embedded cert. the kernel will still fetch it from the cat albeit
> > > slower.
> >
> > No. A boot start driver must have an embedded signature that includes
> > the Microsoft cross-certificate. The loader doesn’t have access to
> > the catalog database, so it can’t verify the signature using the CAT
> > file.
>
> I don’t think this is correct. Do you have a reference for that, or
> direct experience that reinforces it? The Microsoft KMCS documentation
> certainly says “boot-start drivers must be embedded signed”, but that is
> always followed by a note saying that doing so speeds up the boot
> process. The implication to me is that a catalog-signed boot-start
> driver will work, but is a very bad idea because of the performance hit.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
It is my personal experience that boot start drivers require an embedded
Authenticode signature.
My experience is consistent with the WDK documentation:
| * A kernel-mode boot-start driver must have an embedded Software Publisher
| Certificate (SPC) signature. This applies to any type of PnP or non-PnP
| kernel-mode boot-start driver.
| * A non-PnP kernel-mode driver that is not a boot-start driver must have
| either a catalog file with an SPC signature or the driver file must
| include an embedded SPC signature.
| * A PnP kernel-mode driver that is not a boot-start driver must have either
| an embedded SPC signature, a catalog file with a WHQL release signature,
| or a catalog file with an SPC signature.
-------- Original Message --------
Subject: Re: [ntdev] Signing Boot start Drivers
From: Tim Roberts
Date: 3/15/2010 11:50 AM
> John McNamee wrote:
>> > 1. looks like we can have a boot start driver without the pe having
>> > the embedded cert. the kernel will still fetch it from the cat albeit
>> > slower.
>>
>> No. A boot start driver must have an embedded signature that includes
>> the Microsoft cross-certificate. The loader doesn’t have access to
>> the catalog database, so it can’t verify the signature using the CAT
>> file.
>
> I don’t think this is correct. Do you have a reference for that, or
> direct experience that reinforces it? The Microsoft KMCS documentation
> certainly says “boot-start drivers must be embedded signed”, but that is
> always followed by a note saying that doing so speeds up the boot
> process. The implication to me is that a catalog-signed boot-start
> driver will work, but is a very bad idea because of the performance hit.