Re: Configuration for offline usage - best practice tips?
On Sat, Feb 17, 2018 at 11:15:57PM -0500, Daniel Kahn Gillmor wrote: On Thu 2018-02-15 21:33:05 +0100, Juergen Christoffel wrote: I'm looking for best practice tips for offline usage of GnuPG. [...] GnuPG's defaults should be fine for the common, simple backup case. However, i note that you're talking about "today's public key" -- that suggests that you're imagining a regularly-updated key that your backup tooling will know about. This is in some sense antithetical to "offline usage" -- how will the backup scripts learn about the new keys if they can't go online to fetch them? Thanks for the feedback and sorry for the delayed answer, I've been on a business trip. It sounds like you're proposing an OpenPGP primary key that has a series of relatively short-lived, expiring encryption-capable subkeys. Is that correct? Yes, that's what I plan to do, generate a subkey for each month in advance and use this to encrypt my backups. And it seems that I shouldn't have used the term "offline usage" without a better spec what I ment. So: GnuPG tips for communications use state that I should do this or don't configure that in order to keep my keys compatible with potential recipients. That's what I consider "online" use, while I use "offline" to say that I don't intend to share encrypted stuff with external parties, so I have no need for potential limitations For further clarity, it'd be useful to understand what you see as the goal of key rotation here. Do you plan on deleting older secret subkeys? if so, how will you recover backups that were encrypted to the destroyed secrets? Backups are done from a rented root server to a rented storage server in "the cloud" and I want to lessen the impact of a potential compromise of these keys. That is, if I have to restore certain files from a backup, and the machine where the decryption happens might be compromised, I don't want all backups to be compromised in a single step. But for backups, this is a slightly more complicated story. It certainly can be useful if you want to be able to robustly *destroy* backups that might be stored on servers that you don't have full control over. That is: encrypt the backup to public key X, send the encrypted copy to "the cloud", and then when you're sure you don't need it any more, delete the secret key corresponding to X to ensure that it's not recoverable. But most people have a hard time just getting their backups to happen on a reasonable schedule, and don't have a reliable schedule for backup destruction. Do you have such a plan? Or do you envision some other reason for the proposed key rotation? The backup plan is in place and uses rotating backups, so older backups expire anyway after some time. Thanks for your detailed suggestions, I'll rethink my plans with them in mind. Regards, JC -- Doctorow's Law: Anytime someone puts a lock on something you own, against your wishes, and doesn't give you the key, they're not doing it for your benefit. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Nano
Sent from my iPhone ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[How-to] Use multiple smartcards simultaneously
Hello, here's a quick howto for using multiple smartcards at the same time on Fedora 26 with gnupg 2.2.4. To access multiple card readers simultaneously, the internal CCID driver of gnupg must be used. Steps: 1. Allow normal users to access the card readers: Create a "hwdb" file in /etc/udev/hwdb.d/99-smartcard-reader.hwdb This file contains a list of USB IDs of the card readers. usb:v04E6pE003* usb:v046Ap003E* usb:v0C4Bp0504* ID_SMARTCARD_READER=1 Adapt the USB device IDs to your card reader, some IDs are found here: https://wiki.gnupg.org/CardReader/PinpadInput The 'ID_SMARTCARD_READER' tag will trigger an udev rule in /usr/lib/udev/rules.d/70-uaccess.rules that adds the "uaccess" tag for the reader. This allows to access the card reader as normal user while you are logged in. 2. Update systemd's hwdb: systemd-hwdb update This re-generates the file /etc/udev/hwdb.bin 3. Prevent pcscd from starting pcscd can prevent gnupg from accessing the card reader using the internal CCID driver. Therefore you can mask (=disable) pcscd via systemd: systemctl mask --now pcscd.socket systemctl daemon-reload 4. Log out and log in again. All smartcards should now be listed when running "gnupg2 --card-status all" You can modify individual smartcards by using "gnupg2 --card-edit SERIALNO" *** Debug tips'n'tricks *** - Use "udevadm monitor --environment" to see how udev detects a card reader when plugged in. Example output: UDEV [10155.134146] add /devices/pci:00/:00:01.1/:01:00.0/usb1/1-3 (usb) ACTION=add BUSNUM=001 DEVNAME=/dev/bus/usb/001/015 DEVNUM=015 DEVPATH=/devices/pci:00/:00:01.1/:01:00.0/usb1/1-3 DEVTYPE=usb_device DRIVER=usb ID_BUS=usb ID_FOR_SEAT=usb-pci-_01_00_0-usb-0_3 ID_MODEL=SPRx32_USB_Smart_Card_Reader ID_MODEL_ENC=SPRx32\x20USB\x20Smart\x20Card\x20Reader ID_MODEL_FROM_DATABASE=SPR532 PinPad SmartCard Reader ID_MODEL_ID=e003 ID_PATH=pci-:01:00.0-usb-0:3 ID_PATH_TAG=pci-_01_00_0-usb-0_3 ID_REVISION=0601 ID_SERIAL=SCM_Microsystems_Inc._SPRx32_USB_Smart_Card_Reader_x ID_SERIAL_SHORT=x ID_SMARTCARD_READER=1 ID_USB_INTERFACES=:ff: ID_VENDOR=SCM_Microsystems_Inc. ID_VENDOR_ENC=SCM\x20Microsystems\x20Inc. ID_VENDOR_FROM_DATABASE=SCM Microsystems, Inc. ID_VENDOR_ID=04e6 MAJOR=189 MINOR=14 PRODUCT=4e6/e003/601 SEQNUM=4699 SUBSYSTEM=usb SYSTEMD_WANTS=smartcard.target TAGS=:seat:systemd:uaccess: TYPE=0/0/0 USEC_INITIALIZED=10155130754 Notice the "uaccess" tag in the output. It also contains the USB device path in DEVNAME=, in this case /dev/bus/usb/001/015. - Inspect the user ACL on the USB device file via "getfacl" getfacl /dev/bus/usb/001/015 # getfacl /dev/bus/usb/001/015 # file: dev/bus/usb/001/015 # owner: root # group: root user::rw- user:alice:rw- group::rw- mask::rw- other::r-- -> there's an extra read/write ACL for username "alice" in there. - enable scdaemon debug output in ~/.gnupg/scdaemon.conf When inspecting the log file, make sure there are no messages like "ccid open error: skip" If that's the case, try masking pcscd like above. Otherwise gnupg will fall back to pcscd mode which currently does not support multiple smartcards. See also: https://dev.gnupg.org/T1621#110805 Hopefully this short guide is useful to someone else when setting up multiple card readers. In fact it can even be helpful when using just one card reader, since setting up the device permissions using udev's uaccess system is tricky and sparely documented: https://github.com/systemd/systemd/issues/4288 Cheers, Thomas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
