OpenPGP Secret Key Transfer

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OpenPGP Secret Key Transfer

Vincent Breitmoser
Hi there,

one of the long time unsolved problems we had with OpenKeychain was a
good way to transfer secret keys between devices, particularly between
Desktop and Mobile. We finally came up with a concept based on qr-code
authenticated TLS-PSK via local network, which I implemented this week:

https://github.com/open-keychain/open-keychain/pull/2117

You can see it in action here:

http://valodim.stratum0.net/transfer_active.gif
http://valodim.stratum0.net/transfer_passive.gif

The use of TLS-PSK ensures that data on the wire has no value, except
for participants on the local network who have access to the PSK, and
only during the time of exchange.

The usefulness of this mechanism is of course limited until it is
supported on more platforms, which is why I approached Andre about this
and we discussed the idea together with Werner earlier this week.  Andre
asked me to write a short spec and post it here, to collect feedback:

https://pad.stratum0.org/p/openpgp-skt

I went over this with dkg and worked out some warts, and he also seemed
interested in writing a standalone client.

Special thanks to Oliver Wiese and his students at FU Berlin, who got
this ball rolling!


 - V

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenPGP Secret Key Transfer

Werner Koch
On Fri,  2 Jun 2017 14:07, [hidden email] said:

> Desktop and Mobile. We finally came up with a concept based on qr-code
> authenticated TLS-PSK via local network, which I implemented this week:

I briefly looked at the specs which made things more clear to me after
our phone conference.

One immediate problem I see is the use of an arbitrary TCP port.  A
common use case for moving keys between devices are meetings.  There you
often have the corporate network and a separate guest network which are
physically local but from the topology different networks.  Thus the FW
rules won't allow to pass data between them.  To a large extend you have
this problem with all peer-to-peer protocols on the Internet (meaning
connected network segments)

Thus I would suggest to use a dedicated near-field protocol like
Bluetooth.  Or piggyback your protocol on another protocol which is
known to interconnect devices without problems: VoIP or maybe Signal.
Right, that is more effort on the software site but it avoids lots of
practical problems.


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenPGP Secret Key Transfer

Vincent Breitmoser
> A common use case for moving keys between devices are meetings.

Moving secret keys between devices at a meeting, is this a common use
case? Can you elaborate?

> Thus I would suggest to use a dedicated near-field protocol like
> Bluetooth.

Even between Android devices, the experiences I've had as a user with
apps that transfer data via bluetooth have been horrible. Throwing linux
and windows into that mix, I can't imagine this approach leading to
useful results within reasonable effort.

> Right, that is more effort on the software site but it avoids lots of
> practical problems.

WebRTC is a candidate that I have looked into, which is basically ICE
for transport and DTLS for crypto. My conclusion was that we should
stick with simplicity now, and can always make the transport layer more
complex later when we notice that this leads to problems in practice.

 - V

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenPGP Secret Key Transfer

Werner Koch
On Fri,  2 Jun 2017 17:14, [hidden email] said:

> Moving secret keys between devices at a meeting, is this a common use
> case? Can you elaborate?

Project releated (sub)keys.  Not very common today but I hope in the
future this will be a standard practise.

> Even between Android devices, the experiences I've had as a user with
> apps that transfer data via bluetooth have been horrible. Throwing linux
> and windows into that mix, I can't imagine this approach leading to
> useful results within reasonable effort.

I have always used BT to transfer contacts and calendar.  Between cell
phones and desktops.  In these cloudy times it might not be en vogue
anymore - don't know.

> stick with simplicity now, and can always make the transport layer more
> complex later when we notice that this leads to problems in practice.

I agree that using an URL allows to switch to a different transport
protocol.  So, using good old Internet practice it is okay to first test
the code and then work on the specs.


Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenPGP Secret Key Transfer

Daniel Kahn Gillmor-7
On Fri 2017-06-02 17:54:46 +0200, Werner Koch wrote:
> On Fri,  2 Jun 2017 17:14, [hidden email] said:
>
>> Moving secret keys between devices at a meeting, is this a common use
>> case? Can you elaborate?
>
> Project releated (sub)keys.  Not very common today but I hope in the
> future this will be a standard practise.

This idea is neat; but it sounds speculative and only useful to a
certain subset of people (not everyone is involved with projects that
use split or shared keys).

So it doesn't seem like an objection that should block a plan to improve
user experience on more common practice (many more people will have two
devices than will work with project-related (sub)keys) so i lean in the
direction of pursuing Vincent's original approach for now.

     --dkg

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OpenPGP Secret Key Transfer

