Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Upcoming OSR Seminars:

Writing WDF Drivers I: Core Concepts, Nashua, NH 15-19 May, 2017
Writing WDF Drivers II: Advanced Implementation Tech., Nashua, NH 23-26 May, 2017
Kernel Debugging and Crash Analysis, Dulles, VA 26-30 June, 2017
Windows Internals & Software Driver Development, Nashua, NH 24-28 July, 2017


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 259  
14 Jul 15 13:09
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

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.
  Message 2 of 259  
14 Jul 15 13:31
Daniel Terhell
xxxxxx@resplendence.com
Join Date: 15 Apr 2004
Posts To This List: 921
Driver Signing Practical Info

Was that EV you were talking about ? When karma is at work, stop worrying, just eat the popcorn and watch the show. //Daniel
  Message 3 of 259  
14 Jul 15 17:08
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<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
  Message 4 of 259  
15 Jul 15 16:37
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

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?
  Message 5 of 259  
15 Jul 15 22:09
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Yes... An API for this was indeed discussed. Peter OSR @OSRDrivers
  Message 6 of 259  
16 Jul 15 02:46
Daniel Terhell
xxxxxx@resplendence.com
Join Date: 15 Apr 2004
Posts To This List: 921
Driver Signing Practical Info

"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
  Message 7 of 259  
16 Jul 15 08:21
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<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
  Message 8 of 259  
16 Jul 15 08:33
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 2103
Driver Signing Practical Info

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<mailto:xxxxx@osr.com> Sent: ???7/???15/???2015 10:08 PM To: Windows System Software Devs Interest List<mailto:xxxxx@lists.osr.com> 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 --
  Message 9 of 259  
16 Jul 15 13:34
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

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.
  Message 10 of 259  
16 Jul 15 17:49
Mark Fontana
xxxxxx@kinura.net
Join Date: 05 Jul 2013
Posts To This List: 3
Driver Signing Practical Info

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
  Message 11 of 259  
16 Jul 15 21:17
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<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
  Message 12 of 259  
16 Jul 15 21:40
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<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
  Message 13 of 259  
17 Jul 15 12:49
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

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.
  Message 14 of 259  
17 Jul 15 12:51
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

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.
  Message 15 of 259  
17 Jul 15 15:12
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<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
  Message 16 of 259  
17 Jul 15 15:49
Vikram Parthasarathy
xxxxxx@ni.com
Join Date: 17 Jul 2015
Posts To This List: 14
Driver Signing Practical Info

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%28v=vs.85%29.a spx?f=255&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&MSP PError=-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).
  Message 17 of 259  
17 Jul 15 17:10
Larry Clawson
xxxxxx@honeywell.com
Join Date: 25 Sep 2003
Posts To This List: 186
Driver Signing Practical Info

<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
  Message 18 of 259  
17 Jul 15 19:05
Christiaan Ghijselinck
xxxxxx@compaqnet.be
Join Date: 21 Mar 2002
Posts To This List: 476
Driver Signing Practical Info

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
  Message 19 of 259  
17 Jul 15 22:29
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

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
  Message 20 of 259  
18 Jul 15 03:47
Daniel Terhell
xxxxxx@resplendence.com
Join Date: 15 Apr 2004
Posts To This List: 921
Driver Signing Practical Info

>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
  Message 21 of 259  
18 Jul 15 11:20
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<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-wind ows-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
  Message 22 of 259  
20 Jul 15 14:52
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@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.
  Message 23 of 259  
21 Jul 15 18:19
Alan Adams
xxxxxx@novell.com
Join Date: 20 Dec 2010
Posts To This List: 19
Driver Signing Practical Info

Tim Roberts <xxxxx@probo.com> wrote: > xxxxx@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
  Message 24 of 259  
22 Jul 15 00:54
Jeff Pages
xxxxxx@sonifex.com.au
Join Date: 21 Jul 2015
Posts To This List: 20
Driver Signing Practical Info

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
  Message 25 of 259  
22 Jul 15 09:04
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

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
  Message 26 of 259  
22 Jul 15 12:01
Shane Corbin
xxxxxx@hotmail.com
Join Date: 14 Jun 2007
Posts To This List: 198
Driver Signing Practical Info

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.
  Message 27 of 259  
22 Jul 15 18:49
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

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.
  Message 28 of 259  
22 Jul 15 22:53
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 2103
Driver Signing Practical Info

> 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 --
  Message 29 of 259  
23 Jul 15 11:59
Jan Bottorff
xxxxxx@pmatrix.com
Join Date: 16 Apr 2013
Posts To This List: 377
Driver Signing Practical Info

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 <...excess quoted lines suppressed...>
  Message 30 of 259  
23 Jul 15 12:05
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<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
  Message 31 of 259  
23 Jul 15 12:06
ntdev member 134696
xxxxxx@baesystemsdetica.com
Join Date:
Posts To This List: 68
Driver Signing Practical Info

> 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."
  Message 32 of 259  
23 Jul 15 15:27
Gabe Jones
xxxxxx@ni.com
Join Date: 19 Mar 2012
Posts To This List: 38
Driver Signing Practical Info

> In the meantime, if you have specific questions, feel free to post them here. Peter, thanks for doing this. Questions, in no particular order and as they come to mind: 1. How do we handle non-PnP drivers with no INF? We've been mocking up a dummy INF to get a signature on such a binary, but that seems a bit hacky. 2. Will KMCS be enforced on 32-bit Windows 10 in general? 3. The REST API for driver signing doesn't seem to be operational. We've been trying to use the sample code without success. ("401 unauthorized") When will it start working, or could it be that we are doing authorization incorrectly? 4. How do we accomplish prerelease signing? Will putting Windows 10 in test signing mode obviate the need for the Microsoft signature on a kernel driver, or will we need a driver with a Microsoft test signature? If the latter, how do we accomplish that with the REST API? The API lists a "Production" type (https://msdn.microsoft.com/en-us/library/windows/hardware/dn800659.aspx). I assume there is an equivalent "Preproduction" type, but it is not documented. 5. How do we initiate a failure due to lack of an appropriate Microsoft signature? Do we have to wait until after July 29? When it is allowing exceptions for drivers signed prior to July 29, exactly what timestamp is Windows looking at? 6. We are very concerned about the impact of this on our build times and thus our continuous integration. If we only need to have Microsoft sign our finals that's at least only a one-time thing, but (going back to question #4) if we have to do preproduction signing through MS servers that will very much impinge on our current workflow. If prerelease signing is required for test signing mode, will it at least be much quicker than the potential hours that I've seen listed for release signing?
  Message 33 of 259  
24 Jul 15 15:16
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

You had questions... we went to the Microsoft authorities get answers. Thank you, everyone, for your patience while we went out to gather the facts. Here's what we know: <http://bit.ly/1CVeW9q> Hope you find this helpful... I wrote this instead of the driver I'm supposed to be working on. Now I'm behind schedule. Again... ;-) Peter OSR @OSRDrivers
  Message 34 of 259  
24 Jul 15 16:03
Daniel Terhell
xxxxxx@resplendence.com
Join Date: 15 Apr 2004
Posts To This List: 921
Driver Signing Practical Info

Awesome, thanks. //Daniel
  Message 35 of 259  
24 Jul 15 16:08
Don Burn
xxxxxx@windrvr.com
Join Date: 23 Feb 2011
Posts To This List: 1324
Driver Signing Practical Info

Peter, Thanks for the effort of putting this all together. Don Burn Windows Driver Consulting Website: http://www.windrvr.com -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com Sent: Friday, July 24, 2015 3:15 PM To: Windows System Software Devs Interest List Subject: RE:[ntdev] Driver Signing Practical Info You had questions... we went to the Microsoft authorities get answers. Thank you, everyone, for your patience while we went out to gather the facts. Here's what we know: <http://bit.ly/1CVeW9q> Hope you find this helpful... I wrote this instead of the driver I'm supposed to be working on. Now I'm behind schedule. Again... ;-) 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
  Message 36 of 259  
24 Jul 15 17:11
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Thanks for getting us the answers, Peter. These issues are potentially very impactful to our organization. Still trying to digest it all...
  Message 37 of 259  
24 Jul 15 17:13
Gabe Jones
xxxxxx@ni.com
Join Date: 19 Mar 2012
Posts To This List: 38
Driver Signing Practical Info

Thanks for all your work, Peter. This is very useful information.
  Message 38 of 259  
24 Jul 15 21:26
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

My pleasure folks. You know you can count on OSR to get you the info you need. Peter OSR @OSRDrivers
  Message 39 of 259  
24 Jul 15 21:51
mm
xxxxxx@gmail.com
Join Date: 24 May 2010
Posts To This List: 967
Driver Signing Practical Info

Hell yes mm On Jul 24, 2015 6:27 PM, <xxxxx@osr.com> wrote: > My pleasure folks. > > You know you can count on OSR to get you the info you need. > > Peter > OSR > @OSRDrivers > > > --- <...excess quoted lines suppressed...> --
  Message 40 of 259  
26 Jul 15 20:14
Jeff Pages
xxxxxx@sonifex.com.au
Join Date: 21 Jul 2015
Posts To This List: 20
Driver Signing Practical Info

Many thanks Peter for getting those answers, though it's disappointing to see that Microsoft have reneged on the original statement in their April 1 blog that the attestation portal would allow drivers to be signed for earlier versions in addition to 10. Looks like we're going to need a separate driver package for 10 and everything else, which is further complicated by Vista / Server 2008 not recognising EV certificates. Of greater concern is the logo certification requirement for Server vNext. Our products no longer fall within what Microsoft considers to be a "proper" audio device, as they don't have 3.5mm jacks with jack sensing and aren't, in fact can't be, based on the HD Audio architecture. Looks like anything that isn't a generic consumer-grade sound card will be excluded. We live in interesting times. Jeff
  Message 41 of 259  
26 Jul 15 21:40
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Hey Jeff, Yes, I thought the info about server requiring passing the WHQL tests was the biggest news in that interview, actually. You sure you have to logo as a Windows audio device? Given your products aren't "normal" consumer audio stuff, can you fit in another category? I bet you can work this issue... No way they intend to make it impossible for professional audio to be connected to Windows. That's just my feeling... I don't have any special knowledge in this regard... Peter OSR @OSRDrivers
  Message 42 of 259  
26 Jul 15 21:43
Jeff Pages
xxxxxx@sonifex.com.au
Join Date: 21 Jul 2015
Posts To This List: 20
Driver Signing Practical Info

Thanks Peter. I've just emailed sysdev at Microsoft with that very question, and will pass on their response. Jeff
  Message 43 of 259  
27 Jul 15 02:33
Jan Bottorff
xxxxxx@pmatrix.com
Join Date: 16 Apr 2013
Posts To This List: 377
Driver Signing Practical Info

Having worked on a a number of bleeding edge server technologies over the years, which initially didn’t have any matching WHQL category to get certified under (Infinband RDMA and FCOE come to mind), not being able to even load a driver unless it passes WHQL certification seems like a way to assure Windows will get left behind by vendors of interesting new technology. Jan On 7/26/15, 6:39 PM, "xxxxx@lists.osr.com on behalf of xxxxx@osr.com" <xxxxx@lists.osr.com on behalf of xxxxx@osr.com> wrote: >Yes, I thought the info about server requiring passing the WHQL tests was the biggest news in that interview, actually. >
  Message 44 of 259  
27 Jul 15 08:25
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> I've just emailed sysdev at Microsoft with that very question, and will pass on their response </quote> Please DO pass on what they say. Plus, do your own investigation. Read the WHQL requirement carefully and interpret them truthfully, but in the best possible way for your product. Remember: YOU run the tests and send-in the results. I'm not saying to lie. But it's like the tax laws. There's absolutely nothing wrong with working the rules to the best of your advantage. One thing people at smaller vendors typically fail to take into account is that what gets signed is ultimately a matter for negotiation. I'll tell you a story: There is a very large vendor (who shall remain nameless) who had a driver that violated an extremely fundamental policy rule for its category of device. They knew it and Microsoft new it, and the violation was absolutely intentional by design (I know all this to be fact, it's not speculation). Microsoft WHQL'ed that driver for YEARS... like ten years... as a result of negotiation. The result was not bad for the community in any way, not bad for interoperability, not bad for Windows, not bad for the vendor, not bad for for Microsoft. So it was a win-win for everyone involved. But OTHER people? THEY had to follow the rules. Unless they made their OWN deal. The WHQL process has a built-in waiver system for precisely this reason. Smaller vendors need to work this system. It's a PITA, and can require a lot of person-to-person dickering... but there's always a path forward. <quote> initially didn?t have any matching WHQL category to get certified under </quote> I'm not in favor of what they're doing for server, not in any way. But don't forget that there's always "unclassified"... which is a pretty reasonable set of tests (if any of these tests can be termed "reasonable"). What scares me is that the WHQL tests (arrrgh... we're supposed to say the "Windows Lab Kit" Compatibility Tests now, aren't we...) are a mixture of basic correctness tests and policy-based tests. Some of the policy-based tests are more of a "we think this is best practice for device" type of thing, and preventing drivers loading based on their hardware's lack of adherence to what one vendor considers "best practice" seems to be... well... awfully extreme. For example, PCIe devices for server *must* support AER, though it is optional in the Express spec and several of the available FPGA cores don't support it. Sure, supporting AER is good. But refusing to load drivers for devices that don't support AER seems to me to be a really bad policy. How about all those devices that were built before AER was required? Peter OSR @OSRDrivers
  Message 45 of 259  
27 Jul 15 09:17
Chris Read
xxxxxx@clrassociates.co.uk
Join Date:
Posts To This List: 12
Driver Signing Practical Info

"there's always unclassified" It would be interesting to know if Microsoft would accept a device tested under "unclassified" for a signature valid on server. I mainly work on PCIExpress devices, targeted at the ISM market, for which there are no appropriate device specific Microsoft tests: it's far too specialist. Best regards Chris Read
  Message 46 of 259  
27 Jul 15 09:58
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

> I have some practical questions about the Windows 10 driver signing thing, for those of > you who have already been through it. Well, I don't care about driver signing, for the understandable reasons, but what makes me worried is SecureBoot in Windows10 http://arstechnica.com/information-technology/2015/03/windows-10-to-make-the-secu re-boot-alt-os-lock-out-a-reality/ Does someone have any AUTHORITATIVE information on whether a switch to allow Secure Boot to be turned off is still mandatory under Windows10 Anton Bassov
  Message 47 of 259  
27 Jul 15 10:16
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 2103
Driver Signing Practical Info

Why should Microsoft hardware requirements mandate that the switch must exist? Their interest is to require secure boot exist not that it not exist. Want to run Linux on your shiny new Dell server? I bet that will be very much supported by Dell because they will have the option in the firmware. Want to do the same on a SurfacePro? Well geez, really? FUD cheers Dave Cattley Sent from my Windows Phone ________________________________ From: xxxxx@hotmail.com<mailto:xxxxx@hotmail.com> Sent: ???7/???27/???2015 9:57 AM To: Windows System Software Devs Interest List<mailto:xxxxx@lists.osr.com> Subject: RE:[ntdev] Driver Signing Practical Info > I have some practical questions about the Windows 10 driver signing thing=2C for those of > you who have already been through it. Well, I don't care about driver signing, for the understandable reasons=2C but what makes me worried is SecureBoot in Windows10 http://arstechnica.com/information-technology/2015/03/windows-10-to-make-the-secu re-boot-alt-os-lock-out-a-reality/ Does someone have any AUTHORITATIVE information on whether a switch to allow Secure Boot to be turned off is still mandatory under Windows10 Anton Bassov --- 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 --
  Message 48 of 259  
27 Jul 15 10:35
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

> Why should Microsoft hardware requirements mandate that the switch must exist? > Their interest is to require secure boot exist not that it not exist. Whatever their interest may be like, under Windows8 this switch is mandatory. The question is whether it is going to change in Windows10.... >Want to run Linux on your shiny new Dell server? I bet that will be very much supported > by Dell because they will have the option in the firmware. Want to do the same on > a SurfacePro? Well geez, really? My main concern as all about the medium-and-higher-end laptops(Asus,Acer,Sony,DEll,HP, etc). Anton Bassov
  Message 49 of 259  
27 Jul 15 10:46
Gregory G. Dyess
xxxxxx@pdq.net
Join Date:
Posts To This List: 353
Driver Signing Practical Info

I'll have to respectfully disagree, Dave. Since Microsoft is creating the requirement for virtually all PC hardware to include UEFI (and its successors), they should also mandate the OWNER of the hardware be allowed to turn it off in order to run other OS software (or even run bare metal as is the case in embedded systems). I'm not one to give into conspiracy theories, but in this case it sure appears to be an attempt to force migration to Windows 10 and total lock-in to MS after that. Look at it this way: 1. A hardware vendor will not be able to effectively sell PCs without that MS Logo just by sheer market size enjoyed by MS. You can't lock out 80%-90% of all hardware sales by not getting that Windows Logo. Therefore, ALL hardware will include this feature. 2. Once older hardware is no longer available that will run Windows 7 (or accept Linux or...), people and companies will be forced to "upgrade" to Windows 1 or later. 3. Reports I've read (could be wrong) have indicated Windows Updates will no longer be a nuisance to avoid, but will be REQUIRED for all but the largest of customers. Again, MS is forcing people into migrating to the newest OS. It's a good plan for MS as they can drop costly support for older OS versions much quicker. I think this could run afoul of regulators in several countries, just as the original UEFI did before the options to disable it. The Surface Pro isn't a good example in that it fits under the Mobile category, not general PC. Mobile (non-PC) devices have always been vendor-locked. That trend is changing somewhat with the popularity of Android-based phones, availability of the entire source code and even vendor-supplied image modification instructions from some of the largest vendors. Please, this is NOT a flame-bait. I consult on both Windows Embedded and Android (embedded Linux) and find pros and cons in both. Neither is superior to the other for all things. It depends upon your needs. In the case of mandatory secure boot, MS wins, users lose. Greg --- xxxxx@msn.com wrote: From: Dave Cattley <xxxxx@msn.com> To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Subject: RE: [ntdev] Driver Signing Practical Info Date: Mon, 27 Jul 2015 10:15:42 -0400 Why should Microsoft hardware requirements mandate that the switch must exist? Their interest is to require secure boot exist not that it not exist. Want to run Linux on your shiny new Dell server? I bet that will be very much supported by Dell because they will have the option in the firmware. Want to do the same on a SurfacePro? Well geez, really? FUD cheers Dave Cattley Sent from my Windows Phone ________________________________ From: xxxxx@hotmail.com<mailto:xxxxx@hotmail.com> Sent: ‎7/‎27/‎2015 9:57 AM To: Windows System Software Devs Interest List<mailto:xxxxx@lists.osr.com> Subject: RE:[ntdev] Driver Signing Practical Info > I have some practical questions about the Windows 10 driver signing thing, for those of > you who have already been through it. Well, I don't care about driver signing, for the understandable reasons, but what makes me worried is SecureBoot in Windows10 http://arstechnica.com/information-technology/2015/03/windows-10-to-make-the-secu re-boot-alt-os-lock-out-a-reality/ Does someone have any AUTHORITATIVE information on whether a switch to allow Secure Boot to be turned off is still mandatory under Windows10 Anton Bassov --- 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 --- 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
  Message 50 of 259  
27 Jul 15 11:02
Don Burn
xxxxxx@windrvr.com
Join Date: 23 Feb 2011
Posts To This List: 1324
Driver Signing Practical Info

On the UEFI, I think most of the vendors will want to support Windows 7 = for a while, just because of the established base is so large. IT shops = are pretty conservative in many cases, and Windows 7 is likely to be = around for a long time. On the Windows Updates, there is a way to = block them see the article = http://www.zdnet.com/article/microsoft-releases-tool-to-hide-or-block-unw= anted-windows-10-updates/=20 Don Burn=20 Windows Driver Consulting Website: http://www.windrvr.com=20 -----Original Message----- From: xxxxx@lists.osr.com = [mailto:xxxxx@lists.osr.com] On Behalf Of Gregory G Dyess Sent: Monday, July 27, 2015 10:46 AM To: Windows System Software Devs Interest List Cc: xxxxx@lists.osr.com Subject: RE: [ntdev] Driver Signing Practical Info I'll have to respectfully disagree, Dave. Since Microsoft is creating = the requirement for virtually all PC hardware to include UEFI (and its = successors), they should also mandate the OWNER of the hardware be = allowed to turn it off in order to run other OS software (or even run = bare metal as is the case in embedded systems). I'm not one to give into conspiracy theories, but in this case it sure = appears to be an attempt to force migration to Windows 10 and total = lock-in to MS after that. =20 Look at it this way: 1. A hardware vendor will not be able to effectively sell PCs without = that MS Logo just by sheer market size enjoyed by MS. You can't lock = out 80%-90% of all hardware sales by not getting that Windows Logo. = Therefore, ALL hardware will include this feature. 2. Once older hardware is no longer available that will run Windows 7 = (or accept Linux or...), people and companies will be forced to = "upgrade" to Windows 1 or later. 3. Reports I've read (could be wrong) have indicated Windows Updates = will no longer be a nuisance to avoid, but will be REQUIRED for all but = the largest of customers. Again, MS is forcing people into migrating to = the newest OS. It's a good plan for MS as they can drop costly support = for older OS versions much quicker. I think this could run afoul of regulators in several countries, just as = the original UEFI did before the options to disable it. The Surface Pro isn't a good example in that it fits under the Mobile = category, not general PC. Mobile (non-PC) devices have always been = vendor-locked. That trend is changing somewhat with the popularity of = Android-based phones, availability of the entire source code and even = vendor-supplied image modification instructions from some of the largest = vendors. =20 Please, this is NOT a flame-bait. I consult on both Windows Embedded = and Android (embedded Linux) and find pros and cons in both. Neither is = superior to the other for all things. It depends upon your needs. In = the case of mandatory secure boot, MS wins, users lose. Greg --- xxxxx@msn.com wrote: From: Dave Cattley <xxxxx@msn.com> To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Subject: RE: [ntdev] Driver Signing Practical Info Date: Mon, 27 Jul 2015 10:15:42 -0400 Why should Microsoft hardware requirements mandate that the switch must = exist? Their interest is to require secure boot exist not that it not = exist. Want to run Linux on your shiny new Dell server? I bet that will be very = much supported by Dell because they will have the option in the = firmware. Want to do the same on a SurfacePro? Well geez, really? FUD cheers Dave Cattley Sent from my Windows Phone ________________________________ From: xxxxx@hotmail.com<mailto:xxxxx@hotmail.com> Sent: =E2=80=8E7/=E2=80=8E27/=E2=80=8E2015 9:57 AM To: Windows System Software Devs Interest = List<mailto:xxxxx@lists.osr.com> Subject: RE:[ntdev] Driver Signing Practical Info > I have some practical questions about the Windows 10 driver signing = thing, for those of > you who have already been through it. Well, I don't care about driver signing, for the understandable reasons, = but what makes me worried is SecureBoot in Windows10 http://arstechnica.com/information-technology/2015/03/windows-10-to-make-= the-secure-boot-alt-os-lock-out-a-reality/ Does someone have any AUTHORITATIVE information on whether a switch to = allow Secure Boot to be turned off is still mandatory under Windows10 Anton Bassov --- NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=3Dntdev 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=3DListServer --- NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=3Dntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit:=20 http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at = http://www.osronline.com/page.cfm?name=3DListServer --- NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=3Dntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit:=20 http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at = http://www.osronline.com/page.cfm?name=3DListServer
  Message 51 of 259  
