Attested signing not required when using inbox driver?

We have an INF that references usbser.sys and nothing else. I was surprised to find that by simply signing its CAT file in the traditional manner that it loaded fine on Windows 10 with Secure Boot enabled, no attested signing or WHQL required. Is this documented/expected behavior?

gabe.jones@ni.com xxxxx@lists.osr.com wrote:

We have an INF that references usbser.sys and nothing else. I was surprised to find that by simply signing its CAT file in the traditional manner that it loaded fine on Windows 10 with Secure Boot enabled, no attested signing or WHQL required. Is this documented/expected behavior?

It depends. The strict signing requirement only applies to new
installations. If you have upgraded from the original Windows 10
release, then the attestation requirement does not apply.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> It depends. The strict signing requirement only applies to new installations. If you have upgraded

from the original Windows 10 release, then the attestation requirement does not apply.

Yeah, this setup should enforce all the rules: It is Anniversary Update, installed completely clean, Secure Boot enabled. “Normal” driver packages (with a .cat, .inf, and .sys) require Microsoft’s signature on this system, but packages containing only a .cat and .inf do not.

In the original posting I used the term “inbox driver” because my current example is using usbser.sys, but it could be any INF referencing a driver not installed by that INF. We have a package that installs a third-party driver, and we have other INFs that reference that driver. If we generate a CAT for one of those INFs and sign it internally, it installs without a hitch, no Microsoft signature needed.

gabe.jones@ni.com xxxxx@lists.osr.com wrote:

Yeah, this setup should enforce all the rules: It is Anniversary Update, installed completely clean, Secure Boot enabled. “Normal” driver packages (with a .cat, .inf, and .sys) require Microsoft’s signature on this system, but packages containing only a .cat and .inf do not.

In the original posting I used the term “inbox driver” because my current example is using usbser.sys, but it could be any INF referencing a driver not installed by that INF. We have a package that installs a third-party driver, and we have other INFs that reference that driver. If we generate a CAT for one of those INFs and sign it internally, it installs without a hitch, no Microsoft signature needed.

Is this a PnP package? If you’re doing a [DefaultInstall] installation,
then it’s not PnP and the CAT file is irrelevant

Assuming it’s PnP, all I can say is that it’s not supposed to work that
way. As I understand it, on a machine with the “extreme vetting”, with
a PnP package, it checks the CAT file at install time, and it checks the
SYS file OR the CAT file at run time.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Anniversary, so RS2, I guess. And you were careful to say you did a clean install.

For sure, the ability to load a driver that’s cross-signed but not MSFT signed, is neither documented nor expected behavior on new installations of RS2 or later, IF SecureBoot has been enabled.

Because the SYS being loaded is MSFT signed? I wonder…

Peter
OSR
@OSRDrivers

> Anniversary, so RS2, I guess. And you were careful to say you did a clean install.

Yes. Just to make sure, I’ve also attempted to install a standard driver package (inf & sys included) signed locally with a current certificate. This failed due to the more stringent checks. That same driver signed via attestation installs & loads fine.

Because the SYS being loaded is MSFT signed? I wonder…

That is my suspicion as well. I thought it would fail at install time (.cat for the INF is only signed by our certificate, not by MS), but it did not, and after the install succeeds the actual driver is indeed MS-signed, so it loads just fine.

I really like this behavior (it assists greatly in a number of customer scenarios with our products), but I just wasn’t sure if we could rely on it.

Any time the conversation turns to driver signing, my head hurts.

I spend half my time on this topic telling people “No, no… it really is straight forward” and I spend the OTHER half of my time on this topic telling DIFFERENT people “No, no… it’s not nearly as simple as you think.”

I had a conversation with a very senior (and helpful) PM type at MSFT recently, who made it all very simple:

  1. All x64 kernel-mode modules needs to be signed
  2. The necessary signing is “sign and cross-sign”
  3. EXCEPT if Secure Boot is enabled, THEN the signing needs to be by MSFT.

That IS simple. And that IS correct. And that IS enough for at least 75% of the people who author kernel modules.

It just doesn’t account for (a) the details, (b) the exceptions.

:wink:

Did I mention that my head hurts?

Peter
OSR
@OSRDrivers

(hmm… Does the new forum allow revieving year old threads? )

i’m trying to support secure boot, so would like attstation sign an “inbox” driver (winusb in my case). Has anyone manage to submit an inf only cab?

(It’s much better… more helpful, more polite… to start a new thread than to revive a thread that’s over a year old. Lots has happened since then… lots more has been posted on this topic… and when you revive such an old thread that added info is effectively lost.)

Menachem_Shapira wrote:

(hmm… Does the new forum allow revieving year old threads? )

i’m trying to support secure boot, so would like attstation sign an “inbox” driver (winusb in my case). Has anyone manage to submit an inf only cab?

That should not be a problem at all.  It would have been quicker just to
try it.

Yeah, of course I tried. It gets rejected with no apparent reason or information…

Right, my bad. I was under the impression that the package itself doesn’t need to be signed anymore (I thought signing the “signablefile.bin” was enough…

On Oct 24, 2018, at 10:18 PM, Menachem_Shapira wrote:
>
>
> Right, my bad. I was under the impression that the package itself doesn’t need to be signed anymore (I thought signing the “signablefile.bin” was enough…

The files inside the package do not need to be signed (as if you could sign an INF anyway…). The packed cabinet file does. They validate that signature against the certificates that are registered in your dashboard account.

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.