Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Driver signing on Windows 7 and 10

SanderSander Member Posts: 10

Hi,

I'm trying to wrap my mind around the current driver signing situation for windows 7 and windows 10.
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.
( https://social.msdn.microsoft.com/Forums/sqlserver/en-US/b84d0bdc-f661-4ead-b16c-6521093e044a/win-102016-driver-signing-of-nonpnp-software-only-drivers?forum=wdk )

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

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
( https://support.microsoft.com/en-us/help/3033929/microsoft-security-advisory-availability-of-sha-2-code-signing-support
https://support.microsoft.com/en-us/help/2921916/the-untrusted-publisher-dialog-box-appears-when-you-install-a-driver-i )

Before the SHA-256 update SHA-256 signed drivers will show an error on windows 7, and from what I read from the current microsoft documentation SHA-1 signed drivers will throw a warning (but currently still install) on an updated SHA-256 windows 7 machine. (but I guess at some point in the future the might not be allowed at all).
( https://knowledge.digicert.com/solution/SO27330.html )

Will it be possible to use dual signing to have a single driver file be installed on all versions of windows 7?
( https://knowledge.digicert.com/generalinformation/INFO2274.html )

Is it possible to sign a single driver for all these three combinations? ( attestation (w10) and dual signed (w7) )
From what I make up from this comment it seems doable (since we don't have .inf files for these drivers)

"The binary files in your package come back with Microsoft's signature added to whatever signature was there before. So, the driver binary will work on all of the systems."
https://community.osr.com/discussion/286858/driver-signing-for-multiple-os-versions-and-microsoft-documentation

Best,
Sander

Comments

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 238

    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.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,345

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 238

    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?

  • SanderSander Member Posts: 10

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

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,022
    via Email
    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, [email protected]
    Providenza & Boekelheide, Inc.

  • SanderSander Member Posts: 10

    @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?

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 238
    via Email
    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
    >
  • SanderSander Member Posts: 10

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

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 238
    via Email
    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.
  • SanderSander Member Posts: 10

    @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;

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 238
    via Email
    Are there any drivers which require a CAT, rather than an embedded signature?
    What is the point of a CAT file anyway?
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,345

    What is the point of a CAT file anyway?

    Spoken like a true file system dev ;-)

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,022
    via Email
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,022
    via Email
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 238
    via Email
    Aha, I did not know the INFs are signed - true FS Dev, as you said :)

    INFs cannot be embed-signed?:) 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.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,022

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

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 238
    via Email
    They are not SIGNABLE, either?
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,022
    via Email
    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, [email protected]
    Providenza & Boekelheide, Inc.

  • SanderSander Member Posts: 10

    @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?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,022
    via Email
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • RourkeRourke Member Posts: 34

    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?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,022
    via Email
    Rourke wrote:
    > 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 INF is not the key.  A driver package with a CAT file returned from
    attestation will no longer install prior to Windows 10.  The user will
    get a "not designed for this version of Windows" error.  Remember, that
    message is triggered by the CAT file.  If you have a [DefaultInstall]
    type of INF, that's really just a special kind of batch file.  It
    shouldn't need a CAT.


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

    Unless I've missed a meeting somewhere, all you need is one HCK and one
    HLK.  Run the 8.1 tests, and you should be able to request the older
    signatures.


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

    Windows Server 2016 == Windows 10.  Same kernel, same policies. Server
    2019 is also Windows 10.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA