Open Source projects with encryption keys

Question

I currently have a project which I'm planning in the not too distant future to open source on GitHub.

The question I have is regarding how open source projects are released if they have encryption keys.

Basically, the project consists of an Android app (not being open sourced) and a PHP API.

The PHP API can potentially send/receive confidential information such as authentication details. Obviously, the API should be run under HTTPS to offer some security, but on top of that, the Android app, will encrypt all the data, then once encrypted and it sends the request to the PHP API. The PHP API decrypts the request and then generates a response, which is then encrypted and the response is sent back to the Android app to decrypt and process.

The encryption between the Android app and the PHP API has a hard coded encryption key (I'm using 256 AES encryption). It doesn't seem right that this key is kept in the open source code as then if someone managed to find a way to do a man in the middle attack between the app and the API, they have the key, potentially exposing the user authentication details.

What's the recommended way for doing this? Should I just not offer encryption, and just rely on the user using HTTPS, and if they don't, it's their problem or is there an alternative method I could use?

Answer 1

You should not include keys in your open source project. You should include a file location where your code expects a key, and the user (or an included utility) creates or copies their own unique key into the expected location. Imagine a thousand people download your project and stand up their own versions of your open-source server -- what's the point of having encryption if all of those servers are simply using the same key?

Including one specific encryption key is like drawing up a blueprint of a house that includes the specific tooth-sizes of the lock and key to the front door. It's completely the wrong approach: whenever a builder constructs a house from your blueprints, the builder should grab a totally new, unique lock and key and put that in the front door. It's not necessary that your blueprints specify an exact lock in your blueprints. It's merely important that the house has a lock; each separate construction project will supply its own lock.

Your own deployment of your open source server will have its own unique key, just like all other deployments that you don't control will have their own unique keys. The public, open-source project itself should have no key, because the entire point of a secret key is to keep it local to a particular deployment.

---

That said, using encryption within HTTPS seems unnecessary. HTTPS is sufficient to keep the user's traffic private and unaltered -- that's the exact scope what HTTPS was designed to do. As for "if they don't [use HTTPS] its their problem," simply don't offer an unencrypted HTTP service on your server.

Are you hoping to implement this as a kind of DRM to keep the traffic secret from the original user? If so, this will work about as well as any DRM, which is to say: it will work well enough for users who don't care about it, and not well enough to keep out tech-savvy users.