Intriguing question: What standards does Authenticode use?

A colleague of mine just asked a very interesting if potentially misleading question: what standards are used/implemented by Microsoft Authenticode?

I felt pretty dumb at first, because I couldn’t even grok the question.  Authenticode implements a set of APIs, usually derived from IE and its dependencies – that’s the nearest I can think of to a reasonably relevant answer to the question.

When pressed for details, it turns out the context was a security investigation of a particular set of software being developed by a non-security group.  The security auditor was looking for answers to questions like which digital signature standards are implemented by their code, what crypto algorithms, etc, and the responses from the developers were of the form “don’t worry, we’re using crypto, it’s all well-understood”.

I’ve been in this situation many times, and I have a permanent forehead scar from the amount of time I’ve beaten my head against a wall trying to get answers to such questions out of Developers.  I have learned (the hard way) that this is a fruitless exercise – it’s like asking my mom whether her favourite game is written in managed or unmanaged code.  Either way, the only response you should expect are blank stares.  [Yes, there are a small minority of developers who actually understand what is going on deep beneath the APIs of their code, but with the growth of 3rd & 4th-generation languages, that’s a rapidly dying breed.]

Advice: Look for Code, not Standards

My advice to my colleague, which I’m sharing with you as well, is this: don’t pursue the security constructs implemented (or not) by their code.  If you don’t get an immediate answer to such questions, then switch as fast as possible to unearthing where in their code they’re “using crypto”:

  • What component/library/assembly, or which source file(s), are “doing the crypto operations”?
  • Which specific API calls/classes are they using that they believe are implementing the crypto?

With a narrowed-down list of candidate APIs, we can quickly search the SDKs & other documentation for those APIs and find out everything that’s publically known or available about that functionality.  This is a key point:

  • once the developers have implemented a piece of code that they believe meets their security requirements, often they cannot advance the discussion any further
  • once you’ve found the official documentation (and any good presentations/discussions/reverse-engineering) for that API, there’s usually no further you can take the investigation either.
  • If you’re lucky, they’re using an open-source development language and you can then inspect the source code for the language implementation itself.  However, I’ve usually found that this doesn’t give you much more information about the intended/expected behaviour of the code (though sometimes that’s the only way to supplement poorly-documented APIs), and a security evaluation at this level is more typically focused on the design than on finding implementation flaws.  [That’s the realm of such techniques as source code analysis, fuzzing & pen testing, and those aren’t usually activities that are conducted by interviewing the developers.]

Specific Case: Authenticode

Let’s take the Authenticode discussion as one example:

  • the developers are almost certainly using Win32 APIs not managed code, since managed code developers more often refer to the System.Security namespace & classes – however, ShawnFa makes it clear that Authenticode also plays in the managed code space, so watch out.
  • Authenticode is implemented by a number of cryptographic APIs in the Win32 space
  • This page leads one to think they ought to read works from such esteemed authorities as CCITT, RSA Labs and Bruce Schneier, but as with most Microsoft stuff you’re better off looking first at how Microsoft understands and have interpreted the subject.
  • My understanding of Authenticode is that it’s more or less a set of tools and common approaches for creating and validating digital signatures for a wide array of binary files
  • However, its most common (or perhaps I should say most attention-generating) usage is for digitally signing ActiveX controls, so let’s pursue that angle
  • A search of MSDN Library for “activex authenticode” leads to an array of articles (including some great historical fiction – “We are hard at work taking ActiveX to the Macintosh® and UNIX“)
  • One of the earliest (and still one of the easiest to follow) was an article written in 1996 (!) entitled “Signing and Marking ActiveX Controls“.  This article states:
    • Once you obtain the certificate, use the SIGNCODE program provided with the ActiveX software development kit (SDK) to sign your code. Note that you’ll have to re-sign code if you modify it (such as to mark it safe for initializing and scripting). Note also that signatures are only checked when the control is first installed—the signature is not checked every time Internet Explorer uses the control.
  • Another article indicates “For details on how to sign code, check the documentation on Authenticode™ in the ActiveX SDK and see Signing a CAB File.”  The latter also says to use SIGNCODE; the former wasn’t linked anywhere I looked on the related pages.

Further searches for the ActiveX SDK led to many pages that mention but do not provide a link to this mysterious SDK. [sigh…]  However, I think we can safely assume that all APIs in use are those implemented by SIGNCODE and its brethren.  [If you’re curious which ones specifically, you could use Dependency Walker (depends.exe) to make that determination.]

  • However, one of the articles I found has led me to this, which I think provides the answers we’re after: Signing and Checking Code with Authenticode
    • “The final step is to actually sign a file using the SignCode program. This program will:
      • 1. Create a Cryptographic Digest of the file.
        2. Sign the digest with your private key.
        3. Copy the X.509 certificates from the SPC into a new PKCS #7 signed-data object. The PKCS #7 object contains the serial numbers and issuers of the certificates used to create the signature, the certificates, and the signed digest information.
        4. Embed the object into the file.
        5. Optionally, it can add a time stamp to the file. A time stamp should always be added when signing a file. However, SignCode also has the ability to add a time stamp to a previously signed file subject to some restrictions (see the examples that follow the options table).”
    • –a = “The hashing algorithm to use. Must be set to either SHA1 or MD5. The default is MD5.
    • -ky = “Indicates the key specification, which must be one of three possible values:

      1. Signature, which stands for AT_SIGNATURE key specification.
      2. Exchange, which stands for AT_KEYEXCHANGE key specification.
      3. An integer, such as 3.
      See notes on key specifications below.”

    • “The ChkTrust program checks the validity of a signed file by:
      1. Extracting the PKCS #7 signed-data object.
      2. Extracting the X.509 certificates from the PKCS #7 signed-data object.
      3. Computing a new hash of the file and comparing it with the signed hash in the PKCS #7 object.

      If the hashes agree, ChkTrust then verifies that the signer’s X.509 certificate is traceable back to the root certificate and that the correct root key was used.

      If all these steps are successful, it means that the file has not been tampered with, and that the vendor who signed the file was authenticated by the root authority.”

    • “The MakeCTL utility creates a certificate trust list (CTL) and outputs the encoded CTL to a file. MakeCTL is supported in Internet Explorer 4.0 and later.

      The input to MakeCTL is an array of certificate stores. MakeCTL will build a CTL which includes the SHA1 hash of all of the certificates in the certificate stores. A certificate store can be one of the following:

      • A serialized store file
      • A PKCS #7
      • An encoded certificate file
      • A system store”


For those who still want more detail, I’d recommend digging into CryptoAPI and especially reviewing the FIPS submissions Microsoft has made for the Windows components that FIPS evaluated.


Aside: Here’s a really neat easter egg I stumbled on: the Internet Explorer Application Compatibility VPC Image.  You can download a Virtual PC image pre-installed with the stuff you need to troubleshoot compatibility issues for IE apps, add-ins etc.  Very helpful – save you a few hours of setting up a clean testing environment every time you run into a problem (or if you’re like me, it’ll save you weeks of hair pulling when trying to troubleshoot such issues when using your own over-polluted browser).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s