|
Microsoft is shipping a patch to eliminate SHA-1 hashes from its update process. There’s nothing wrong with eliminating SHA-1—but their reasoning may be very interesting.
SHA-1 is a “cryptographic hash function”. That is, it takes an input file of any size and outputs 20 bytes. An essential property of cryptographic hash functions is that in practice (though obviously not in theory), no two files should have the same hash value unless the files are identical.
SHA-1 no longer has that property; we’ve known that for about 15 years. But definitions matter. SHA-1 is susceptible to a “collision attack”: an attacker can simultaneously create two files that have the same SHA-1 hash. However, given an existing file and hence its hash, it is not possible, as far as anyone knows, to generate a second file with that same hash. This attack, called a “pre-image attack”, is far more serious. (There’s a third type of attack, a “second pre-image attack”, which I won’t go into.)
In the ordinary sequence of events, someone at Microsoft prepares an update file. Its hash—its SHA-1 hash, in many cases—is calculated; this value is then digitally signed. Someone who wished to create a fake update would have to crack either the signature algorithm or, somehow, produce a fake update that had the same hash value as the legitimate update. But that’s a pre-image attack, and SHA-1 is still believed to be secure against those. So: is this update useless? Not quite—there’s still a risk.
Recall that SHA-1 is vulnerable to a collision attack. This means that if two updates are prepared simultaneously, one good and one evil, there can be a signed, malicious update. In other words, the threat model here is a corrupt insider. By eliminating use of SHA-1 for updates, Microsoft is protecting users against misbehavior by one of its own employees.
Now, perhaps this is just housekeeping. Microsoft can get SHA-1 out of its code base, and thus discourage its use. And it’s past time to do that; the algorithm is about 25 years old and does have serious weaknesses. But it’s also recognition that an insider who turns to the Dark Side can be very dangerous.
Sponsored byVerisign
Sponsored byRadix
Sponsored byIPv4.Global
Sponsored byCSC
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byDNIB.com
When reading your note I was imagining that the evil insider would be substituting the evil version in lieu of all instances of the pure version.
In that situation would it not be easier for the evil insider to simply discard the good update, prepare the evil update, sign the evil update, and thus never have to be concerned about all of this?
Or are you positing a situation in which the evil insider wants to publish *both* an evil and a pure version such that the two can versions not be distinguished by the digest value? (And then presumably channel the evil version to a selected set of targets.)