27 Jul 15 11:04
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> It would be interesting to know if Microsoft would accept a device tested under "unclassified" for a signature valid on server. </quote> They always have in the past... I can't imagine they wouldn't. There's just no possible way for them to create categories for every potential device you would want in a server. For example: I worked on a very cool hardware solution for *very closely* synchronizing time among multiple servers. That's the type of device that's very obviously unclassifiable. Peter OSR @OSRDrivers
  Message 52 of 259  
27 Jul 15 11:17
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

When I read "Does anybody have authoritative information about..." and the information being requested is public, I often wonder why the person asking doesn't just go and read the Windows Requirements, since they're curious, and post the answer here for the benefit of the community. GIYF. For Windows 10 Mobile and Desktop, support for UEFI Secure Boot is *required* for Win10 ?Logo? In terms of the ability to disable Secure Boot: <https://msdn.microsoft.com/library/windows/hardware/dn915086(v=vs.85).aspx#_#3.0 _-_minimum_hardware_requirements_for_windows_10_for_desktop_editions> <quote> 6.8 UEFI and Secure Boot Windows 10 for desktop editions and Windows 10 Mobile and Windows 10 IoT Core must boot into UEFI mode by default and ship with UEFI Secure Boot enabled. System firmware must be compliant with the UEFI Specification Version 2.3.1 or higher. OEM systems for special purpose commercial systems, build to order, and customer systems with a custom image are not required to ship with UEFI Secure Boot enabled. Windows 10 for desktop editions and Windows 10 IoT Core systems can optionally support the ability to disable Secure Boot via firmware setup. Windows 10 Mobile systems must not implement the ability to disable Secure Boot. Windows 10 for desktop editions and Windows 10 Mobile systems must implement measurements into PCR [7]. Note No systems should allow programmatic disabling of Secure Boot during boot services or after exiting EFI boot services. </quote> Just look it up, people. It's not a mystery. And everyone else is just as busy as you are. Peter OSR @OSRDrivers
  Message 53 of 259  
27 Jul 15 11:47
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

> A hardware vendor will not be able to effectively sell PCs without that MS Logo just by > sheer market size enjoyed by MS. You can't lock out 80%-90% of all hardware sales by > not getting that Windows Logo. Actually, the last time I checked laptops in the store was something around a year ago or so. What amazed me was noticing that virtually NONE of the laptops on display had Windows logo - the only thing that I saw was a store-provided poster saying "Windows8 included", but no Windows logos, no "Designed for Windows" posters/stickers,etc. To make it even more interersting, some machines were nothing more than just pieces of bare hardware with no OS pre-installed. The whole thing was reminiscent of early 2000s and looked totally different from the way it had looked just 3-4 years before (i.e 2010-2011) when evey laptop on display was proudly displaying (no pun intended) "Windows 7 " logo on it. I just wonder if the whole thing may be somehow related to Secure Boot and UEFI..... Anton Bassov
  Message 54 of 259  
27 Jul 15 11:57
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

<quote> When I read "Does anybody have authoritative information about..." and the information being requested is public, I often wonder why the person asking doesn't just go and read the Windows Requirements, since they're curious, and post the answer here for the benefit of the community. GIYF. </quote> Simply because the article that I had referred to was, in turn, referring EXACTLY to the docs that you quote, and saying that this info was not yet a final one and a subject to change...... Anton Bassov
  Message 55 of 259  
27 Jul 15 12:13
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> Simply because the article that I had referred to was... saying that this info was not yet a final one and a subject to change. </quote> Sloppy thinking resulting in sloppy journalism. Everything is subject to change. It's called entropy. <quote> A hardware vendor will not be able to effectively sell PCs without that MS Logo just by sheer market size enjoyed by MS. </quote> Sigh. The reason OEMs insist on the "logo" (or whatever it's called now) isn't because people want it (for the most part... some corporate customers DO in fact require the logo as a simple measure of "goodness"). It's because if the OEM sells a Logo'ed system, they get a discount on the OS license from MSFT. It's all economics. Peter OSR @OSRDrivers
  Message 56 of 259  
27 Jul 15 12:51
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

<ironical mode> > Everything is subject to change. Really? Even "interface contracts" like "supported" API? > It's called entropy. Actually, the term "entropy" happens to refer to the degree of disorder in a system. I guess you should check https://en.wikipedia.org/wiki/Entropy (feel free to dismiss it as a piece of "sloppy journalism") before using the terminology that you don't really seem to understand.... </ironical mode> > It's because if the OEM sells a Logo'ed system, they get a discount on the OS > license from MSFT. .....which amounts to unfair market practice, abuse of dominant position,etc... Anton Bassov
  Message 57 of 259  
27 Jul 15 15:09
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> > It's called entropy. Actually, the term "entropy" happens to refer to the degree of disorder in a system. I guess you should check https://en.wikipedia.org/wiki/Entropy (feel free to dismiss it as a piece of "sloppy journalism") before using the terminology that you don't really seem to understand.... </quote> Oh, citing Wikipedia! You ARE a scholar. Actually, you should check your attitude, your English usage, and your definitions, before you mouth off to the list owner. As usual, you've missed the point of my (rather clever, I though) post... and concentrated on the trees instead of the forest. The term entropy is most often used in English as shorthand for the process of "all things" eventually trending toward degradation or disorder. It comes from the measure of *unavailable* energy in a thermodynamic system. The unavailable energy in the system is considered to be a measure of that system's lack of "order." Hence, "everything is subject to change" because in the end, everything in the world tends to disorder. Breathing increases entropy, after all. So, you know, I think I'm good without Wikipedia. I advise you to take the rest of the day off from posting here. Peter OSR @OSRDrivers
  Message 58 of 259  
27 Jul 15 22:00
James Bellinger
xxxxxx@gmail.com
Join Date: 29 Nov 2011
Posts To This List: 46
Driver Signing Practical Info

On 7/27/2015 10:15 AM, Dave Cattley wrote: > Why should Microsoft hardware requirements mandate that the switch > must exist? Their interest is to require secure boot exist not that it > not exist. > > Want to run Linux on your shiny new Dell server? I bet that will be > very much supported by Dell because they will have the option in the > firmware. > > Want to do the same on a SurfacePro? Well geez, really? > <...excess quoted lines suppressed...> Microsoft introduced the whole concept. If we are only talking purely about interest, their *interest* is that nothing but Windows can run, however they can get to that end. Want to do the same on a Surface Pro? It's a laptop. Why *not*? The only honest argument I can think of is lock-in. James --
  Message 59 of 259  
28 Jul 15 02:18
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

> Oh, citing Wikipedia! You ARE a scholar. Actually, I am just a "regular bloke"who was brought up to believe that trying to sound unnecessarily "clever" and "educated" by using scientific terminology may be indicator of anything but "high intelligence" that the person in question purports to show. In fact, in most cases it shows exactly the opposite. However, if one is just desperate to use scientific terminilogy they should at least make sure that they use it properly in order to avoid making complete fools of themselves. The funniest thing is that, in actuality, they rarely use this "clever" terminology properly. As an example, few years ago someone whose name rhymes with "Jim Floberts" was speaking about "six sigma average" in this NG, referring to 99% of cases. Sigma is a statistical term that is used for standard deviation. For example, a value may differ from the sample average (mean) by more than 3 deviations, effectively falling outside of six-sigma range, i.e. 3 deviations in each direction that covers more than 99% of the cases. However, the phrase "six sigma average" in itself is nothing more than just a meaningless word salad,albeit a "clever-sounding" one. Your use of the term "entropy" in this context falls in the same class as "six sigma average". More on it below. > Actually, you should check your attitude, your English usage, and your definitions, OK, let me do it http://www.merriam-webster.com/dictionary/entropy <quote> Definition of ENTROPY 1 : a measure of the unavailable energy in a closed thermodynamic system that is also usually considered to be a measure of the system's disorder, that is a property of the system's state, and that varies directly with any reversible change in heat in the system and inversely with the temperature of the system; broadly : the degree of disorder or uncertainty in a system 2 a : the degradation of the matter and energy in the universe to an ultimate state of inert uniformity b : a process of degradation or running down or a trend to disorder </quote> > The term entropy is most often used in English as shorthand for the process > of "all things" eventually trending toward degradation or disorder. The above quotation strongly suggests that this term simply does not and cannot have ANY usage in a "regular" English language - this is a scientific term that originates in thermodynamics and is simply unfamiliar to an "average Joe". In fact, even some textbooks admit that "entropy"happens to be not the easiest term to explain. This is why I referred you to Wikipedia that generally defines this term as a "degree of disorder". It may have different meanings in different contexts, depending on what the term "disorder" means in a given context. For example, due to the nature of our occupation, we are most likely to encounter this term in context of information theory, which defines it as a measure of unpredictability of information content, so that it may be used as an expected value (average) of the information contained in each message received (i.e Shannon entropy). However, the way you used it here is reminiscent of "six sigma average" ..... > before you mouth off to the list owner. I don''t "mouth off to the list owner." - I just politely pointed out to the list owner that unnecessary (and wrong) use of scientific terminology makes him sound in a way that happens to be exactly the opposite of the one he purports to sound....... Anton Bassov
  Message 60 of 259  
28 Jul 15 22:02
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 2103
Driver Signing Practical Info

Mr. Bellinger & Mr. Dyess I appreciate your perspectives. My point was really to just note that by removing a requirement (or relaxing one) MSFT was just simply enabling more =E2??freedom??? in the market. Had they mandated that the Secure Boot Disable option be removed, that would have been a whole different thing. Instead they just said (or propose to say) it is =E2??optional??? (except for mobile platforms). This seems to me to be completely consistent with the downgrade rights available for Windows licensing. And to our gracious host???s observation that MSFT discounts OEM licensing to manufacturers that get the logo, well, hey, that is business. (I don???t know that this is true but it seems reasonable and likely and PGV is not likely to be wrong on this point). Again my reaction is ???so what???? I want to acknowledge Mr. Bassov???s restrained reply by saying that I think we can reasonably expect high-end laptop manufacturers to do precisely nothing that they are not compelled to do. And given that they are shipping firmware that permits disabling secure boot they will more than likely continue to do so until the conspiracy theorists are proven correct and MSFT mandates that secure boot is required on all platforms. What I find interesting is the hoopla. This is a relaxation of restriction. The OEM is ???free??? to choose what type of market then pursue and the customer is ???free??? to choose what sort of OEM platform they will source for their application. I can definitely imagine a market for PC endpoints that does not permit relaxation of the secure boot requirement and now that market is enabled and OEMs are free to service it with logo compliant systems. And I can of course see that there still exists a [healthy] market for systems that permit the choice and I expect OEMs to continue to service that market. Let the market do what it does. Sort out what matters. Over time. Cheers all, Dave Cattley From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Bellinger Sent: Monday, July 27, 2015 10:00 PM To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: Re: [ntdev] Driver Signing Practical Info On 7/27/2015 10:15 AM, Dave Cattley wrote: Why should Microsoft hardware requirements mandate that the switch must exist? Their interest is to require secure boot exist not that it not exist. Want to run Linux on your shiny new Dell server? I bet that will be very much supported by Dell because they will have the option in the firmware. Want to do the same on a SurfacePro? Well geez, really? FUD cheers Dave Cattley Microsoft introduced the whole concept. If we are only talking purely about interest, their *interest* is that nothing but Windows can run, however they can get to that end. Want to do the same on a Surface Pro? It's a laptop. Why *not*? The only honest argument I can think of is lock-in. James --- 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 --
  Message 61 of 259  
29 Jul 15 01:56
Advance J
xxxxxx@hotmail.com
Join Date: 25 Jun 2013
Posts To This List: 29
Driver Signing Practical Info

From all above discussions, can we confirm that : 1. There is still a way to install&load KMCS drivers on Windows 10 client (desktop) version, which MS call that Configurable Code Integrity. 2. WHQL driver signing is enforced on Server version, and seems they will not change their mind for this restriction. 3.Drivers signed by EV certificate will not be recognized on older Windows platforms like Windows Vista (but Windows 7 can still support). Please give a clear answer, thanks very much !
  Message 62 of 259  
29 Jul 15 02:06
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

> My point was really to just note that by removing a requirement (or relaxing one) MSFT > was just simply enabling more =E2??freedom??? in the market. You seem to have a prety peculiar understanding of the concepts of "freedom"and "market", Mr.Cattley. To be honest, I would normally expect such "definitions" from the likes of Mr.Kyler. Anyway, I digress..... > Had they mandated that the Secure Boot Disable option be removed, that would have > been a whole different thing. Well, they are not THAT stupid, are they - they obviously DO realise that such a move would put them in legal trouble and result in hefty penalties in various jurusdictions(particularly in the EU).Therefore, they prefer to go "indirect way".. > And to our gracious host???s observation that MSFT discounts OEM licensing to > manufacturers that get the logo, well, hey, that is business. ........ > I think we can reasonably expect high-end laptop manufacturers to do precisely nothing > that they are not compelled to do. If you look at your own statement above you will (hopefully) realize that they don't have to be "compelled" to do things - instead, they may be "enticed" to do them by the offers of larger discountsfrom MSFT.... > the customer is ???free??? to choose what sort of OEM platform they will source > for their application. .....apart from the fact that they are not. For example, I happen to be a kind of customer who does not want to have any Windows version pre- installed on his machine altogether due to the natural "MSFT allergy". Although I would not normally speak for other people in this particular case I can assure you there are quite a few customers like me worldwide. However, practically all the machines that I see have this "MSFT puke" pre-installed by OEMs. Any suggestions, Mr.Cattley? Anton Bassov
  Message 63 of 259  
29 Jul 15 08:23
ntdev member 158647
xxxxxx@gmail.com
Join Date:
Posts To This List: 10
Driver Signing Practical Info

<quote> From all above discussions, can we confirm that : 1. There is still a way to install&load KMCS drivers on Windows 10 client (desktop) version, which MS call that Configurable Code Integrity. 2. WHQL driver signing is enforced on Server version, and seems they will not change their mind for this restriction. 3.Drivers signed by EV certificate will not be recognized on older Windows platforms like Windows Vista (but Windows 7 can still support). </quote> I can only help with number 3. I did not try Vista, but 32-bit versions of XP and 7 worked fine with an EV-signed driver. 64-bit Windows 7 will work as long as KB3033929 is installed. Matt
  Message 64 of 259  
29 Jul 15 09:59
Advance J
xxxxxx@hotmail.com
Join Date: 25 Jun 2013
Posts To This List: 29
Driver Signing Practical Info

Thank you for sharing the test result . Today I tested our virtual device driver in Windows 10 x64 version, the driver got install & load properly without change any settings. It's definitely a good news for developers that don't wanna buy an EV certificate or don't wanna mix sysdev portal signing into their deployment process. Now I am confused about the actual requirement, why MS said it's ENFORCED in RTM, but still CONFIGURABLE, even DISABLED by default ?
  Message 65 of 259  
29 Jul 15 10:08
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Excellent points, all, Mr. Cattley. I agree 100%. Mr. "Advance J" -- I'm sorry, but I'm not certain I understand your questions. I'll try to answer, and you can post back if I don't give you an answer you need. <quote> 1. There is still a way to install&load KMCS drivers on Windows 10 client (desktop) version, which MS call that Configurable Code Integrity. </quote> I have no idea what "which MS call that Configurable Code Integrity" means in this sentence. But I can tell you that if you cross-sign drivers using a proper Class 3 Code Signing Certificate that was issued prior to Windows 10 RTM, the policy is that your drivers will load on Windows 10. <quote> 2. WHQL driver signing is enforced on Server version, and seems they will not change their mind for this restriction. </quote> Assuming you mean that "In order to load drivers on Windows V.Next Server, the drivers will need to pass the HLK Compatibility tests and signed by Microsoft" the answer APPEARS to be "Yes, this is true." The first non-NDA statement from MSFT on this topic that I am aware of is from Mr. Murray in my Q&A with him. As far as whether "seems they will not change their mind for this restriction" there is a lot of time between now and Server V.Next GA. I strongly *suspect* there will be some sort of policy for legacy drivers and devices. Microsoft establishes these policies and announces them well in advance (under NDA) to allow an opportunity for stakeholders to provide feedback. To their credit, Microsoft can (and has) modified their policies based on that feedback. So, for example, if enough Server OEMs, Enterprise Licensees, key IHVs, and the like raise objections or articulate reasons the announced policy should be altered, that'll pretty certainly happen. Peter OSR @OSRDrivers
  Message 66 of 259  
29 Jul 15 13:00
Advance J
xxxxxx@hotmail.com
Join Date: 25 Jun 2013
Posts To This List: 29
Driver Signing Practical Info

Dear Mr. Peter, I'm sorry for my poor English, and thank you very much for the detailed answers, you are so kind to explain this useful information ! I was considered purchase an EV Certificate instead of renew my Class 3 Code Certificate but now I can just renew the old one.
  Message 67 of 259  
29 Jul 15 14:41
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@hotmail.com wrote: > Dear Mr. Peter, I'm sorry for my poor English, and thank you very much for the detailed answers, you are so kind to explain this useful information ! I was considered purchase an EV Certificate instead of renew my Class 3 Code Certificate but now I can just renew the old one. Actually, I don't think you can. Read Peter's statement: But I can tell you that if you cross-sign drivers using a proper Class 3 Code Signing Certificate that was issued prior to Windows 10 RTM, the policy is that your drivers will load on Windows 10. Windows 10 released today. If you renew your certificate now, it will not qualify. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 68 of 259  
29 Jul 15 15:04
ntdev member 158647
xxxxxx@gmail.com
Join Date:
Posts To This List: 10
Driver Signing Practical Info

<quote> Actually, I don't think you can. Read Peter's statement: But I can tell you that if you cross-sign drivers using a proper Class 3 Code Signing Certificate that was issued prior to Windows 10 RTM, the policy is that your drivers will load on Windows 10. Windows 10 released today. If you renew your certificate now, it will not qualify. </quote> The only caveat being that they will still work if the system you are installing on either doesn't support secure boot or has it disabled. Not that this is something to aim for or force on your users/customers, but it is an interesting piece of information that came out of Peter's interview with James Murray. Matt
  Message 69 of 259  
29 Jul 15 23:09
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 2103
Driver Signing Practical Info

> instead, they may be "enticed" to do them by the offers of larger discounts from MSFT.... While I agree in principle that this can (and does) happen, in the singular case brought up in this thread the OEM can do exactly nothing (e.g. leave the firmware control to disable secure boot as available) and still be Logo compliant. I suspect that absent any compelling reason from the market or enticement from Redmond that "don't fix what is not broken" will prevail for the vast majority of systems. > However, practically all the machines that I see have this "MSFT puke" pre-installed by OEMs. Any suggestions, Mr.Cattley? FWIW a quick search located at least a few OEMs (Acer for one) that ship systems with Linux pre-installed. I'm sure if you want to buy in high enough volume that most any system VAR will preconfigure whatever you want. They probably would peel off the Logo sticker too if that was desired. If the market is large and underserved then maybe this is an opportunity for you to service it. If the market is not worth pursuing on economic grounds then you are starting to sound like an old dog laying on a nail that causes it just enough pain to howl but not enough pain to get up and move. Regards, Dave Cattley
  Message 70 of 259  
30 Jul 15 02:27
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

<quote> FWIW a quick search located at least a few OEMs (Acer for one) that ship systems with Linux pre-installed. I'm sure if you want to buy in high enough volume that most any system VAR will preconfigure whatever you want. They probably would peel off the Logo sticker too if that was desired. </quote> However, I don't "buy in high enough volume", and I don't want ANY pre-configuaration (including Linux) either. The only thing that I want is the ability to walk into a store and to buy a "clean" laptop. I don't want any pre-installed Windows on my machine because I happen to be Linux user, but I can easily imagine some "Windows 7 fanboy" who had purchased his RTM version of Windows 7, paid his $200 -300 (or whatever it costs) to MSFT, so that he does not need any OEM version on his machine either. Am I requesting something extraordinary, Mr.Cattley? <quote> If the market is large and underserved then maybe this is an opportunity for you to service it. If the market is not worth pursuing on economic grounds then you are starting to sound like an old dog laying on a nail that causes it just enough pain to howl but not enough pain to get up and move. </quote> .....and this is,again, the kind of an "argument" that I would normally expect from some simpleton like Mr.Kyler.... Anton Bassov
  Message 71 of 259  
30 Jul 15 12:55
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@hotmail.com wrote: > However, I don't "buy in high enough volume", and I don't want ANY pre-configuaration (including Linux) either. The only thing that I want is the ability to walk into a store and to buy a "clean" laptop. I don't want any pre-installed Windows on my machine because I happen to be Linux user, but I can easily imagine some "Windows 7 fanboy" who had purchased his RTM version of Windows 7, paid his $200 -300 (or whatever it costs) to MSFT, so that he does not need any OEM version on his machine either. Am I requesting something extraordinary, Mr.Cattley? Using a traditional definition of "extraordinary", yes, you absolutely are. There are about 300 million laptops and desktops sold every year. Of that number, I would hazard a wild guess that perhaps 300 of those sales encounter the scenario you describe. That definitely qualifies as "extraordinary". -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 72 of 259  
30 Jul 15 13:04
Don Burn
xxxxxx@windrvr.com
Join Date: 23 Feb 2011
Posts To This List: 1324
Driver Signing Practical Info

Tim, You need to qualify that, I know of a lot of laptops and desktops for medium to large scale business that are sold without software (a lot more than 300). I am not sure if you 300 million number is based on all PC sales, or consumer/small business PC sales. In the consumer/small business market it is truly the case you are unlikely to find a clean laptop. Anton, if you want a clean machine look at the PC manufacturers websites for Business systems, of course they cost more than the consumer models, so you may not save anything. Don Burn Windows Driver Consulting Website: http://www.windrvr.com -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts Sent: Thursday, July 30, 2015 12:54 PM To: Windows System Software Devs Interest List Subject: Re: [ntdev] Driver Signing Practical Info xxxxx@hotmail.com wrote: > However, I don't "buy in high enough volume", and I don't want ANY pre-configuaration (including Linux) either. The only thing that I want is the ability to walk into a store and to buy a "clean" laptop. I don't want any pre-installed Windows on my machine because I happen to be Linux user, but I can easily imagine some "Windows 7 fanboy" who had purchased his RTM version of Windows 7, paid his $200 -300 (or whatever it costs) to MSFT, so that he does not need any OEM version on his machine either. Am I requesting something extraordinary, Mr.Cattley? Using a traditional definition of "extraordinary", yes, you absolutely are. There are about 300 million laptops and desktops sold every year. Of that number, I would hazard a wild guess that perhaps 300 of those sales encounter the scenario you describe. That definitely qualifies as "extraordinary". -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc. --- 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
  Message 73 of 259  
30 Jul 15 13:35
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

