Signed Gems README

Table of Contents

• Overview

• Walkthrough

• Command-Line Options

• OpenSSL Reference

• Bugs/TODO

• About the Author

Overview

Gem::Security implements cryptographic signatures in RubyGems. The section below is a step-by-step guide to using signed gems and generating your own.

Walkthrough

In order to start signing your gems, you’ll need to build a private key and a self-signed certificate. Here’s how:

# build a private key and certificate for gemmaster@example.com
$ gem cert --build gemmaster@example.com

This could take anywhere from 5 seconds to 10 minutes, depending on the speed of your computer (public key algorithms aren’t exactly the speediest crypto algorithms in the world). When it’s finished, you’ll see the files “gem-private_key.pem” and “gem-public_cert.pem” in the current directory.

First things first: take the “gem-private_key.pem” file and move it somewhere private, preferably a directory only you have access to, a floppy (yuck!), a CD-ROM, or something comparably secure. Keep your private key hidden; if it’s compromised, someone can sign packages as you (note: PKI has ways of mitigating the risk of stolen keys; more on that later).

Now, let’s sign an existing gem. I’ll be using my Imlib2-Ruby bindings, but you can use whatever gem you’d like. Open up your existing gemspec file and add the following lines:

# signing key and certificate chain
s.signing_key = '/mnt/floppy/gem-private_key.pem'
s.cert_chain  = ['gem-public_cert.pem']

(Be sure to replace “/mnt/floppy” with the ultra-secret path to your private key).

After that, go ahead and build your gem as usual. Congratulations, you’ve just built your first signed gem! If you peek inside your gem file, you’ll see a couple of new files have been added:

$ tar tf tar tf Imlib2-Ruby-0.5.0.gem
data.tar.gz
data.tar.gz.sig
metadata.gz
metadata.gz.sig

Now let’s verify the signature. Go ahead and install the gem, but add the following options: “-P HighSecurity”, like this:

# install the gem with using the security policy "HighSecurity"
$ sudo gem install Imlib2-Ruby-0.5.0.gem -P HighSecurity

The -P option sets your security policy – we’ll talk about that in just a minute. Eh, what’s this?

Attempting local installation of 'Imlib2-Ruby-0.5.0.gem'
ERROR:  Error installing gem Imlib2-Ruby-0.5.0.gem[.gem]: Couldn't
verify data signature: Untrusted Signing Chain Root: cert =
'/CN=gemmaster/DC=example/DC=com', error = 'path
"/root/.rubygems/trust/cert-15dbb43a6edf6a70a85d4e784e2e45312cff7030.pem"
does not exist'

The culprit here is the security policy. RubyGems has several different security policies. Let’s take a short break and go over the security policies. Here’s a list of the available security policies, and a brief description of each one:

• NoSecurity - Well, no security at all. Signed packages are treated like unsigned packages.

• LowSecurity - Pretty much no security. If a package is signed then RubyGems will make sure the signature matches the signing certificate, and that the signing certificate hasn’t expired, but that’s it. A malicious user could easily circumvent this kind of security.

• MediumSecurity - Better than LowSecurity and NoSecurity, but still fallible. Package contents are verified against the signing certificate, and the signing certificate is checked for validity, and checked against the rest of the certificate chain (if you don’t know what a certificate chain is, stay tuned, we’ll get to that). The biggest improvement over LowSecurity is that MediumSecurity won’t install packages that are signed by untrusted sources. Unfortunately, MediumSecurity still isn’t totally secure – a malicious user can still unpack the gem, strip the signatures, and distribute the gem unsigned.

• HighSecurity - Here’s the bugger that got us into this mess. The HighSecurity policy is identical to the MediumSecurity policy, except that it does not allow unsigned gems. A malicious user doesn’t have a whole lot of options here; he can’t modify the package contents without invalidating the signature, and he can’t modify or remove signature or the signing certificate chain, or RubyGems will simply refuse to install the package. Oh well, maybe he’ll have better luck causing problems for CPAN users instead :).

So, the reason RubyGems refused to install our shiny new signed gem was because it was from an untrusted source. Well, my code is infallible (hah!), so I’m going to add myself as a trusted source.

Here’s how:

# add trusted certificate
gem cert --add gem-public_cert.pem

I’ve added my public certificate as a trusted source. Now I can install packages signed my private key without any hassle. Let’s try the install command above again:

