What is code signing?

Code signing is the process of digitally signing files to confirm the author and guarantee that the file has not been altered or corrupted. It’s essentially the same as signing emails: it guarantees that they were actually authored by the person claiming to be the author, and that they weren’t changed after the author signed them. (For more information see Apple’s explanation and Microsoft’s).

How does digital signing work?

Basically, digital signing is cryptography, so a full understanding of it really requires taking a 400-level college course, but here are the basics: You take some data (binary bits) and use a well-known algorithm to calculate what is called a “hash” of the bits. This hash is mathematically-generated from the source data, and so it can be re-calculated by the receiver. The hash is then “signed” via another algorithm: using a private key (see Public Key Infrastructure (PKI) for more about how these keys are managed) the signer encrypts the hash and attaches it to the file.

With public/private key encryption, data that is encrypted by the private key can be decrypted by the public key, so the encryption of the hash (and sometimes the public key, as well) is attached to the file so that the end user can re-calculate the hash and decrypt the signature to verify: a) that it was encrypted by the private key belonging to the author, and b) that the hash matches the hash that the author signed.

What’s all this about keys?

In PKI, the “key” is actually part of what’s called an SSL certificate issued to you by a Certificate Authority (CA) who verifies your identity. Verisign introduced the idea of “classes” for certificates, and you can now get free, Class 1 certificates for email signing from most CA’s now (like Thawte and Comodo and StartCOM), where the only thing they verify is that the person being issued the certificate can send/receive email at that address.

Of course, if you want to verify yourself as the author of code, we want to know more about you than your email address. So to sign code, you need at least a Class 2 certificate, for which proof of identity is required. This typically comes in the form of providing (photos of) your passport, driver’s license and/or other photo ID to verify that you are who you claim to be, and answering a few questions on the phone to validate that you own the phone number provided… or providing tax or other documents to prove the existence of an organization and that you’re qualified to speak for them. There are also additional classes: Class 3, 4, and 5 are extended validation certificates used for servers, software signing, b2b transactions and government security.

Why should I sign PowerShell scripts?

Well, the chances are, you don’t need to. Script signing is really a feature for corporations. The idea is that scripts from your IT department need to be verifiable and unalterable… code-signing gives companies a way to lock down and secure PowerShell scripts: setting a global policy requiring script signing, and ensuring that all scripts produced by the corporate administrators are properly signed…

As an individual, script-signing doesn’t really offer you much unless you share your computer with other administrator users. After all, what it protects you from is intentional or accidental altering of the script. If there’s no one else who has access to your computer, then nobody can alter your scripts. Of course, if someone hacks your computer enough to alter or create files on your hard drive and wanted to do something malicious, scripts would be a silly thing to target

There is, however, one additional time when you might want to sign your scripts. If you’re distributing scripts, whether via PoshCode.org, the TechNet script gallery, or on CodePlex or the MSDN code gallery … signing them gives you (and your users) the assurance that you are the author, and they haven’t been altered. In fact, the PoshCode Module which is available on PoshCode.org, and which allows you to search and download (as well as upload) PoshCode scripts uses script signing to allow it to safely upgrade itself. It features a Get-PoshCode -Upgrade command which will check for, and fetch, the latest version of the PoshCode module, and then validate it’s code signature is the same as the previous one before using it.

Remember, code signing cannot:

• Guarantee that code is free of security vulnerabilities.
• Guarantee that a script doesn’t load unsafe or altered code during execution.

• Prevent copying or altering of your scripts (although PowerShell policies can prevent accidental execution of altered scripts).

How do I sign scripts?

Assuming that after skimming all of that, you want to try signing your scripts, you need a certificate. You can generate one yourself (although it’s not easy, and the signed scripts which will only work locally on your system, and won’t be trusted by anyone else) or you can get one from a public Certificate Authority (I recommend StartCom/StartSSL which only costs $40 for two year certificates).

Typically, your certificate will be a .pfx file which you can load using Get-PfxCertificate, or you might have imported it into your local certificate store using CertMgr.msc, in which case you can load it using Get-Item Cert:\CurrentUser\My\ with the thumbprint of the certificate. In either case, you’ll have a certificate object you can pass to Set-AuthenticodeSignature along with the file path.

Wasn’t there supposed to be something automatic here?

Awhile back I wrote an Authenticode Script Module which has wrappers for signing and testing signatures on scripts. It uses a metadata file (which you have to create yourself) with a PrivateData variable that points to either the thumbprint of a certificate you’ve imported to your computer’s certificate store, or the path to a .pfx file … and allows you to sign files by just writing sign .\FileToSign.ps1 without having to Get-PfxCertificate each time, or even remember to turn on the -TimeStampUrl feature so that your signed scripts stay signed even after the certificate expires. That script helps a lot, but I’ve been wanting my text editor to sign the scripts automatically when I save them …

