Driver signing on Windows 7 and 10

can only be signed through a “trick” in the attestation signing procedure for windows 10

It’s not a “trick”… it’s just the way it works.

Does this procedure make them valid for each version of windows 10

Yes.

Is it possible to sign a single driver for all these three combinations? ( attestation (w10) and dual signed (w7) )

I’ve never seen this work, personally. But Mr. Maksimovic, above, say it works… so I believe him.

Peter

I believe the order, which I mentioned, is important. I.e. dual-sign first, attest second.

IIRC, this requries Windows 7 x64 to verify, as x86 version still allows loading of unsigned binaries?

@Dejan_Maksimovic said:
Yes, this is doable. Sing your driver with both SHA1 and SHA2, before sending it off for attestation, and use the resulting binary (from attestation) for both Win7/SHA2-Win7 and Win10.

Thanks for your answer.

I believe the order, which I mentioned, is important. I.e. dual-sign first, attest second.
Yes, that is what I make up from the comment I mentioned earlier too

@Tim_Roberts said:
The binary files in your package come back with Microsoft’s signature added to whatever signature was there before
https://community.osr.com/discussion/286858/driver-signing-for-multiple-os-versions-and-microsoft-documentation

@“Peter_Viscarola_(OSR)” said:
It’s not a “trick”… it’s just the way it works.
My apologies for the wording, but when I read the post it did sound a little bit like it to me.

Sander wrote:

We have some non-pnp software only drivers which, if I understand correctly, can only be signed through a “trick” in the attestation signing procedure for windows 10.

Does this procedure make them valid for each version of windows 10 (including the pre 1607 versions)?

Yes, and if you have a non-PnP driver, as you say, then it works for
pre-Windows 10 systems as well, if they support SHA-256.

However it doesn’t make a valid signed driver for windows 7 so we need to sign it differently for those systems.
There are two flavours for windows 7; before and after the SHA-256 update

Yes, but the attestation signature will satisfy Windows 7 with SHA-256. 
All you need to do is add the SHA-1 first.

The reason why attestation only works on Windows 10 for PnP packages is
that they create a brand-new CAT file that only lists Windows 10.  If
you are not PnP, then you will throw away the CAT file anyway, so that
limitation does not affect you.

@Tim_Roberts said:
The reason why attestation only works on Windows 10 for PnP packages is
that they create a brand-new CAT file that only lists Windows 10. If
you are not PnP, then you will throw away the CAT file anyway, so that
limitation does not affect you.

Can I conclude from this that for a PnP package you only would need the two different signed CAT files (one dual signed for windows 7, the other from the windows 10 attestation signing) but still can use just a single SYS file to make it work on both Windows 7 and 10?

Different Cats always worked with the same SYS, in terms of signatures.
It is the embedded and single-CAT solutions that did not work in all situations.
Of course, it presumes your SYS works on both versions, i.e. you
cannot expect a WDK10 target binary to work on Windows 7.
ExAllocatePool Nx pool type comes to mind, as, probably, the most
common caveat.

Frankly, I wish MS made some performance figures available on embedded
vs. CAT signatures, I would reckon embedded ones are faster (one less
less to open, when there are a lot that need opening, it should make a
difference).

On 4/18/19, Sander > Can I conclude from this that for a PnP package you only would need the two
> different signed CAT files (one dual signed for windows 7, the other from
> the windows 10 attestation signing) but still can use just a single SYS file
> to make it work on both Windows 7 and 10?
>
> –
> Reply to this email directly or follow the link below to check it out:
> https://community.osr.com/discussion/comment/293497#Comment_293497
>
> Check it out:
> https://community.osr.com/discussion/comment/293497#Comment_293497
>

@Dejan_Maksimovic said:
Different Cats always worked with the same SYS, in terms of signatures.

But is this still valid (for PnP packages) when also going through the attestation signing for windows 10? If I read the earlier comment about the process:

@Tim_Roberts said:
The binary files in your package come back with Microsoft’s signature added to whatever signature was there before
This sounds to me like the SYS file also has been signed, and thus altered. Meaning the SYS file won’t work with any CAT file created earlier.

If I understand correctly to make it work for Windows 7 versions (both pre/post SHA-256 update) I have to dual sign the CAT file.
To make it work for windows 10 I do need a different set of SYS/CAT files.

I am not sure how dual-signing, or added signatures affect the CAT
files. I would presume they do not, otherwise the first of the
dual-signatures would not be valid, right?

Either way, you can create your Win7 CAT after you get the files from
MS. I see no point though, if you dual-sign them… CATs are not
required for embed signed binaries.

@Dejan_Maksimovic said:
Either way, you can create your Win7 CAT after you get the files from MS.

Ah yes; good point.

I see no point though, if you dual-sign them… CATs are not required for embed signed binaries.

