Microsoft signs all code that ships from it (that is except for the case when it\u00a0doesn’t); so how does one verify that the code came from them vs. anyone with a fraudulent certificate claiming to be them?<\/p>\n
Well the answer is pinning, but the pinning for the most part does not happen at the signing certificate level as those keys change to frequently to be pinned. The pinning happens at the certificate issuer level, much like has been proposed by CAA<\/a>.<\/p>\n So to understand how this happens in code you need to understand code signing in Windows<\/a> a little. There are two types of signatures those that are \u201cembedded\u201d and those that are \u201cattached\u201d.<\/p>\n Authenticode<\/a> would be an example of an embedded signature; Catalog Files<\/a> on the other hand are detached signatures. There are other examples of both of these but in general these other formats have the same abstract properties.<\/p>\n So when do you use one vs. the other? Well if a user will download your binary directly (ActiveX, Setup, etc.) you would typically embed a signature.<\/p>\n If that\u2019s not the case you would use a detached signature because a single signature can be placed on a list of binaries without increasing the package size (it\u2019s one signature on n hashes). You produce these signatures with SignerSignEx<\/a>.<\/p>\n For the two signature formats I mentioned you do your signature verifications using an API called WinVerifyTrust<\/a>. You can also use this API to get information out of a signature<\/a> (who signed it, when, etc.).<\/p>\n With that information you do a certificate validation that is accomplished with the CertGetCertificateChain<\/a> API, that gives you a CERT_CHAIN_CONTEXT which you can use to call CertVerifyCertificateChainPolicy<\/a>.<\/p>\n This API is used to do application specific verifications, for example in the case of TLS the CERT_CHAIN_POLICY_SSL provider is used \u2013 this is where the name and EKU verification logic for Windows exists.<\/p>\n The providers we care about for our story today are:<\/p>\n The last one is the one in has an array of hashes in it, I don\u2019t recall if they are key hashes or thumbprints of the certificate. In essence what it does is look at the top of the chain to see if the Root matches one of these hashes if it does it passes, if it doesn\u2019t it fails.<\/p>\n Applications may choose to do additional \u201cpinning\u201d also, for example in the case of Windows Update Services<\/a> a manifest is exchanged between the client and server, that manifest comes down over SSL they may choose to also do pinning to a set of certificates for the SSL session or apply digital signatures to the manifest and do pinning for the keys that are used to do signing.<\/p>\n\n