Hello, Iustin Pop <ius...@debian.org> wrote on 31/03/2024 at 13:13:27+0200:
> On 2024-03-31 10:47:57, Luca Boccassi wrote:
>> On Sun, 31 Mar 2024 at 08:39, Bastian Blank <wa...@debian.org> wrote:
>> >
>> > On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
>> > > On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
>> > > > As others have said, the best solution is to relay on HSW for handling
>> > > > the cryptographic material.
>> > > Aren't these answers to different questions?
>> > > Not all attacks are about stealing the key or using it to sign unintended
>> > > things.
>> >
>> > Also a HSM does only allow to control access to the cryptographic
>> > material. But it asserts no control over what is actually signed.
>> >
>> > So an attacker needs to wait until you ask the HSM it is okay to sign
>> > something.
>> >
>> > Bastian
>>
>> This is true as in the default configuration you get asked for the
>> yubikey pin only once per "session", and then it's cached
>> transparently and there's no GUI feedback when the token is used (the
>> light on it blinks, but noticing that requires having it in line of
>> sight at all times). However, it's already better than nothing as it
>> means such an attack must be "online", and run in the same "session"
>> as the active user, so perfect should definitely not be the enemy of
>> good here IMHO. Also, iirc this can be configured to always ask for
>> the pin on each signature, although this could get burdensome. But
>> given the very low price of yubikeys (or similar tokens), and how well
>> and seamless they work these days, I think the offer of buying any DD
>> that doesn't have one such a token is one that we should take up and
>> make it happen.
>
> Jumping in late in the HSM thread, but I'm not sure I understand the
> exact setup people propose.
>
> Option 1: Moving keys to one yubikey, while keeping the original key
> material "safe" offline. How do you know the "safe offline" material is
> safe and hasn't been copied?
If your threat model includes NSA, you can't.
I have two backups of my main PGP key on two encrypted devices. One is
always with me, the other is stored "safely" at home. (I put quotes
because while I'm convinced it'd be from hard to impossible to find it,
theoretically when I leave home, a sufficiently motivated agent could
try and find it)
I consider this model safe enough, especially since the key also is
encrypted with a passphrase, meaning one would need to:
1. Find the backup device
2. Copy it (I've put some measures that would normally make me
aware that someone touched the device)
3. Break the cryptographic protection on it
4. Break the passphrase protection on the private key.
I consider that doing more would be too expensive for a little to no
gain.
> Option 2: Generate keys on the yubikey and have them never leave the
> secure enclave. That means having 2 yubikeys per developer, and ensuring
> you keep track of _two_ keys, but it does ensure there's a physical
> binding to the key.
>
> Are there other options? And which option is proposed?
I would object against creating a PGP key on the HSM itself. Not having
the proper control on the key is room for disaster as soon as you lose
it or it dies.
> I have quite a few yubikeys, but I haven't migrated to use them since
> it's not clear to me what is a good, and recommended, workflow. I'm
> relatively against option 1, since the "safe offline" key material
> somehow doesn't appeal to me.
Any workflow that makes a non-governmental attacker's life a PITA
without forcing you to share their pain is a good workflow.
Security habits are incremental learning and trials, don't expect to
reach top levels in one day.
As stated elsewhere, I started to work on a blog post regarding my
Yubikey configs/habits. I'll try to get it out at some point. I consider
the opportunity to extend further upon the topic and try to write about
some of my security habits, it that can help.
Cheers,
--
PEB
signature.asc
Description: PGP signature
