958332 - Store a key for the signing service

Status: RESOLVED FIXED

(Marketplace Graveyard :: Integration, defect, P1)

Description

[Andy McKay]

We'll need to be able to store a key for an app. This is likely going to be the one created in bug 958331, but in later versions of the service could be one provided to us.

This bug is about storing the key appropriately. The main idea is that the HSM will encrypt and decrypt the key. The encrypted key could be stored on a file system controlled by the HSM or somewhere else (to be confirmed with security). If the key storage is compromised, they will just end up with a bunch of keys they can't decrypt anyway.

Comment 1

[Andy McKay]

Kang: is there a preference for the storage of the encrypted data?

Comment 2

[Guillaume Destuynder [:kang] [this account is no longer active]]

we need to discuss this further to clarify how this is done, :rforbes will request a meeting
i heard several versions ;-)

will link the result back to this bug

Comment 3

[Ryan Tilder [:rtilder]]

The meeting with kang and rforbes on Tuesday yielded the following agreement on the design:

- per-app private keys need only be encrypted if they are stored off the machine(s) performing the signing operations
- PKCS12 for ease of migration to probable later non-Java signing implementation
- On disk/at rest data layout similar to squid's diskd:
    - hash the webapp manifest URL as the app ID
    - /path/to/storage/<first byte of hash in hex>/<second byte of hash in hex>/<full hexadecimal representation of hash>.p12

All of this will happen internally to the new signing service so no movement of unencrypted keys between servers is necessary.

Comment 4

[Kumar McMillan [:kumar]]

keys are stored in an isolated S3 bucket

https://github.com/mozilla/apk-signer/commit/c5b3330a87b9c046040437c3759c37cb7b4b653b