> There are about 300 million laptops and desktops sold every year. Of that number, > I would hazard a wild guess that perhaps 300 of those sales encounter the scenario you describe. Oh, I see - now I know that, all in all, there are 300 Linux users and retail Windows license holders in the entire world combined...... Anton Bassov
  Message 74 of 259  
30 Jul 15 13:52
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

> Anton, if you want a clean machine look at the PC manufacturers websites for Business systems, But I don't need a "Business system" - once I buy it for myself I want a laptop with USB ports,a wireless card, webcam and other things that a "Business system" is more than likely to lack due to the potential security risks that these features may pose in a corporate environment.... Anton Bassov
  Message 75 of 259  
30 Jul 15 17:14
Chris Aseltine
xxxxxx@gmail.com
Join Date: 23 Sep 2006
Posts To This List: 1220
Driver Signing Practical Info

anton bassov wrote: > But I don't need a "Business system" - once I buy it > for myself I want a laptop with USB ports,a wireless > card, webcam and other things that a "Business system" > is more than likely to lack due to the potential security risks > that these features may pose in a corporate environment.... http://krebsonsecurity.com/wp-content/uploads/2015/07/fb-wifisense.png
  Message 76 of 259  
30 Jul 15 21:21
Jeff Pages
xxxxxx@sonifex.com.au
Join Date: 21 Jul 2015
Posts To This List: 20
Driver Signing Practical Info

I've had no reply to my email to sysdev on Monday, but I did perform an experiment this morning, creating a portal submission which included a cat file tagged for all 64-bit operating systems from Vista to 10. The portal submission all worked, but the signed cat file that came back is only tagged for 10 and won't install on any of the earlier systems. This confirms the most recent statement that the portal will only sign drivers for Windows 10, but contradicts what was in the blog post back in April. I guess they changed their minds. Jeff
  Message 77 of 259  
31 Jul 15 02:41
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

On Jul 30, 2015, at 6:21 PM, Jeff Pages <xxxxx@sonifex.com.au> wrote: > > The portal submission all worked, but the signed cat file that came back is > only tagged for 10 and won't install on any of the earlier systems. Was the CAT the only file that was signed? Not the SYS? That’s what I expect, but that represents a showstopper for non-PnP drivers. James mentioned this during his interview with Peter, but his suggested workaround (add a fake INF) doesn’t solve the problem at all. — Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 78 of 259  
31 Jul 15 08:11
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

It's complicated. The attestation signature program is limited to Win10 by design, according to Mr. Murray. If you pass the Win10 HLK tests, your package can be signed for Win10 AND down level... Again, according to Mr Murray. What type of submission did you create? Peter OSR @OSRDrivers
  Message 79 of 259  
31 Jul 15 16:06
Gabe Jones
xxxxxx@ni.com
Join Date: 19 Mar 2012
Posts To This List: 38
Driver Signing Practical Info

> Was the CAT the only file that was signed? Not the SYS? That?s what I expect, but that represents > a showstopper for non-PnP drivers. James mentioned this during his interview with Peter, but his > suggested workaround (add a fake INF) doesn?t solve the problem at all. We've tried both a PnP driver package and a non-PnP kernel service with a dummy INF. In both cases, we signed the .sys and the .cat with our existing (SHA1 cross-signing) cert before uploading. The returned driver package had both our old signature and the Microsoft signature on the .sys file. The .cat file had only a Microsoft signature. -- Gabe
  Message 80 of 259  
31 Jul 15 16:42
Jeff Pages
xxxxxx@sonifex.com.au
Join Date: 21 Jul 2015
Posts To This List: 20
Driver Signing Practical Info

> Was the CAT the only file that was signed? Not the SYS? I'll check when I'm back in the office on Monday, Tim. > The attestation signature program is limited to Win10 by design, according to Mr. Murray. > If you pass the Win10 HLK tests, your package can be signed for Win10 AND down level... Again, according to Mr Murray. > What type of submission did you create? It was an attestation package, Peter. I know Mr Murray said it's limited to Win10, but the April 1 blog said it was "simple" to use the portal to sign drivers for all platforms so I wanted to see which one was right. Jeff
  Message 81 of 259  
02 Aug 15 14:00
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

> http://krebsonsecurity.com/wp-content/uploads/2015/07/fb-wifisense.png "Monkey Boy" must be getting pretty nervous - MSFT's new manangement is about to do something he could not imagine even in his wildest dream. His best "achievement" was reducing MSFT market share in the world of mobile systems to laughable 3% out of thin air. MSFT's new management seems to be just desperate to take things to a basically new level and achieve the same result in the world of corporate desktops/laptops, i.e in the market that happens to be one of the last MSFT strongholds at the time. Let's face it - this "Wi-fi Sense"(or whatever they call it) seems to be just a dream of any Kevin Mitnick-style "hacker" (i.e. the one who mainly relies upon so-called "social engineering", rather than technical sophistication), as well as any rogue employee who wants to steal corporate data while enjoying an extra protection against any criminal/civil "repercussions"........ Anton Bassov
  Message 82 of 259  
02 Aug 15 16:32
Volodymyr M. Shcherbyna
xxxxxx@shcherbyna.com
Join Date: 07 Oct 2010
Posts To This List: 162
Driver Signing Practical Info

Hello everyone, It's been four days since the official release date of Windows 10 and I just checked - all of my wfp callout drivers (kmdf) as well as legacy ones (wdm) are still loading fine using the old way of signing (cross signing using signtool). I signed the drivers just now and they load fine. All Windows 10 machines are up-to date. I thought the 'sysdev portal signing' should be used also for non pnp drivers. No?
  Message 83 of 259  
02 Aug 15 18:22
Volodymyr M. Shcherbyna
xxxxxx@shcherbyna.com
Join Date: 07 Oct 2010
Posts To This List: 162
Driver Signing Practical Info

Just rechecked again the doc at https://www.osr.com/blog/2015/07/24/questions-answers-windows-10-driver-signing/ and I can see that it works for me because my certificate was issued prior to release of Windows 10. The following statement, however, is unclear: >> Cross-signing will continue to work, as long as the cross-signing certificate was issued prior to Windows 10 RTM (the cut off). The default state for this policy is turned on, but IT admins can choose to turn it off using a new feature in Windows 10 called configurable code integrity << What is the name of this option? Is there any documentation on how to test this?
  Message 84 of 259  
02 Aug 15 18:59
Jeff Pages
xxxxxx@sonifex.com.au
Join Date: 21 Jul 2015
Posts To This List: 20
Driver Signing Practical Info

>> Was the CAT the only file that was signed? Not the SYS? > I'll check when I'm back in the office on Monday, Tim. Interesting, the .sys file and my property page dll are also signed. Jeff
  Message 85 of 259  
02 Aug 15 22:27
Prokash Sinha
xxxxxx@garlic.com
Join Date: 23 Feb 2000
Posts To This List: 1063
Driver Signing Practical Info

I don=92t know who posted this link and what for ? this link asks to get info from some social media. If some remember that you indeed posted this link, could you please also = provide your social media login/passwd, so I can look ? Pro On Aug 2, 2015, at 10:59 AM, xxxxx@hotmail.com wrote: >> = http://krebsonsecurity.com/wp-content/uploads/2015/07/fb-wifisense.png >=20 >=20 > "Monkey Boy" must be getting pretty nervous - MSFT's new manangement = is about to do something he could not imagine even in his wildest = dream. His best "achievement" was reducing MSFT market share in the = world of mobile systems to laughable 3% out of thin air. MSFT's new = management seems to be just desperate to take things to a basically new = level and achieve the same result in the world of corporate = desktops/laptops, i.e in the market that happens to be one of the last = MSFT strongholds at the time. Let's face it - this "Wi-fi Sense"(or = whatever they call it) seems to be just a dream of any Kevin = Mitnick-style "hacker" (i.e. the one who mainly relies upon so-called = "social engineering", rather than technical sophistication), as well as = any rogue employee who wants to steal corporate data while enjoying an = extra protection against any criminal/civil "repercussions"........ >=20 >=20 >=20 > Anton Bassov=20 >=20 > --- > NTDEV is sponsored by OSR >=20 > Visit the list at: http://www.osronline.com/showlists.cfm?list=3Dntdev >=20 <...excess quoted lines suppressed...> http://www.osronline.com/page.cfm?name=3DListServer
  Message 86 of 259  
03 Aug 15 01:23
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

On Aug 2, 2015, at 3:58 PM, Jeff Pages <xxxxx@sonifex.com.au> wrote: > >>> Was the CAT the only file that was signed? Not the SYS? > >> I'll check when I'm back in the office on Monday, Tim. > > Interesting, the .sys file and my property page dll are also signed. That’s good news, I guess. It means that there is a working attestation path for non-PnP drivers. — Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 87 of 259  
03 Aug 15 03:35
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

> this link asks to get info from some social media. No, Pro, this link does not "ask to get info from some social media.".......... What it does is just displaying an image of a dialog box (or whatever they call it these days) presented to Windows10 users. If you click "OK", Windows will send an encrypted copy of your password to all your Facebook "friends" and Outlook contacts who happen to be physically close enough to access your wireless network (i.e up to 100m for 802.11) so that they can use it. Now imagine a system like that in a corporate environment. Seems to be just a crook's dream, don't you think - you click "OK" in the office and, once in a sudden, your accomplice with a laptop in a car parked outside has an access to your company's networks...... Anton Bassov
  Message 88 of 259  
03 Aug 15 03:41
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 10395
Driver Signing Practical Info

>easily imagine some "Windows 7 fanboy" who had purchased his RTM = version of Windows 7, paid=20 >his $200 -300 (or whatever it costs) to MSFT, so that he does not need = any OEM version on his=20 >machine either. Abnormal. What is not abnormal is to have a _pathetic Windows SKU_ pre-installed = by the vendor on the otherwise great laptop. In this case, paid SKU upgrade (especially pre-Win8 since that times = Windows Home was even more pathetic) is often performed. Technically it is as simple as re-activating Windows with another key. --=20 Maxim S. Shatskih Microsoft MVP on File System And Storage xxxxx@storagecraft.com http://www.storagecraft.com
  Message 89 of 259  
03 Aug 15 03:50
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 10395
Driver Signing Practical Info

> Now imagine a system like that in a corporate environment. Seems to be = just a crook's dream, don't=20 >you think - you click "OK" in the office and, once in a sudden, your = accomplice with a laptop in a car=20 >parked outside has an access to your company's networks...... The notion of public/private networks appeared as early as in Vista More so, the option you're speaking about was there in Windows Phone for = some time. Many, many things in Win10 are from Windows Phone. --=20 Maxim S. Shatskih Microsoft MVP on File System And Storage xxxxx@storagecraft.com http://www.storagecraft.com
  Message 90 of 259  
03 Aug 15 04:56
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

<quote> Abnormal. What is not abnormal is to have a _pathetic Windows SKU_ pre-installed by the vendor on the otherwise great laptop. In this case, paid SKU upgrade (especially pre-Win8 since that times Windows Home was even more pathetic) is often performed. Technically it is as simple as re-activating Windows with another key. </quote> Well, I mean reasonable people, Max (I really hope you can find some even among Windows users). It does not apply to a sheep that goes with the rest of the herd and thoughtelessly does absolutely everything that it is told to do by a shepherd, i.e by someone whom it finds in a position of authority in a given situation, be it a corporate entity, some dim pop would-be-star or politician. Someone like that is, indeed, going to do something that you have mentioned above simply because of being told to do so by MSFT. However, someone who is capable of thinking is going to think a bit,effectively realising that doing something that you have mentioned above is just plainly stupid This is why you will find PLENTY of XP, W2K (and probably even NT4) installations in corporate environments - after all, they are managed by those who are capable of thinking and would not pay money for "updates" and "upgrades" simply because of being told to do so by MSFT. > More so, the option you're speaking about was there in Windows Phone for some time. > Many, many things in Win10 are from Windows Phone. ...and now look at the statement that you seem to be arguing with <quote> "Monkey Boy" must be getting pretty nervous - MSFT's new manangement is about to do something he could not imagine even in his wildest dream. His best "achievement" was reducing MSFT market share in the world of mobile systems to laughable 3% out of thin air. MSFT's new management seems to be just desperate to take things to a basically new level and achieve the same result in the world of corporate desktops/laptops, i.e in the market that happens to be one of the last MSFT strongholds at the time. </quote> Indeed, they seem to be introducing features of Windows Phone (i.e the system that failed miserably, effectively losing the market almost completely) to the desktop OS, i.e the market that is still dominated by MSFT. Under these circumstances it would not be too unreasonable to expect more or less the same outcome in the desktop market as well, don't you think.... Anton Bassov
  Message 91 of 259  
03 Aug 15 10:55
Prokash Sinha
xxxxxx@garlic.com
Join Date: 23 Feb 2000
Posts To This List: 1063
Driver Signing Practical Info

Thanks for pointing Anton ! I just wanted to see what that link about, and I know it asked me to = share Facebook info. =97 Crazy :) Anyways =85 Pro On Aug 3, 2015, at 12:34 AM, xxxxx@hotmail.com wrote: >> this link asks to get info from some social media.=20 >=20 > No, Pro, this link does not "ask to get info from some social = media.".......... >=20 >=20 >=20 > What it does is just displaying an image of a dialog box (or whatever = they call it these days) presented to Windows10 users. If you click = "OK", Windows will send an encrypted copy of your password to all your = Facebook "friends" and Outlook contacts who happen to be physically = close enough to access your wireless network (i.e up to 100m for 802.11) = so that they can use it. >=20 >=20 > Now imagine a system like that in a corporate environment. Seems to be = just a crook's dream, don't you think - you click "OK" in the office = and, once in a sudden, your accomplice with a laptop in a car parked = outside has an access to your company's networks...... >=20 >=20 >=20 > Anton Bassov=20 >=20 > --- > NTDEV is sponsored by OSR >=20 > Visit the list at: http://www.osronline.com/showlists.cfm?list=3Dntdev >=20 <...excess quoted lines suppressed...> http://www.osronline.com/page.cfm?name=3DListServer
  Message 92 of 259  
03 Aug 15 14:58
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Anton... You're once again pointlessly ranting and off topic... Maybe you can find a Linux group where your spew will be appreciated? One way or the other, find another song to sing or sing your current one elsewhere, please. Mr. Sinha: Please don't feed the troll, it only makes him stronger and more determined. Peter OSR @OSRDrivers
  Message 93 of 259  
03 Aug 15 17:15
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4343
Driver Signing Practical Info

> One way or the other, find another song to sing Agreed - let me try the one that you are,apparently, going to appreciate <MSFT sycophant's anthem> God save our Microsoft Long live our Microsoft God save Microsoft Send them victorious Happy and glorious Long to reign over us God save Microsoft Cutler our God arise Crash NT enemies And make them fall Confound their politics Frustrate their knavish tricks On Thee our hopes we fix Cutler save us all From every latent foe From every Stallman's blow God save Microsoft </MSFT sycophant's anthem> The above "anthem" is just a idiomatic representation of something that certain posters (we don't really need to name them here, do we) "sing" all the time in this NG, going MILES away from the topic of the original discussion, and doing so on a regular basis. Furthermore, some of them consider themselves too "serious" to subscribe to NTTALK - instead, they prefer to pollute NTDEV with OT discussions. To make it even more interesting, some of them post literally in a machine-gun fashion, making 15-20 posts in a row, effectively turning the whole thread unreadable after making "3-4 sets of 15-20 reps each". You don't seem to have any objections to these posts/posters, do you. However, anyone who is critical of MSFT is immediately branded as a "troll", and any criticism is branded as ."pointless ranting", "spew" and "off topic". I DO realise that this is your list so that you are free to set any posting rules that you wish, so that you should take it all simply as a casual observation.... Anton Bassov
  Message 94 of 259  
03 Aug 15 17:37
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

>I DO realise that this is your list Excellent! Then you'll understand when I tell you that in order to limit your rants (and my personal annoyance) on my list, yet still allow you to enjoy my renowned hospitality, you are now on moderation. Congratulations! You are the first list member in the long and storied history of NTDEV to reach this lofty status. Peter OSR @OSRDrivers
  Message 95 of 259  
03 Aug 15 18:49
Christiaan Ghijselinck
xxxxxx@compaqnet.be
Join Date: 21 Mar 2002
Posts To This List: 476
Driver Signing Practical Info

Dear all , Something is still not clear to may ( may be because I an not so brilliant with interpretation of English texts ) . At the OSR blog conversation , "James" said : a.. We do support a transitional policy for folks that hopefully alleviates some of the pressure. Cross-signing will continue to work, as long as the cross-signing certificate was issued prior to Windows 10 RTM (the cut off). The default state for this policy is turned on, but IT admins can choose to turn it off using a new feature in Windows 10 called configurable code integrity. That's a good thing for folks to be aware of before making the decision to continue using their cross-signing certificates. This document gives a high-level of these changes. Now , I interprete this as there would be new cross-certificates released starting from the "cutt off" . The cross-certificates at https://msdn.microsoft.com/en-us/library/windows/hardware/dn170454%28v=vs.85%29.a spx are still the same as from months ago. I agree this sounds stupid , but can someone explain in simple english what James meant here. Personally I was persuaded that drivers signed ( and time-stamped ) before the cut-off will be accepted on Win 10 with Secure Boot enabled. Those time stamped after the cut-off would be rejected. It seems now that I am wrong about this. Regards , Christiaan --
  Message 96 of 259  
03 Aug 15 19:49
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

Christiaan Ghijselinck wrote: > > Something is still not clear to may ( may be because I an not so > brilliant with interpretation of English texts ) . At the OSR blog > conversation , "James" said : > > /a.. We do support a transitional policy for folks that hopefully > alleviates some of the pressure. Cross-signing will continue to > work, as long as the cross-signing certificate was issued prior to > Windows 10 RTM (the cut off). The default state for this policy > is turned on, but IT admins can choose to turn it off using a new <...excess quoted lines suppressed...> I think the confusion here is that he uses the phrase "cross-signing certificate" where I would have used the phrase "certificate that needs to be cross-signed". The important item is not the cross certificate, the important item is the original code-signing certificate. So, drivers that are signed and cross-signed in the traditional manner, using a code-signing certificate that was issued prior to the RTM date, will continue to work. No changes will be required. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 97 of 259  
03 Aug 15 21:43
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

I agree with Mr. Roberts. In context, this must be correct. While those are the exact words Mr. Murray used, I'm actually going to change his quote in the interview to make it more clear. There's exactly nothing to gain by having a quote that's literally correct, but confusing or unclear. Peter OSR @OSRDrivers
  Message 98 of 259  
04 Aug 15 03:11
Christiaan Ghijselinck
xxxxxx@compaqnet.be
Join Date: 21 Mar 2002
Posts To This List: 476
Driver Signing Practical Info

Thanks Tim and Peter. Really appreciated. Regards , Christiaan
  Message 99 of 259  
05 Aug 15 01:10
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 10395
Driver Signing Practical Info

>It does not apply to a sheep that goes with the rest of the herd and = thoughtelessly does absolutely=20 >everything that it is told to do by a shepherd Well, let's talk on shepherds and slaves :-) My very strong belief is that "rage against the machine" for the sake of = _rage itself_, as also _Ego boosting_ by such rage (which most = anti-establishment people do, in Linux fandom/Slashdot community also) - = it just plain a moronity. Sometimes the "shepherd" just knows the way which _works_ (not = _perfect_, but still _works_). Sometimes it does not demand anything = sufficient from you. Also note the 2 points: - a Jew in 1930ies Germany, lying (with forged documents provision) = about himself being an Aryan to the Reichs-official - is GOOD. Such a = thing is by no mean morally evil, it only deserves respect. And, I = personally extend this notion to rather many bureaucratic regulations of = the current governments, even if though they are not Nazis. You can = consider me as "anti-establishment" (though I'm not such) :-) - "a tame calf sucks from 2 mothers" - the Russian proverb. >something that you have mentioned above is just plainly stupid This is = why you will find PLENTY of >XP, W2K (and probably even NT4) = installations in corporate environments =20 Currently? in 2015? 100% false on NT4, which hardly ever survived even in embedded stuff = like kiosk boxes (NT4-based boxes just did not survive = physically/mechanically/electrically, being very old). 100% false on w2k too. In around 2010, it was not so false on w2k, but = in non-Western countries (Spanish-speaking America and Brazil, according = to my information). But in 2015 - w2k is gone. Also note that, even though many companies will not upgrade the OS on = their desktops just for the sake of upgrade, _no one in serious world = will deliberately install obsolete OS to the newly purchased PC_. So, the lifetime of obsolete Windows versions is limited by the = physical/mechanical/electrical (and moral, even though Moore's law does = not work anymore and 2008-era desktop is not this abysmal in 2015) = lifetime of the PCs themselves. > "Monkey Boy" must be getting pretty nervous - MSFT's new manangement = is about to do something=20 >he could not imagine even in his wildest dream. His best "achievement" = was reducing MSFT market=20 >share in the world of mobile systems to laughable 3% out of thin air.=20 This is absolutely a true, and I think this person will contribute - = together with that lady who was the CEO of the company making Barbie = dolls - to the list of "great managers who finally ruined their = businesses". Given the fact that WinPhone is so much technically superior to Android = - this is even more laughable. One of the major contributions to this moronity was, obviously, bad = business-wise attitude to hardware makers. Google suggested them with = better business/legal conditions, so they went with inferior Google's = OS. Timeline is also important. Android is 3 years older. > Indeed, they seem to be introducing features of Windows Phone (i.e the = system that failed=20 >miserably, effectively losing the market almost completely)=20 It failed not due to technical reasons, but due to business reasons = (MSFT's style of making relations with hardware vendors, for instance). Surface - as a single product - is not a failure at all. So are Nokias, = especially given their cheap price (Apple do not make devices this = cheap, and any Android phone for the same money will be a = slow-performance disaster). But... other HW vendors, one by one, turned their heads away from = WinRT/WinPhone. --=20 Maxim S. Shatskih Microsoft MVP on File System And Storage xxxxx@storagecraft.com http://www.storagecraft.com
  Message 100 of 259  
05 Aug 15 14:20
Vikram Parthasarathy
xxxxxx@ni.com
Join Date: 17 Jul 2015
Posts To This List: 14
Driver Signing Practical Info

Tim Roberts wrote: > I think the confusion here is that he uses the phrase "cross-signing > certificate" where I would have used the phrase "certificate that needs > to be cross-signed". The important item is not the cross certificate, > the important item is the original code-signing certificate. Are we confident that James Murray didn't actually mean "cross-signing certificate"? :) The msdn blog post also says "valid cross-signing certificate" http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver- signing-changes-in-windows-10.aspx
  Message 101 of 259  
05 Aug 15 18:52
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Regarding the transitional "configurable code integrity policy" that James Murray referred to in the interview, I have some questions: 1. I see online info from Microsoft talking about "Kernel Mode Code Integrity (KMCI)" which is part of "Device Guard". The info states this only applies to Windows 10 Enterprise editions (not Professional or Home editions). Does this mean drivers signed in the traditional Win8 manner (using cross-signing) will always run fine on Windows 10 Professional and Home editions, since there would be no configurable code integrity policy on these editions and the default behavior is to allow? 2. Does KMCI function independent of Hyper-V, i.e. in a non-hypervisor system, is the KMCI active?
  Message 102 of 259  