# install the gem with using the HighSecurity policy (and this time
# without any shenanigans)
$ sudo gem install Imlib2-Ruby-0.5.0.gem -P HighSecurity

This time RubyGems should accept your signed package and begin installing. While you’re waiting for RubyGems to work it’s magic, have a look at some of the other security commands:

Usage: gem cert [options]

Options:
  -a, --add CERT          Add a trusted certificate.
  -l, --list              List trusted certificates.
  -r, --remove STRING     Remove trusted certificates containing STRING.
  -b, --build EMAIL_ADDR  Build private key and self-signed certificate
                          for EMAIL_ADDR.
  -C, --certificate CERT  Certificate for --sign command.
  -K, --private-key KEY   Private key for --sign command.
  -s, --sign NEWCERT      Sign a certificate with my key and certificate.

(By the way, you can pull up this list any time you’d like by typing “gem cert –help”)

Hmm. We’ve already covered the “–build” option, and the “–add”, “–list”, and “–remove” commands seem fairly straightforward; they allow you to add, list, and remove the certificates in your trusted certificate list. But what’s with this “–sign” option?

To answer that question, let’s take a look at “certificate chains”, a concept I mentioned earlier. There are a couple of problems with self-signed certificates: first of all, self-signed certificates don’t offer a whole lot of security. Sure, the certificate says Yukihiro Matsumoto, but how do I know it was actually generated and signed by matz himself unless he gave me the certificate in person?

The second problem is scalability. Sure, if there are 50 gem authors, then I have 50 trusted certificates, no problem. What if there are 500 gem authors? 1000? Having to constantly add new trusted certificates is a pain, and it actually makes the trust system less secure by encouraging RubyGems users to blindly trust new certificates.

Here’s where certificate chains come in. A certificate chain establishes an arbitrarily long chain of trust between an issuing certificate and a child certificate. So instead of trusting certificates on a per-developer basis, we use the PKI concept of certificate chains to build a logical hierarchy of trust. Here’s a hypothetical example of a trust hierarchy based (roughly) on geography:

                    --------------------------
                    | rubygems@rubyforge.org |
                    --------------------------
                                |
              -----------------------------------
              |                                 |
  ----------------------------    -----------------------------
  | seattle.rb@zenspider.com |    | dcrubyists@richkilmer.com |
  ----------------------------    -----------------------------
       |                |                 |             |
---------------   ----------------   -----------   --------------
| alf@seattle |   | bob@portland |   | pabs@dc |   | tomcope@dc |
---------------   ----------------   -----------   --------------

Now, rather than having 4 trusted certificates (one for alf@seattle, bob@portland, pabs@dc, and tomecope@dc), a user could actually get by with 1 certificate: the “rubygems@rubyforge.org” certificate. Here’s how it works:

I install “Alf2000-Ruby-0.1.0.gem”, a package signed by “alf@seattle”. I’ve never heard of “alf@seattle”, but his certificate has a valid signature from the “seattle.rb@zenspider.com” certificate, which in turn has a valid signature from the “rubygems@rubyforge.org” certificate. Voila! At this point, it’s much more reasonable for me to trust a package signed by “alf@seattle”, because I can establish a chain to “rubygems@rubyforge.org”, which I do trust.

And the “–sign” option allows all this to happen. A developer creates their build certificate with the “–build” option, then has their certificate signed by taking it with them to their next regional Ruby meetup (in our hypothetical example), and it’s signed there by the person holding the regional RubyGems signing certificate, which is signed at the next RubyConf by the holder of the top-level RubyGems certificate. At each point the issuer runs the same command:

# sign a certificate with the specified key and certificate
# (note that this modifies client_cert.pem!)
$ gem cert -K /mnt/floppy/issuer-priv_key.pem -C issuer-pub_cert.pem
   --sign client_cert.pem

Then the holder of issued certificate (in this case, our buddy “alf@seattle”), can start using this signed certificate to sign RubyGems. By the way, in order to let everyone else know about his new fancy signed certificate, “alf@seattle” would change his gemspec file to look like this:

# signing key (still kept in an undisclosed location!)
s.signing_key = '/mnt/floppy/alf-private_key.pem'