I mostly use Notepad++ for editing PowerShell scripts (with a PowerShell Syntax lexer I helped create), but after playing with the idea of writing a plugin to sign things after saving, I ended up deciding to go with something simpler: a PowerShell script to watch a folder for changes and sign any scripts I edit or save.

I’ve added a function I call Start-AutoSign to my authenticode script module which takes a path and a -Recurse flag and sets up a System.IO.FileSystemWatcher to detect saves, creates, and moves … and (re)sign the script if it needs it. Here is Start-AutoSign without the help docs or anything (so I can discuss it). You should just download the whole script module if you want to use it

A few things to notice: first, I’m assuming you’re using my Set-AuthenticodeSignature wrapper, so by default I don’t pass it an actual certificate. Second, in order to avoid eternally looping and re-signing the script over-and-over, you have to have a way to make sure you don’t re-sign it when it “changes” because you signed it. The approach I took was to test and see if the signature was valid or not (and if it’s valid, then don’t sign it again). Third: when you Get-AuthenticodeSignature, the Status codes leave much to be desired, returning the same “UnknownError” in several cases where they know exactly what the error is. You can check the StatusMessage and see that they even tell you what the error was:

• The form specified for the subject is not one supported or known by the specified trust provider
• A certificate chain could not be built to a trusted root authority
• A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider

• A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file

There may be other reasons too that I haven’t encountered yet, but the one thing we’re concerned with is the first one that the “form” isn’t supported. That means this is a file type which Set-AuthenticodeSignature can’t sign. PowerShell’s signing only works with executables, PowerShell scripts, modules, metadata, and xml files … so there’s no point trying to sign anything else. You may also notice that in my script (by default) I’m only signing .ps* files (that is: scripts, modules, metadata and ps1xml files), and that’s because with .dll and .exe files, I would prefer to sign them as part of my build step anyway.

One last thing: as with a few of my recent scripts, this one is designed to use Growl for Windows to notify you whenever it signs anything. If you don’t have the Growl module available, it should just skip right over that without any problems, but you can disable it in any case with the -NoNotify switch. Personally, I like seeing the popup so that I know it’s working, and know that I’m not accidentally signing something … and I love Growl for script notices because I can skin it, configure sounds, and forward the notices to other machines … or even temporarily disable them, all without having to tweak scripts.

In order to keep the conversation going, and hopefully, include some of the Microsoft MVPs and PowerShell developers that don’t participate in the IRC channel at all, I’m going to post a summary of the conclusions we’ve drawn so far, and then outline a proposal for the repository.

In case you don’t know, PowerShell implements code-signing for scripts using x509 Certificates (basically, SSL certs with “Extended” use properties), but the signatures are just embedded in the script as a comment, much like PGP signatures in email. Depending on your settings, the engine will actually check the signature on a script before executing it, and refuse to execute it if the signature isn’t valid, for instance, if the script has been modified, or the certificate used to sign it can’t be traced to a trusted Certificate Authority.

PowerShell code-signing is inconvenient, and expensive. Scripts are only Valid if they are signed, unmodified, and the certificate traces back to a CA(Certificate Authority) that is in your Trusted Roots store (by default, basically, Microsoft’s, VeriSign, Thawte, and Comodo).

You can create your own “test” certificate (that is, one that you sign yourself), but scripts signed by that certificate will only work on that computer. This system works fine for large companies which typically have either a subscription for purchasing certificates, or their own in-house trusted CA, but not for small private developers or open source script sharing communities without financial motivation.

Because of this, to take advantage of PowerShell’s code-signing on your computer (that is, to set your ExecutionPolicy to “AllSigned” or “RemoteSigned”) you must do one of these things:

1. Make sure that all script authors rent and use code-signing certs which cost more than $150 a year.
2. Add a non-commercial root CA certificate (like CACert) to (all of) your computer(s), and offer your authors the option of going through the process of getting one of those instead.
3. Create a “community” CA … and try to figure out how to make sure the certificate is secure enough to convince people to use it (yeah, ok, this was partly my idea, and it’s really a bad idea).

1. Generate your own code-signing certificate (which can be self-signed) and just sign every script that you trust.

So far, it seems like that last option is the only one that’s going to fly, because although some developers are willing to buy certificates to sign software they’re going to sell … most scripters and sys-admins aren’t willing to buy one to share their certificates for free.

So. Here’s the base fact:

The PowerShell Code repository is a repository of user-provided code.

We can’t actually afford to audit all of the code that users submit, nor take responsibility for verifying the identity of every contributor, but we’d like to have a way to do so. The best way would be to give everyone a free CodeSigning certificate from Microsoft or one of the established CAs, but we can’t afford to do that, so here’s our proposal (although it may sound like it, none of this is written yet, I’m just trying to get some feedback on the ideas):

