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 Practical Info

Tim_RobertsTim_Roberts Member - All Emails Posts: 12,854
I have some practical questions about the Windows 10 driver signing
thing, for those of you who have already been through it.

The requirement is that the package be submitted to the Windows Hardware
Dev Center Dashboard portal for signing. That is the same place where
one submits packages for WHQL, right? Is the new portal submission
thing separate from WHQL, or will all of these submissions have to have
HCK test logs?

In the past, just logging in to the WHDC Dashboard required a genuine
Verisign certificate (although not necessarily a code-signing
certificate). Is that required for these driver submissions? So, if I
choose a different vendor for the EV Code Signing cert, will I also need
a Verisign cert to log in?

Have any of you already been through this process? Can you briefly
describe what the steps look like? What's the turnaround time?

The web descriptions IMPLY that requirement is not enforced when
/testsigning is enabled. Is that so? Do most of you run with
/testsigning on all of the time? I have always resisted that, because I
want my test environment to match my clients' environment as closely as
possible, and THEY aren't going to run /testsigning. If the portal
submission adds 5 minutes to every build, it may no longer be practical
for me to do that.

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

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

«13456789

Comments

  • Daniel_TerhellDaniel_Terhell Member Posts: 1,349
    Was that EV you were talking about ? When karma is at work, stop worrying,
    just eat the popcorn and watch the show.

    //Daniel
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,058
    <quote>
    That is the same place where
    one submits packages for WHQL, right? Is the new portal submission
    thing separate from WHQL, or will all of these submissions have to have
    HCK test logs?
    </quote>

    Yes, it's the same place.

    The two submissions are different... you use "File Signing Services" and select "Driver Signing Submission" -- To be eligible for this, you must sign an "attestation agreement" saying you've tested your driver, it's compatible with Windows, and that you'll monitor the telemetry on sysdev and you agree to support the driver (for some value of "support").

    We do 95% of our testing with a kernel debugger connected (for release AND debug builds). So, signing isn't an issue. We only run our final tests on the final executable that has been signed with our "real" signing certificate once we have what we think is a "final" version.

    You can log into sysdev and check it out... You can submit things for Win10 signing right now... without even needing an EV Cert. Yet.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tom_McDermottTom_McDermott Member Posts: 57
    Does anyone know if it will be possible to automate the driver submission process to Microsoft, or must it be done manually each time a driver needs to be signed?
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,058
    Yes... An API for this was indeed discussed.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Daniel_TerhellDaniel_Terhell Member Posts: 1,349
    "You can log into sysdev and check it out... You can submit things for
    Win10 signing right now... without even needing an EV Cert. Yet"

    That's what they are saying. On the blog they also wrote

    "starting 90 days after the release of Windows 10, the portal will only
    accept driver submissions, including both kernel and user mode driver
    submissions, that have a valid Extended Validation (“EV”) Code Signing
    Certificate."

    However to be able to even sign up for a sysdev account, as a requirement
    you need to sign a winqual.exe file with a Symantec Class 3 certificate
    ($795/year). If signed using a standard KMCS procedures, the application is
    rejected .

    All this appears much contradictory to me.

    //Daniel
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,058
    <quote>
    as a requirement
    you need to sign a winqual.exe file with a Symantec Class 3 certificate
    </quote>

    But... hasn't that been the requirement forever? Not ANY class 3 Code Signing Cert, but a particular Symantec one? That's why there was the special $100 offer for that cert that folks (including OSR) used for years.

    And, yes... I agree it IS more confusing than it should be. And, it goes without saying that the cost of the EV Certificates is ridiculous to the point that it is scandalous.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • David_R._CattleyDavid_R._Cattley Member - All Emails Posts: 2,112
    Discussed? Was it decided and delivered? I know it was requested but I have not yet found it.

    Cheers
    Dave Cattley

    Sent from my Windows Phone
    ________________________________
    From: xxxxx@osr.com
    Sent: ‎7/‎15/‎2015 10:08 PM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] Driver Signing Practical Info

    Yes... An API for this was indeed discussed.

    Peter
    OSR
    @OSRDrivers


    ---
    NTDEV is sponsored by OSR

    Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

    OSR is HIRING!! See http://www.osr.com/careers

    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
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,854
    xxxxx@osr.com wrote:
    > <quote>
    > as a requirement
    > you need to sign a winqual.exe file with a Symantec Class 3 certificate
    > </quote>
    >
    > But... hasn't that been the requirement forever? Not ANY class 3 Code Signing Cert, but a particular Symantec one? That's why there was the special $100 offer for that cert that folks (including OSR) used for years.

    This is actually one of the primary reasons I asked my recent question.

    Yes, creating a winqual account has always required a Symantec
    certificate, although not necessarily a Symantec code-signing
    certificate. Thus, you could either get a "Symantec plain" plus an
    "affordable Class 3", or you could get a gold-plated "Symantec Class 3".

    Since I don't actually distribute any of the drivers I write, and the
    winqual account has to belong to the submitting company, I've never had
    a winqual account, so I've never had the Symantec certificate. Hence,
    my question. In order to reproduce my client's environment, am I now
    going to be REQUIRED to get a genuine Symantec certificate in order to
    create the account through which I make these submissions?

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

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

  • Mark_FontanaMark_Fontana Member Posts: 3
    On 07/16/2015 01:45 AM, xxxxx@resplendence.com wrote:
    >
    > However to be able to even sign up for a sysdev account, as a
    > requirement you need to sign a winqual.exe file with a Symantec Class
    > 3 certificate ($795/year). If signed using a standard KMCS procedures,
    > the application is rejected .
    >

    The least-expensive EV code signing certificate I could find is via this
    link: https://www.digicert.com/friends/sysdev/

    If I could use that same certificate to sign winqual.exe, that would be
    a great help. The drivers I sign under my own name tend to be pro bono
    efforts (e.g. to keep old hardware working on newer versions of
    Windows). It's painful to be periodically shaken down for hundreds of
    dollars for the privilege of releasing work I'm giving away for free.

    Over the last decade, the requirements have become decidedly unfriendly
    to lone developers taking up this craft. GlobalSign used to offer
    special pricing to individuals, but they declined my most recent renewal
    and told me that code signing certificates are now available only to
    corporations.

    Mark Fontana
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,058
    <quote>
    Over the last decade, the requirements have become decidedly unfriendly
    to lone developers taking up this craft. GlobalSign used to offer
    special pricing to individuals, but they declined my most recent renewal
    and told me that code signing certificates are now available only to
    corporations.
    </quote>

    When driver signing was originally implemented for x64, I spent a great deal of time arguing with the MSFT architects that it would screw hobby/community developers. I cited several examples of why this was not good for Windows. I couldn't get one person to express any interest, or to seriously attempt to address this issue.

    It will be VERY hard and almost prohibitively expensive for these devs to acquire EV cents (I read the guidelines, and I think it's technically possible, but the dev will have to have an actual business with an address).

    I think it's a real shame, and bad for Windows, to force hobby and community devs out of the marketplace.

    Perhaps somebody will form a .org to sign these kinds of projects. But that'd be a tricky business in today's world.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,058
    <quote>
    am I now
    going to be REQUIRED to get a genuine Symantec certificate in order to
    create the account through which I make these submissions?
    </quote>

    I don't understand. If you want to release sign drivers for testing, which I think it a bad idea but whatever, you're going to need an EV Cert. OR you're going to have to get your client to get an EV Cert and give you access to their sysdev account (this is actually very practical... The primary sysdev account holder can create other accounts for the same company and control a fairly fine grained set of permissions associated with each account) and THEIR EV Cert. This second option is what we do now when we have clients that want the Logo and want to pay us to run the Logo tests and submit for them. It works out quite well.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,854
    xxxxx@osr.com wrote:
    > <quote>
    > am I now going to be REQUIRED to get a genuine Symantec certificate in order to
    > create the account through which I make these submissions?
    > </quote>
    >
    > I don't understand. If you want to release sign drivers for testing, which I think it a bad idea but whatever,...

    I'm curious to know why you think it is a bad idea. I'm bothered by the
    idea of requiring my clients -- some of whom are not as technically
    sophisticated as they need to be -- to run their machines in
    /testsigning mode.


    > you're going to need an EV Cert. OR you're going to have to get your client to get an EV Cert and give you access to their sysdev account (this is actually very practical... The primary sysdev account holder can create other accounts for the same company and control a fairly fine grained set of permissions associated with each account) and THEIR EV Cert. This second option is what we do now when we have clients that want the Logo and want to pay us to run the Logo tests and submit for them. It works out quite well.

    That's certainly what I have done for logo submissions in the past. I
    did finally go out to the WHDC web site, and it looks like you can now
    use a certificate from either Symantec ($800) or Digicert ($225) to open
    a sysdev account, so there does appear to be another option now.

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

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

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,854
    xxxxx@resplendence.com wrote:
    > However to be able to even sign up for a sysdev account, as a requirement
    > you need to sign a winqual.exe file with a Symantec Class 3 certificate
    > ($795/year).

    The WHDC web site now says you can use a Digicert certificate as well,
    which is $225/year. That's good news, relatively speaking.
    https://msdn.microsoft.com/en-us/library/windows/hardware/hh801887.aspx

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

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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,058
    <quote>
    I'm curious to know why you think it is a bad idea.
    </quote>

    No deep thinking involved, really. I'm just concerned about pre-releases (my beta releases to clients or whatever) somehow getting out into the wild. If they're not "release signed" accidentally releasing them won't matter.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I've been looking into Windows 10 kernel driver signing for a while now and this is what I've found so far:

    1. The portal accepts submissions using a Symantec certificate (I haven't tried digicert, but they claim it's supported as well)
    2. The signing takes anywhere between 5 - 30 min. But it can apparently take several hours based on server load
    3. The cab that you upload for signing needs to be in a specific format - https://msdn.microsoft.com/en-us/library/windows/hardware/dn962252(v=vs.85).aspx?f=255&amp;MSPPError=-2147217396
    4. The driver (.sys) needs to have a .inf along with it. The portal will not accept .sys files without an accompanying .inf (e.g. some non-PnP drivers)

    Open questions:
    1. (this is the biggest open question) The latest preview build of Windows 10 does not enforce this check. My drivers, which are NOT signed by Microsoft, still continue to load fine. When will we start seeing failures? Only after July 29 when Windows 10 releases?
    2. An API is supposed to exist - https://msdn.microsoft.com/en-us/library/windows/hardware/dn800659.aspx?f=255&MSPPError=-2147217396, but the URL it's using, https://api.sysdev.microsoft.com is not available
    3. Will it be possible to sign .sys files on their own without an inf? I think the workaround until then would be to create a dummy inf (which hasn't worked for me yet).
  • Larry_ClawsonLarry_Clawson Member Posts: 191
    <quote>
    I'm just concerned about pre-releases (my
    beta releases to clients or whatever) somehow getting out into the wild.
    </quote>

    You obviously need to change your release management into the at least the 1990s and let your clients know it is BETA. :)


    We have many Clients that want to come to our facility to test with a "NON DEBUG" version of our software before release in the wild. Our lab is setup like their live system and they run tests. Now they may want 10 different adjustments but want to test them 1 at a time, again NON DEBUG, turn around time is important to our SCM department.

    Larry C
  • Christiaan_GhijselinckChristiaan_Ghijselinck Member Posts: 476
    All these new signing practices may be useful en valuable , but it kills my current business. I've decided not to support Win10 (
    although my driver software installs and works perfectly on Win10 Insider preview ) , and I am even thinking about stopping driver
    development it all. I pay now yearly for a MSDN membership and a Sha1 certificate. Additionally payments for a Sha2 EV certificate
    and a dashboard ( winqual ) account exceeds the yearly income of providing the software. I also worked out a method whereby each
    user received a "branded" ( with name , e-mail address , etc ) *.sys file as a sort of license identification. Compilation ,
    signing , packaging en sending takes only a few minutes. All this collapses due the time needed when to submit it to the dashboard.
    All my customers receive currently updates for free. Now , I will send a note to all of them not to expect updates anymore ( unless
    they keep using pre-Win10 versions ) and suggest them to send their complaints about this to Microsoft.

    Christiaan
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,058
    Mr. Clawson: Debug vs non-debug builds don't have anything at all to do with driver signing.

    So, I really don't know what your talking about. Let them come to your office, and let them run an unsigned copy with the kernel debugger attached, or (as of today) a test signed copy with the signature loaded on the machine.

    Release signing is for released code. You start release signing betas, then you have to release sign beta updates, the you have to release sign private builds... All because nobody at your customer can enable test signing or disable signature enforcement? That's a lot of versions to be kicking around, waiting to escape into the wild accidentally.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Daniel_TerhellDaniel_Terhell Member Posts: 1,349
    >1. (this is the biggest open question) The latest preview build of Windows
    >10 does not enforce this check. My >drivers, which are NOT signed by
    >Microsoft, still continue to load fine. When will we start seeing failures?
    >Only >after July 29 when Windows 10 releases?

    This is my biggest concern as well. I have to update my software for Windows
    10. I don't know if I can still ship a fixed driver or if I should include
    the old buggy driver in there for Windows 10 only ?

    It's pretty bizarre that the information is so contradictory and unclear,
    is it too much effort to post a real date or some thing or is that on
    purpose ? All this leads me to believe EV isn't quite ready for it's prime
    time. But still, I don't like to be playing with dice, it's nice if we can
    keep at least some level of control.

    In any case, being a DBA, I'm not going to incorporate (with legal
    implications) just to be able to buy a certificate. Just before the
    announcement I bought a 5 year nonEV certificate of which I hope it got me
    settled and I haven't quite recovered from the pain of getting that (it
    wasn't the money that hurt).

    //Daniel
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,058
    <quote>
    The latest preview build of Windows
    10 does not enforce this check. My drivers, which are NOT signed by
    Microsoft, still continue to load fine.
    </quote>

    Right. According to the announcements at WinHEC, as described in my blog post at: <http://www.osr.com/blog/2015/03/18/microsoft-signatures-required-km-drivers-windows-10/>;

    "Drivers signed before Windows 10 RTM will be able to use the older signing mechanisms. But once Windows 10 ships, if you want your driver to run on Windows 10 desktop systems, you?ll need to (a) get an EV certificate, (b) using that signature submit your driver to sysdev to get Microsoft?s signature."

    That's why we thought it was pretty important for people to start dealing with this back in March, months before Win10 RTM. Get your stuff updated, signed the old way before Win10 RTM, and you SHOULD be GTG for Win10 according to this announcement.

    ALTERNATIVELY, get an EV Cert, work through the new procedures, and get your stuff signed at your leisure and you're GTG. That's what WE chose to do.

    That's all *I* know. I haven't heard anything to the contrary in the intervening months, but then again, I haven't done anything to specifically follow-up on this either.

    Of course, this *does* beg the question as to how you ever update your drivers after Win10 RTM if you don't get an EV Cert and have them signed by MSFT's program. According to what's been announced so far, the answer to that is "you don't... After Win10 RTM you have to get an EV Cert and get your drivers signed by MSFT's program." Well see if that sticks. Like I said, I haven't done anything to follow-up on this personally.

    <quote>
    In any case, being a DBA, I'm not going to incorporate (with legal
    implications) just to be able to buy a certificate.
    </quote>

    There is absolutely nothing in the guidelines that says you have to incorporate.

    This isn't that mysterious... just Google "Guidelines For The Issuance And Management Of Extended Validation Certificates" and read what the requirements are for an EV cert.

    NOW... what a given Certification Authority may be willing to do CAN be more limited than these guidelines allow. But non-incorporated business entities are certainly allowable (consider all the general partnerships that would be ruled-out if this were not possible).

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,854
    vikram.parthasarathy@ni.com wrote:
    > I've been looking into Windows 10 kernel driver signing for a while now and this is what I've found so far:
    > ...
    > 3. The cab that you upload for signing needs to be in a specific format - https://msdn.microsoft.com/en-us/library/windows/hardware/dn962252.aspx

    Uh-oh. That page says each driver package can only support one
    architecture. I have always preferred to release one package with one
    INF supporting multiple architectures, just because that reduces the
    redundancy and hence the opportunity for errors. Does this mean such an
    architecture is simply no longer possible?


    > 3. Will it be possible to sign .sys files on their own without an inf? I think the workaround until then would be to create a dummy inf (which hasn't worked for me yet).

    That's an important question, and it leads to something that I'm not
    clear about. As I have written previously, in a brilliant article
    published in the NT Insider, there are two entirely different signature
    checks in Windows. We have the PnP install-time check, which happens on
    all systems, but only happens when the driver package is installed.
    Then we have the KMCS check, which only applies to 64-bit systems, but
    happens every time the driver is LOADED.

    Reading on this page about CAB files and driver packages makes me start
    to wonder if this change only applies to the PnP install-time signature
    check, and NOT to KMCS. If that is the case, then that eases some of my
    fears. That would mean that once I get a driver installed, I can do
    updates to my heart's content by copying the new files into place. It
    would also mean that service-based drivers and device filter drivers
    aren't affected.

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

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

  • Alan_Adams-2Alan_Adams-2 Member Posts: 46
    Tim Roberts <xxxxx@probo.com> wrote:

    > vikram.parthasarathy@ni.com wrote:
    > > I've been looking into Windows 10 kernel driver signing for a while now and this is what I've found so far:
    > > ...
    > > 3. The cab that you upload for signing needs to be in a specific format - https://msdn.microsoft.com/en-us/library/windows/hardware/dn962252.aspx
    >
    > Uh-oh. That page says each driver package can only support one
    > architecture. I have always preferred to release one package with one
    > INF supporting multiple architectures, just because that reduces the
    > redundancy and hence the opportunity for errors. Does this mean such an
    > architecture is simply no longer possible?

    That was a surprising and concerning limitation when we read it, too.

    When both the .INF format and seemingly "the intention" of installing
    software via .INF is to easily and transparently support multiple
    architectures from a single .INF and installation set, the "single
    architecture" statement seems very arbitrary and limiting.

    But I can't be sure what it truly means at a technical level, yet.
    e.g. Does "single architecture" only refer to what platform the .INF
    sections target, but still supports a mix of 32-bit and 64-bit binary
    images being part of the driver set? Is it only concerned about
    kernel-mode driver images, or all binary images including .DLLs?

    For example, we have a "NetClient"-class software-only driver set that
    includes a network redirector & the associated supporting network
    provider DLL.

    Never mind that we support installation on Windows 32-bit versus
    Windows 64-bit using the same single .INF and the appropriate section
    decorations. Even if we supported only Windows 64-bit in this .INF,
    we would /still/ be including both 64-bit and 32-bit files in that
    package, because you install the 32-bit network provider so that WNet
    APIs on 32-bit processes can access your network redirector services,
    etc.

    Still waiting to see how this turns out. Noted that when you make a
    new "Create driver signing submission" in SysDev, you are able to put
    a checkbox beside both:

    > Qualifications:
    > [x] Signed for Microsoft Windows 10 Client family, x86
    > [x] Signed for Microsoft Windows 10 Client family, x64

    I'm stymied from completing the submission for now, due to unrelated
    certificate complications still being worked out within the company.

    But I'm interested to see what the system kicks back once I
    successfully upload our existing multi-platform "NetClient"-class .INF
    "as-is", but having selected both "Signed for Microsoft Windows 10
    Client family, x86" and "Signed for Microsoft Windows 10 Client
    family, x64" during the submission.

    Alan Adams
    Novell Client CPR Group
    xxxxx@novell.com

    Novell, Inc.
    www.novell.com
  • Jeff_PagesJeff_Pages Member Posts: 20
    I'm also confused by this portal thing. In the 1st of April blog, they said you could select earlier operating systems (like Vista, 7, etc.) as well as 10, but the only platform options on the portal are Windows 10 32-bit and Windows 10 64-bit. Will the portal's signature be recognised by earlier versions? I'd hate to think we have to have separate drivers for 10 and everything else.

    I'm also scratching my head about the .cab requirement. Do we have to use makecab and create a ddf file to do this, or is there some automated way to cab a driver package?

    Jeff
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,058
    OK folks... There are obviously a lot of gaps in our knowledge about how this is going to work.

    I'm trying to gather some detailed and definitive technical answers... I'll write-up whatever I learn and publish it either (a) in our blog, or (b) in The NT Insider ... probably both.

    In the meantime, if you have specific questions, feel free to post them here.

    I'll spend some time trying to engage with the right person at Microsoft, and bring the answers back to the community.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Shane_CorbinShane_Corbin Member Posts: 233
    Thanks Peter. I've been actively following this discussion as I have many of the same questions raised here.

    I've got my shiny new EV cert in house and am changing my build processes to appropriately sign with the EV cert only for release builds. However, I have yet to go through the sysdev submission process.

    If you could get some clarity on the API (does it exist?, how do we use it?, etc.) that'd be highly valuable for me. I do continuous integration nightbuilds and need to utilize that same system for my release builds; which means I need to account for the extra submission steps.

    On a slightly related note it's been difficult working through the details of how to get our new cert installed as part of the installation process. It could be very useful for people to get the end-to-end descriptive summary of what it takes to get a new cert, integrate it into your workflow, use it with sysdev, and get your end product ready for distribution.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,854
    xxxxx@osr.com wrote:
    > OK folks... There are obviously a lot of gaps in our knowledge about how this is going to work.
    >
    > I'm trying to gather some detailed and definitive technical answers... I'll write-up whatever I learn and publish it either (a) in our blog, or (b) in The NT Insider ... probably both.
    >
    > In the meantime, if you have specific questions, feel free to post them here.

    I've started trying to explain this to my clients, and that has pointed
    out several additional gaps in my understanding. It would be nice to
    have a Lync/Skype Q&A session with someone who knows the One Truth.

    I am assuming that the new web-service signing requirement only applies
    to driver PACKAGES, and hence only applies to the PnP install-time
    signature check. Specifically, I assume that the KMCS requirements are
    unchanged. Still 64-bit only, still Class 3 Code-Signing Cert with
    cross certificate, still SHA1. True?

    Assuming that is true, where does the EV Cert come in to play? In the
    past, when WHQL signed a CAT file, it replaced whatever vendor
    certificate was there. Does the CAT file we submit have to be signed by
    our EV Cert? Will it still be replaced? Or is the EV Cert only used to
    establish the winqual account itself?

    If I want to have both SHA1 and SHA256, will I have to add an SHA1 cert
    onto the CAT file after I get it back? Or does that happen before?

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

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

  • David_R._CattleyDavid_R._Cattley Member - All Emails Posts: 2,112
    > I am assuming that the new web-service signing requirement only applies
    > to driver PACKAGES, and hence only applies to the PnP install-time
    > Specifically, I assume that the KMCS requirements are
    > unchanged. Still 64-bit only, still Class 3 Code-Signing Cert with
    > cross certificate, still SHA1. True?

    Any platform that does UEFI secure boot requires a KMCS signature on drivers - even 32-bit platforms. This has been true of Win8+. Basically one should be KMCS drivers for any (all) architectures. period.

    A cute little Acer tablet that was SWAG at //Build a few years ago taught me that lesson. It is an anemic little x86 system and it flat out refused to load my driver until it was KMCS signed. I now cherish the toy as the only x86 UEFI secure boot platform I have to test that scenario with.

    As for the other points I am among the increasingly befuddled.

    Cheers,
    Dave Cattley
  • Jan_BottorffJan_Bottorff Member - All Emails Posts: 471
    It’s my understanding you can no longer purchase a SHA1 signing certificate, and all existing ones will expire by 1/1/2016, so after that date the issue of how to do SHA1 signatures (or dual SHA1/SHA2) will be moot. Drivers already signed with a SHA1 signature will continue to work until some future point that Microsoft decides SHA1 is too vulnerable and releases a patch disabling SHA1.

    This does mean older OS versions that didn’t support SHA2 KMCS will not support new/updated drivers unless they are patched with the correct SHA2 support. If you already have a SHA1 cert, I assume you have until the end of the year to update/sign any drivers for these unpatched systems.


    Jan



    On 7/22/15, 3:48 PM, "xxxxx@lists.osr.com on behalf of Tim Roberts" <xxxxx@lists.osr.com on behalf of xxxxx@probo.com> wrote:

    >I am assuming that the new web-service signing requirement only applies
    >to driver PACKAGES, and hence only applies to the PnP install-time
    >signature check. Specifically, I assume that the KMCS requirements are
    >unchanged. Still 64-bit only, still Class 3 Code-Signing Cert with
    >cross certificate, still SHA1. True?
    >
    >Assuming that is true, where does the EV Cert come in to play? In the
    >past, when WHQL signed a CAT file, it replaced whatever vendor
    >certificate was there. Does the CAT file we submit have to be signed by
    >our EV Cert? Will it still be replaced? Or is the EV Cert only used to
    >establish the winqual account itself?
    >
    >If I want to have both SHA1 and SHA256, will I have to add an SHA1 cert
    >onto the CAT file after I get it back? Or does that happen before?
    >
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,058
    <quote>
    I am assuming that the new web-service signing requirement only applies
    to driver PACKAGES, and hence only applies to the PnP install-time
    signature check.
    </quote>

    According to what I've been told just yesterday, that would be an incorrect assumption.

    Hang on for a bit longer... I should have a Q&A up with answers to most of your questions within the next day.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > It?s my understanding you can no longer purchase a SHA1 signing certificate

    It looks like this was going to be the case but Microsoft changed the policy so that developers could still support the legacy operating systems:

    http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

    "CAs must stop issuing new SHA1 SSL end-entity certificates by 1 January 2016. Update: For code signing certificates, CAs may continue issuing new SHA1 code signing certificates to ensure that developers targeting Windows Vista and Windows Server 2008 are properly supported."
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
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space