<spyros.seimenis@canonical.com> wrote:
>>
>> with
>> Qubes OS this is extremely easy because of the hardware isolation
>> model used in Qubes. You can have a VM with no network access, into
>> which you copy files that you need to sign, then copy them back out
>> once they have been signed (or you can use qubes-split-gpg, which
>> allows you to essentially use an airgapped vault VM as a virtual
>> Yubikey of sorts).
>
>
> Thanks for the detailed answer! This sounds indeed very interesting (and I agree with your points about the security of open source fw code). My point about building trust in a way that scales is the same even with this approach. You have to factor in that it is much more difficult to collect the necessary information, from a more complex system, required to prove that a particular key was actually created and used with a setup like this **and** cryptographically verify them compared to a hw token/HSM approach.
>
> To give an example, once I have a signature produced by a key generated in a yubikey, an automated service in launchpad could run one command to attest that the key used was indeed generated in a yubikey [1]. We then implicitly put our trust to the yubikey's manufacturer and for many this is enough. With HSMs it is similar, you are essentially paying the HSM manufacturer for trusting them.
>
> We should have clear guidelines about what are the requirements for an alternative method to be considered as trusted as the ones I mentioned above (what are the necessary attestations, how feasible it is to automate verification as a whole/in parts etc). For the Qubes example, I want to see cryptographic proof that the signing happened inside the "air-gapped" qube, proof that the key was indeed generated inside of it and cannot leave it, proof that you have set up your system properly and that your system comes from a manufacturer I consider trusted so that I can trust its hardware isolation mechanisms etc. (turtles all the way down) and I also want a system to do that verification for me as much as possible.
I think you're approaching this from the standpoint of Ubuntu being a
corporate project with security requirements from employees. That
would be great if that is what Ubuntu was, but that is not what Ubuntu
is.
Ubuntu is a community project with a largely volunteer-based
workforce. As such, we have traditionally always taken steps to ensure
that the volunteers who work as part of Ubuntu are highly trusted - we
work with them on a personal level for months before trusting them
with archive upload privileges, ensuring that they are non-malicious,
constructive members of the community who know what they're doing and
will work closely with the rest of Ubuntu to do their job correctly.
If someone is trustworthy enough to do everything else with their
development work correctly, I see no reason they shouldn't be trusted
to do their key management correctly, provided they have been trained
on how to manage their keys just like they were trained on how to
manage packages.
Ensuring that the key comes from a source that is somehow considered
objectively trustworthy is essentially enforcing an enterprise policy
across a non-enterprise community. It's also very insufficient as far
as real-world security goes; a person could just use a mini Yubikey
that's left inserted into their machine at all times, meaning anyone
who runs off with the machine (or even gets near it for a few seconds)
can simply take the key (and maybe the machine too) and now have
upload privileges to the archive. Or the developer could install
persistent malware that implants itself into packages in some form
prior to signing, and so on. No amount of enterprise policy or
attestation will change the fact that if the person using the key
doesn't know what they're doing, bad things can easily happen. A
sufficiently trained user doesn't need the enterprise policy to keep
bad things from happening, and they might be actively made less secure
or otherwise unable to do their job because of the policy.
A huge portion of our developer community with archive upload rights
is not employed by Canonical. The entirety of that community is highly
trusted. To cut off that trust when it comes to signing keys is
strange and sets a very bad precedent for how things are done with
Ubuntu as a community.
--
Aaron
> [1]: https://developers.yubico.com/PKI/yubico-ca-certs.txt
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
