[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Transparency into private keys of Debian



Hello there,

I have read a little on this discussion and feel like sharing my thoughts.
I think the current lacking procedures are number 3 and 4 from my summarization
based on the current standards adopted for PKI:
1) Chain of trust from developer, [intermediaries,] to root CA.
2) Ensure multiple signing of packages at the above layers (intermediaries, root).
|__This allows for a buffer for key revocation whether by user choice or the other party holding the authority (intermediaries, root).
3) Use 'password enabled key store' to prevent unauthorized access to digital keys.
4) Use 'password enabled signing' to prevent unauthorized usage of digital keys.
The use of number 3 and 4 are the steps for developers to upload application packages as part of the
verification process by Google for the 'Play store' used in Android OS devices.
I am not sure about the others like Apple, Windows, Amazon etc, but they all probably have the same process.
Nothing new is being invented here and none being reinvented to complicate matters.
The existing security framework is quite simple yet sophisticated which is probably good.

Cheers,
Simon khng

On Tue, Feb 6, 2024 at 1:12 AM Stephan Verbücheln <verbuecheln@posteo.de> wrote:
Your work is valuable. Many of the things have probably evolved over
time and could use some analysis based on modern cryptography and
security practices. I just wanted to point out that there are subtle
but important differences outside of the key and signature formats.

The most important distinction is probably the one of personal keys on
the one hand which purpose is to identify a developer and the Release
keys which are stored on some build servers to create Release files.

You cannot only have PGP keys signing each other (like CAs and leaf
certificates in X.509 PKI). PGP has subkeys and they could be used in
the release process to mitigate risks.

Example:
1. Debian creates a PGP key for releases.
2. The public key is installed in Debian to verify releases.
3. The release team creates subkeys for signing.
4. The main private key is stored in a restricted place.
5. The build server only uses the subkeys to sign releases.

The subkeys could be expired and rotated all the time without changing
the PGP fingerprint and therefore without changing the trusted key ring
in the Debian installations. I do not know whether Debian actually
makes use of this, or it has been discussed before.

Regards
Stephan

Reply to: