Key revocation for pip with TUF

We show how easy it is to revoke compromised keys with TUF. You may manually sign packages with PGP, and keys could implicitly expire with time, but how would you explicitly and immediately revoke compromised keys?

First, we set up the virtual environment (for cleanroom testing) and install pip-with-TUF:

$ cd  /tmp
$ curl -O https://pypi.python.org/packages/source/v/virtualenv/virtualenv-1.10.1.tar.gz
$ tar xvfz virtualenv-1.10.1.tar.gz
$ python virtualenv-1.10.1/virtualenv.py --no-site-packages key-revocation-with-tuf
$ source key-revocation-with-tuf/bin/activate
$ sudo apt-get install python-dev libgmp-dev
$ pip install --upgrade https://github.com/theupdateframework/tuf/archive/v0.7.5.zip
$ pip install --upgrade https://github.com/theupdateframework/pip/archive/trishank.poly.edu.zip

First, let us download the current FooBar package. Assume that the FooBar package developer has not been compromised:

# POINT TO REPOSITORY WITH INTACT TUF METADATA.
$ curl http://mirror1.poly.edu/test-pip/key-revocation/repository.previous/tuf.interposition.json -o key-revocation-with-tuf/local/lib/python2.7/site-packages/pip/tuf.interposition.json

$ pip install FooBar
Downloading/unpacking FooBar
  Downloading FooBar-0.1.tar.gz (unknown size): 539bytes downloaded
  Running setup.py egg_info for package FooBar
    
Installing collected packages: FooBar
  Running setup.py install for FooBar
    FooBar 0.1
    
Successfully installed FooBar
Cleaning up...

Now, suppose that the FooBar package developer has been compromised, but that he does not know it. He does not release any new FooBar package, but he practices the good security principle of replacing his old FooBar-package-signing key with a new one. This is what the user who previously installed the FooBar package would see:

# POINT TO REPOSITORY WITH INTACT TUF METADATA.
$ curl http://mirror1.poly.edu/test-pip/key-revocation/repository.current/tuf.interposition.json -o key-revocation-with-tuf/local/lib/python2.7/site-packages/pip/tuf.interposition.json

$ pip install --upgrade FooBar
Requirement already up-to-date: FooBar in ./key-revocation-with-tuf/lib/python2.7/site-packages
Cleaning up...

Sure enough, there is no new (benign) package, but we make note of the new key. Now, suppose that the hacker who had compromised the FooBar package developer and has the revoked key tries to release a malicious FooBar package in his place:

# POINT TO REPOSITORY WITH INTACT TUF METADATA.
$ curl http://mirror1.poly.edu/test-pip/key-revocation/repository.next/tuf.interposition.json -o key-revocation-with-tuf/local/lib/python2.7/site-packages/pip/tuf.interposition.json

$ pip install --upgrade FooBar
Cleaning up...
Exception:
Traceback (most recent call last):
  File "/tmp/key-revocation-with-tuf/local/lib/python2.7/site-packages/pip/basecommand.py", line 134, in main
    status = self.run(options, args)
  File "/tmp/key-revocation-with-tuf/local/lib/python2.7/site-packages/pip/commands/install.py", line 270, in run
    sys.exit('TUF stopped the update due to an error:\n'+str(error))
SystemExit: TUF stopped the update due to an error:
No working mirror was found:
  mirror1.poly.edu: targets/FooBar metadata has bad signature!

Storing complete log in /home/trishank/.pip/pip.log

This FooBar metadata, which signs for malicious FooBar packages, has been signed for only by the revoked key stolen by the hacker. However, (assuming the good security practice of keeping the targets role key offline), the FooBar package metadata is now trusted to be signed for by a new key (unbeknownst to the hacker who is now no longer privy to the secrets of the FooBar package developer) belonging to the actual FooBar package developer. Therefore, any attempt to sign for metadata with an inappropriate key will be noticed and no attempt is made to upgrade to malicious FooBar packages not signed for by the actual FooBar package developer. Compare this with the situation where pip or PyPI works without TUF.