# certificate chain (includes the issuer certificate now too)
s.cert_chain  = ['/home/alf/doc/seattlerb-public_cert.pem',
                 '/home/alf/doc/alf_at_seattle-public_cert.pem']

Obviously, this RubyGems trust infrastructure doesn’t exist yet. Also, in the “real world” issuers actually generate the child certificate from a certificate request, rather than sign an existing certificate. And our hypothetical infrastructure is missing a certificate revocation system. These are that can be fixed in the future…

I’m sure your new signed gem has finished installing by now (unless you’re installing rails and all it’s dependencies, that is ;D). At this point you should know how to do all of these new and interesting things:

• build a gem signing key and certificate

• modify your existing gems to support signing

• adjust your security policy

• modify your trusted certificate list

• sign a certificate

If you’ve got any questions, feel free to contact me at the email address below. The next couple of sections

Command-Line Options

Here’s a brief summary of the certificate-related command line options:

gem install
  -P, --trust-policy POLICY        Specify gem trust policy.

gem cert
  -a, --add CERT                   Add a trusted certificate.
  -l, --list                       List trusted certificates.
  -r, --remove STRING              Remove trusted certificates containing
                                   STRING.
  -b, --build EMAIL_ADDR           Build private key and self-signed
                                   certificate for EMAIL_ADDR.
  -C, --certificate CERT           Certificate for --sign command.
  -K, --private-key KEY            Private key for --sign command.
  -s, --sign NEWCERT               Sign a certificate with my key and
                                   certificate.

A more detailed description of each options is available in the walkthrough above.

Manually verifying signatures

In case you don’t trust RubyGems you can verify gem signatures manually:

1. Fetch and unpack the gem

   gem fetch some_signed_gem
   tar -xf some_signed_gem-1.0.gem
   

2. Grab the public key from the gemspec

   gem spec some_signed_gem-1.0.gem cert_chain | \
     ruby -pe 'sub(/^ +/, "")' > public_key.crt
   

3. Generate a SHA1 hash of the data.tar.gz

   openssl dgst -sha1 < data.tar.gz > my.hash
   

4. Verify the signature

   openssl rsautl -verify -inkey public_key.crt -certin \
     -in data.tar.gz.sig > verified.hash
   

5. Compare your hash to the verified hash

   diff -s verified.hash my.hash
   

6. Repeat 5 and 6 with metadata.gz

OpenSSL Reference

The .pem files generated by –build and –sign are just basic OpenSSL PEM files. Here’s a couple of useful commands for manipulating them:

# convert a PEM format X509 certificate into DER format:
# (note: Windows .cer files are X509 certificates in DER format)
$ openssl x509 -in input.pem -outform der -out output.der

# print out the certificate in a human-readable format:
$ openssl x509 -in input.pem -noout -text

And you can do the same thing with the private key file as well:

# convert a PEM format RSA key into DER format:
$ openssl rsa -in input_key.pem -outform der -out output_key.der

# print out the key in a human readable format:
$ openssl rsa -in input_key.pem -noout -text

Bugs/TODO

• There’s no way to define a system-wide trust list.

• custom security policies (from a YAML file, etc)

• Simple method to generate a signed certificate request

• Support for OCSP, SCVP, CRLs, or some other form of cert status check (list is in order of preference)

• Support for encrypted private keys

• Some sort of semi-formal trust hierarchy (see long-winded explanation above)

• Path discovery (for gem certificate chains that don’t have a self-signed root) – by the way, since we don’t have this, THE ROOT OF THE CERTIFICATE CHAIN MUST BE SELF SIGNED if Policy#verify_root is true (and it is for the MediumSecurity and HighSecurity policies)

• Better explanation of X509 naming (ie, we don’t have to use email addresses)

• Possible alternate signing mechanisms (eg, via PGP). this could be done pretty easily by adding a :signing_type attribute to the gemspec, then add the necessary support in other places

• Honor AIA field (see note about OCSP above)

• Maybe honor restriction extensions?

• Might be better to store the certificate chain as a PKCS#7 or PKCS#12 file, instead of an array embedded in the metadata. ideas?

• Possibly embed signature and key algorithms into metadata (right now they’re assumed to be the same as what’s set in Gem::Security::OPT)

About the Author

Paul Duncan <pabs@pablotron.org> http://pablotron.org/

---

forward-declare

lib/rubygems/security.rb
lib/rubygems/install_update_options.rb