Rather than rely strictly on user login authentication, we will require that all (non anonymous) submissions be SIGNED, and the signing certificate (key) will be the user authentication mechanism. Essentially, any unsigned code will show up as written by “anonymous” ... and any signed code will show up with the identity from the signing certificate — the certificate must include an email address, and the first post by each key will be held back until the email address can be authenticated.

In addition to the author’s signature on a script, other users who have used the code (or read through it without finding any issues), can also sign it as a show of trust — they simply submit the exact same script as a modification, but with their signature in place of the author’s.

So users will sign scripts to say they trust them, and when you browse or search the repository, you’ll see a lists of the users who have signed each code-snippet. You can download a copy of the code with any of the signatures and verify the signature yourself…

Additionally, there will be a Get-PoshCode cmdlet which probably should:

• Mark the downloaded scripts as ‘remote’.
• Add the download permalink url in a comment upon download (to aid in discovering other signatures and in adding your signature).
• Handle a cache of “trusted” key/certs and choose a trusted author (if there is one) from multiple available downloads, and ask you if you want to add any of the signers to your trusted list — particularly if there isn’t already a trusted signature available for the script.
• Validate the signature(s) after download, and provide a report (eg: valid/invalid).

• Offer to replace the signature (with yours) if it’s not a trusted x509 authenticode signature.

What certificate system should we use?

You may have assumed that we’re planning on using Microsoft’s code signing which is built into PowerShell, but when we were discussing this in the IRC channel, one of the things that kept coming up is that one way or another, we’re essentially creating an alternative way for people to “trust” the certificate — since we’re assuming that most of these certificates will be self-signed.

That is, if we use x509, we’ll STILL be creating an alternate way for people to say that they trust the x509 certs, and thus, using them in a way they weren’t intended. If we use PGP, we’ll basically be using them as intended, and will have peer key-signing as a trust mechanism, but we’re STILL introducing a secondary way for users to establish trust for PowerShell scripts which doesn’t integrate with the engine’s policy settings, thus making things more complicated.

Let me sum up the positive and negative sides of what I see as our two options.

x509 (aka “Authenticode”) signatures — supported by Microsoft.

• Probably self-signed and therefore won’t “work” properly in PowerShell anyway.
• Some of them would probably be commercial certificates issued by trusted CAs like Thawte or Comodo, giving you instant trust in the identity of the author. In that case, they would additionally be:
• Verifiable by PowerShell natively, and therefore, they:

• Don’t require a separate signature in order to execute when the ExecutePolicy is set to AllSigned.

PGP signatures (supported by the Open Source community and used in Debian, etc)

• Just as (un)trustworthy as any other self-signed certificate ... except that:
• PGP certificates (keys) are inherently user-signable. The community can vouch for each other’s identities, and create a web-of-trust for authentication purposes (which is all x509 really accomplishes anyway — you trust that Verisign makes sure that they are who they say they are, and live where they say they live).
• Not inherently usable by PowerShell.

• AllSigned mode requires re-signing (probably with a self-signed cert). This also means that if you have an x509 authenticode-signed script to submit, we would still need you to re-sign it with a PGP certificate when you wanted to upload it.

Final thoughts

Of course, there’s a lot of outstanding issues with this idea. But I wanted to put it out there for some broader feedback, particularly because we really are thinking about using PGP certificates since they can be counter-signed by other users, and since the general consensus opinion is that actually expecting scripters to buy code-signing certificates is just out of the question.

So the first question is, can we do PGP signing in pure .Net for a cmdlet (maybe using bouncy castle), and can we easily create a Set-PGPSignature cmdlet?

Has there been any progress on a way to do PGP signing that’s compatible with XML files (eg: ps1xml files)?

Can we do signature checking in-memory, so we can download the script with many signatures embedded and stitch them together for verification without creating multiple temporary files?

Regardless, if you trust a signature, but the signature isn’t Authenticode (PGP) or isn’t Valid (self-issued), the PowerShell security measures will require you (the end user) to sign the script in order to allow it to execute — essentially, every signed script on your system will be signed by you (or your sysadmin) and so, signing essentially becomes the administrator’s equivalent of blessing a script, and is somewhat like setting the eXecute flag on a linux script — except that you have to re-set it every time you edit the script.

We need to make signing slightly easier.

It’s a pain to find your certificate, and the built-in AuthenticodeSignature cmdlets are horrible at parsing parameters.

We need to make generating these self-signing certs trivial for non-SDK machines

It’s really pretty easy with MakeCert, but that’s not redistributable, and the Windows SDK is a ridiculously large download for someone who just wants to sign their scripts. I’ve written a script to generate code-signing certs using OpenSSL, which is redistributable, but it’s still not great.