Guilhem Moulin
Hi there,

On Sun, 04 Jun 2017 at 17:04:59 -0400, Daniel Kahn Gillmor wrote:

> On Fri 2017-06-02 17:54:46 +0200, Werner Koch wrote:
>> On Fri,  2 Jun 2017 17:14, [hidden email] said:
>>
>>> Moving secret keys between devices at a meeting, is this a common use
>>> case? Can you elaborate?
>>
>> Project releated (sub)keys.  Not very common today but I hope in the
>> future this will be a standard practise.
>
> This idea is neat; but it sounds speculative and only useful to a
> certain subset of people (not everyone is involved with projects that
> use split or shared keys).
For signature verification I think we would need some mechanism to tell
GnuPG to limit the scope of this or that subkey.  FWIW I brought that up
to gnupg-devel in autumn 2015, and proposed to use certification
notation to limit subkey scopes:

    https://lists.gnupg.org/pipermail/gnupg-devel/2015-November/030576.html

(I wish I could limit the scope of the signing subkey I use for Debian
packages for instance, and take it offline. ;-)

Cheers,
--
Guilhem.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

limiting scope of signing subkeys [was: Re: OpenPGP Secret Key Transfer]

Daniel Kahn Gillmor-7
On Mon 2017-06-05 16:12:15 +0200, Guilhem Moulin wrote:
> For signature verification I think we would need some mechanism to tell
> GnuPG to limit the scope of this or that subkey.  FWIW I brought that up
> to gnupg-devel in autumn 2015, and proposed to use certification
> notation to limit subkey scopes:
>
>     https://lists.gnupg.org/pipermail/gnupg-devel/2015-November/030576.html
>
> (I wish I could limit the scope of the signing subkey I use for Debian
> packages for instance, and take it offline. ;-)

I think this is an entirely different feature request than the one that
Werner was talking about, which is why i've changed the Subject: line
here.

If i understand you correctly, i think you want more than just limiting
the scope of your debian package signing subkey -- i think you want to
limit the scope of your e-mail signing subkey so that it will not be
considered acceptable for signing debian packages.  is that right?

to make a new subkey and mark it as capable only for package signing is
just a matter of making up a new notation and marking it with *no*
capabilities otherwise (or to mark it as just package-signing).  But to
get you the security constraints you want, you'll need to mark the
*other* subkeys as incapable of signing packages.

I'm happy to talk this over further -- the other approach would be to
have a capability that means "signing software" as distinct from
"signing messages" or "certifying identities".  From an API perspective,
i'm not sure how you'd phase that in on top of the existing signature
verification API.  How should GnuPG learn that the thing you're
verifying is in the "software" domain as opposed to the "e-mail message"
domain?

        --dkg

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: limiting scope of signing subkeys

Guilhem Moulin
On Mon, 05 Jun 2017 at 16:34:57 -0400, Daniel Kahn Gillmor wrote:

> On Mon 2017-06-05 16:12:15 +0200, Guilhem Moulin wrote:
>> For signature verification I think we would need some mechanism to tell
>> GnuPG to limit the scope of this or that subkey.  FWIW I brought that up
>> to gnupg-devel in autumn 2015, and proposed to use certification
>> notation to limit subkey scopes:
>>
>>  https://lists.gnupg.org/pipermail/gnupg-devel/2015-November/030576.html
>>
>> (I wish I could limit the scope of the signing subkey I use for Debian
>> packages for instance, and take it offline. ;-)
>
> I think this is an entirely different feature request than the one that
> Werner was talking about, which is why i've changed the Subject: line
> here.
Oops yeah, apologies for hijacking the thread :-/
 
> If i understand you correctly, i think you want more than just limiting
> the scope of your debian package signing subkey -- i think you want to
> limit the scope of your e-mail signing subkey so that it will not be
> considered acceptable for signing debian packages.  is that right?

That's correct indeed.
 
> to make a new subkey and mark it as capable only for package signing is
> just a matter of making up a new notation and marking it with *no*
> capabilities otherwise (or to mark it as just package-signing).  But to
> get you the security constraints you want, you'll need to mark the
> *other* subkeys as incapable of signing packages.
>
> I'm happy to talk this over further -- the other approach would be to
> have a capability that means "signing software" as distinct from
> "signing messages" or "certifying identities".

