[OpenAFS] Microsoft Changing Digital Signature Requirements
Sat, 04 Apr 2015 01:03:40 -0400
This is a cryptographically signed message in MIME format.
Content-Type: text/plain; charset=utf-8
On 4/3/2015 3:39 PM, Dave Botsch wrote:
> Hi, Jeff.
> The updates are very very much appreciated. Certainly, these changes
> will make life interesting in the future.
> A couple of followup questions, if you know the answers...
> When MS implements the new signing changes, whenever that is, is it
> expected that existing installations of the AFS client will break? Or
> is it expected that those will break? Or that clients up to a certain
> version, even if not yet installed, will work?
I understand that the situation is very complex and confusing. You can
be rest assured that any system you have today that is running a driver
that Your File System signed up to this point will continue to function
in the future. Including if you upgrade such a Windows 7 system to
Windows 10 with the driver installed. The problems are going to begin
once Windows 10 is released to manufacturing because drivers signed
after that point must be signed using the new process if they are going
to continue to function after a system is upgraded to Windows 10.
> Also, do you have to wait until MS "flips the switch" to be able to
> submit the client for the certification/review process? Or will you be
> able to do that earlier and get feedback with some sort of lead time?
As I wrote yesterday one of the complications is that there is no well
defined certification process for file systems. If there was a
"Certified for Windows" logo that I could easily obtain for the AFS
redirector drivers I would have done so years ago. Now there is a
Catch-22. Drivers "must be certified in order to install on Windows
Server" but "no certification process for file systems".
There is no certification for file systems because the semantics of file
systems vary so much. Just think about the varying capabilities of FAT
vs NTFS vs ReFS vs CDFS vs CIFS vs AFS vs AuriStor vs NFS3 vs NFS4. It
would not be possible to define a single set of tests that could cover
all of them.
The first step is going to be working with Microsoft to define a set of
tests that must be passed and required features that must be implemented
in order to be certified. The second step is going to be implementing
the tests and any new code or architectural changes that will be needed.
Finally, the certification submission will consist of the execution
test results plus the drivers and any other supporting documentation.
This certification will be required for each new revision of the driver
to be signed by Microsoft.
To clarify, certification is not a process by which a driver and its
source code are given to a third party for analysis. For example you
might be familiar with the FIPS 140-2 validation procedure for
cryptographic libraries. This process is not like that. For most
driver classes there exists a well defined set of tests and a functional
requirement list. The tests are performed by the developer and the
results are submitted to Microsoft along with the driver for review.
Prior to signing a driver I suspect that Microsoft will also analyze the
driver to ensure the apis it is calling are sane, that the driver is not
self modifying, that it implements stack randomization, and other code
hardening features. If I were Microsoft I would also examine the diffs
between drivers with the same name to ensure that the code is similar to
the prior submission. If it isn't I would ask for additional details
before issuing a signature.
This isn't an answer to your question but I hope it explains the current
> Finally, does the certification process itself cost $$?
I think you are asking if there is a check that needs to be written to
Microsoft for each request to certify and sign a driver. The answer to
that is "no". However, there are many costs associated with getting to
the point where you can submit a driver to be certified and signed.
> I'm, of course, wondering if this change will be implemented with some
> sort of update we can block. So far, the only publicity w.r.t. signing
> I've heard from MS has been on web certs. So, I'm really surprised this=
> very major change hasn't been more publicized, yet.
Regarding publicity. NIST deprecated SHA-1 for use in code signing
certificates at the end of 2013. Microsoft announced on 14 November
2013 that SHA-1 would not longer be accepted for code signing after 31
December 2015. As I mentioned on 28 March the Microsoft pushed the most
recent update to Windows 7 and Server 2008 R2 that adds support for
SHA-256 as part of the March 2015 Windows Update. Blocking this update
will only prevent a driver signed with a SHA-256 certificate from
While Your File System is currently signing with a SHA-1 certificate the
new EV certificate we are receiving is SHA-256. One question I have to
decide is whether it is worth the effort once the new signature program
is in place for Your File System to issue two versions of each installer
* one signed with the SHA-1 certificate for older systems
* one signed with the EV SHA-256 certificate for everything else
Once we reach 2016 there will not be a choice because it will not be
possible to obtain or renew a SHA-256 Authenticode certificate.
> Again, thanks so much for the heads up.=20
I should also point out that there is no guarantee that Microsoft will
be willing to certify OpenAFS because it might not be possible for
OpenAFS to satisfy the agreed upon requirements. One example of a
potential requirement is support for UNC Hardening. UNC Hardening was
introduced by MS15-011 in February 2015. It is an architectural change
to how file systems work to prevent man in the middle attacks against
the Group Policy Service but is also relevant for protecting roaming
profiles and redirected folders.
It would be perfectly reasonable for Microsoft to require any network
file system that supports roaming profiles and redirected folders to
also support UNC Hardening. But there is no point in implementing UNC
hardening for OpenAFS because the hardening guarantees cannot be
enforced by AFS.
The reason I attend Microsoft's IFS PlugFests is be aware of the
requirements for new OS releases and to build the personal relationships
necessary to jump hurdles such as this one. I have begun a
conversation. It is going to be some time before I know where it will en=
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature