From owner-freebsd-questions@freebsd.org Fri May 19 14:19:17 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1663D744FF for ; Fri, 19 May 2017 14:19:17 +0000 (UTC) (envelope-from mfv@bway.net) Received: from smtp2.bway.net (smtp2.v6.bway.net [IPv6:2607:d300:1::28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95D4CF0D for ; Fri, 19 May 2017 14:19:17 +0000 (UTC) (envelope-from mfv@bway.net) Received: from gecko4 (host-216-220-115-148.dsl.bway.net [216.220.115.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: m1316v@bway.net) by smtp2.bway.net (Postfix) with ESMTPSA id BFD6E95876; Fri, 19 May 2017 10:19:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bway.net; s=mail; t=1495203549; bh=BA3j5npgZgp1rjctkYyw+80mDC34daCOMUuoJ2gdmPw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:Reply-To; b=UV6Lh/HFeugvnFxV1GtlHbprTJr74+gmUbuWpcmygSFYqpLW/vlNPy3p2sGzSVlTT H9OsT5jttS9bo2cGMUP0og7jo7E1zpMfPQwUe6/fivXc1RsQpzxOa15JrIG93ljIWd IO01L48+EI3/7OJ6Fj0ABdTKv5RYnTe2Lyls+bo8= Date: Fri, 19 May 2017 10:19:06 -0400 From: mfv To: Matthias Apitz 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> Reply-To: mfv@bway.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 14:19:17 -0000 > On Wed, 2017-05-17 at 12:38 Matthias Apitz 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