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.
Kang: is there a preference for the storage of the encrypted data?
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
Priority: -- → P1
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.
keys are stored in an isolated S3 bucket https://github.com/mozilla/apk-signer/commit/c5b3330a87b9c046040437c3759c37cb7b4b653b
Assignee: nobody → kumar.mcmillan
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.