Sorry for the confusion; We also do have some PnP Packages ( with SYS, CAT, INF ) where only the CAT is being signed. So indeed these are different from the non-PnP software only ones I mentioned in the topic start;

Are there any drivers which require a CAT, rather than an embedded signature?
What is the point of a CAT file anyway?

What is the point of a CAT file anyway?

Spoken like a true file system dev :wink:

It’s used as part of PnP installation with an INF file, so embedded signing and CAT signing are complementary not interchangeable. They key aspect of the CAT file is that it contains the signature of the INF file. This makes the INF not changeable without breaking the signature, and hence the driver’s installability.

Peter

Dejan_Maksimovic wrote:

Are there any drivers which require a CAT, rather than an embedded signature?
What is the point of a CAT file anyway?

There are two entirely different signature checks.

The KMCS signature check happens every time a driver is loaded into
memory, but only on 64-bit systems.  This check can use either the CAT
file or the driver binary.  I should know which is checked first, but I
don’t.  I would guess it checks the driver binary first, because that’s
easier to find; the CAT file requires a registry lookup.  However, the
CAT check does not look at the operating system list in the CAT file, so
attestation works fine below Windows 10.

There is also a signature check done at install time, when a PnP driver
package is pre-loaded, and every time a new device is detected and
matched to an INF file.  This check looks only at the CAT file, and it
also checks the operating system version.  This check is not applicable
to non-PnP installs.  Note that the CAT file contains a checksum of the
INF and every binary mentioned in the INF; if any of the checksums don’t
match, the CAT is invalid. I am told that the checksum check does NOT
include any certificates in the binary, so adding an additional
certificate does not invalidate the CAT.

Sander wrote:

@Tim_Roberts said:
> The binary files in your package come back with Microsoft’s signature added to whatever signature was there before
This sounds to me like the SYS file also has been signed, and thus altered. Meaning the SYS file won’t work with any CAT file created earlier.

I have been told, but have not personally verified, that the checksum in
the CAT file does not include any certificates.  Thus, you can add
additional signatures without invalidating the CAT.

If I understand correctly to make it work for Windows 7 versions (both pre/post SHA-256 update) I have to dual sign the CAT file.

Well, it depends.  If all you care about is Windows 7, just use SHA-1. 
Windows 7 allows either; it was only later when the SHA-1 support was
dropped.

To make it work for windows 10 I do need a different set of SYS/CAT files.

You certainly need a different CAT file, with a Microsoft signature.

Aha, I did not know the INFs are signed - true FS Dev, as you said :slight_smile:

INFs cannot be embed-signed?:slight_smile: Can the SYS be embed sign, while the
CAT would be for the INF only?
This makes the BOOT process faster, I would reckon, as there is no
need to process INF/CAT files.

No, INFs are not signed. Just CAT files and executables.

They are not SIGNABLE, either?

Dejan_Maksimovic wrote:

They are not SIGNABLE, either?

No.  It’s a plain text file; there’s no place to put a signature.  Just
CAT files and PE files (executables).

@Tim_Roberts said:
Well, it depends. If all you care about is Windows 7, just use SHA-1.
I was under the impression Microsoft was already adding warnings when something with SHA-1 is being used (also on windows 7); The phase 3 mentioned in this article (although it seems more aimed at browsers):
https://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-sha1-certificates.aspx

Windows 7 allows either;
But you do need the windows 7 update to make SHA-256 work right?

it was only later when the SHA-1 support was dropped.
But for all windows 7 versions (thus also the ones patched with the SHA-256 update) SHA-1 will still work?

To rephrase; In principle both a non-pnp software only driver and a PnP package (with a signed CAT) will work on all Windows 7 versions with just SHA-1 signing?

Sander wrote:

I was under the impression Microsoft was already adding warnings when something with SHA-1 is being used (also on windows 7); The phase 3 mentioned in this article (although it seems more aimed at browsers):

Right, for browsers and applications, not for KMCS.

But you do need the windows 7 update to make SHA-256 work right?

Right.  Win 7 SP 2 includes it, so any up-to-date system would be OK.

But for all windows 7 versions (thus also the ones patched with the SHA-256 update) SHA-1 will still work?

Yes.

To rephrase; In principle both a non-pnp software only driver and a PnP package (with a signed CAT) will work on all Windows 7 versions with just SHA-1 signing?

Right.

So is it correct to say that a driver that is installed using an inf file returned from attestation signing will no longer install in any version of windows 7, 8, or 8.1 ? The solutions are:

(1) make an additional cat file with one’s code signing certificate for use with pre-windows 10
(2) discontinue use of inf files and install programatically (non-pnp type devices only)
(3) spend weeks trying get a bunch of old, unsupported HCK and WLK monstrosities to work.

Another question: after attestation signing what Windows Server versions (if any) will the driver be able to load on? And does the existence of an INF file matter in this?