05 Aug 15 19:58
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@ni.com wrote: > Tim Roberts wrote: >> I think the confusion here is that he uses the phrase "cross-signing >> certificate" where I would have used the phrase "certificate that needs >> to be cross-signed". The important item is not the cross certificate, >> the important item is the original code-signing certificate. > Are we confident that James Murray didn't actually mean "cross-signing certificate"? :) > The msdn blog post also says "valid cross-signing certificate" > > http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver- signing-changes-in-windows-10.aspx Again, I think that's just a shortcut way of expressing the very wordy phrase "signed by a valid code-signing certificate and cross-signed with a valid cross-signing certificate". Everything I read leads me to believe that I don't have to do anything at all until my current certificate expires. When it comes time for me to renew, I cannot just replace it with another class 3 code-signing certificate -- I have to get an EV certificate, and I will have to go through the new attestation process. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 103 of 259  
05 Aug 15 20:10
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

>> Everything I read leads me to believe that I don't have to do anything >> at all until my current certificate expires. When it comes time for me >> to renew, I cannot just replace it with another class 3 code-signing >> certificate -- I have to get an EV certificate, and I will have to go >>through the new attestation process. Tim, I do think you have to worry about your drivers running on Win10 machines where the sys admin can lock down this "configurable code integrity" policy that James Murray alluded to. This may only affect Windows 10 Enterprise editions, which is why I asked my questions above.
  Message 104 of 259  
05 Aug 15 20:52
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > Tim, I do think you have to worry about your drivers running on Win10 machines where the sys admin can lock down this "configurable code integrity" policy that James Murray alluded to. This may only affect Windows 10 Enterprise editions, which is why I asked my questions above. It has always been possible to configure Windows to make things hard for drivers. The vast majority of people don't, and I'm guessing this will be the same. I just went exploring in my Win 10 Enterprise machine to see if I could find this setting, and I think I found it in Group Policy under Device Guard, called "Deploy Code Integrity Policy". It requires that you specify the path to a P7B file, which is a certificate file. I don't see any instructions showing what should go into that file. If it becomes an issue for my clients, it won't be until after my certificate has renewed anyway. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 105 of 259  
06 Aug 15 03:16
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 10395
Driver Signing Practical Info

> specify the path to a P7B file, which is a certificate file. Probably this is a customer-generated file, and so the feature allows = the enterprise customers to do their own driver package signing for = internal redistribution inside the enterprise. --=20 Maxim S. Shatskih Microsoft MVP on File System And Storage xxxxx@storagecraft.com http://www.storagecraft.com
  Message 106 of 259  
06 Aug 15 08:15
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

I think Mr. Roberts' course of action (using his non-EV KMCS code signing cert until it expires) is a safe one, if not exactly a "best practice." *I* don't see why getting an EV Cert and doing the attestation thing is a big deal, but we all see the issue through the unique lens of our customers and the products we build. And for Server .Next, you're APPARENTLY going to have to pass the WLK tests in any case... and you'll need an EV Cert for that submission. So (once again) might just as well get the cert and start signing stuff with it. In terms of logistics: Let me just say that dealing with the EV cert is a f'ing PITA. Our is on an eToken (I. HATE. ETOKEN.) and (apparently) a specific set of drivers had to be installed to allow you to download the cert and load it onto the eToken. It can't be exported from the eToken as far as I can tell. Why or if you have to use an eToken specifically (and not some other smart card) is entirely unclear... But that's what Symantec/Verisign supply, and those are the procedures they document. It'll take us all a while to "adjust" and discover the easiest path through this latest maze. Peter OSR @OSRDrivers
  Message 107 of 259  
06 Aug 15 13:19
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@osr.com wrote: > I think Mr. Roberts' course of action (using his non-EV KMCS code signing cert until it expires) is a safe one, if not exactly a "best practice." I see your position, but allow me this rebuttal. Signing drivers is not the focus of my business. If it were, I would certainly be jumping on the latest bandwagon and investing in its tools and procedures immediately. But it's not. The focus of my business is shipping drivers that load and work. When the KMCS signing requirement first came up, it interfered with that task. We climbed through the a few hoops and modified our build procedures so we could continue to perform our primary business function while still satisfying the dragons, essentially transparently. A few additional steps in the driver build process, an extra five seconds per build, and everyone is happy. It's still the focus of my business to ship drivers that load and work, and the existing KMCS process does that. Making the investment in dollars and labor to move to the attestation procedure is not going to help me produce drivers that load and work any better than now. It is simply an impediment -- an annoyance to be swatted away. Unlike the last signing adventure, however, it does not look like this change is going to be a transparent five-second addition to the build process. Right now, it's a manual step. Sooner or later, some clever dev will post a script or a tool to automate the attestation process, and at that point maybe things will change, but for now I simply do not see the move as a "best practice". I understand the original signing requirement, and the need for tracability for liability reasons. I don't understand the new requirement yet. I don't see any benefit, to either Microsoft or the community. I don't see what problem it solves. Maybe that will change. > *I* don't see why getting an EV Cert and doing the attestation thing is a big deal, but we all see the issue through the unique lens of our customers and the products we build. You're probably right. I think my hesitation is little more than fear of the unknown. I'm afraid of spending $1,000 and making some mistake stupid mistake ("uh-oh, you ordered a class 3.2.9.1 certificate, when you should have ordered a class 3.2.9.2 certificate! Alas, no refunds.") -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 108 of 259  
06 Aug 15 15:41
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> Signing drivers is not the focus of my business. ... The focus of my business is shipping drivers that load and work. </quote> I definitely see your point. And I agree that this new procedure is a major PITA. And, just like you, there are a lot of things about the motivations behind it that *I* do not yet understand. Did I wish they left things alone? Yes. But that's because I have plenty to do, and don't need to seek additional amusement by trying to figure out how to use my shiny new eToken (bah!) to sign CAT files containing my driver package (CAT files, for goodness sakes!). The only place we diverge is that I do *not* think it a service for OSR to provide OSR's clients with OSR Corporate Certificate signed drivers (signed with a Cert/Cross-Cert or signed with an EV Cert and a MSFT Cert through attestation) for testing or distribution. If the client is going to eventually distribute these drivers, they need to sign them. If they are going to test the drivers, I don't see how it's an imposition to have them enable test signing, thus enabling ME to not provide them a test version of my driver that could be loaded by anybody at any time. So... you know... I think we mostly agree. It's just probably that our clients or business practices are slightly different. Peter OSR @OSRDrivers
  Message 109 of 259  
06 Aug 15 19:56
Jeff Pages
xxxxxx@sonifex.com.au
Join Date: 21 Jul 2015
Posts To This List: 20
Driver Signing Practical Info

I seem to have ended up between a rock and a hard place in all of this. Our old certificate expired in June, but after reading the 1st of April blog about the new signing requirements, and taking Microsoft at their word that the attestation portal would allow drivers to be signed for previous versions of Windows as well as 10, I told management we needed to buy an EV certificate. Now, it turns out we can't sign drivers for Vista / Server 2008 since they don't recognize EV certificates, and portal-signed drivers only work on 10. If we'd just renewed our non-EV certificate we'd have been fine, but if I now buy a new non-EV certificate so we can cover the older systems, it won't work on 10 because we've passed the cut-off date. Our products fall outside Microsoft's narrow consumer-oriented view of what an audio device should be, so the HLK route isn't an option either. And there's been no reply to my email to sysdev about this that I sent a couple of weeks back. Time to retire and take up fishing, I think. Jeff
  Message 110 of 259  
06 Aug 15 22:15
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Just get a SHA-1 Cert and sign whatever you want on XP and later. Use your EV Cert for Win10 attestation signing. Problem solved, no? Peter OSR @OSRDrivers
  Message 111 of 259  
07 Aug 15 04:55
Jeff Pages
xxxxxx@sonifex.com.au
Join Date: 21 Jul 2015
Posts To This List: 20
Driver Signing Practical Info

It sounds pretty simple when you say it quickly, Peter, but you're not the one who has to explain to management why they've just payed out a large sum of money for a 3-year EV certificate we didn't really need, and now have to spend more money buying the SHA-1 certificate we should have bought, except if we had back in June, we'd have been able to use it to sign Windows 10 drivers until it expired, but now because it's August we can't, so will have to supply and maintain two sets of each driver, one for Win10 signed through the portal and the other SHA-1 signed for all the earlier systems, and deal with the customers who try to load the wrong driver on the wrong system, all because Microsoft said in their April Fools Day blog that the portal would allow drivers to be signed for earlier systems as well as 10 but then reneged on that without so much as a by-your-leave. Simple, yeah. Or is there something I'm missing in all of this? Jeff
  Message 112 of 259  
07 Aug 15 05:47
Christiaan Ghijselinck
xxxxxx@compaqnet.be
Join Date: 21 Mar 2002
Posts To This List: 476
Driver Signing Practical Info

>>they've just payed out a large sum of money for a 3-year EV certificate we didn't really need, and now have to spend more money >>buying the SHA-1 certificate we should have bought, You could ask Bill to pay the bill :) ( joke ) This is exaclty the same I will have to do when my sha1 certifiate expires in 2016. I will then provide a Win10 specific version that will cost 10 x the price of the driver version for Win8.1 and older. I have no problem that people will complain about this .... Btw. , Yesterday , Win10 corrupted an auxiliary fixed NTFS hard disk on my multi boot test system. Win7 was able to repair the drive , nothing got lost. ----- Original Message ----- From: <xxxxx@sonifex.com.au> To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Sent: Friday, August 07, 2015 10:54 AM Subject: RE:[ntdev] Driver Signing Practical Info > It sounds pretty simple when you say it quickly, Peter, but you're not the one who has to explain to management why they've just > payed out a large sum of money for a 3-year EV certificate we didn't really need, and now have to spend more money buying the > SHA-1 certificate we should have bought, except if we had back in June, we'd have been able to use it to sign Windows 10 drivers > until it expired, but now because it's August we can't, so will have to supply and maintain two sets of each driver, one for Win10 > signed through the portal and the other SHA-1 signed for all the earlier systems, and deal with the customers who try to load the > wrong driver on the wrong system, all because Microsoft said in their April Fools Day blog that the portal would allow drivers to > be signed for earlier systems as well as 10 but then reneged on that without so much as a by-your-leave. > > Simple, yeah. Or is there something I'm missing in all of this? <...excess quoted lines suppressed...>
  Message 113 of 259  
07 Aug 15 07:40
Pavel A
xxxxxx@fastmail.fm
Join Date: 21 Jul 2008
Posts To This List: 2377
Driver Signing Practical Info

On 07-Aug-2015 11:54, jeff@ wrote: > Simple, yeah. Or is there something I'm missing in all of this? Everyone wants your money. What can be simpler. And trust is priceless. -- pa
  Message 114 of 259  
07 Aug 15 08:36
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Mr. Pages, You didn't make a mistake. You would have been in exactly the same position in June 2016, when your old cert no longer worked for Win10. So you NEEDED the EV cert in any case. It happens you ALSO need the (comparatively inexpensive SHA-1 Cert because you still need to support Vista and Vista Server. Management will get that. If they don't want to spend the $200 on the SHA-1 cert, their option is to drop Vista support. As an aside: I 'm kind of surprised you have customers that care about Vista, in fact. We have had exactly zero requests for Vista support...Win7, yes. Even XP for very specific things (like embedded drivers). But not one client who care about Vista. But back to signing. The situation sucks, sure. But it's the one in which we all find ourselves. We live with it, or we write-off support for the Windows platform. And it's far from clear, BTW, that getting a compatibility signature (by passing the WLK tests) will work down to Vista. Win7 and later, sure.... But Vista? I seriously doubt it. Peter OSR @OSRDrivers
  Message 115 of 259  
07 Aug 15 11:43
Vikram Parthasarathy
xxxxxx@ni.com
Join Date: 17 Jul 2015
Posts To This List: 14
Driver Signing Practical Info

signtool.exe has a /fd option which specifies the digest algorithm to use. I've never used it before but I wonder if you can use it to tell signtool to generate a sha1 digest using your sha256 certificate (EV). Has anyone tried this before?
  Message 116 of 259  
07 Aug 15 16:55
Volodymyr M. Shcherbyna
xxxxxx@shcherbyna.com
Join Date: 07 Oct 2010
Posts To This List: 162
Driver Signing Practical Info

Peter, >> Peter Viscarola: You didn't make a mistake. You would have been in exactly the same position in June 2016, when your old cert no longer worked for Win10 << In fact I believe that it was possible to prolongate (or buy) the old certificate for 2 or 3 years thus deferring the problem with Windows 10 for several years. Overall yes. It looks like driver development for Windows becomes harder and harder for small companies and this probably get even worse with time.
  Message 117 of 259  
07 Aug 15 17:27
Jeff Pages
xxxxxx@sonifex.com.au
Join Date: 21 Jul 2015
Posts To This List: 20
Driver Signing Practical Info

Peter wrote: > I 'm kind of surprised you have customers that care about Vista Actually we still have a steady stream of enquiries from people wanting to know if our application software will work on Vista, but thinking about it from a driver perspective, the transition from Vista to 7 also coincided with the hardware transition from PCI to PCIe, so I guess it's unlikely that anyone would be wanting to (or even able to) put one of our new PCIe cards in a Vista machine. None of our old PCI cards have needed a driver update for some years, so we're probably safe to just leave those alone unless something really drastic happens. So yeah, quietly drop Vista support so we can just cross-sign our new drivers with our EV certificate and the worst of the problems go away, at least until 2018. Jeff
  Message 118 of 259  
11 Aug 15 16:25
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Getting back to a fundamental question -- Assuming one is not doing WHQL program, I still am not clear on whether, in fact, one needs to have two sets of driver packages, one for Win10 signed using attestation process, and another for previous OS's using existing cross-signing procedure. Do we have a consensus here, or is there still some debate about this?
  Message 119 of 259  
11 Aug 15 16:29
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Is it just Vista and Server 2008 that absolutely will not be able to handle the SHA-256 EV cert?
  Message 120 of 259  
11 Aug 15 17:13
ntdev member 158647
xxxxxx@gmail.com
Join Date:
Posts To This List: 10
Driver Signing Practical Info

<quote> Do we have a consensus here, or is there still some debate about this? </quote> I think the consensus is that if your code signing certificate was issued *prior* to Windows 10 RTM, then you can continue to sign your drivers as always and everything will work. Once you renew your certificate in a few years, then you will need to perform attestation for Windows 10. The package you get back from Microsoft is only good on Windows 10, so at that point, yes, you will need multiple packages. <quote> Is it just Vista and Server 2008 that absolutely will not be able to handle the SHA-256 EV cert? </quote> No, Windows 7 64-bit will also not handle it. Installing KB3033929 fixes this. Matt
  Message 121 of 259  
11 Aug 15 17:13
Jeff Pages
xxxxxx@sonifex.com.au
Join Date: 21 Jul 2015
Posts To This List: 20
Driver Signing Practical Info

Tom, this is my understanding of the current situation: 1. A cross-signed driver using a SHA-1 certificate issued prior to the 29th of July will work on all platforms Vista through to 10. 2. A cross-signed driver using an EV certificate issued prior to the 29th of July will work on 8 and above, and will work on 7 / Server 2008R2 if the patch issued through Windows Update earlier this year has been applied. It won't work on Vista / Server 2008 though. 3. A cross-signed driver using either type of certificate issued after the 29th of July won't work on Windows 10. 4. A portal-signed driver (which requires an EV certificate) will only work on Windows 10. 5. Server vNext will only load WHQL-signed drivers. Jeff
  Message 122 of 259  
11 Aug 15 19:09
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Mr Pages summed up my understanding of the situation perfectly. Peter OSR @OSRDrivers
  Message 123 of 259  
11 Aug 15 20:03
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Guys, thanks for the clarification. It is my understanding that, to be complete, Item #1 and Item #4 need additional wording, as follows: 1. A cross-signed driver using a SHA-1 certificate issued prior to the 29th of July will work on all platforms Vista through to 10, subject to configurable enterprise-defined code integrity policy, part of Device Guard (Windows 10 Enterprise edition only), which may be configured to require at least an attestation-signed driver. 4. A portal-signed driver signed using attestation signing (which requires an EV certificate) will only work on Windows 10. However, a portal-signed driver signed with WHQL signing will work on all platforms Vista through to Win10. Please correct my additional statements if not accurate.
  Message 124 of 259  
11 Aug 15 22:01
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

For item number 4, it depends of course on the operating systems selected during the submission. For example, I don't believe you can logo for Vista anymore. It's quite easy to check on the portal to see what OSes they allow you to select. Peter OSR @OSRDrivers
  Message 125 of 259  
11 Aug 15 22:59
Larry Clawson
xxxxxx@honeywell.com
Join Date: 25 Sep 2003
Posts To This List: 186
Driver Signing Practical Info

NDIS intermediate drivers will not install on the release of Win10 regardless of signing. Larry C
  Message 126 of 259  
12 Aug 15 04:17
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 10395
Driver Signing Practical Info

>above, and will work on 7 / Server 2008R2 if the patch issued through = Windows Update earlier this=20 One of the WU patches on Win7 changed the "Digital Signatures" shell = property page, and added the "Algorithm" column to it. Is it exactly this patch? > 4. A portal-signed driver (which requires an EV certificate) will only = work on Windows 10. Are you really sure portal signing is important? Isn't the thing about = EV/non-EV, and not about portal/non-portal? > 5. Server vNext will only load WHQL-signed drivers. Isn't this a group policy setting, which is IIRC on for Win10 Ent too? --=20 Maxim S. Shatskih Microsoft MVP on File System And Storage xxxxx@storagecraft.com http://www.storagecraft.com
  Message 127 of 259  
12 Aug 15 12:31
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@sonifex.com.au wrote: > 4. A portal-signed driver (which requires an EV certificate) will only work on Windows 10. However, based on what was reported here earlier, it should be possible to append your cross-signed SHA-1 certificate to the package you get back, which then allows it to work in prior systems. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 128 of 259  
12 Aug 15 12:53
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> Are you really sure portal signing is important? Isn't the thing about EV/non-EV, and not about portal/non-portal? </quote> No. You seem to have missed something critical here. In Win10, you need to have a portal signed driver. To submit that driver to the portal, you need an EV Cert. The exception is if you have a cert that was issued before Win10 RTM. In THIS case, you can continue to cross-sign with your usual (non-EV) cert. Peter OSR @OSRDrivers
  Message 129 of 259  
12 Aug 15 14:26
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

<quote> However, based on what was reported here earlier, it should be possible to append your cross-signed SHA-1 certificate to the package you get back, which then allows it to work in prior systems. </quote> Tim, I don't remember seeing anything about this. Could you please elaborate, or point me to where this was explained. This question is key, since this determines whether one has to maintain a separate set of driver packages for Win10 only. Has anyone tried this yet?
  Message 130 of 259  
12 Aug 15 14:52
Advance J
xxxxxx@hotmail.com
Join Date: 25 Jun 2013
Posts To This List: 29
Driver Signing Practical Info

Thanks a lot, now totally get the point. The only question from me is, there is a known expiration date of SHA1 algorithm before 2016, the drivers signed by a class 3 cert with SHA1 will no longer be able to load on any x64 platform, is this right ?
  Message 131 of 259  
12 Aug 15 17:27
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Let me try to restate the rules (this is what we're planning to publish in The NT Insider... so if it's wrong, I'd appreciate folks letting me know): ? A driver signed with the standard SHA-1 certificate issued prior to the 29th of July and correctly cross-signed according to the pre-Windows 10 KMCS procedures, will work on all platforms Vista through to 10. This is, however, subject to configurable an enterprise-defined code integrity policy that is part of Device Guard (available on Windows 10 Enterprise edition only). This enterprise-defined policy may be configured to require at least an attestation-signed driver. ? A driver signed with an EV certificate issued prior to the 29th of July, and cross-signed according to the pre-Windows 10 KMCS procedure, will work on 8 and above, and will work on Windows 7 / Server 2008R2 if the patch issued through Windows Update earlier this year has been applied. It won't work on Vista / Server 2008 though. ? A driver signed with any certificate issued after the 29th of July won't work on Windows 10, unless the driver is signed with a Microsoft signature available through the SysDev portal. ? A portal-signed driver using attestation signing (which requires an EV certificate) will only work on Windows 10, unless also signed with an additional valid certificate and cross-signed according to the pre-Windows 10 KMCS procedure. ? A portal-signed driver that passes WLK tests (which requires an EV certificate) will work on Windows 7 through Windows 10. ? Windows Server vNext will only load portal-signed drivers that have successfully passed the WLK tests. Peter OSR @OSRDrivers
  Message 132 of 259  
12 Aug 15 17:33
Volodymyr M. Shcherbyna
xxxxxx@shcherbyna.com
Join Date: 07 Oct 2010
Posts To This List: 162
Driver Signing Practical Info

Peter, >> Peter Viscarola: ? A portal-signed driver that passes WLK tests (which requires an EV certificate) will work on Windows 7 through Windows 10. << For this case the KB3033929 will not be required?
  Message 133 of 259  
12 Aug 15 17:33
Phil Barila
xxxxxx@logrhythm.com
Join Date: 07 Feb 2012
Posts To This List: 114
Driver Signing Practical Info

You might add that if the signature is timestamped, the pre-Windows 10 sign= ature remains valid, even after the cert expires. If the signature is not = timestamped, the signature expires when the cert does. I'm sure you already knew that, PGV, just want it to make it into the doc. Phil Not speaking for LogRhythm Phil Barila | Senior Software Engineer 720.881.5364 (w) LogRhythm, Inc. The Security Intelligence Company A LEADER in Gartner's SIEM Magic Quadrant four consecutive years (2012-2015= ) A CHAMPION in Info-Tech Research Group's 2015 SIEM Vendor Landscape Report SANS "Best of the Year" in SIEM, 2014 Perfect 5-Star Rating in SC Magazine (2009-2014) > -----Original Message----- > From: xxxxx@lists.osr.com [mailto:bounce-588825- > xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com > Sent: Wednesday, August 12, 2015 3:27 PM > To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> > Subject: RE:[ntdev] Driver Signing Practical Info >=20 > Let me try to restate the rules (this is what we're planning to publish i= n > The NT Insider... so if it's wrong, I'd appreciate folks letting me know)= :
  Message 134 of 259  
13 Aug 15 03:18
Menachem Shapira
xxxxxx@gmail.com
Join Date: 08 Dec 2013
Posts To This List: 28
Driver Signing Practical Info