I recall you and I discussed that on #debian-keyring a while ago
(probably around the time I sent that mail to gnupg-devel) :-P  Adding
another capability sounds neat, but IMHO that won't scale if other folks
want to limit the scope of their signing subkeys to other domains /
types of data.

> From an API perspective, i'm not sure how you'd phase that in on top
> of the existing signature verification API.  How should GnuPG learn
> that the thing you're verifying is in the "software" domain as opposed
> to the "e-mail message" domain?

As I envisioned it that new option ‘--assert-notation=’ should make gpg
and gpgv reject signatures made with a signing (sub)key that is lacking
the given notation.  With (yet :-/) another flag, the program would
relax the behavior to accept the signature when *none* of the
*non-revoked* signing (sub)keys have the given notation.

Then of course one would need to pass these options to all signature
verifiers; but when signature verification is done centrally like in the
case of Debian it sounds feasible, right?

--
Guilhem.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: limiting scope of signing subkeys

Vincent Breitmoser


> With (yet :-/) another flag, the program would
>relax the behavior to accept the signature when *none* of the
>*non-revoked* signing (sub)keys have the given notation.

Careful there: if the key is obtained via an untrusted channel, subkeys may be suppressed and this won't be caught by the usual fingerprint checks. This becomes relevant here, since the properties of one subkey depend on the presence of other.

 - V

(sent from K-9 Mail)

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: limiting scope of signing subkeys

Daniel Kahn Gillmor-7
In reply to this post by Guilhem Moulin
On Tue 2017-06-06 21:23:04 +0200, Guilhem Moulin wrote:
> I recall you and I discussed that on #debian-keyring a while ago
> (probably around the time I sent that mail to gnupg-devel) :-P  Adding
> another capability sounds neat, but IMHO that won't scale if other folks
> want to limit the scope of their signing subkeys to other domains /
> types of data.

How about a non-critical notation "signing-scope" to the subkey binding
signature (or to the self-sig, if the primary key is marked as
signing-capable) which is a comma-separated list of domains?  we could
enumerate a few different domains and people could add them as they
wanted:

 * email
 * software

then you'd add a new parameter to GnuPG's --verify-options
"signing-scope=foo", and it would accept signatures only from:

 * signing-capable (sub)keys without the signing-scope notation
 * signing-capable (sub)keys with the signing-scope notation with "foo"
   in the list.

and signatures from any other key would be rejected.

Then people who want to constrain their keys can just issue new
subkey-binding signatures as needed.

wdyt?

               --dkg


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: limiting scope of signing subkeys

Guilhem Moulin
In reply to this post by Vincent Breitmoser
On Wed, 07 Jun 2017 at 15:55:31 +0200, Vincent Breitmoser wrote:
>> With (yet :-/) another flag, the program would
>>relax the behavior to accept the signature when *none* of the
>>*non-revoked* signing (sub)keys have the given notation.
>
> Careful there: if the key is obtained via an untrusted channel,
> subkeys may be suppressed and this won't be caught by the usual
> fingerprint checks. This becomes relevant here, since the properties
> of one subkey depend on the presence of other.

Isn't that the same for subkey rotation via revocation + creation?  A
MiTM could strip away the revocation subpacket and the new subkey;
gpg(1) would then accept signatures made by old subkey (until it
expires), right?

--
Guilhem.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: limiting scope of signing subkeys

Guilhem Moulin
In reply to this post by Daniel Kahn Gillmor-7
On Wed, 07 Jun 2017 at 10:13:51 -0400, Daniel Kahn Gillmor wrote:

> then you'd add a new parameter to GnuPG's --verify-options
> "signing-scope=foo", and it would accept signatures only from:
>
> * signing-capable (sub)keys without the signing-scope notation
> * signing-capable (sub)keys with the signing-scope notation with "foo"
>  in the list.
>
> and signatures from any other key would be rejected.
>
> Then people who want to constrain their keys can just issue new
> subkey-binding signatures as needed.
>
> wdyt?
I like this! :-)  Compared to the previous proposal this verification
logic sounds a lot less error-prone for verifiers, while keeping an easy
“upgrade path” for users willing to limit the scope of their signing
(sub)keys.  (I would for instance add another — annotated — subkey
binding signature to the subkey used to sign this email, in order to
limit its scope to the “email” domain.  And generate another signing
subkey to use e.g., for code signing.)  Thanks for the idea!

--
Guilhem.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (849 bytes) Download Attachment
Loading...