<spyros.seimenis@canonical.com> wrote:
>
> Hi everyone,
>
> I love seeing this discussion happening here and the points raised by Aaron because this is a topic I have argued on many times in the past. I would like to reiterate on the value brought by hw tokens.
>
>> some developers may
>> reasonably distrust such keys (vulnerabilities in the embedded
>> hardware of Yubikeys have been found before), and there are other ways
>> to store a GPG key in a highly secure fashion, for instance by using
>> an airgapped system, or (as I plan to do in the future) a Qubes OS
>> machine with an airgapped vault VM.
>
>
> It is true that vulnerabilities are everywhere but in the end it is a matter of trust. In general I would expect an air-gapped system to actually have far more vulnerabilities compared to a hw token that is purpose-built, as the former has a lot more components. More components usually lead to more potential vulnerabilities. More importantly though, to trust an air-gapped system, it needs to be able to provide verifiable claims about itself. The OS that is running on it, the installation medium that was used, list of each individual hw component of the machine, how they work together, how the system has booted etc. It is very hard (maybe impossible) to provide these sorts of claims for all potential system configurations ubuntu developers may have and also in a format that can be verified later. With hw keys the attestation process becomes tractable. Yes you now have to trust the manufacturer of the hw key but this is a single extra entity which can actually provide verifiable claims about its state.
>
> The other argument against the air-gapped system (only) approach is that even if you did generate your key in a highly secure air-gapped system, you still have to have some subkey available to the system that you do work on (which supposedly is online and not air-gapped) for i.e signing operations. The guide already describes this. The thing is, everyone can get hacked. An attacker who has access to your machine can use your locally stored key to sign things that you wouldn't sign otherwise (hw token or not), they can steal your passphrase, they can trick you to touch your hw key (even with user presence configured). But one thing they won't be able to do is ex-filtrate the key itself and use it without you being able to notice it somehow (unless they physically steal the key from you, which hopefully you would also notice). I think this is an important security property that has value by itself.
On the surface, I agree with this 100%. The inability to exfiltrate
the key without a software vuln that can make the hardware leak the
key is a very, very useful and powerful security property of hardware
keys, and I very much like this fact. I don't exactly *distrust* them,
I just trust them substantially less than I trust GPG running on an
airgapped system.
As for the issue of subkey theft, it's not mandatory that the signing
happen on the system where work is being done at all, a developer can
simply transfer data to the airgapped system for signing and then
transfer the signed data back to the original system for upload. Now
granted, with physical hardware, this is a massive hassle, but 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). I regularly work with Qubes as part of my work with
the Kicksecure and Whonix projects, have contributed to its code, and
have developed a lot of trust for it watching how it is developed and
looking at the components that make it up. At the same time I've
reviewed open-source security key firmware code and found
vulnerabilities (not directly related to GPG handling, but
vulnerabilities nonetheless).
Granted, I do not use a setup like the one described above yet. Right
now I just have my key directly on my main work system, the same as I
have since I started contributing to Ubuntu. It has a strong
passphrase but that's about as far as the protections on it go. I'm
intending to switch to the new setup described above some time before
the end of October.
I liked Christian's idea of coming up with acceptable alternatives. In
my mind, a perfect solution would be to have an exception process so
that users who can't use or don't trust the normal documented process
can propose a solution that works for them and have it discussed. That
way I could have (or at least argue for) the Qubes setup. Another
setup that people might reasonably want would be something involving a
network-attached HSM.
--
Aaron
> It is a given that when I am trusting Ubuntu, I am already implicitly trusting each of its individual developers and their claims that they know how to manage their keys but I would be much more comfortable if I could verify some of those claims cryptographically when possible.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