<Quote> A portal-signed driver that passes WLK tests (which requires an EV certificate) will work on Windows 7 through Windows 10. </Quote> WLK now has a dual meaning. We have HCK (for pre windows 10) and HLK (windows 10 only). What tests is the minimum that would have to pass in order to run the driver on windows 7 through to windows 10? Menachem On Thu, Aug 13, 2015 at 12:26 AM, <xxxxx@osr.com> wrote: > Let me try to restate the rules (this is what we're planning to publish in > The NT Insider... so if it's wrong, I'd appreciate folks letting me know): > > ? A driver signed with the standard SHA-1 certificate issued prior > to the 29th of July and correctly cross-signed according to the pre-Windows > 10 KMCS procedures, will work on all platforms Vista through to 10. This > is, however, subject to configurable an enterprise-defined code integrity > policy that is part of Device Guard (available on Windows 10 Enterprise > edition only). This enterprise-defined policy may be configured to require > at least an attestation-signed driver. <...excess quoted lines suppressed...> --
  Message 135 of 259  
13 Aug 15 09:14
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> For this case the KB3033929 will not be required? </quote> I assume it WILL be required, yes. I sort of thought that was obvious, but perhaps it's not, so I'll add that. Thanks, Mr. Shcherbyna. <quote> You might add that if the signature is timestamped, the pre-Windows 10 signature remains valid, even after the cert expires. If the signature is not timestamped, the signature expires when the cert does. </quote> Excellent point, Mr. Barila. I'll definitely add that. <quote> We have HCK (for pre windows 10) and HLK (windows 10 only). </quote> Excellent pickup, Mr. Shapira. The correct term for the Win10 kit is HLK, *not* WLK. Thanks! Peter
  Message 136 of 259  
14 Aug 15 10:09
Xiaofan Chen
xxxxxx@gmail.com
Join Date: 09 Sep 2010
Posts To This List: 182
Driver Signing Practical Info

On Thu, Aug 13, 2015 at 2:51 AM, <xxxxx@hotmail.com> wrote: > Thanks a lot, now totally get the point. The only question from me is, > there is a known expiration date of SHA1 algorithm before 2016, > the drivers signed by a class 3 cert with SHA1 will no longer be > able to load on any x64 platform, is this right ? Where does this 2016 come from? Ref: https://www.osronline.com/showthread.cfm?link=269119 Our cert uses SHA1 and apparently it only expires in 2017 and Tim says that it will work until then. -- Xiaofan
  Message 137 of 259  
17 Aug 15 15:42
Carl Appellof
xxxxxx@symantec.com
Join Date: 25 Jan 2013
Posts To This List: 5
Driver Signing Practical Info

I sure wish Microsoft had turned on signing enforcement before Windows 10 RTM. I've been waiting breathlessly to confirm a few edge cases. Now that I have the real RTM bits, I can test my kernel file system driver with various signing options. Luckily, for now, my older driver version works since it was signed before the magic RTM date. But I have a copy of my driver signed with a newer certificate, issued August 4th, 2015. And guess what? The driver loads and runs! On my "Generation 1" Hyper-V VM running Windows 10. Which apparently didn't cause the new enforcement to kick in because "secure boot" wasn't an option there. But on a "Generation 2" Hyper-V VM (with "secure boot" permanently enabled), my newly signed driver does not run. Old driver runs fine, as promised. I guess I had missed the part about "secure boot" being the enforcement gate. Gotta improve our test matrix to make sure we have all the security stuff cranked up to its highest level. Now to start the adventure of getting an EV certificate and a signature from the MS portal.
  Message 138 of 259  
17 Aug 15 16:10
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Peter, question on your 4th bullet point: <quote> ? A portal-signed driver using attestation signing (which requires an EV certificate) will only work on Windows 10, unless also signed with an additional valid certificate and cross-signed according to the pre-Windows 10 KMCS procedure. </quote> According to Microsoft Security Advisory 2880823, certificate authorities may no longer issue SHA-1 certificates after January 1, 2016. So, under the scenario described above, where for a given driver package, an organization is doing the attestation signing AND cross signing under the pre-Win10 KMCS procedure, what happens when that existing SHA-1 cert expires? Do they need to purchase another cert (or renew before 1/1/2016) for use solely in cross signing, in addition to their new EV cert which they obtained for attestation signing? In other words, when applying both the new attestation procedure, followed by the old KMCS cross signing procedure, is there a problem if the cert used for the old procedure is now a SHA-2 cert? If not, can the new EV cert be used for both signing procedures?
  Message 139 of 259  
17 Aug 15 18:12
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

The key is that Vista and earlier only recognize SHA-1. If you care about those OSes, then you'll want that SHA-1 Cert. We plan to use our SHA-2 EV cert for everything. Peter OSR @OSRDrivers
  Message 140 of 259  
17 Aug 15 18:22
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Ok, thanks, that makes sense.
  Message 141 of 259  
18 Aug 15 01:09
Xiaofan Chen
xxxxxx@gmail.com
Join Date: 09 Sep 2010
Posts To This List: 182
Driver Signing Practical Info

On Tue, Aug 18, 2015 at 6:12 AM, <xxxxx@osr.com> wrote: On Tue, Aug 18, 2015 at 4:11 AM, <xxxxx@gmail.com> wrote: >> According to Microsoft Security Advisory 2880823, certificate authorities >> may no longer issue SHA-1 certificates after January 1, 2016. > > The key is that Vista and earlier only recognize SHA-1. If you care > about those OSes, then you'll want that SHA-1 Cert. > > We plan to use our SHA-2 EV cert for everything. > https://technet.microsoft.com/en-us/library/security/2880823.aspx "Recommendation: Microsoft recommends that certificate authorities no longer sign newly generated certificates using the SHA-1 hashing algorithm and begin migrating to SHA-2. Microsoft also recommends that customers replace their SHA-1 certificates with SHA-2 certificates at the earliest opportunity." So that opportunities depend on whether the customer wants XP/Vista support or not. And in the real situation, certificate authority may still issue SHA-1 certificate if there are enough customers who want that one. Thanks a lot for this thread. Things are much clearer now. Luckily for us (libusb-win32 project/libusbK project) we have a certificate which works until 2017 and we see no future in libusb-win32 kernel driver and libusbK kernel driver (other than for legacy device and legacy OS). The future of generic USB driver under Windows is WinUSB. -- Xiaofan
  Message 142 of 259  
18 Aug 15 01:26
Xiaofan Chen
xxxxxx@gmail.com
Join Date: 09 Sep 2010
Posts To This List: 182
Driver Signing Practical Info

On Tue, Aug 18, 2015 at 1:09 PM, Xiaofan Chen <xxxxx@gmail.com> wrote: > https://technet.microsoft.com/en-us/library/security/2880823.aspx > "Recommendation: Microsoft recommends that certificate authorities > no longer sign newly generated certificates using the SHA-1 hashing > algorithm and begin migrating to SHA-2. Microsoft also recommends > that customers replace their SHA-1 certificates with SHA-2 certificates > at the earliest opportunity." > > So that opportunities depend on whether the customer wants XP/Vista > support or not. > <...excess quoted lines suppressed...> The wording here is not the same. https://msdn.microsoft.com/en-us/library/windows/hardware/dn170454%28v=vs.85%29.a spx **Please also review Microsoft Security Advisory (2880823) "Deprecation of SHA-1 Hashing Algorithm for Microsoft Root Certificate Program" which describes a policy change wherein Microsoft will no longer allow root certificate authorities to issue X.509 certificates using the SHA-1 hashing algorithm for the purposes of SSL and code signing after January 1, 2016.** So it is not a recommendation but rather requirements, right? -- Xiaofan
  Message 143 of 259  
18 Aug 15 02:19
Krystian Bigaj
xxxxxx@gmail.com
Join Date: 17 Nov 2010
Posts To This List: 22
Driver Signing Practical Info

It's a requirement for SSL certs (like for web pages) not a KMCS certs. On 18 Aug 2015 07:26, "Xiaofan Chen" <xxxxx@gmail.com> wrote: > On Tue, Aug 18, 2015 at 1:09 PM, Xiaofan Chen <xxxxx@gmail.com> wrote: > > https://technet.microsoft.com/en-us/library/security/2880823.aspx > > "Recommendation: Microsoft recommends that certificate authorities > > no longer sign newly generated certificates using the SHA-1 hashing > > algorithm and begin migrating to SHA-2. Microsoft also recommends > > that customers replace their SHA-1 certificates with SHA-2 certificates > > at the earliest opportunity." > > > > So that opportunities depend on whether the customer wants XP/Vista > > support or not. <...excess quoted lines suppressed...> --
  Message 144 of 259  
18 Aug 15 11:11
Bo Brantén
xxxxxx@acc.umu.se
Join Date: 16 Jun 2015
Posts To This List: 27
Driver Signing Practical Info

On Mon, 17 Aug 2015, xxxxx@symantec.com wrote: > I guess I had missed the part about "secure boot" being the enforcement gate. Gotta improve our test matrix to make sure we have all the security stuff cranked up to its highest level. Yes that was one of the most interesting new information that come up in OSR:s interview with Microsoft Program Manager James Murray: https://www.osr.com/blog/2015/07/24/questions-answers-windows-10-driver-signing/
  Message 145 of 259  
19 Aug 15 13:22
Chris Aseltine
xxxxxx@gmail.com
Join Date: 23 Sep 2006
Posts To This List: 1220
Driver Signing Practical Info

Bo Branten wrote: > Yes that was one of the most interesting new information > that come up in OSR:s interview with Microsoft Program > Manager James Murray: Hey Don...look who it is...
  Message 146 of 259  
01 Sep 15 14:34
Vikram Parthasarathy
xxxxxx@ni.com
Join Date: 17 Jul 2015
Posts To This List: 14
Driver Signing Practical Info

Has anyone figured out how to enable the Kernel Mode Code Integrity Policy in Device Guard? As Tim Roberts mentioned earlier, Device Guard has an option called "Deploy Code Integrity Policy" and it requires the path to a Code Integrity Policy file. I don't know what the contents of this file should be.
  Message 147 of 259  
01 Sep 15 15:43
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

I'm not sure what this has to do with driver signing, but in any case... You use the PowerShell command New-CIPolicy to create the necessary XML Policy file. You can see some of the info here: https://technet.microsoft.com/en-us/library/mt243445(v=vs.85).aspx Peter OSR @OSRDrivers
  Message 148 of 259  
01 Sep 15 16:32
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Vikram, I too have been trying to figure out how to properly create and adjust one of these Device Guard Code Integrity XML policy files. I would like to be able to at least test the situation on Win10 Enterprise where our traditional KMCS signed driver is rejected, so I can see the failure mode in detail. I have created one of these files using the info from the article for which Peter provided the link. I also have looked at the following slides from the May 2015 Microsoft Ignite conference, which does provide some clues: "Dropping the Hammer on Malware Threats with Windows 10's Device Guard" https://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%2fvideo.ch9.ms%2fses sions%2fignite%2f2015%2fdecks%2fBRK2336_Sutherland.pptx The PowerShell command Set-RuleOption -Help reveals the following: 0 Enabled:UMCI 1 Enabled:Boot Menu Protection 2 Required:WHQL 3 Enabled:Audit Mode 4 Disabled:Flight Signing 5 Enabled:Inherit Default Policy 6 Enabled:Unsigned System Integrity Policy 7 Allowed:Debug Policy Augmented 8 Required:EV Signers 9 Enabled:Advanced Boot Options Menu 10 Enabled:Boot Audit On Failure It would seem that these could be placed in the XML file as Rules. Options 2 and 8 seem like they would apply to kernel-mode signatures -- Required:WHQL and Required:EV Signers. It's unclear what option 6 does -- Enabled:Unsigned System Integrity Policy. If anyone has gone through this and can offer more details, the information would be greatly appreciated.
  Message 149 of 259  
02 Sep 15 17:33
Gabe Jones
xxxxxx@ni.com
Join Date: 19 Mar 2012
Posts To This List: 38
Driver Signing Practical Info

We are having scarce little luck trying to get any drivers to actually fail due to signing problems. The first scenario I want to reproduce is seeing a driver signed with our traditional signing method fail on Windows 10 when signed with a certificate that was issued after Windows 10 RTM. My setup: * Windows 10 Enterprise x64 * Secure Boot enabled (as verified by msinfo32) * Installed two drivers signed locally with a certificate listed as "Valid from 8/30/2015 to 8/30/2018" I expected the above to fail, but it did not. One quirk: The above certificate is the EV cert that we acquired earlier this year when the new Windows 10 requirements came to light. It went unused until recently, and it seems that it is not considered "active" until first use, thus the 8/30/2015 start date. Is Windows checking this date, or is there some other record somewhere of the (pre-RTM) date that we actually aquired the cert? Second scenario: What are the conditions under which Windows 7 is expected to fail on validating drivers signed with SHA-1? We built a non-timestamped version of a driver with a SHA-1 signature and loaded it on a Windows 7 Pro x64 system on which the clock had been set to March of 2016. Again, it did not fail. Is there some upcoming update to Windows 7 that will enable this check or some button Microsoft has to push when the ball drops in Times Square? KB3033929 is installed on this system.
  Message 150 of 259  
02 Sep 15 17:56
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

So, your drivers were KMCS cross-signed, and not Win10 signed? Open the certificate manager utility and check your EV cert... it'll have the valid dates. If you cert was issue prior to Win10 RTM, then I would expect it to work, per the rule above: ? A driver signed with the standard SHA-1 certificate issued prior to the 29th of July and correctly cross-signed according to the pre-Windows 10 KMCS procedures, will work on all platforms Vista through to 10. Here, you have an EV cert, not a SHA-1 cert, but the rule would be the same. I don't expect the SHA-1 signature to EVER fail on Win7. The "unsupported" statement from Microsoft applies to SSL certs, not KMCS to the best of my knowledge. Peter OSR @OSRDrivers
  Message 151 of 259  
03 Sep 15 09:22
Gabe Jones
xxxxxx@ni.com
Join Date: 19 Mar 2012
Posts To This List: 38
Driver Signing Practical Info

> So, your drivers were KMCS cross-signed, and not Win10 signed? Open the > certificate manager utility and check your EV cert... it'll have the valid > dates. If you cert was issue prior to Win10 RTM, then I would expect it to work Not Win10 signed. (We haven't even updated the portal with our EV cert yet.) Certificate Manager shows "Valid from 8/30/2015 to 8/30/2018." I didn't see any oddities in setupapi.dev.log or Event Viewer, but I'll look again to see what they say. > I don't expect the SHA-1 signature to EVER fail on Win7. The "unsupported" > statement from Microsoft applies to SSL certs, not KMCS to the best of my > knowledge. I'd found the Microsoft published statements confusing, so I was referring to the summary chart at <https://www.globalsign.com/en/blog/microsoft-announces-updates-sha-1-code-signin g-policy>, which mentions that "Code Signed Kernel Driver Acceptance" for SHA-1 will cease for Windows 7 & 8 on or after Jan. 1, 2016. That does seem to contrast with the "This enforcement will be performed only in user mode" statement on <http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx>.
  Message 152 of 259  
03 Sep 15 17:14
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

OK, I spent the money to buy an EV Cert, acquired the token, setup a sysdev account, digitally signed 22 different legal agreements, and submitted a driver package for attestation. Surprisingly (or not), it all actually seems to work. I only have a few observations. It took several hours. That surprised me. Several people have said "oh sure, you can request whatever operating systems you need." That's not what I see. The attestation web page gives me the option of Windows 10 x86, or Windows 10 x64. There are no other choices. And, in fact, those are the only selections embedded in the CAT file. Installing on Windows 7 gives me the nasty red "unsigned driver!" warning, and "Error 0xe0000244: The software was tested for compliance with Windows Logo requirements on a different version of Windows, and may not be compatible with this version." In the package I got back, they not only signed the CAT, they also signed every executable I sent, regardless of extension. I accidentally included my installer EXE, which is not mentioned in the INF or the CAT, and it ALSO got signed. That's probably a security hole that needs to get patched. Because they signed everything, my certificate is gone. I guess that's the way WHQL has always worked, but it's an interesting choice. In the past, when I signed a package, it was possible to trace the package back to me for liability purposes. That's gone now. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 153 of 259  
04 Sep 15 09:48
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

That's right. We noticed that downlevel OSes weren't a choice for attestation signing, and asked Mr Murray about it... He confirmed this was by design and if you wanted an all in one signature you need to pass the HLK tests. This is in the Q&A. Interesting that they would sign everything in the package, but I guess as long as you signed the package, they know who to come after if you do anything "bad." Peter OSR @OSRDrivers
  Message 154 of 259  
04 Sep 15 10:16
Vikram Parthasarathy
xxxxxx@ni.com
Join Date: 17 Jul 2015
Posts To This List: 14
Driver Signing Practical Info

>> It took several hours. That surprised me. Back in May/June, it used to take only a few minutes (5-15 min). But since July or so, it takes several hours, possibly due to load. Tim Roberts, when you find time, please can you try loading your new EV-signed driver (but not portal signed) on Windows 10 and check if it loads? For me it still continues to load although my certificate was issued after July 29 and it's perplexing!
  Message 155 of 259  
04 Sep 15 11:42
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> it still continues to load although my certificate was issued after July 29 and it's perplexing! </quote> That IS perplexing... I haven't tried it myself. Some more to add to the list of things to try "in my copious free time." I'll be interested to hear other's experience. Peter OSR @OSRDrivers
  Message 156 of 259  
04 Sep 15 11:50
Vikram Parthasarathy
xxxxxx@ni.com
Join Date: 17 Jul 2015
Posts To This List: 14
Driver Signing Practical Info

But I do see a comment in this from Carl Appellof that his newly signed driver failed, which is the expected behavior. The weird thing about our certificate is that it was purchased before July 29 but activated after. The "Valid From" date is after. I don't know if our special case is causing this behavior. I'm curious to hear from the others as well.
  Message 157 of 259  
04 Sep 15 12:32
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@osr.com wrote: > That's right. We noticed that downlevel OSes weren't a choice for attestation signing, and asked Mr Murray about it... He confirmed this was by design and if you wanted an all in one signature you need to pass the HLK tests. This is in the Q&A. I probably blocked it out. Stuff doesn't become real until we hold it in our hands, ya know. It is unfortunate, because unless someone has actually figured out how to "dual sign" these files (I have not), it makes it impossible to distribute a single driver package for Windows 7, 8, and 10. > Interesting that they would sign everything in the package, but I guess as long as you signed the package, they know who to come after if you do anything "bad." I wonder how detailed is their tracking. The Dr. Evil scenario I'm thinking about is that I submit an innocuous driver package with a nefarious EXE. I then remove the Microsoft-signed EXE and distribute it separately through my world-wide botnet, thereby bringing down western civilization, or at least causing a Facebook outage, which is just as bad. Would Microsoft have stored enough information to trace it back to me? -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 158 of 259  
04 Sep 15 13:14
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> The Dr. Evil scenario I'm thinking about is that I submit an innocuous driver package with a nefarious EXE. I then remove the Microsoft-signed EXE and distribute it separately through my world-wide botnet </quote> Wouldn't the exe being signed or not signed make no difference in any case? Except for the amusement factor of having a nefarious exe signed by MSFT, of course. I mean, sign it or not, it's not like it gets magical powers with the WHQL signature. So, I think they're not enabling anything by signing it... Or are they? Peter OSR @OSRDrivers
  Message 159 of 259  
04 Sep 15 13:58
Vikram Parthasarathy
xxxxxx@ni.com
Join Date: 17 Jul 2015
Posts To This List: 14
Driver Signing Practical Info

>> It is unfortunate, because unless someone has actually figured out how to "dual sign" these files (I have not), it makes it impossible to distribute a single driver package for Windows 7, 8, and 10. By dual sign, if you simply mean adding multiple signatures to a file - http://stackoverflow.com/questions/20601575/how-does-one-correctly-dual-sign-code -with-a-timestamp. You have to do the signing and timestamping in two separate steps. There's also a /tp flag which you'd have to use while timestamping.
  Message 160 of 259  
04 Sep 15 14:21
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@osr.com wrote: > Wouldn't the exe being signed or not signed make no difference in any case? Except for the amusement factor of having a nefarious exe signed by MSFT, of course. I mean, sign it or not, it's not like it gets magical powers with the WHQL signature. So, I think they're not enabling anything by signing it... Or are they? No, you're right, which shows why I'd be such a terrible criminal. I suppose there may be locked-down environments where a signed EXE would run when an unsigned one would not, but it appears that my glorious plan is falling apart. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 161 of 259  
04 Sep 15 14:35
Mark Fontana
xxxxxx@kinura.net
Join Date: 05 Jul 2013
Posts To This List: 3
Driver Signing Practical Info

On 09/04/2015 01:21 PM, Tim Roberts wrote: > xxxxx@osr.com wrote: >> Wouldn't the exe being signed or not signed make no difference in any case? Except for the amusement factor of having a nefarious exe signed by MSFT, of course. I mean, sign it or not, it's not like it gets magical powers with the WHQL signature. So, I think they're not enabling anything by signing it... Or are they? > No, you're right, which shows why I'd be such a terrible criminal. I > suppose there may be locked-down environments where a signed EXE would > run when an unsigned one would not, but it appears that my glorious plan > is falling apart. > The MSFT signature could help your EXE evade anti-virus software, though. The magical power of implicit trust might prevent your plan from being thwarted.
  Message 162 of 259  
04 Sep 15 14:36
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@ni.com wrote: >>> It is unfortunate, because unless someone has actually figured out how to "dual sign" these files (I have not), it makes it impossible to >>> distribute a single driver package for Windows 7, 8, and 10. >>> > By dual sign, if you simply mean adding multiple signatures to a file - http://stackoverflow.com/questions/20601575/how-does-one-correctly-dual-sign-code -with-a-timestamp. You have to do the signing and timestamping in two separate steps. There's also a /tp flag which you'd have to use while timestamping. You're right, I was just able to add my SHA1 certificate to the Microsoft-signed CAT file. It was easier than I expected. Thanks for that reference. However, that still doesn't solve the problem, which I stated incorrectly. The problem with Win 7 is not the dual signing, it's the operating system attribute. I suppose I could try to build a new CAT using the Microsoft-signed SYS file... -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 163 of 259  
09 Sep 15 17:35
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Ok guys, I am hearing some conflicting information out there. Regarding the exception case statement, and the 1st, 4th, and 5th bullet points in the most recent NT Insider article: <quote> So, aside from the exception case, drivers for Windows 10 must have a Microsoft signature obtained through the SysDev portal. What?s the exception case? The exception is that Windows 10 Client (not server) systems will load drivers that have been properly signed and cross-signed using the pre-Windows 10 KMCS procedure if the certificate used to sign those drivers was issued prior to the release of Windows 10. This gives driver developers some ?breathing room? to adjust to the new policy. 1. A driver signed with the standard SHA-1 certificate issued prior to the 29th of July 2015 and correctly cross-signed according to the pre-Windows 10 KMCS procedures, will work on all platforms Vista through to 10. This is, however, subject to configuration an enterprise-defined code integrity policy that is part of Device Guard (available on Windows 10 Enterprise edition only). This enterprise-defined policy may be configured to require at least an attestation-signed driver. 4. A driver signed with any certificate that expires after the 29th of July will work on Windows 10, assuming that the signature was timestamped at the time of signing. If the signature was not timestamped, the driver will not work after the certificate expires. 5. A portal-signed driver using attestation signing (which requires an EV certificate) will only work on Windows 10, unless also signed with an additional valid certificate and cross-signed according to the pre-Windows 10 KMCS procedure. </quote> What I'm hearing is that, for Windows 10, drivers being signed with the standard SHA-1 certificate issued prior to the 29th of July 2015 and correctly cross-signed according to the pre-Windows 10 KMCS procedures can only be signed up until January 1, 2016, regardless of the certificate expiry date. In our case our certificate expires in November 2016, but we are being told we can only sign Win 10 drivers up until January 1, 2016, due to the fact that SHA1 will not be accepted after that date. Regarding bullet point #5, I'm hearing that to also run on pre-Win 10 systems, there is no need to do the double signing, i.e., adding the pre-Windows 10 KMCS properly cross-signed signature to the already obtained Microsoft attestation signature. Has anyone else heard anything similar? I thought that we had evolved a set of definitive rules and answers, but now I'm not so sure.
  Message 164 of 259  
