Date: Mon, 18 Dec 2017 20:21:56 +0000 From: halfdog <me@...fdog.net> To: oss-security@...ts.openwall.com Subject: Re: Recommendations GnuPG-2 replacement Daniel Kahn Gillmor writes: > On Sun 2017-12-17 09:06:08 +0000, halfdog wrote: > > Solar Designer writes: > >> On Thu, Dec 07, 2017 at 06:32:11AM +0000, halfdog wrote: > >> > After getting gpg and agent running, I noticed, that not reliably > >> > stopping the gpg-agent on initrd would introduce a private key > >> > data leak via /proc from early boot process to running system > >> > when stopping fails. > >>=20 > >> Can you elaborate on this, please? > > > > As the agent process stays alive and initrd PID namespace is the > > same as final init-process PID namespace, the agent will stay > > via /proc and traceable by root using PTRACE. > > I think what you're saying is basically that the key (or its passphrase) > remains in RAM while the agent is running. > > This is also true for things like ssh-agent. > > Keeping the key in RAM enables convenient, simple reuse -- this is a > security benefit, because it means it is possible to do things like read > a series of encrypted e-mails without entering your password for each > message. Without this, reading encrypted mail is an extreme nuisance > (esp. at the rate at which some people send and receive mail), and it > encourages people to just revert to cleartext mail in the first place. The features you describe are a clear must for desktop/enduser usecases, that require frequent access to the key. It is clear to me, that those features are required, no discussion to this point. The point in starting this thread was, that GnuPG does NOT conveniently cover usecases for headless or scripting operation. Thus it seems that the time has come to look for replacement, as GnuPG is moving more in the "desktop" direction, as also your comments indicate. > >> Personally, I intend to stay with GnuPG 1 for now. > > > > As Debian marked the packages with "gnupg1 - GNU privacy guard - > > a PGP implementation (deprecated "classic" version)" I wanted to > > anticipate the changes now, giving me more time to evaluate the > > changes and to find alternatives when needed. > > Hi! I'm the person who marked gpg1 "deprecated" in debian. i consider > it deprecated for several reasons, including: > > * upstream is not devoting much time to it ... > > * gpg1 does not support any of the newer cryptographic primitives, > ... You will not be able to verify elliptic-curve signatures, nor ... > > * gpg1's network interaction is entirely one-shot, ... > > * gpg1 always holds private key material in-process. it can be PTRACE'd > by the user themselves (not just as root) for full recovery of the > secret key. gpg2 never sees the private key material, since it > delegates that task to the agent. This process separation means it's > possible to create gpg-agent backend processes that run in isolated > namespaces, that hook into hardware, that store keys in the kernel, > etc. While these steps haven't been taken yet, they will only be > possible with gpg2, since gpg1 expects to handle the private keys > directly. That's really a strange argument. You fear PTRACING for key extraction of a short-lived, per-key instance of gpg1 process and solve that by putting all the key material into a single long-lived gpg-agent process, not even providing convenient commands to flush the keys from there? Hence not even PTRACING is needed, you can just access the socket to make the process give you the keys (directly or by requesting decrypts/signatures - I did not check on that). Even with namespaces, PTRACE is still allowed unless you are running the agent as SUID-binary, causing other risks again. In my opinion, for server operation both schemes would not improve security the same way as on desktops: if the automated tasks is implemented to be run as root, PTRACE and namespaces do not help in any way. If run as distinct user, there are only two usecases: * The service just does encryption/signature verification: here the unavoidable agent just provides additional attack surface, e.g. by replacing verification keys in the agent only, thus everything looks nice on disk but your signature verification is broken. * The service does signing/decryption: the key is passwordless (or password is within user-readable configuration) or HW-token. In both cases, the initial security of the key material before being transfered to gpg-agent only depends on file system level access restrictions. Gaining access to UID or PTRACE is already equivalent to full key material compromise. So also here the agent only adds attack surface and that's it. To reduce the attack surface, a "gpg --one-shot" argument could be added, which will terminate the agent immediately after use, maybe not even exposing it via sockets visible to other processes but only connected to its "parent" gpg process via pipes. > * gpg1 retains and provides backward compatibility for known-broken > formats, like PGP-2, and will likely never effectively drop them... > ... hd
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