@“Peter_Viscarola_(OSR)” said:
Just got notified of this lovely little addition to the page on cross-signing:
Will I be able to continue signing drivers if my certificate chains to a cross-cert that expires after 2021?
No, using any code signing certificate to sign a kernel-mode driver without a WHQL signature after July 1st, 2021 is a violation of Microsoft Trusted Root Program (TRP) policy. Certificates in violation of Microsoft TRP policies will be revoked.
So, yeah… there’s that.
Peter
Well there’s that i guess, not a good news.
So what’s next? Has Microsoft made its final decision and not backing down?
@“Peter_Viscarola_(OSR)” said:
Just got notified of this lovely little addition to the page on cross-signing:
Will I be able to continue signing drivers if my certificate chains to a cross-cert that expires after 2021?
No, using any code signing certificate to sign a kernel-mode driver without a WHQL signature after July 1st, 2021 is a violation of Microsoft Trusted Root Program (TRP) policy. Certificates in violation of Microsoft TRP policies will be revoked.
So, yeah… there’s that.
Peter
So lets say we buy a 3 year cert from Entrust, then if the cert expires in 3 years, how can Microsoft even know when did we cross sign it? considering its not expired yet, we don’t even need to timestamp the certificate, therefore we can cross sign it locally without network connection, and load it successfully. Am i missing something here?
The cross-certificates are issued BY MICROSOFT. They can certainly interfere in the trust chain. I don’t think they could make any currently signed packages go invalid, but they can certainly prevent any new packages from being signed.
They can.
If the excerpt from the license is true (that cross signing after
April 1st is against the license), they can revoke your cert, thus
making it invalid for all machines that update to thee new CRL.
If you do it locally, I doubt anything will happen, but if the driver
goes into the wild, they can catch it easily.
Whether they wish to revoke certs that were not abused to make havoc
is a different thing.
But they are making us leave Windows 
The cross-certificates are issued BY MICROSOFT. They can certainly
interfere in the trust chain. I don’t think they could make any currently
signed packages go invalid, but they can certainly prevent any new packages
from being signed.
–
Reply to this email directly or follow the link below to check it out:
https://community.osr.com/discussion/comment/300634#Comment_300634
Check it out:
https://community.osr.com/discussion/comment/300634#Comment_300634
@Dejan_Maksimovic said:
If you do it locally, I doubt anything will happen, but if the driver
goes into the wild, they can catch it easily.
Whether they wish to revoke certs that were not abused to make havoc
is a different thing.
@Tim_Roberts said:
The cross-certificates are issued BY MICROSOFT. They can certainly interfere in the trust chain. I don’t think they could make any currently signed packages go invalid, but they can certainly prevent any new packages from being signed.
But how can they even know when i signed the driver if i do it locally without even using a timestamp?!! i can literally revert the date of my signing machine to 2020/early-2021, sign it locally without internet connection, and then its done. how on earth can they stop this?
And we are not even using our drivers in the wild, we want this in our local company for less than 40 computers, ranging from windows 7 to 10. and we HAVE TO support old windows 7 machines and cannot upgrade them.
But our main question is, if we purchase a 3 year code signing EV certificate from Entrust right now, does this mean that we can cross sign our drivers locally without using a timestamp server for 3 years? again i have to emphasize that we want this for our company’s computers, its not a commercial driver… (and NO, we do not want to use test signing mode…)
I don’t think anyone knows the answer to that.
@henrik_meida said:
But our main question is, if we purchase a 3 year code signing EV certificate from Entrust right now, does this mean that we can cross sign our drivers locally without using a timestamp server for 3 years? again i have to emphasize that we want this for our company’s computers, its not a commercial driver… (and NO, we do not want to use test signing mode…)
Not using timestamps means, that in 3 years all the drivers’ signatures will become invalid with the expiration of the main certificate. Because timestamping prevents exactly that: it identifies, that you signed the driver at the moment in time, when all the involved certificates were valid.
Technically, if MS wants to push it real hard, they can simply revoke the non-expired cross-certificates, and signing will become… not really impossible, but problematic at best. And, at a guess, just to use drivers signed with a revoked cross-certificate, you’d have to prevent all your machines from updating the CRLs (which in itself is a bit dangerous: certificates may be revoked due to them being used maliciously).
As Tim said, nobody knows for sure, we can only guess what will happen after July 1. I personally am inclined to think, that MS will not go to such drastic measures, and that internal-only use should be safe, even with timestamping (I don’t think timestamp CAs report to Microsoft; even more, I’m not even sure CAs themselves know what certificate you are using; most probably, they receive just a hash of the file). But, on the other hand, I would never have believed, that one day MS would blow up the whole cross-certificate system, and yet here we are…
And, at a guess, just to use drivers signed with a revoked cross-certificate, you’d have to prevent all your machines from updating the CRLs (which in itself is a bit dangerous:
That’s an interesting side point in itself. It is my (potentially flawed) understanding that the KMCS check, which happens on the 64-bit systems every time the driver loads, doesn’t actually validate the whole chain. That takes too much time. It only looks for that “Microsoft Code Verification Root” at the end. If so, revoking would prevent new signings, but would not block existing drivers.
It WOULD prevent new installs – the installation process does check the whole chain.
Well, to be fair, the kernel-mode check is indeed somewhat simplified. I deliberately tried not to touch that subject, since it may be sensitive, and if discussed and misused too widely, it may cause Microsoft to patch it (like they added UAC, even though they had perfectly working permissions system; but very few people used it properly, and the most common reply to “why this program does not work?” was “just run from Admin”). Even with new installs, it will not prevent it completely, but make it harder…
@CaptainFlint said:
Technically, if MS wants to push it real hard, they can simply revoke the non-expired cross-certificates, and signing will become… not really impossible, but problematic at best. And, at a guess, just to use drivers signed with a revoked cross-certificate, you’d have to prevent all your machines from updating the CRLs (which in itself is a bit dangerous: certificates may be revoked due to them being used maliciously).
What is the easiest way to stop computers in our company from updating the CLRs? is there any group policy for it? again our computers range from windows 7 to latest version of 10, and we use 2012 windows servers.
@Tim_Roberts said:
That’s an interesting side point in itself. It is my (potentially flawed) understanding that the KMCS check, which happens on the 64-bit systems every time the driver loads, doesn’t actually validate the whole chain. That takes too much time. It only looks for that “Microsoft Code Verification Root” at the end. If so, revoking would prevent new signings, but would not block existing drivers.
@CaptainFlint said:
Even with new installs, it will not prevent it completely, but make it harder…
Interesting! I didn’t know this, which windows kernel module is responsible for this check? Is there any article regarding this?
Is there any article regarding this?
I don’t think they have made this public. Security through obscurity. It has to be somewhere in the kernel module loader.
@henrik_meida said:
What is the easiest way to stop computers in our company from updating the CLRs? is there any group policy for it? again our computers range from windows 7 to latest version of 10, and we use 2012 windows servers.
Sorry, no idea. The most reliable way is to disconnect it from Internet forever, and maybe even from the domain controllers which are connected to the Internet. But that would be a very restricted environment…