ReleasesKey¶

• Table of contents
• ReleasesKey
  • Design goals
  • Signature schemes
    • Long term Replicant key
    • Contributor keys
    • Long term
    • Keyring
    • Signify
    • minisign
    • Specific tool
  • Applications

Design goals¶

We need to make sure that users are able to easily check the signature with as few steps as possible, else they would simply skip the signature checking as it's too complicated.

Signature schemes¶

Long term Replicant key¶

• As developers making releases changes, the key would need to be passed around. This has several issues:
  • Developers having the key might not be reachable anymore.
  • It increase the probability of having security issues:
    • The key has to be passed around, and mistakes can happen
    • The number of people with access to the key increase over time:
      • Decades after, former developers could be facing situations where they are forced to hand over the key.
      • People can also change over time

It may be possible to limit some of the impact by using the gpg key as a PKI: It's possible to have some people have a separate primary key, while handing over subkeys to other people, but it doesn't completely solve any of the issues above, as they would all still apply to the people having access to the primary key, and only remove the subkeys of the equation.

Contributor keys¶

This is what is in use at the time of writing.

• Users have to trust developers signing Replicant images. So the advantage is that developers can change, and even work on different Android versions.
• The issue is that contributors tend to use the same key for signing Replicant images and other usages (like mails, etc). That is good as it enables users to more easily check the key, but in the other hand both uses case might conflict at some point. For instance it might be a good idea to have ephemeral signing subkeys and short expiration dates. But for Replicant images, it's better to have longer term signatures.

Long term¶

At the time of writing, the Replicant images tend to be relevant for a very long time (years).

For instance The GTA04 A4 is supported by Replicant 4.2 but not by Replicant 6.0, and in order to maintain support for some devices in libsamsung-ipc we also need to build and test Replicant 4.2 images, many years after. While old images do have many security issues, some people don't care much as other distributions probably have other issues like backdoors and freedom issues.

Having the ability to easily run Replicant 4.2 years later was also very useful to solve the bug about SIM card not being recognized.

So it's still good to make sure that everyone can easily check the signature of old releases.

• If the primary key of a gpg key is not used to sign the images, like for the Replicant 6.0 0004 RC1, the subkeys have to be kept for as long as possible and not discarded unless they never expire. If they never expire it could be possible to generate a key just for signing the image and discard the private part of that key right after. It might even still be possible to somehow revoke that key if people update their keyring, but it would not be possible to sign new images with it.
• If the keys or the subkeys do expire at some point (which is a good practice in case you loose your key), then the image verification will fail.

Keyring¶

Parabola uses a keyring to check the package.

• It enables multiple developers to sign packages without having to share a key.
• It works well when it's shipped by the distribution you use. It would need a tool to check Replicant images anyway.
• We might not be able to ship a Replicant keyring in each GNU/Linux distribution.

Signify¶

OpenBSD uses signify.

• The fact that the key are ephemeral and from an OpenBSD version, you will be able to check the next one, but not the one after is very secure and very simple to get it right too.
• Replicant images are longer term than OpenBSD releases. We would also need to ship the public keys in various GNU/Linux distributions.

minisign¶

minisign looks interesting as you can add text to be displayed (like the Replicant version) in the signature.

• Check how widely it is packaged
• Check how widely it is deployed (gpg is probably not going to go away anytime soon as people rely on it).

Specific tool¶

The tool could use other schemes, like something similar to signify or a keyring.

• Would suit our needs perfectly
• Would need to be shipped in every GNU/Linux distribution

Such tool could for instance check signatures of an image, and even identify the Replicant version of the image.

Rockbox managed to ship an installer in many GNU/Linux distributions, so if we ever make a dedicated tool, it would be interesting to have the ability to easily install Replicant from that tool.

Applications¶

Schemes could also be combined.

So far we have the following install flow: Recovery signature -> Recovery -> zip

The users check the recovery signature, and the recovery then check the zip.

The recovery could be signed with a Replicant contributor key, while it could check the signatures of the zip through a keyring for instance.