09 Sep 15 18:02
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > Regarding bullet point #5, I'm hearing that to also run on pre-Win 10 systems, there is no need to do the double signing, i.e., adding the pre-Windows 10 KMCS properly cross-signed signature to the already obtained Microsoft attestation signature. Where did you hear that? The attestation CAT file is marked only for Win 10. If you load it on a prior system, it gets the red "unsigned driver" warning, and the setup log reports that it was tested for a different version of Windows. I tested this on Win 7. If you're just worried about KMCS (as opposed to PnP), then it depends on whether your target system understands SHA-256 signatures. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 165 of 259  
09 Sep 15 18:18
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

This is coming from someone at Microsoft WDK Support. We have opened a support ticket. Interestingly enough, the first suggestion we got from this person was a link to the recent NT Insider article :-) Then we pressed further, asking for them to comment on a write-up I had done summarizing our understanding of various signing scenario options we foresee for our company going forward. That's when I got these strange answers. I'm not sure whether to believe them or not.
  Message 166 of 259  
10 Sep 15 05:45
David Boyce
xxxxxx@becrypt.com
Join Date: 19 Mar 2015
Posts To This List: 65
Driver Signing Practical Info

At the risk of further muddying the waters, we've seen another inconsistency: a boot driver satisfying point 1) is accepted in a fresh Windows 10 installation, but is NOT accepted when injected as part of an Windows 10 Upgrade image (a la https://technet.microsoft.com/en-us/library/Cc766141%28v=WS.10%29.aspx ) from 8.1 to 10. It may be worth mentioning that the driver's counter-signature's timestamp (proving time of driver signing) is later than 29th July 2015; according to what I have read so far, this should not cause rejection but it's possible it is being taken into account - and if it is, this may explain some of the other inconsistencies reported. This can be worked around by temporarily turning on TestSigning during the upgrade, but IMO this mechanism needs further work and/or clarification. > -----Original Message----- > From: xxxxx@lists.osr.com [mailto:bounce-590827- > xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com > Sent: 09 September 2015 22:35 > To: Windows System Software Devs Interest List > Subject: RE:[ntdev] Driver Signing Practical Info > > Ok guys, I am hearing some conflicting information out there. > Regarding the exception case statement, and the 1st, 4th, and 5th > bullet points in the most recent NT Insider article: <...excess quoted lines suppressed...> This email message has been delivered safely and archived online by Mimecast.<Br> For more information please visit <a href="http://www.mimecast.com">http://www.mimecast.com --
  Message 167 of 259  
11 Sep 15 12:48
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Ok, an additional point of information now mentioned by our Microsoft support contact -- Driver signers can continue to use their SHA1 certs until they expire, or until possibly October when a forced deprecation "may" take effect. Has anyone else heard of this possible October forced deprecation?
  Message 168 of 259  
16 Sep 15 11:32
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Ok, turns out that the October 29th forced deprecation relates only to the use of non-EV certs with Sysdev. There is a 90 day grace period from July 29th to Oct 29th where you don?t need a EV cert to submit to Sysdev. This is a moot point for those of us just getting started with Sysdev (for the purpose of Win10 Attestation signing). We already know we need to sign up with the EV cert. The other misinformation we were given has now also been debunked -- existing SHA1 certs which expire after January 1, 2016 will continue to be able to be used for signing until their expiration date. The January 1, 2016 date only applies to CAs, who may not issue new SHA1 certs after that date. Exception is they may still issue SHA1 certs anyway, to support Vista and earlier. Simple, right?
  Message 169 of 259  
17 Sep 15 10:28
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Thanks very much for co ti using to keep everyone here "in the loop", Tom. I'm sure it's very helpful to a lot of people. Peter OSR @OSRDrivers
  Message 170 of 259  
17 Sep 15 17:48
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Just received more comprehensive information from our Microsoft support contact, which I am including verbatim below. He also indicated this info may contradict what has already been published by Microsoft. They are planning on writing a new consolidating KB article for all of this. <quote> First, the only time you need to worry about using your SHA1 certificate, is if you are targeting Vista or 2008 unpatched. If you targeting these OS?s, you will have to embed sign the binaries with your SHA1 and a cross certificate. This is because Vista and 2008 can?t enumerate more than one cert.. so dual signing is not supported. So if either of these OS?s are selected, even if you are targeting 7 and higher as well, you have to provide at least this. Second, If you are targeting Win7/2008 R2 and higher only, the only thing you need to sign will be your CAB file with your EV certificate. None of the binaries need to be embed signed or cross signed. Sysdev/WHQL will take care of that aspect for you, even dual signing. Sysdev will also use SHA1 certs and cross signing as needed to make sure that the drivers are accepted. The exception to using the EV certificate to sign the CAB file is the Oct 29th 2015 deadline. Up till then, you can still use your current certificates to submit. After that date, your submission cert must be EV. What this means is that you can submit for a single driver package that will cover all OS?s. If you are including XP,Vista,2008, you will have to embed sign your binaries with your SHA1 and a cross cert. Otherwise you do not need to sign anything other than the submission CAB. You could make a second submission if you like, but is not necessary. There are no current plans to force deprecate anything. The process of moving over to SHA2 will slowly replace SHA1 over time. IF there is a problem with SHA1 we may force deprecate it but we have no current plans for this. SHA1 will remain valid as long as you have it. Developers will continue to sign drivers for XP, Vista and 2008 with some Win7 unpatched systems involved. So SHA1 will remain in play for a while. The goal of the deprecation policy is not to prevent or hinder the progress of any of that. The above makes driver signing much easier for the developer. In short, most of the driver signing responsibility will reside with Sysdev/WHQL with the only exception being Vista/2008 drivers which you will have to "prime? with your SHA1 and a cross cert prior to submission. How you submit to Sysdev/WHQL has changed and that?s where the EV cert really comes into play. We will sign the drivers based on the account you establish with the EV cert, but you don?t have to actually sign the binaries (less the above exception for Vista/2008). Summary chart: When submitting a driver package, the CAB file must be signed with your cert (after oct 29th, must be EV): Driver package must be prepped in the following way (not sure if XP even shows up as an option anymore, but if it does?): SHA1 CrossSign SHA2 EV XP Yes N/A N/A N/A Vista Yes Yes N/A N/A 2008 Yes Yes N/A N/A Win7 N/A N/A N/A N/A 2008 R2 N/A N/A N/A N/A Win8 N/A N/A N/A N/A Win 8.1 N/A N/A N/A N/A Win 10 N/A N/A N/A N/A Sysdev will ensure that the returned driver package is correctly signed in all other ways. The idea being, since we are signing it, we will take care of the details and confusion with SHA1/SHA2/Cross sign/Dual sign, EV, etc. </quote>
  Message 171 of 259  
17 Sep 15 17:58
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

This is really great info, but there is one assertion here that is, based on my experience, incorrect: xxxxx@gmail.com wrote: > ... > What this means is that you can submit for a single driver package that will cover all OS?s. If you are including XP,Vista,2008, you will have to embed sign your binaries with your SHA1 and a cross cert. Otherwise you do not need to sign anything other than the submission CAB. You could make a second submission if you like, but is not necessary. The attestation process REPLACES the certificates in every executable file in the cabinet with Microsoft's cert. When I submitted my test package, I submitted a package that was already signed for XP and Win 7, using my SHA1 and cross cert. In the package I got back, no trace of my certificate could be found. With the tools as they currently exist, it is simply impossible to build a single package that loads on all systems. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 172 of 259  
17 Sep 15 22:48
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

I don't understand any of that text from MSFT at all. None of it. Is he saying if I sign my cab, and submit a package to be attestation signed, that the components will be appropriately ceoss-signed for loading on Win7??? Either (a) that's not what he's saying,(b) there's been a big change ...no an enormous change.... In thinking, or (c) that's wrong. If he's talking about a Compatibility submission.... One that has passed the HLK ... This makes sense and its exactly as I would expect. Having the summary write-up in one place is awesome, and I really appreciate Tom passing it along. That's really considerate, Tom.... Thanks! Can we get a clarification that what he's talking about is NOT attestation signing.? Peter OSR @OSRDrivers
  Message 173 of 259  
18 Sep 15 01:18
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Peter, I asked him specifically if what he was describing applied to attestation signing or WHQL signing, because it didn't sound right to me. He said applies to both. I told him there is still a lot of confusion in the driver dev community, and asked him to comment on this list directly, for the benefit of all. He said he would be posting here soon.
  Message 174 of 259  
18 Sep 15 02:34
ntdev member 162870
xxxxxx@hotmail.com
Join Date:
Posts To This List: 3
Driver Signing Practical Info

Correct, it is not attestation signing. There was a mix up there. Attestation signing will not take care of Win7 signing.. only Win10. However, submitting a passing driver package for Win7 will get it properly signed and cross signed by Sysdev/WHQL. Each OS still has the same Sysdev requirements as before. Only the signing aspect is taken care of by Sysdev fully. I've asked Sysdev and the codesigning team multiple times about this to make sure this is how it will be from now on and they assure me this is how Sysdev/whql handles driver signing for Win10 on down.
  Message 175 of 259  
18 Sep 15 02:49
ntdev member 162870
xxxxxx@hotmail.com
Join Date:
Posts To This List: 3
Driver Signing Practical Info

Regarding how Sysdev replaces your signature during signing Sysdev (aka WHQL) always does the following: 1. Appends a SHA2 embedded signature (i.e. it will NOT replace any embedded signatures) 2. Creates and signs a catalog file with either SHA1 or SHA2 depending on which operating systems are targeted If the customer embed signs binaries with their own SHA1 certificate, those will NOT be overwritten. There was a bug back in April of this year where Sysdev was incorrectly replacing embedded signatures. That was quickly corrected though. WHQL should not be overwriting embedded signatures. If a customer is seeing that, then we should report it to the Sysdev team for investigation.
  Message 176 of 259  
18 Sep 15 05:01
Mike Kemp
xxxxxx@sintefex.com
Join Date: 30 May 2006
Posts To This List: 273
Driver Signing Practical Info

So to clarify: Windows software and drivers are designed by computer scientists / engineers. Windows signing is designed by committees of middle managers? (Perhaps they should go back to figuring out how to organise a piss-up in a brewery.) M. >>> I told him there is still a lot of confusion in the driver dev community, and asked him to comment on this list directly, for the benefit of all. He said he would be posting here soon. <<<
  Message 177 of 259  
18 Sep 15 10:29
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Ok, so apparently there's been another "mix up". This is getting frustrating. What is going on at Microsoft these days?
  Message 178 of 259  
18 Sep 15 15:03
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

<quote> (Perhaps they should go back to figuring out how to organise a piss-up in a brewery.) </quote> Mike, not being British, I had to look that one up. For the benefit of others on this list, here is the definition from Urban Dictionary: <quote> A 'piss up' is British slang for a drinking session, so if you couldn't organise a piss up in a brewery, you really suck at organising things. </quote>
  Message 179 of 259  
18 Sep 15 17:15
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@hotmail.com wrote: > Regarding how Sysdev replaces your signature during signing > > Sysdev (aka WHQL) always does the following: > > 1. Appends a SHA2 embedded signature (i.e. it will NOT replace any embedded signatures) > > 2. Creates and signs a catalog file with either SHA1 or SHA2 depending on which operating systems are targeted > > If the customer embed signs binaries with their own SHA1 certificate, those will NOT be overwritten. > <...excess quoted lines suppressed...> You're right. I ran a signed driver package through the attestation process today (it took 3 hours again). The CAT file has been completely replaced, but the attestation SHA2 signatures have been appended to the executables, and my SHA1 signature is still present. My 71k binary now has 18k bytes of certificates added to it... -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 180 of 259  
18 Sep 15 22:30
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Thank you, Mr McDermott and Mr. Roberts (again, both of you... Well done!). Too right, Mr Kemp. Mr. Whitaker... These being your first two posts to this list, and seeing that you're posting from hotmail, and you're attempting to speak with what authority, and you didn't bother to sign either of your posts, would you be so kind as to identify yourself, please? Peter OSR @OSRDrivers
  Message 181 of 259  
18 Sep 15 22:58
ntdev member 162870
xxxxxx@hotmail.com
Join Date:
Posts To This List: 3
Driver Signing Practical Info

Greetings, Sorry about the lack of info... My name is Daniel Whitaker and I currently work in the Windows Driver Kit team at Microsoft. While working with Tom McDermott, the information we obtained percolated here so I've been following up as much as I can. Daniel
  Message 182 of 259  
19 Sep 15 07:05
Maxim S. Shatskih
xxxxxx@storagecraft.com
Join Date: 20 Feb 2003
Posts To This List: 10395
Driver Signing Practical Info

> For the benefit of others on this list, here is the definition from = Urban Dictionary: Thanks! for me non-native-speaker, "piss up" sounds like "some major = annoyance due to major failure". It reminds me on SNAFU :-) --=20 Maxim S. Shatskih Microsoft MVP on File System And Storage xxxxx@storagecraft.com http://www.storagecraft.com
  Message 183 of 259  
19 Sep 15 08:56
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Thank you Mr Whitaker, and welcome. Thanks for taking the time to help us out with this unexpectedly confusing issue. Hope you'll stick around and perhaps answer a few other questions in you spare time :-) Peter OSR @OSRDrivers
  Message 184 of 259  
23 Sep 15 15:52
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

<quote> You're right. I ran a signed driver package through the attestation process today (it took 3 hours again). The CAT file has been completely replaced, but the attestation SHA2 signatures have been appended to the executables, and my SHA1 signature is still present. My 71k binary now has 18k bytes of certificates added to it... -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc. </quote> Ok Tim, my question to you is this -- since your CAT file has been completely replaced (and I assume now has only the Attestation signature), will your driver package load successfully on downlevel OS's?
  Message 185 of 259  
23 Sep 15 16:05
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > <quote> > You're right. I ran a signed driver package through the attestation > process today (it took 3 hours again). The CAT file has been completely > replaced, but the attestation SHA2 signatures have been appended to the > executables, and my SHA1 signature is still present. > My 71k binary now has 18k bytes of certificates added to it... > </quote> Ok Tim, my question to you is this -- since your CAT file has > been completely replaced (and I assume now has only the Attestation > signature), will your driver package load successfully on downlevel OS's? No. Older systems complain that the package was not tested on this version of Windows. It's the same dreaded red "unsigned driver" dialog, but with different text. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 186 of 259  
23 Sep 15 16:12
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

So the fact that Sysdev does not replace any embedded signatures is not really helpful to you at all then? By replacing your CAT file, they have wiped out your SHA1 signature on the package. So if you want to install as a package, you still need 2 separate driver packages for Win10 and downlevel OS's. Is that correct? If that is the case, then what is meant by the term "dual-signed" drivers? Is that only possible for WHQL signed drivers?
  Message 187 of 259  
23 Sep 15 16:41
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > So the fact that Sysdev does not replace any embedded signatures is not really helpful to you at all then? By replacing your CAT file, they have wiped out your SHA1 signature on the package. So if you want to install as a package, you still need 2 separate driver packages for Win10 and downlevel OS's. Is that correct? Correct. > If that is the case, then what is meant by the term "dual-signed" drivers? Is that only possible for WHQL signed drivers? Correct, and I THINK that's what the Microsoft reps have actually said. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 188 of 259  
23 Sep 15 16:54
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Alright, let me explain about our scenario. Going forward, I'm trying to figure out a logical approach for our situation, and keep it as simple as possible. 1. We have software-only drivers, and have deployed simply by copying our .sys files to \System32\Drivers 2. Thus we have no INF file or CAT file, and do not use Plug & Play to install, because we have no hardware. 3. We recognize that to support Attestation signing for Win10, we need to package our drivers, create an INF, etc. Which means we also have to change the way our drivers get installed on Win10. 4. However, why wouldn?t our embed signed .sys files continue to work OK on downlevel OS?s, where we are not deploying as a driver package -- not deploying the INF and CAT files? And they would also be fine as part of the Attestation package, where on Win10 all that is being checked is the CAT file, which would pass under the Attestation rules (no testing required).
  Message 189 of 259  
23 Sep 15 17:10
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > 1. We have software-only drivers, and have deployed simply by copying our .sys files to \System32\Drivers > 2. Thus we have no INF file or CAT file, and do not use Plug & Play to install, because we have no hardware. > 3. We recognize that to support Attestation signing for Win10, we need to package our drivers, create an INF, etc. Which means we also have to change the way our drivers get installed on Win10. This is not true, and this is another case where I think you have to read between the lines of what was said. For now, you have to concoct a fake INF file in order to pass through attestation, but I don't think anyone has said that the copy-and-Service-Manager installation method is now dead. So, all you should have to do is pass your driver and your fake INF through attestation. That will give you a CAT file which you can discard, and a SYS file that has your SHA1 signature AND the Microsoft SHA2 signature. You can then copy that into place just like you always have, and it should also work on Win 7. It won't work on XP and Server 2003, because they can't handle multiple certificate chains. > 4. However, why wouldn?t our embed signed .sys files continue to work OK on downlevel OS?s, where we are not deploying as a driver package -- not deploying the INF and CAT files? And they would also be fine as part of the Attestation package, where on Win10 all that is being checked is the CAT file, which would pass under the Attestation rules (no testing required). I don't believe you need the CAT file. I don't think you could use it if you have one. There's no way to pre-install a non-PnP package. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 190 of 259  
23 Sep 15 17:24
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Tim, what you say makes perfect sense. I have just gotten a more meaningful, straightforward opinion from you than I have in 29 days of back and forth with MSFT support. So, because we have software-only drivers deployed via copy-and-Service-Manager installation method, we can effectively achieve the goal of having dual-signed drivers that are not WHQL signed. If this is indeed true, it is very good news for us.
  Message 191 of 259  
23 Sep 15 17:38
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > Tim, what you say makes perfect sense. I have just gotten a more meaningful, straightforward opinion from you than I have in 29 days of back and forth with MSFT support. > > So, because we have software-only drivers deployed via copy-and-Service-Manager installation method, we can effectively achieve the goal of having dual-signed drivers that are not WHQL signed. If this is indeed true, it is very good news for us. I would encourage you to try it and let us know. Do you have your EV token yet? -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 192 of 259  
23 Sep 15 17:47
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Yes, we have the EV token, but we are still waiting on our legal department to consider and sign all the various legal agreements. Since our executables will have the dual signatures and we would pass under the grandfathering, the only way I see to test this is to try it on Win10 Enterprise with the Device Guard configurable code integrity policy set to non-audit mode (which effectively ratchets up the enforcement to require at least Attestation signature).
  Message 193 of 259  
23 Sep 15 19:04
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > Yes, we have the EV token, but we are still waiting on our legal department to consider and sign all the various legal agreements. > > Since our executables will have the dual signatures and we would pass under the grandfathering, the only way I see to test this is to try it on Win10 Enterprise with the Device Guard configurable code integrity policy set to non-audit mode (which effectively ratchets up the enforcement to require at least Attestation signature). Well, I suppose you could send in your package with your driver binary unsigned, and see if you can install the result. Since attestation is free, it wouldn't cost anything. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 194 of 259  
26 Sep 15 15:14
ntdev member 163018
xxxxxx@gmail.com
Join Date:
Posts To This List: 3
Driver Signing Practical Info

Hello, *I've posted a similar message but it doesn't appear on the list. I've tried sysdev EV signing on non PnP volume filter driver with fake INF and it worked. After that I've installed it by copy-and-Service-Manager installation method and a message that "A digitally signed driver is required" appeared on the screen. After restart "Preparing Automatic Repair"/"Diagnostic PC" and recovery environment started. The only way to boot the system is to "Disable Signature Enforcement" option. Also I've tried sysdev EV signing on a different PnP driver and it boots OK on the same system. How I need to proceed to make it work? Maybe WHQL is required? btw Secure Boot is OFF on my system. Thank you, Mark
  Message 195 of 259  
28 Sep 15 12:24
ntdev member 163018
xxxxxx@gmail.com
Join Date:
Posts To This List: 3
Driver Signing Practical Info

Hello, I've fixed the issue. It was because token support software was used for signing. New cross-cert "DigiCert High Assurance EV Root CA" that is issued by "Microsoft Code Verification Root" was downloaded and signtool used instead. Everything boots OK after that. Best Regards, Mark
  Message 196 of 259  
28 Sep 15 12:59
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > I've tried sysdev EV signing on non PnP volume filter driver with fake INF and it worked. > After that I've installed it by copy-and-Service-Manager installation method and a message > that "A digitally signed driver is required" appeared on the screen. Interesting -- that's not what I expected. Was your driver binary signed during the attestation process? Since there's no way to pre-install a non-PnP driver, it's not clear to me how this could be made to work. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 197 of 259  
28 Sep 15 23:49
ntdev member 163018
xxxxxx@gmail.com
Join Date:
Posts To This List: 3
Driver Signing Practical Info

On Mon, Sep 28, 2015 at 7:59 PM, Tim Roberts <xxxxx@probo.com> wrote: > > Interesting -- that's not what I expected. Was your driver binary > > signed during the attestation process? > Yes. I've created fake driver package for non PnP driver. Compiled sys and > Inf2Cat fake inf file: [Version] Signature="$WINDOWS NT$" Class=Volume ClassGuid={71a27cdd-812a-11d0-bec7-08002be2092f} Provider=%PROV% DriverVer=08/08/2010, 1.0.0.0 CatalogFile=Driver.cat [DestinationDirs] DefaultDestDir = 12 [ControlFlags] BasicDriverOk=* ;***************************************** ; Install Section ;***************************************** [Manufacturer] %StdMfg%=Standard,NT$ARCH$ [Standard.NT$ARCH$] %Driver.DeviceDesc%=Driver_Device, STORAGE\Driver [Driver_Device.NT] ; ; Nothing to do (these devices are raw). We just needed an INF ; match so these don't show up as "unknown" devices. ; ;-------------- Service installation [Driver_Device.NT.Services] AddService = ,2, ; Run the device RAW [Strings] PROV = "Copyright (C) 2015 DUMMY LLC" StdMfg = "(Standard system devices)" Driver.DeviceDesc = "Driver" ; End Of File. After that signed CAT and SYS with signtool EV certificate (+ cross cert from Microsoft site). All 3 files INF/CAT/SYS archived to CAB with CABDIR. CAB was signed again with EV certificate. CAB was uploaded to sysdev Microsoft site and submission was created. Submission was Approved. I've downloaded ZIP and copied SYS from it. SYS was copied to system32\drivers and driver entry was created within Services. Let me know if you need more details. Best Regards, Mark > Since there's no way to pre-install a non-PnP driver, it's not clear to > me how this could be made to work. > > -- > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > --- <...excess quoted lines suppressed...> --
  Message 198 of 259  
