|
|
От: |
okman
|
https://searchinform.ru/ |
| Дата: | 25.03.15 06:05 | ||
| Оценка: | 36 (7) | ||
Nobody likes having to sign their 64-bit Windows kernel-mode drivers. But after you’ve done it a few times,
you get used to it. And after all, you tell yourself, it’s probably worth it in terms of security.
And at least it’s something you can do in-house and Microsoft doesn’t have to get involved, right?
Well, that’s about to change. According to announcements made today at WinHEC in Shenzhen, kernel-mode
code signing as we’ve come to know it will not be sufficient for your drivers to run on Windows 10.
In order for your driver to be trusted on Windows 10 desktop machines, you will have to get a Microsoft signature.
Wait! Stop. Breathe. This does not mean your drivers will have to pass the Windows Certification tests.
OK? Have you calmed down? If so, let me explain how this is going to work. For Windows 10 and later, for
each kernel-mode driver you want to distribute you will have to:
Sign your driver package with your company’s code signing certificate
Login to the Microsoft Hardware Developer Portal (AKA sysdev)
Upload your signed driver package
Agree to a few particulars
Download the Microsoft signed files, within minutes.
Of course, you can optionally still run your driver through the full battery of tests and submit your
logs to sysdev, just as you could in the past. This new option replaces the ability to self-sign drivers.
Why the Change?
For year, security engineers have been saying that driver signing is vulnerable to exploitation.
Bad actors have managed to steal certificates, and some have even managed to acquire code signing
certificates on their own. It seems that Microsoft agrees.
Starting in Windows 10, to get a Microsoft signature your organization will need to create an account on
the Microsoft Hardware Development Portal (http://sysdev.microsoft.com). Creating an account on sysdev
is both free and easy, but it does require that your organization have a valid code signing certificate.
And starting in Windows 10 your organization will need to have an Extended Validation Code Signing Certificate.
Extended Validation (EV) certificates require your organization to pass more background checks by the
Certification Authority (CA) than ordinary certificates.ev-shield And they must be stored on “secure
hardware tokens.” In addition, only CAs that pass an independent audit review can issue EV certificates.
Of course, it should go without saying that EV certificates are more expensive than regular Class 3 Code
Signing certificates (the lowest cost EV cert we were able to find was $450). Sysdev currently supports
EV certificates from Verisign (Symantec) and Digicert.
Therefore, starting in Windows 10, to get any sort of signature from Microsoft (just the driver signing
signature or the certification signature) your organization will need to pass the more stringent
requirements to qualify for an EV code signing certificate. Microsoft claims this will make driver
signing a whole lot safer. However, how this will really play out in the real world depends entirely on
how secure the process of obtaining an EV certificate is.
Oh, and one more thing: To obtain the Windows signature you will need to “attest” to the fact that you’ve
comprehensively tested your driver and that you’ll monitor the Hardware Developer Portal for issues
discovered in your driver and respond to those issues. That seems pretty reasonable to me.
What’s Affected?
These requirements only apply to Windows 10 and later. In fact, Microsoft plans to offer a bit of a
grace period: 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.
The Ramifications
We don’t have the time to fully explore all of the ramifications of this new Windows 10 requirement
here in this blog post. We’ll delve into this topic further, in future issues of The NT Insider.
But we see several interesting complications, including:
Will smaller, independent, developers and OSS teams be able to obtain the EV certificates necessary
to sign their Windows 10 drives?
Will you need two certificates now? EV Certs require the use of SHA 256. Less than a week ago (when
this was written) Microsoft issued a Security Advisory and KB that updates Windows 7 systems to support
SHA-256 for code signing. Does this work? We don’t know yet. We’ll test it, we’ll let you know.
If it doesn’t work, it means you’ll have to have two Certs for signing your Win7 through Win10 kernel-mode code:
One SHA1 cert for signing Win7 drivers and one EV SHA256 for signing everything else, including your
submission to sysdev.
Will the signatures all be additive (in other words, can I sign my components with my SHA1 cert and
appropriate cross cert, my EV cert, and then add the MSFT signature to those 2), so that I can have three
simultaneous signatures at the same time? Will this work properly on older versions of Windows?
While it’s sort of clear what’s happening on Windows 10 Client systems, how will these changes
impact the next version of Windows Server? So far, we don’t know.
Conclusions
Starting in Windows 10, the old way of signing drivers is no longer sufficient. You’ll need an EV Code
Signing certificate, and you’ll need to use the sysdev web site to get a Microsoft signature on your driver.
As part of getting that signature, you’ll need to agree to monitor sysdev for driver problems that are
reported and respond to issues. This will only apply on Windows 10 and later, and to drivers built after
Windows 10 is released.
If this provides additional real security to the process of creating kernel-mode software, it’ll be a
good thing. As long as it doesn’t simultaneously freeze out small organizations and open software developers.
Stay tuned. We’ll be delving into these issues further in the months to come.
