I can't really see that happening for something like Windows Update.
Microsoft has "MD5" and "hashing" associated with the "evil OSS community" and so prefers expensive file signing.
The only time I've seen "MD5" and "Microsoft" in the same paragraph is in the MSDN Documentation.
MD5 is only a hash algorithm. It can only tell you that the bits are the same as they were at the time the hash was computed. Digital signatures give you that assurance, plus the assurance that the file was signed by the private key corresponding to
the public key you verified the signature with. If you trust that the purported owner of the private key has been responsible and not allowed the key to be stolen or otherwise used without appropriate permission, you can trust that the file was signed by the
But how do you trust that the key's owner is who they say they are? There are two main Public Key Infrastructures - PGP and the X.509 certificate scheme.
In the PGP scheme, users try to establish a "Web of Trust". Users sign their friends' public keys to validate that the owner of that key is who they say they are. There are also, IIRC, key-signing events
where you can take your key along with supporting identity documentation and have a trusted individual (in the sense that they are trusted by many others, their key has been signed by many others) sign your key.
In the X.509 Certificate scheme, each certificate (which contains the public key) is signed by its issuer. Where does the issuer's signature come from? Their own certificate. How do you trust that certificate? It is signed by its issuer. Of course, we run out
of issuers - at some point a certificate was simply issued by the organisation itself - these certificates are
self-signed, i.e. signed with the private key that corresponds to the certificate. There can be many of these roots of trust. Instead of forming a web, trust forms a hierarchy.
HTTPS, and other SSL/TLS protocols, use the certificate mechanism for authenticating the server (and potentially mutually authenticating the client).
Your installation of Windows comes with a number of trusted root certificates pre-installed, from VeriSign, Thawte and many others. You can see the list that IE recognises by going to Internet Options, Content tab and clicking Certificates, then the Trusted
Root Certification Authorities tab.
In both cases you have to deal with the problem of lost, stolen or compromised keys. In the PGP case you upload a key-revocation notice to a public PGP server (I think, it's been a long time). In the certificate case you inform the issuer who adds your certificate
to their Certificate Revocation List.
Now, clearly the issuer should perform some background checks before issuing a certificate, to verify the authenticity of the application. Doing this costs a certain amount of investigation time, which therefore costs money. Is the cost of code-signing certificates
excessive? Probably. Can much be done about it? Really only by setting up a competitor to VeriSign. You would have to encourage MS to allow certificates signed by your certificate to be trusted.
Could MS do this themselves? Certainly. Would users actually trust those certificates (if they understood what was happening)? Most likely not - you'd get uproar from the computing press. Microsoft already preinstalls their own root certificates. Current updates
are signed by a Microsoft code-signing key which was issued by "Microsoft Code Signing PCA", itself issued by "Microsoft Root Authority" (which is self-signed). The updates are counter-signed by a VeriSign Time-Stamp key (which corroborates the time the update
Could we move to a distributed trust scheme like PGP? I think few users would really understand it - ultimately they'd have to pick which keys they trusted, which isn't much of an improvement over hashing alone. Indeed it could be counter-productive.
You can, of course, add your own trusted root certificates. You could set up your own certification authority and issue certificates. Some corporates do this.