29 Sep 15 13:38
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

Mark Twen wrote: > On Mon, Sep 28, 2015 at 7:59 PM, Tim Roberts <xxxxx@probo.com > <mailto:xxxxx@probo.com>> wrote: > > > > Interesting -- that's not what I expected. Was your driver binary > > signed during the attestation process? > > Yes. I've created fake driver package for non PnP driver. Compiled > sys and Inf2Cat fake inf file: > I don't know the right answer. I expected that to work. I notice that you do not mention your SYS file in any fake CopyFiles directives, but all that means is that SYS won't be checksummed in the CAT, and since you aren't using the resulting CAT anyway, it shouldn't matter. This is an icky problem. I hesitate to suggest that a product support incident may be required. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 199 of 259  
30 Sep 15 14:09
David Pastor
xxxxxx@qustodio.com
Join Date: 22 Sep 2015
Posts To This List: 2
Driver Signing Practical Info

Hello, I'm quite confusing about how the Deprecation of SHA-1 Hashing Algorithm for Microsoft Root Certificate Program and could affect it to our development for Windows XP and Vista platforms (current signed executable, kernel filter driver and MSI files and the future ones). Now, for Windows XP SP3 and Windows Vista platforms we are signing all files with our SHA1 certificate and Microsoft cross-signed certificate VeriSign Class 3 Code Signing 2010 CA. The certification chain is: VeriSign (Thumbprint: 4e b6 d5 78 49 9b 1c cf 5f 58 1e ad 56 be 3d 9b 67 44 a5 e5) <=> VeriSign Class 3 Code Signing 2010 CA (Thumbprint: 49 58 47 a9 31 87 cf b8 c7 1f 84 0c b7 b4 14 97 ad 95 c6 4f) <=> Our Certificate But we have some doubts and questions related to the SHA1 certificates involved into the code-signing for those platforms after 31 Dec 2015: 1) Will this certification chain still be valid after 31 Dec 2015? If so, two questions: 1.1) How long the certificate chain will be valid for all already signed files? 1.2) How long can we continue signing files using our SHA1 certificate (not expired) and the VeriSign Class 3 Code Signing 2010 CA (Thumbprint: 49 58 47 a9 31 87 cf b8 c7 1f 84 0c b7 b4 14 97 ad 95 c6 4f) certificate after 31 Dec 2015? Could we have issues timestamping a file using SHA1 certificates? 2) If certification chain will not be valid or un-trusted after 31 Dec 2015 then how we sign executable, kernel filter drivers and MSI files after that date? Will we need a new SHA2 certificate to be able to sign those files but using a SHA1 digest signature (I am not sure that this will work for Windowns XP SP3 and Vista)? Kind regards and thanks in advance.
  Message 200 of 259  
30 Sep 15 14:45
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@qustodio.com wrote: > I'm quite confusing about how the Deprecation of SHA-1 Hashing Algorithm for Microsoft Root Certificate Program and could affect it to our development for Windows XP and Vista platforms (current signed executable, kernel filter driver and MSI files and the future ones). > ... "Confusion" seems to be the name of the game in the certificate world. > But we have some doubts and questions related to the SHA1 certificates involved into the code-signing for those platforms after 31 Dec 2015: > > 1) Will this certification chain still be valid after 31 Dec 2015? If so, two questions: Yes. The only change is that certificate authorities are now officially discouraged from selling you brand new SHA1 certificates. It doesn't mean they cannot do so, nor does it mean your existing certificates will suddenly explode. > 1.1) How long the certificate chain will be valid for all already signed files? Forever, as long as they are timestamped. Nothing will change here. > 1.2) How long can we continue signing files using our SHA1 certificate (not expired) and the VeriSign Class 3 Code Signing 2010 CA (Thumbprint: 49 58 47 a9 31 87 cf b8 c7 1f 84 0c b7 b4 14 97 ad 95 c6 4f) certificate after 31 Dec 2015? Until the certificate expires. Nothing will change here. > Could we have issues timestamping a file using SHA1 certificates? No. Nothing will change here. > 2) If certification chain will not be valid or un-trusted after 31 Dec 2015 then how we sign executable, kernel filter drivers and MSI files after that date? Will we need a new SHA2 certificate to be able to sign those files but using a SHA1 digest signature (I am not sure that this will work for Windowns XP SP3 and Vista)? Nothing will change. You will need an EV SHA2 certificate to submit drivers for Windows 10 signing, and you COULD use your non-EV SHA2 certificate to sign for Windows 7 and Windows 8. To sign for XP and Vista, you will still need an SHA1 certificate. Put simply, the deprecation really doesn't mean very much. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 201 of 259  
30 Sep 15 16:09
Vikram Parthasarathy
xxxxxx@ni.com
Join Date: 17 Jul 2015
Posts To This List: 14
Driver Signing Practical Info

Latest article from Microsoft - http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcem ent-of-authenticode-code-signing-and-timestamping.aspx
  Message 202 of 259  
30 Sep 15 16:34
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

The problem is, I don't see kernel-mode code signing addressed in this article. One of the PROBLEMS is that MSFT has addressed these signing issues in isolation. "Here are the rules for signing ...(everything in the world, like MSIs and EXEs)..." and "Here are the rules for signing kernel-mode modules. It's like the user-mode people don't know what the kernel-mode people are doing, and vice-versa. In fact, it's not difficult to believe that this is true... they're totally different folks... but they could at least give us the ILLUSION that they're talking to each other by having PMs from each teach review and comment on these sorts of posts. It would save a lot of confusion out here in the third party community where we hang on every word on what has been a very confusing, and for some worrisome, topic. Peter OSR @OSRDrivers
  Message 203 of 259  
30 Sep 15 16:49
Vikram Parthasarathy
xxxxxx@ni.com
Join Date: 17 Jul 2015
Posts To This List: 14
Driver Signing Practical Info

In the "Schedule" table, it briefly says "Note: no kernel mode enforcement" but it's not called out anywhere else. But seems like the deprecation is definitely happening for user-mode stuff. This means after Jan 1 2016, we need to start signing our exes, msis, dlls etc. with sha256. Atleast that's what I think it means.
  Message 204 of 259  
01 Oct 15 06:29
David Pastor
xxxxxx@qustodio.com
Join Date: 22 Sep 2015
Posts To This List: 2
Driver Signing Practical Info

Hello Tim, And thank you very much for you response. "Confusion" seems to be the name of the game in the certificate world. > Yes, I agree with you :) > > 1) Will this certification chain still be valid after 31 Dec 2015? If > so, two questions: > > Yes. The only change is that certificate authorities are now officially > discouraged from selling you brand new SHA1 certificates. It doesn't > mean they cannot do so, nor does it mean your existing certificates will > suddenly explode. > Ok for already signed and timestamped files prior 31 Dec 2015. > > 1.2) How long can we continue signing files using our SHA1 certificate > (not expired) and the VeriSign Class 3 Code Signing 2010 CA (Thumbprint: 49 > 58 47 a9 31 87 cf b8 c7 1f 84 0c b7 b4 14 97 ad 95 c6 4f) certificate after > 31 Dec 2015? > > Until the certificate expires. Nothing will change here. > So after 31 Dec 2015, I could continue signing and timestamping all new kernel filter drivers for Windows XP and Vista using my SHA1 and cross-sign certificate issued by VeriSign as usually and those files will work fine, isn't it? If I understand correctly, I will only need is to renew my current SHA1 certificate issued by VeriSign as a developer that supports Windows XP and Windows Vista platforms. Nothing changes the current signing process used for those OS versions. And the decision to renew or provide the SHA-1 certificate is on the certification provider side. > > Could we have issues timestamping a file using SHA1 certificates? > > No. Nothing will change here. > I'm referring trying to sing and timestamp files using SHA1 certificate and SHA-1 signature after 31 Dec 2015. > > > 2) If certification chain will not be valid or un-trusted after 31 Dec > 2015 then how we sign executable, kernel filter drivers and MSI files after > that date? Will we need a new SHA2 certificate to be able to sign those > files but using a SHA1 digest signature (I am not sure that this will work > for Windowns XP SP3 and Vista)? > > Nothing will change. You will need an EV SHA2 certificate to submit > drivers for Windows 10 signing, and you COULD use your non-EV SHA2 <...excess quoted lines suppressed...> Why I need a non-EV SHA2 certificate to sing files for Windows 7 and 8.x? Cannot I sign those files using EV SHA2 certificate? And other question, someone know what will happening with MSI signed files? Is it possible to have a single signed MSI file for all Windows platforms? I haven't test it but it seems that some OS doesn't support double-sign (eg: Windows XP). At section "Concerns with MSIs" from wiki page ( http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcem ent-of-authenticode-code-signing-and-timestamping.aspx#H1_A) says: "... it is possible to ship a single MSI that is appropriately trusted on all down-level editions of Windows by signing the MSI with a SHA-2 code signing certificate while maintaining a SHA-1 file hash." But, will it work for a Windows XP SP3 and Windows Vista? The certification path will include SHA2 certificates. Thank you in advance! -- David --
  Message 205 of 259  
01 Oct 15 08:01
Christiaan Ghijselinck
xxxxxx@compaqnet.be
Join Date: 21 Mar 2002
Posts To This List: 476
Driver Signing Practical Info

Hello all To create an account at the portal , one need to submit a signed winqual.exe file. When I sign with my current Audenthicode SHA1 code signing certificate , I get the message that it needs to be signed by a Verisign certificate. Is this going to change ? I don't like this restriction, Christiaan --
  Message 206 of 259  
01 Oct 15 10:40
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> When I sign with my current Audenthicode SHA1 code signing certificate , I get the message that it needs to be signed by a Verisign certificate. </quote> This has been the case since, well, forever. Hence the "super duper discount deal" on Verisign SHA1 certificates that we've discussed here in the past. To the best of my knowledge, when you get an EV Certificate it can be from any approved EV CA... not just Verisign/Symantec. Peter OSR @OSRDrivers
  Message 207 of 259  
01 Oct 15 14:05
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

David Pastor wrote: > > > > > 1) Will this certification chain still be valid after 31 Dec 2015? If so, two questions: > > Yes. The only change is that certificate authorities are now > officially > discouraged from selling you brand new SHA1 certificates. It doesn't > mean they cannot do so, nor does it mean your existing > certificates will <...excess quoted lines suppressed...> As far as I know, you can continue to sign driver packages with your pre-8/1/2015 SHA1 certificate until it expires, even if you do the signing after 12/31/2015, and even Windows 10 will accept it. > So after 31 Dec 2015, I could continue signing and timestamping all > new kernel filter drivers for Windows XP and Vista using my SHA1 and > cross-sign certificate issued by VeriSign as usually and those files > will work fine, isn't it? Yes. This will have to be true forever, unless they issue a hotfix for XP and Vista to support SHA2, and that seems unlikely. > > If I understand correctly, I will only need is to renew my current > SHA1 certificate issued by VeriSign as a developer that supports > Windows XP and Windows Vista platforms. Nothing changes the current > signing process used for those OS versions. > > And the decision to renew or provide the SHA-1 certificate is on the > certification provider side. Correct. > > Could we have issues timestamping a file using SHA1 certificates? > > No. Nothing will change here. > > > I'm referring trying to sing and timestamp files using SHA1 > certificate and SHA-1 signature after 31 Dec 2015. Yes, I know. The timestamp server doesn't know anything about your certificate, so it doesn't care. > Nothing will change. You will need an EV SHA2 certificate to submit > drivers for Windows 10 signing, and you COULD use your non-EV SHA2 > certificate to sign for Windows 7 and Windows 8. > > > > Why I need a non-EV SHA2 certificate to sing files for Windows 7 and > 8.x? Cannot I sign those files using EV SHA2 certificate? I worded that poorly. IF you happen to have a non-EV SHA2 certificate, you can use it to sign for Win 7 and Win 8. The EV SHA2 is only required for Win 10 attestation, and in that case it is only used for the CAB file. It doesn't matter whether you sign the individual files or not. > And other question, someone know what will happening with MSI signed > files? Is it possible to have a single signed MSI file for all Windows > platforms? > I haven't test it but it seems that some OS doesn't support > double-sign (eg: Windows XP). At section "Concerns with MSIs" from > wiki page > (http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforce ment-of-authenticode-code-signing-and-timestamping.aspx#H1_A) > says: > I am struggling to keep up with kernel-mode code signing. I know nothing at all about user-mode code signing. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 208 of 259  
01 Oct 15 14:11
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

Christiaan Ghijselinck wrote: > > To create an account at the portal , one need to submit a signed > winqual.exe file. When I sign with my current Audenthicode SHA1 code > signing certificate , I get the message that it needs to be signed by > a Verisign certificate. Is this going to change ? I don't like this > restriction, It doesn't matter what you like, those are the rules. The WHQL portal has always required a Verisign certificate, and only Verisign. With these new changes, they will now allow Digicert certificates as well. However, if you are hoping to use the Windows 10 attestation process, then you cannot use an SHA1 certificate as all. You must use the same EV SHA2 certificate that you will use to sign your submissions. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 209 of 259  
01 Oct 15 14:13
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@osr.com wrote: > To the best of my knowledge, when you get an EV Certificate it can be from any approved EV CA... not just Verisign/Symantec. The rules seem to be ever in flux, but it was my understanding from the documentation that, as of right now, only Verisign and Digicert were acceptable. It did say they hoped to open it to other vendors at some point. This might already have been changed. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 210 of 259  
01 Oct 15 14:32
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

Here is my current understanding of the state of certificate acceptance. If I have some of this wrong, let me know and I'll tweak it: http://timr.probo.com/signing.html -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 211 of 259  
02 Oct 15 08:48
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 2103
Driver Signing Practical Info

I think that x86 platforms with secure boot enabled also enforce kmcs. Cheers, Dave Cattley=20 Sent from my Windows Phone -----Original Message----- From: "Tim Roberts" <xxxxx@probo.com> Sent: =E2=80=8E10/=E2=80=8E1/=E2=80=8E2015 2:32 PM To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Subject: Re: [ntdev] Driver Signing Practical Info Here is my current understanding of the state of certificate acceptance. If I have some of this wrong, let me know and I'll tweak it: http://timr.probo.com/signing.html --=20 Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc. --- NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=3Dntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit:=20 http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.o= sronline.com/page.cfm?name=3DListServer=
  Message 212 of 259  
15 Oct 15 04:14
Advance J
xxxxxx@hotmail.com
Join Date: 25 Jun 2013
Posts To This List: 29
Driver Signing Practical Info

[quote] 01 Oct 15 14:13 Tim Roberts xxxxx@probo.com Join Date: 28 Jan 2005 Posts To This List: 10385 Driver Signing Practical Info xxxxx@osr.com wrote: > To the best of my knowledge, when you get an EV Certificate it can be from any approved EV CA... not just Verisign/Symantec. The rules seem to be ever in flux, but it was my understanding from the documentation that, as of right now, only Verisign and Digicert were acceptable. It did say they hoped to open it to other vendors at some point. This might already have been changed. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc. [/quote] I've confirmed the EV certificates for Windows is available from WoSign, they has updated details on their website. There should be more options for developers that may prefer to choose a local vendor.
  Message 213 of 259  
15 Oct 15 15:38
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@hotmail.com wrote: > I've confirmed the EV certificates for Windows is available from WoSign, they has updated details on their website. There should be more options for developers that may prefer to choose a local vendor. Have you verified that they work with the Microsoft portal? It's easy to say "we support Windows", but unless the Microsoft portal is configured to accept them, it isn't worth the paper it's printed on. Many vendors had code-signing certificates that advertised Windows support but did not work for KMCS. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 214 of 259  
16 Oct 15 01:50
Advance J
xxxxxx@hotmail.com
Join Date: 25 Jun 2013
Posts To This List: 29
Driver Signing Practical Info

Yes, they announced that their product can support signing for Windows 10 kernel drivers in the EV credit mechanism, and this certificate can also be used to submit HKC application, with the portal you mentioned. I am going to purchase one, later will post our test result here.
  Message 215 of 259  
16 Oct 15 08:54
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Thank you, Mr. "Advance J" -- We'll look forward to your confirmation when you report back. Peter OSR @OSRDrivers
  Message 216 of 259  
20 Oct 15 12:20
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

(this thread will never die) Another wrinkle! According to yet another new and improved policy announced today, you will have to have "at least one" EV certificate associated with your sysdev account to be able to make a submission. BUT you CAN SIGN your submission with either the EV certificate or your standard non-EV certificate until 1 May 2016. After that time, you'll need to use the EV certificate for sysdev submissions. I don't understand the motivation for this change. You still have to HAVE the EV Certificate, so why not sign with it? But, apparently, this makes it easier for... somebody. Peter OSR @OSRDrivers
  Message 217 of 259  
20 Oct 15 13:19
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@osr.com wrote: > Another wrinkle! > > According to yet another new and improved policy announced today, you will have to have "at least one" EV certificate associated with your sysdev account to be able to make a submission. BUT you CAN SIGN your submission with either the EV certificate or your standard non-EV certificate until 1 May 2016. After that time, you'll need to use the EV certificate for sysdev submissions. > > I don't understand the motivation for this change. You still have to HAVE the EV Certificate, so why not sign with it? But, apparently, this makes it easier for... somebody. I've been wondering how large companies will handle teams of developers. In the past, one could ship the certificate file to whoever needed it. With EV, you have to have the physical token device. Does Intel just order 20 duplicate devices and hand them to everyone who needs to do signing? -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 218 of 259  
20 Oct 15 13:45
Mark Fontana
xxxxxx@kinura.net
Join Date: 05 Jul 2013
Posts To This List: 3
Driver Signing Practical Info

At my larger company, we have one signing server shared by all of the build servers. They drop binaries to be signed into a unique folder that they create beneath a certain top-level folder, the binaries are picked up and signed by a script that periodically scans the directory tree, then the requesting build server retrieves the results shortly after. Some simple "presence of an empty file" handshaking indicates "ready for signing" and "signing done". EV and its token device ought to fit into this scheme OK, but we haven't changed over yet. On 10/20/2015 12:19 PM, Tim Roberts wrote: > I've been wondering how large companies will handle teams of > developers. In the past, one could ship the certificate file to > whoever needed it. With EV, you have to have the physical token > device. Does Intel just order 20 duplicate devices and hand them to > everyone who needs to do signing?
  Message 219 of 259  
20 Oct 15 13:59
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> Does Intel just order 20 duplicate devices and hand them to everyone who needs to do signing? </quote> In my experience, in larger companies devs can't release sign anything. Where there are multiple divisions or autonomous groups, that release products to customers, every group or division just has their own Cert. Peter OSR @OSRDrivers
  Message 220 of 259  
20 Oct 15 14:40
Jan Bottorff
xxxxxx@pmatrix.com
Join Date: 16 Apr 2013
Posts To This List: 377
Driver Signing Practical Info

Yup, the company I work at got a bunch of EV keys for everybody who needs one. I assume they get a discount, but don’t actually know since I didn’t do the work to order the keys. Jan On 10/20/15, 10:19 AM, "xxxxx@lists.osr.com on behalf of Tim Roberts" <xxxxx@lists.osr.com on behalf of xxxxx@probo.com> wrote: >I've been wondering how large companies will handle teams of >developers. In the past, one could ship the certificate file to whoever >needed it. With EV, you have to have the physical token device. Does >Intel just order 20 duplicate devices and hand them to everyone who >needs to do signing?
  Message 221 of 259  
20 Oct 15 14:41
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

Jan Bottorff wrote: > Yup, the company I work at got a bunch of EV keys for everybody who needs one. I assume they get a discount, but don’t actually know since I didn’t do the work to order the keys. The Digicert web site seems to imply they'll send me additional duplicate tokens at no additional charge. I just wondered if that's what Real Live Companies were doing. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 222 of 259  
20 Oct 15 15:12
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 3971
Driver Signing Practical Info

We were told that the policy is "one company - one ev cert". I found that difficult to believe. Mark Roddy On Tue, Oct 20, 2015 at 1:57 PM, <xxxxx@osr.com> wrote: > <quote> > Does > Intel just order 20 duplicate devices and hand them to everyone who > needs to do signing? > </quote> > > In my experience, in larger companies devs can't release sign anything. > > Where there are multiple divisions or autonomous groups, that release > products to customers, every group or division just has their own Cert. <...excess quoted lines suppressed...> --
  Message 223 of 259  
21 Oct 15 08:09
David R. Cattley
xxxxxx@msn.com
Join Date: 09 Jul 2002
Posts To This List: 2103
Driver Signing Practical Info

> (this thread will never die) I want to say that this has been amusing; like listening two a four year old tell a story constantly adding new characters, changing the plot, swinging off in a new direction. But irritatingly we are the characters in that story. I???m just holding on tight for the next plot turn???. I???m not even sure how to summarize this thread or the published, spoken, and intimated information on signing anymore. I suspect it will be: 1. Sign something. 2. Submit something. 3. Get rejected. 4. Ask SysDev why it was rejected. 5. Rinse & Repeat Dave Cattley --
  Message 224 of 259  
21 Oct 15 13:31
Eric Berge
xxxxxx@gmail.com
Join Date: 17 Oct 2011
Posts To This List: 15
Driver Signing Practical Info

The problem with the "drop files in a folder and wait for the signing server" approach is that with EV certificates, it appears that a human needs to be on the console of the server ready to type the password for the EV certificate. At least that's been my experience with our new DigiCert EV certificate. I attempted to circumvent this with the "single signon" option with the DigiCert-supplied SafeNet tools but that only works until the console goes into lockscreen and then you need to unlock and enter the password again. But at least that keeps you from needing to enter the password for every individual invocation of signtool. Also, remote desktop does not work for, as the password entry popup does not occur there although I've had some luck with VNC for remote signing access. And, by the way, we have been able to take a double-signed driver, submit it for online signing and it did appear to preserve the double signing (i.e., came back with three signatures: both our SHA1 and EV-SHA256 plus a "Microsoft Windows Hardware Compatibility Publisher" signature). However, as pointed on in earlier posts this may not help you if you need to install the catalog file. We have a non-PNP driver so I'm hoping that's good enough but haven't been able to figure out the exact magic to configure Device Guard to verify this yet. Our EV cert appears to be early enough (Aug 3) to be "grandfathered" in for Windows 10 (unfortunately for testing this but perhaps fortunately for other reasons...). That's interesting because that's after Windows 10 RTM so they must be given some "margin" here beyond the RTM date (I thought I saw a previous post indicating this was pushed out to 8/31 but I can't seem to find that post again to confirm that).
  Message 225 of 259  
21 Oct 15 13:37
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > ...Our EV cert appears to be early enough (Aug 3) to be "grandfathered" in for Windows 10 ... Did you mean "Our non-EV cert"? -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 226 of 259  
21 Oct 15 14:34
Eric Berge
xxxxxx@gmail.com
Join Date: 17 Oct 2011
Posts To This List: 15
Driver Signing Practical Info

