Support for GPG > 2.3

[andrewkrug]

GPG home directory location is different in newer versions of GPG. The repository class should detect the version and act appropriately.

(env) ubuntu@ip-172-31-22-35:~/aws_ir$ python
Python 2.7.6 (default, Oct 26 2016, 20:30:19)
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gnupg
>>> gnupg.__version__
'2.3.0'
>>> homedir=''
>>> gpg = gnupg.GPG(homedir=homedir)
>>> gpg = gnupg.GPG(gnupghome=homedir)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() got an unexpected keyword argument 'gnupghome'
>>>
KeyboardInterrupt

[andrewkrug]

It looks like there's a ton of weird stuff going on in the python-gnupg project. For one there seem to be two main stream versions:

1. The one in pypy https://github.com/isislovecruft/python-gnupg
2. The one in bitbucket https://bitbucket.org/vinay.sajip/python-gnupg/

For the current release against GPG 2.3.0 on Ubuntu 14.04 against a python 3.4 virtualenv the scan_keys() function seems to not be present on the GPG object that's returned.

>>> import gnupg
>>> import os
>>> gpg_home = os.path.expanduser('~/.gnupg')
>>> gpg = gnupg.GPG(homedir=gpg_home)

I went ahead and pulled down the last 4 major releases of the module from pypy and grepped them for the method and could not find it in the GPG.py file itself so I wonder where it has been coming from. Any thoughts on this or clear requirements as guidance for freezing versions of these things @joelferrier ?

[andrewkrug]

Thinking on this a little further it looks like we could just load the blob directly from the request library's output and then process that to check the fingerprint. In digging further into this it looks like this may not be working in GPG 2 and higher due to the deprecation of a dry run option that formerly output the fingerprint.

[andrewkrug]

Looked into this a bit more this morning. There are plenty of OpenPGP native python libraries that can be used for native validation but none of them support integration with the systems GPG home.

So here is what I would propose:

1. Register the signing key with a public server.
2. During validation stream the file from the public key server instead of writing it to the /tmp location.
3. Embed a copy of the fingerprint for the GPG with the package.
4. Compare against the known good fingerprint distributed in package. If a new fingerprint is seen as part of the exchange warn, prompt the user, display the fingerprint, and serialize the file to an alternate location on disk that would be part of the search for trusted keys.

Overall I think that this is sufficient for ensuring that there is no tampering in transit from S3 to the examiner/acquiring workstation since the process does not have end-to-end integrity. In terms of the threat model this assumes that the module can not be tampered with at the memory source ( compromised instance ). We also assume the following:

• Communications with Amazon have confidentiality and integrity ensured by the use of TLS.
• The authentication and access control functionality of KMS is secure.

Threats at the Endpoint
The greatest threat is from an attacker that completely owns the box.

• Threats at the endpoint would include a malicious piece code that detects execve style events and self desructs or modifies the behavior of the module in stream. Lime itself does not facilitate checking signatures.

[andrewkrug]

@joelferrier @jparr @amccormack what do you think of this as a strategy? This is a fair amount of code to lift out and change to another PGP library and I want to make sure we're doing it right before fork-lifting libs.

[jparr]

+1 for a public key server - the new security boundary for finger prints and package storage
+1 for using standard crypto libraries
+10 for simplification

I agree. If we can't trust amazon services then why are we even doing this?

[joelferrier]

@andrewkrug @jparr sorry for my slow responses, still working on settling in after my move.

Andrew, backing up to the original message, can you clarify what you mean by when you say that GPG 2.3 has a new home directory? Does GPG 2.3 no longer use ~/.gnupg?

I check my local virtualenv and version 0.3.9 of the python-gnupg library has been what I've been using since at least December, is it possible the errors you have encountered were introduced in version 0.4.0 released in january?

I have no problem switching away from python-gnupg to another GPG library but will need do some research to find the best fit.

I'll try and address my thoughts on the rest of what has been covered.

1. Register the signing key on a public key server: This has been in my backlog for some time but only recently did we get the email address setup, at which time I was in the middle of my move. We can knock this out quickly I suspect.
2. Loading the repository GPG key directly instead of writing it to a temp file: This is an implementation detail related to the scan_keys gpg method, we should try and remove the temp file requirement when switching to a new GPG library but I don't think it should be a hard requirement for a new library.
3. Embed a copy of the fingerprint in the package: in aws_ir#46 you noted problems with key pinning, I won't reiterate them again here, but a general comment I have on this issue is that this will restrict the ability of individuals to host their own kernel module repository which I do not feel comfortable with. I originally selected GPG as a verification method so that we can rely on the user's keychain and their choice of what GPG key to trust.
4. Check embedded fingerpring: I'll leave off my comments on this as I think the previous point needs further discussion.

I agree with you that kernel modules are being installed in a hostile environment, and I think it is a safe assumption to assume the integrity and confidentiality of communications with Amazon and the authentication and access control functionality of KMS.

[andrewkrug]

I agree with you that kernel modules are being installed in a hostile environment, and I think it is a safe assumption to assume the integrity and confidentiality of communications with Amazon and the authentication and access control functionality of KMS.

What are the potential attack vectors that signing protects us against in this case if we can not do endpoint validation?

[andrewkrug]

So another thought after chatting a bit about this with Gene ( who also uses python-gnupg ).

Moments of clarity we had during the discussion:

• Full form of the public key is not required to verify a signature only the fingerprint
• scan_keys is effectively only deriving the fingerprint for comparison

Recommendation:

• Generate a longer lived GPG key than the current signing key, treat that key like a root-ca. That fingerprint gets pinned in the code.

Implementation Details:

• Use that to sign a plain text file of additional key fingerprints that could be used for signing kernel modules.
• Download the trusted-signatures file at the beginning of the run. Check it's signature and then validate any module signatures against the list.

[andrewkrug]

I went ahead and implemented the first part of this ( which is not any worse from a security perspective than deriving the fingerprint as we do now from the public key ) Merging PR #19 would allow this to go forward and keeps this working in Ubuntu 14.04 and other distros using GPG 2.3 or higher as native. +r on #19 @joelferrier @jparr

Thanks. This would unblock testing in the aws_ir development branch for full integrations with signing enabled.