Questions about SHA-1 deprecation from Microsoft Authenticode RRS feed

  • Question

  • Hi all

    I'm new to the forums and have some questions about Microsoft Authenticode verification of digitally signed Windows application code. I'm hoping this is the right place to ask this question as I see a number of other Authenticode questions in here, although I haven't managed to find an existing topic that covers my questions.

    I have some code which I currently sign using RSA with SHA-1 digital signatures, however I recently became aware of some changes to the "Windows Root Certificate Program - Technical Requirements version 2.0" document. 

    From what I understand in the "algorithm policies" section, the SHA-1 algorithm is being deprecated in 2016. I know there are some other changes regarding RSA key sizes, however my initial assessment is that the deprecation of SHA-1 is the most disruptive change because some old Windows versions do not support the SHA-2 alternatives.

    I'm aware of the need to move to something like RSA with SHA-256, however I'll need to support a number of legacy users on old versions of Windows which lack full SHA-2 support for Authenticode. These include Windows Server 2003 and Windows XP. I'm well aware that these are very old and that XP security updates are ending imminently, however in reality a number of users are having problems in migrating up to newer Windows versions and for various reasons it will take them some time to upgrade. I therefore need to understand more about the deprecation of SHA-1 support in Authenticode so that I can understand the impact to anyone who doesn't make it in time. No matter how much one might disapprove of lagging behind in OS versions, the issue still remains.

    In particular, item #3 in the SHA-1 section of the requirements document caught my eye:

    "For code signing certificates, Windows will stop accepting SHA1 signed code and SHA1 certificates that are time stamped after 1 January 2016. SHA1 signed code time stamped by an RFC 3161 Time Stamp Authority before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack."

    In what follows I will use the term "date" as a shorthand for "date and time" or "timestamp". For project planning reasons I find it useful to think in terms of calendar dates for deadlines, but I realise that the time of day is also significant in these calculations.

    It seems to me that there are various dates involved in the calculation here:

    (a) the date when the timestamped code was digitally signed

    (b) the validity dates of the code signer (end entity) certificate

    (c) the validity dates of the CA certificate that signed the code signer certificate (and any other CA certificates higher up the chain)

    (d) the date on which the validity of the signature is being checked, i.e. the current date when the user tries to run the signed application

    I am slightly unclear on how all of these dates are used in determining whether a signed application is valid. I think I can probably guess how it works, but I can't afford to guess... so I have some questions:

    1) Out of the dates listed above (a), (b), (c) and (d), which of them must be before 1st January 2016 in order for the signed code to be considered valid under the Windows Authenticode rules? (My guess is all except (d))

    2) Are there any other dates not listed above which are significant in determining the digital signature validity? If so, how do those dates affect the decision about the trustworthiness of the code?

    3) Supposing someone has a genuine business need to continue running their system using SHA-1 signed software after 1st January 2016. Will there be any system setting where such a user could tell Windows "I understand the risks of trusting SHA-1 based signatures and want to continue trusting software signed using SHA-1 despite those risks"? I'm imagining this being a short-term emergency mitigation for anyone whose migration plan hits a bump at the last minute.

    4) Conversely, is there any system setting where I could ask Windows to start prematurely enforcing the new behaviour so that I can test what the impact will be in advance? I realise I could set my system clock to 2nd Jan 2016, however in my experience changing the system clock artificially can be very disruptive to normal system operations. I would prefer it if there were a way to enable the new enforcement for testing without having to adjust the clock so I thought I'd ask just in case.

    5) If I really had to (and I must say that it's not my intention to do so)... is there any way I could sign some code on 2nd January 2016 with SHA-1 and have it be considered valid by Windows? I'm guessing the answer is a definite "no", but for completeness I have to ask.

    6) Other than the deprecation of SHA-1, is there anything else in the code signing requirements changing which will break backwards compatibility with older (let's say pre-Windows 7 / Server 2008) versions of Windows? While I'm worrying about SHA-1 I might as well consider if any of the other requirements will break compatibility with older versions such that I can no longer provide a single application which will run on all of the Windows versions I currently support.

    Many thanks in advance

    Andrew Akehurst-Ryan

    (I work for IBM, but any opinions in my posts are my own)

    Friday, March 21, 2014 3:58 PM