No, I meant our EV certificate. To test this, I signed with our EV certificate only (no double-signing with SHA1) and did not submit the driver to the portal and installed on Windows 10. I just re-did this test to verify that this wasn't just my confusion. Does that suggest there might be something else in play that allowed it to load the driver without sysdev signing?
  Message 227 of 259  
21 Oct 15 14:42
Eric Berge
xxxxxx@gmail.com
Join Date: 17 Oct 2011
Posts To This List: 15
Driver Signing Practical Info

And to eliminate the possibility of Device Guard playing a role, I confirmed that there was not a policy in place in c:\Windows\System32\CodeIntegrity (hopefully that was sufficient to be sure of that...).
  Message 228 of 259  
22 Oct 15 07:03
Eugene
xxxxxx@mail.ru
Join Date: 22 Feb 2001
Posts To This List: 61
Driver Signing Practical Info

Hi, folks! I'm totally confused. Until today we plan to use our existing SHA1 certificate (valid from 12.11.2014 to 06.01.2018) and cross-certificate to sign our products until it expired. We plan to get an EV certificate to support UEFI/Secure Boot/.. in a new products. We have 2 main groups of our products: 1. Products that target Windows XP - Windows 8.1. 2. Products that target Windows Vista - Windows 10. We have bunch of drivers and affected modules: a) Hardware PnP driver b) Hardware PnP KMDF driver c) PnP device filter drivers (non KMDF), some of them installed with inf/cat, some - with SCM d) Software drivers e) File system filter drivers f) NDIS filter driver g) LSA module h) UEFI module (loader and driver) All our msi also signed.. So.. What my company should to do? How many types of certificates we need to buy? We still need a support our old products (group 1) and plan to release a new products (group 2). In every group we use one install package for supported OSes. We have projects that include one or two drivers and heavy one that includes almost all of our drivers/modules (for example our so called "endpoint protection").. Thanks in advance.
  Message 229 of 259  
22 Oct 15 08:35
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> I'm totally confused. </quote> Welcome to the club. Everyone here is confused. Even those of us who THINK we're not confused, are merely too confused to know they're confused. This is what happens when you layoff almost the entire technical writing team. But let's not go there today. To your questions: The Win10 answers are here: <https://www.osr.com/nt-insider/2015-issue2/driver-signing-windows-10/ > For drivers prior to Win7, you'll need to sign using the "traditional" SHA1 certificate. Peter OSR @OSRDrivers
  Message 230 of 259  
22 Oct 15 12:56
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@osr.com wrote: > <quote> > I'm totally confused. > </quote> > > Welcome to the club. Everyone here is confused. Even those of us who THINK we're not confused, are merely too confused to know they're confused. +1 for quote of the week. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 231 of 259  
24 Oct 15 17:22
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 3971
Driver Signing Practical Info

I put off getting confused until this week. Now I am completely confused. Luckily the symantec docs are up to their usual standards (non-existent) and are thus far better than the microsoft docs, as they contain fewer errors. Mark Roddy On Thu, Oct 22, 2015 at 12:55 PM, Tim Roberts <xxxxx@probo.com> wrote: > xxxxx@osr.com wrote: > > <quote> > > I'm totally confused. > > </quote> > > > > Welcome to the club. Everyone here is confused. Even those of us who > THINK we're not confused, are merely too confused to know they're confused. > > +1 for quote of the week. > <...excess quoted lines suppressed...> --
  Message 232 of 259  
06 Nov 15 11:32
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

FYI, a new document was just released by Microsoft concerning Win10 Attestation Signing. Here is the link https://msdn.microsoft.com/en-us/windows-drivers/develop/attestation_signing_a_ke rnel_driver_for_public_release Also, we have been informed that Step 5 (Sign the CAB file submission with your EV Cert) has just been changed, as follows: The EV cert will be required when opening an user or company account with Sysdev. Once that account has been established, you can use a standard SHA2 non-EV cert to sign the CAB file. This was modified to accommodate companies that have multiple signing sites and the use of a HSM Dongle is not practical.
  Message 233 of 259  
06 Nov 15 11:37
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Mr. McDermott... THANKS! Nice pointer to that article. <quote> we have been informed that Step 5 (Sign the CAB file submission with your EV Cert) has just been changed </quote> Yes. This change was announced several weeks back. *I* was told that the accommodation was temporary... I guess we'll see. I really appreciate you taking the time to update the community as you learn about this issue. In time, and with some practical use, I'm sure this whole process will get sorted out. Until then, however, we've got to help each other as much as we can. Peter OSR @OSRDrivers
  Message 234 of 259  
06 Nov 15 11:45
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

You're welcome. Glad to share with the community. (Also doing my part to ensure the longevity of this thread, lol.)
  Message 235 of 259  
06 Nov 15 17:27
Don Marshall
xxxxxx@live.com
Join Date: 06 Nov 2015
Posts To This List: 1
Driver Signing Practical Info

Also new up on MSDN is a Code Signing FAQ in "Get a code signing certificate" that includes an OS signing matrix. https://msdn.microsoft.com/en-us/library/windows/hardware/hh801887.aspx The new content is located at the bottom of the topic.
  Message 236 of 259  
09 Nov 15 14:40
Kashif Hasan
xxxxxx@gmail.com
Join Date: 28 Sep 2007
Posts To This List: 7
Driver Signing Practical Info

Can anyone confirm which date is being referred to in the statements which describe how existing drivers will function, such as: "Cross-signed using a SHA-1 certificate issued prior to July 29, 2015" Does this refer to the issue date of the Cross-Signing certificate which we downloaded from Microsoft's website? Or does this refer to the issue date of the certificate issued to be us by our 3rd party Certificate Authority? Our product uses a certificate issued by GlobalSign on 9/1/2015, cross-signed by the GlobalSign Root CA available at https://msdn.microsoft.com/en-us/library/windows/hardware/dn170454(v=vs.85).aspx and this currently loads on Windows 10 without issue, which leads me to believe the 1st interpretation is correct. But it sure would be nice if someone who knows for certain could confirm this.
  Message 237 of 259  
09 Nov 15 14:42
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> Does this refer to the issue date of the Cross-Signing certificate which we downloaded from Microsoft's website? Or does this refer to the issue date of the certificate issued to be us by our 3rd party Certificate Authority? </quote> The latter. The former doesn't make any sense. Peter OSR @OSRDrivers
  Message 238 of 259  
09 Nov 15 15:18
Kashif Hasan
xxxxxx@gmail.com
Join Date: 28 Sep 2007
Posts To This List: 7
Driver Signing Practical Info

Agreed the former doesn't make any sense. Neither does the fact that a SHA1 Code Signing Certificate issued on 9/1/2015 can be used to sign a binary driver file and have that file successfully load on Win7, Win8 and Win10, at least not based on what I have read on this thread and other such resources. Can anyone offer an explanation as to why we are seeing this work currently and assurances if it will continue to work in the future? Our driver is a software only product, loaded through the CreateService() api, but I gather this should not make a difference either.
  Message 239 of 259  
09 Nov 15 15:25
Vikram Parthasarathy
xxxxxx@ni.com
Join Date: 17 Jul 2015
Posts To This List: 14
Driver Signing Practical Info

I don't think the policy has actually been enforced yet. http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver- signing-changes-in-windows-10.aspx#10645947 http://blogs.msdn.com/b/jpwdkblog/archive/2015/09/18/windows-10-sha-1.aspx (use translate)
  Message 240 of 259  
09 Nov 15 16:19
Kashif Hasan
xxxxxx@gmail.com
Join Date: 28 Sep 2007
Posts To This List: 7
Driver Signing Practical Info

Thanks Vikram. The first link you sent does not work, but the 2nd, after translating through Google, does seem to indicate the policy is not currently being enforced. This would explain the behavior we are seeing and would indicate we need to update our digital signatures. I suppose asking for documentation in the English language which clearly explains this is asking too much? Acquiring EV certs is expensive and cumbersome, would love to know if we really need to do this or not.
  Message 241 of 259  
09 Nov 15 17:11
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > Our product uses a certificate issued by GlobalSign on 9/1/2015, cross-signed by the GlobalSign Root CA available at https://msdn.microsoft.com/en-us/library/windows/hardware/dn170454(v=vs.85).aspx and this currently loads on Windows 10 without issue, which leads me to believe the 1st interpretation is correct. But it sure would be nice if someone who knows for certain could confirm this. The intent is that your certificate would not be accepted. However, there have been hints on the interwebs that there may be a magical registry entry that gets set during an upgrade installation of Win 10 that disables this particular check, to allow drivers coming from the old system to continue to work. You'd have to do a clean install of Win 10 to test that theory. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 242 of 259  
12 Nov 15 16:17
Kashif Hasan
xxxxxx@gmail.com
Join Date: 28 Sep 2007
Posts To This List: 7
Driver Signing Practical Info

Tried again with a clean install of Windows 10 64 bit and I see the same results. We are able to load our software driver, which is signed with a SHA1 Cert issued by GlobalSign on 9/1/2015, through a CreateService() call Can anyone confirm this policy is actually being enforced currently?
  Message 243 of 259  
19 Nov 15 04:30
Advance J
xxxxxx@hotmail.com
Join Date: 25 Jun 2013
Posts To This List: 29
Driver Signing Practical Info

These days I got my certificate issued by WoSign, still preparing for the submission jobs, and found that the page https://msdn.microsoft.com/en-us/library/windows/hardware/hh801887(v=vs.85).aspx was updated, added more players as authorized EV certificate vendor, including GlobalSign and WoSign. Good to see Microsoft is willing to open more information.
  Message 244 of 259  
07 Dec 15 17:53
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

Just wanted to point out that there is a very helpful section in a MSFT Hardware Dev Center document for "Code Signing FAQ", which succinctly summarizes the code signing situation. Includes a good "OS Support Summary" table at the end. Here is the link: https://msdn.microsoft.com/en-us/library/windows/hardware/hh801887#code_signing_f aq
  Message 245 of 259  
07 Dec 15 18:41
Jan Bottorff
xxxxxx@pmatrix.com
Join Date: 16 Apr 2013
Posts To This List: 377
Driver Signing Practical Info

I’ve looked at that table and it seems incomplete. For example, the table implies I can no longer use a cert from an approved CA, with a cross-certificate, to sign a driver for Server 2012 R2, even though this is exactly how many drivers (that are not HLK tested) have been signed in the last couple years. You would get a dialog asking if you wanted to trust the signing cert, or you could preinstall the cert. Server 2003 was very inflexible about driver signatures, but Server 2008 through Server 2012 R2 have been more flexible, in the past anyway. Server 2016 clearly seems to be going back to a totally inflexible signing policy, only allowing HLK certificated drivers. Jan On 12/7/15, 2:53 PM, "xxxxx@lists.osr.com on behalf of xxxxx@gmail.com" <xxxxx@lists.osr.com on behalf of xxxxx@gmail.com> wrote: >Just wanted to point out that there is a very helpful section in a MSFT Hardware Dev Center document for "Code Signing FAQ", which succinctly summarizes the code signing situation. Includes a good "OS Support Summary" table at the end. Here is the link: >https://msdn.microsoft.com/en-us/library/windows/hardware/hh801887#code_signing_ faq > > >--- >NTDEV is sponsored by OSR > >Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> > <...excess quoted lines suppressed...>
  Message 246 of 259  
07 Dec 15 19:17
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

I don't see how the table implies what you said. It would seem that your situation falls under the far right column (Cross-signed using a SHA-1 certificate issued prior to July 29, 2015), where the entry for Windows Server 2012 R2 says "Yes".
  Message 247 of 259  
07 Dec 15 20:07
Jan Bottorff
xxxxxx@pmatrix.com
Join Date: 16 Apr 2013
Posts To This List: 377
Driver Signing Practical Info

The table does not really say what happens with my current SHA2 EV cert, which I got after my old SHA1 cert expired, after July 29. In the past, this SHA2 EV cert with a cross certificate should work fine for kernel signing of Server 2012 R2 drivers. I have no idea if it still works for that or not, based on the table. The issue is if Server 2012 R2 will still work with cross signed drivers that have not been though HLK testing. The table needs another column that says what the behavior of certs made after July 29th are, for each OS. Maybe it needs a couple more columns to distinguish between SHA1 and SHA2 certs, made before and after July 29. Jan On 12/7/15, 4:17 PM, "xxxxx@lists.osr.com on behalf of xxxxx@gmail.com" <xxxxx@lists.osr.com on behalf of xxxxx@gmail.com> wrote: >I don't see how the table implies what you said. It would seem that your situation falls under the far right column (Cross-signed using a SHA-1 certificate issued prior to July 29, 2015), where the entry for Windows Server 2012 R2 says "Yes". > >-
  Message 248 of 259  
08 Dec 15 15:20
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

I agree that there are more potential scenarios which the table should also cover. Having said that, I believe that the July 29 date really only affects whether the old cross-signing procedure will be acceptable on Windows 10 in lieu of Attestation signing. I would bet that your cross-signing using the SHA2 EV cert issued after July 29 will work just fine on Server 2012 R2. Of course, absent definitive information from MSFT, we are left to speculate on these things, which is not good.
  Message 249 of 259  
08 Dec 15 16:06
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > Just wanted to point out that there is a very helpful section in a MSFT Hardware Dev Center document for "Code Signing FAQ", which succinctly summarizes the code signing situation. Includes a good "OS Support Summary" table at the end. Here is the link: > https://msdn.microsoft.com/en-us/library/windows/hardware/hh801887#code_signing_f aq There's a very interesting note here that I do not recall seeing before: *Windows 10 Earlier Certificate Transition Signing* * A driver signed with any certificate issued after July 29th, 2015, with time stamping, is not recommended for Windows 10. * A driver signed with any certificate that expires after July 29th, 2015, without time stamping, will work on Windows 10 until the certificate expires. What this SAYS is that the old driver signing scheme will continue to work for Windows 10 forever, but you have to feel guilty for using it. This finally matches the actual experience in the field, which is that attestation is not actually required for Windows 10, even with a brand new SHA1 certificate. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 250 of 259  
10 Dec 15 16:37
Tom McDermott
xxxxxx@gmail.com
Join Date: 03 Jun 2014
Posts To This List: 57
Driver Signing Practical Info

<quote> There's a very interesting note here that I do not recall seeing before: *Windows 10 Earlier Certificate Transition Signing* * A driver signed with any certificate issued after July 29th, 2015, with time stamping, is not recommended for Windows 10. * A driver signed with any certificate that expires after July 29th, 2015, without time stamping, will work on Windows 10 until the certificate expires. What this SAYS is that the old driver signing scheme will continue to work for Windows 10 forever, but you have to feel guilty for using it. This finally matches the actual experience in the field, which is that attestation is not actually required for Windows 10, even with a brand new SHA1 certificate. -- Tim Roberts, xxxxx@probo.com </quote> Now I'm really confused. Does this imply that if you got your certificate after July 29th, you can avoid Attestation signing by simply NOT using time stamping? This would be good until your new certificate expires -- not ideal, but does avoid Attestation for a number of years.
  Message 251 of 259  
10 Dec 15 20:40
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11487
Driver Signing Practical Info

xxxxx@gmail.com wrote: > Now I'm really confused. Does this imply that if you got your certificate after July 29th, you can avoid Attestation signing by simply NOT using time stamping? This would be good until your new certificate expires -- not ideal, but does avoid Attestation for a number of years. I think it says more than that. I think it says the attestation method is just an additional alternative (as opposed to the ONLY alternative), and that the current method will continue to work forever, regardless of the date of your certificate. That interpretation matches the experience in the field thus far. Phrases like "not recommended" are not very helpful here. Either it works or it doesn't, and if it works, then attestation is optional. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 252 of 259  
11 Dec 15 03:12
Christiaan Ghijselinck
xxxxxx@compaqnet.be
Join Date: 21 Mar 2002
Posts To This List: 476
Driver Signing Practical Info

> Phrases like "not recommended" are not very helpful here. Either it > works or it doesn't, and if it works, then attestation is optional. As far as I understood the doc's and the discussions from the past , SHA1 drivers signed with a cert issued after July 29th will install and run as long as UEFI secure boot is disabled ( or not present ),. When UEFI secure boot is enabled , drivers must be signed with the EV certificate. Christiaan ----- Original Message ----- From: "Tim Roberts" <xxxxx@probo.com> To: "Windows System Software Devs Interest List" <xxxxx@lists.osr.com> Sent: Friday, December 11, 2015 2:39 AM Subject: Re: [ntdev] Driver Signing Practical Info > xxxxx@gmail.com wrote: >> Now I'm really confused. Does this imply that if you got your certificate after July 29th, you can avoid Attestation signing by >> simply NOT using time stamping? This would be good until your new certificate expires -- not ideal, but does avoid Attestation >> for a number of years. > > I think it says more than that. I think it says the attestation method > is just an additional alternative (as opposed to the ONLY alternative), > and that the current method will continue to work forever, regardless of > the date of your certificate. That interpretation matches the <...excess quoted lines suppressed...>
  Message 253 of 259  
11 Dec 15 04:46
Mike Kemp
xxxxxx@sintefex.com
Join Date: 30 May 2006
Posts To This List: 273
Driver Signing Practical Info

I like this conclusion. It means this entire thread has been a waste of everyone's time and has caused unnecessary confusion and made people buy very expensive but unnecessary certificates. Can this have been MS's original poorly communicated plan or have they backed off in the face of catastrophic lack of driver / community support? Mike ----- Original Message ----- From: Tim Roberts To: Windows System Software Devs Interest List Sent: Friday, December 11, 2015 1:39 AM Subject: Re: [ntdev] Driver Signing Practical Info xxxxx@gmail.com wrote: > Now I'm really confused. Does this imply that if you got your certificate > after July 29th, you can avoid Attestation signing by simply NOT using > time stamping? This would be good until your new certificate expires -- > not ideal, but does avoid Attestation for a number of years. I think it says more than that. I think it says the attestation method is just an additional alternative (as opposed to the ONLY alternative), and that the current method will continue to work forever, regardless of the date of your certificate. That interpretation matches the experience in the field thus far. Phrases like "not recommended" are not very helpful here. Either it works or it doesn't, and if it works, then attestation is optional. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc. --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
  Message 254 of 259  
11 Dec 15 09:02
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

<quote> I think it says the attestation method is just an additional alternative (as opposed to the ONLY alternative) </quote> The certainly LOOKS like the final outcome. <quote> Can this have been MS's original poorly communicated plan or have they backed off in the face of catastrophic lack of driver / community support? </quote> Well, we KNOW that wasn't their original plan, because we have a very clear statement that describes what the original plan was. One thing you can say about Microsoft is that they are NOT afraid to change course if something isn't working in the market OR if they get the significant amounts of the right kind of push-back. We've seen this many, many, times over the years. If the OEMs provided strong feedback to MSFT that this wasn't a workable scheme, I suspect that'd be enough to get the policy changed. From what I've read here and in other places, I suspect this MIGHT have to do with the practical aspects of how EV Certs are managed. My original understanding was that any division/group/team of a corporation could get an EV Cert... However, (some? most of? all of?) the Certification Authorities don't seem to share this view. Thus, if you're Big Company X that's incorporated in Ireland, US headquarters in California, development teams around the world, and a product group in Colorado, how does that Colorado group get THE Corporate EV Cert to use for signing the products they release to the web? It's unworkable. Again, this is purely speculation on my part. I'll make some casual inquiries to see if I can find out any more about this, but it being just about half-past December I'm not sure I'll find the right people at home in Redmond to give us definitive answers. Peter OSR @OSRDrivers
  Message 255 of 259  
11 Dec 15 12:26
Vikram Parthasarathy
xxxxxx@ni.com
Join Date: 17 Jul 2015
Posts To This List: 14
Driver Signing Practical Info

This is my interpretation - Microsoft has not yet enabled this policy on Windows 10. When they do enable it through a Windows Update, your driver that was loading just fine will suddenly stop loading after this update. This will be a poor experience for end user clients. Hence they're recommending us not to use a post-July 29th issued certificate, "yet". Again, this is just my interpretation. I spoke to James Murray and MS support a couple of months back and both of them hinted that MS fully intends to enable the policy. However, things might have changed since then.
  Message 256 of 259  
11 Dec 15 18:56
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 3971
Driver Signing Practical Info

On Fri, Dec 11, 2015 at 9:02 AM, <xxxxx@osr.com> wrote: > From what I've read here and in other places, I suspect this MIGHT have to > do with the practical aspects of how EV Certs are managed. My original > understanding was that any division/group/team of a corporation could get > an EV Cert... However, (some? most of? all of?) the Certification > Authorities don't seem to share this view. Thus, if you're Big Company X > that's incorporated in Ireland, US headquarters in California, development > teams around the world, and a product group in Colorado, how does that > Colorado group get THE Corporate EV Cert to use for signing the products > they release to the web? It's unworkable. Again, this is purely > speculation on my part. yeah that part is just a colossal cluster fuck. We have something like eight development centers that sign things. What were they thinking? Mark Roddy --
  Message 257 of 259  
16 Dec 15 07:43
Chris Read
xxxxxx@clrassociates.co.uk
Join Date:
Posts To This List: 12
Driver Signing Practical Info

This would actually work quite well in my case:- 1) A single release for Windows7/8/10, signed with a normal codesigning certificate, from my company to the OEM customer. 2) The OEM customer can test on an unmodified system (testsigning not required). 3) The OEM customer can then decide whether or not to perform the attestation signing using their own EV-certificate. I am fortunate in that the drivers which I write are not for general deployment on consumer machines. Best regards Chris Read -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com Sent: 10 December 2015 21:37 To: Windows System Software Devs Interest List Subject: RE:[ntdev] Driver Signing Practical Info <quote> There's a very interesting note here that I do not recall seeing before: *Windows 10 Earlier Certificate Transition Signing* * A driver signed with any certificate issued after July 29th, 2015, with time stamping, is not recommended for Windows 10. * A driver signed with any certificate that expires after July 29th, 2015, without time stamping, will work on Windows 10 until the certificate expires. What this SAYS is that the old driver signing scheme will continue to work for Windows 10 forever, but you have to feel guilty for using it. This finally matches the actual experience in the field, which is that attestation is not actually required for Windows 10, even with a brand new SHA1 certificate. -- Tim Roberts, xxxxx@probo.com </quote> Now I'm really confused. Does this imply that if you got your certificate after July 29th, you can avoid Attestation signing by simply NOT using time stamping? This would be good until your new certificate expires -- not ideal, but does avoid Attestation for a number of years. --- NTDEV is sponsored by OSR Visit the list online at: <http://www.osronline.com/showlists.cfm?list=ntdev> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
  Message 258 of 259  
17 Dec 15 15:00
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

Colleagues: This has been a great, and useful, thread. But at over 250 replies (on no pagination support) the thread has simply gotten too,long to render properly in many browsers. The choice is either for me to write the code to page ate long threads (ha!) or lock the thread and start a new one. So, let's please keep the discussion going in the new thread located here: https://www.osronline.com/showthread.cfm?link=272498 Peter OSR @OSRDrivers
  Message 259 of 259  
17 Dec 15 15:00
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5879
List Moderator
Driver Signing Practical Info

(seq: B1874939-FEE6-B5A3-EDBAA27B3EC2A9FC) FYI: This thread has been locked. No further replies to this topic will be allowed.
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 14:54.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license