Date: Fri, 19 May 2017 10:19:06 -0400 From: mfv <mfv@bway.net> To: Matthias Apitz <guru@unixarea.de> Cc: freebsd-questions@freebsd.org Subject: Re: GnuPG smart card && geli Message-ID: <20170519101806.1674fda0@gecko4> In-Reply-To: <20170517103822.GB16462@c720-r314251> References: <20170517103822.GB16462@c720-r314251>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Wed, 2017-05-17 at 12:38 Matthias Apitz <guru@unixarea.de> wrote:
>
>Hello,
>
>I'm using gpg2 (from the ports) which supports a so called GnuPG smart
>card, i.e. the private key is stored in some CCID SIM (the card, which
>sits in a small USB stick) and access to the private gpg key is secured
>by a PIN entry, not a passphrase. This works fine and is very secure
>for using gpg on many hosts because you do not have to pollute all
>these hosts with your secret key material which could be copied (i.e.
>stolen) by anyone, for example even IP personal, having priv access to
>your workspace(s)).
>
>gpg2 brings a gpg-agent, to which gpg2 commands communicate, for
>example 'gpg2 --card-status' and which in turn connects to the daemon
>/usr/local/sbin/pcscd (as well in ports) which has the communication to
>special GnuPG-card. All you need is the PIN defined for the card.
>
>I use the HID Global OMNIKEY 6121 Smart Card Reader and the GnuPG-card
>produced here in Germany.
>
>On the other hand, the gpg-agent can also substitute the ssh-agent as
>a dropin. One exports the ssh public key for the remote
>~/.ssh/authorized_keys with:
>
>$ gpg2 --export-ssh-key ID > ssh.pub
>
>kills the (old) 'ssh-agent' and starts a 'gpg-agent':
>
>$ ssh-agent -k
>$ gpg2 --card-status
>(the latter launches as well the gpg-agent)
>
>$ unset SSH_AGENT_PID
>$ unset SSH_AUTH_SOCK
>$ if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then export
>SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"; fi $
>env | grep SSH SSH_AUTH_SOCK=/home/guru/.gnupg-ccid/S.gpg-agent.ssh
>
>Now 'ssh-add -l' will contact not the 'ssh-agent', but the 'gpg-agent':
>
>$ ssh-add -l
>4096 SHA256:lo2xgyFAnSXz6HNMELNZogJEfyj7XEKZiHIHg+e1DFw
>cardno:00050000532B (RSA)
>
>and on first access to the key with
>
>$ ssh id@remote-server
>
>the secret key is needed and 'gpg-agent' uses /usr/local/bin/pinentry
>or /usr/local/bin/pinentry-qt5 to request the PIN. Further ssh commands
>find the card already unlocked (until disconnect of the USB stick) and
>no PIN is needed anymore.
>
>So far so good and the same works this way for signing e-mails, etc.
>
>What I now want to get is using this too while booting the system which
>has the root and user partition geli(8) crypted. I.e. boot a mini
>system from some un-encrypted USB stick which has
>only /boot, /etc/fstab and enough files to make gpg2, gpg-agent
>and /usr/local/sbin/pcscd working, including shared libs needed by
>these. On a very early stage the gpg2 decrypts the keyfile for geli(8)
>which was encrypted by gpg2 using the public key of the card. Than the
>rest of the partitions are attached with 'geli attach' using on STDIN
>the keyfile decrypted on the flight with gpg2. So the unencrypted
>keyfile is never stored onto the USB boot key.
>
>This would lead to a system (netbook) which never can be booted or
>otherwise data read from and you can only boot it with the USB boot
>key, the USB GnuPG-card and the PIN (normally 6 digits).
>
>Any comments on this?
>
> matthias
>
Hello Matthias,
I agree with your idea. Some time ago I did some research to find out
a method to read the password from a USB memory stick but was not
successful. I was not concerned with disk encryption, just wanted a
very long password, automatic login and no system access without a
hardware key. Do not know if the situation has changed and do not know
the serious downsides of this approach. Clearly, the addition of disk
encryption would make systems, especially laptops, even more secure.
Perhaps a compromise would be to encrypt a /home partition and use the
card reader for access.
Cheers ...
Marek
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170519101806.1674fda0>