[messaging] Whiteout Secure PGP Key Sync

[Tankred Hase]

Hi Daniel,

thanks for your feedback. We're still at the beginning with this spec
and insight like that really helps to get a feeling for week points.

> A) Device Registration Scope says both of these:
>
> * The device configuration protocol MUST NOT allow a device to
> impersonate another one just with the knowledge of its DeviceSecret.
>
> * The device configuration protocol WILL NOT protect the user from an
> attacker stealing the DeviceSecret from the server and impersonating the
> device for that DeviceSecret.
>
> The two statements seem in conflict to me, but maybe i'm not
> understanding them.

The spec is a bit unclear here. The DeviceSecret is basically a
randomly generated password that is generated on a new device and is
used to authenticate the device. This is not the only thing the device
requires for authentication though. Since the user has uploaded and
authenticated a public PGP key to the whiteout key server before
private PGP key sync, there is already a trust relationship between
the PGP keypair and the server. This is used as an additional factor
for authentication.

The device secret is known to the server and stored as a hash pretty
much like a password. This is why it should not be trusted to protect
the user from a threat model point of view.

> B) the diagrams use Ea(X,Y) and Es(X,Y), i think meaning "Encrypt Y
> asymmetrically with key X " and "Encrypt Y symmetrically with key X",
> but that's not documented anywhere.

You're right. I edited the spec in a separate document before copying
it to the blog post. Seems I forgot to the copy that part. The diagram
reference should now be there.

> C) it's not clear how Device Registration (as described here) implements
> "The device configuration protocol MUST NOT allow multiple devices with
> the same DeviceSecret." -- is this true per user? or globally? what
> happens if i submit a DeviceSecret that someone else already has used?

The device secret is a globally unique random string with 256 bits of
entropy that is generated using a RNG on the device to avoid
collisions. I added this to the spec to make it more clear.

> D) how is the communication between the client and the server secured
> (if at all)? I'm assuming from context and the 2XX responses that this
> is a traditional HTTPS tunnel, presumably anchored with traditional
> X.509 trust chain.

Yes. The server is a standard REST service secured via TLS.

> E) in all of the documented exchanges, the session keys appear to be
> dictated entirely by the server. This suggests that a possibility for a
> poorly-implemented or compromised server to regularly use weak or known
> keys. Is there a reason to avoid, say, a DH-style exchange where both
> parties contribute some entropy to establish a novel session key? I
> don't have a specific attack in mind, but it does seem unusual to me to
> have an asymmetric arrangement like this. It also occurs to me that a
> rogue server can force a client to decrypt arbitrary session keys for
> use in any of these communications.

That's a valid point. From a threat model point of view, the session
keys are used to authenticate the client and to wrap transmitted data
to add an additional layer of security on top of TLS. The actual key
used to wrap the user's private PGP key is generated solely by the
client. So in transit the private key is wrapped three times (TLS,
session key, wrapping key). At rest the private key is stored
encrypted only by the wrapping key. Given that all Whiteout Endpoints
use TLS 1.2 with forward secrecy, could you elaborate on how adding a
DH-style key exchange for the session keys would add security?

I would also like to point out that the client src code is on GitHub
if you find the spec unclear in certain areas:
https://github.com/whiteout-io/mail-html5

Specifically the key sync protocol code is here:
https://github.com/whiteout-io/mail-html5/blob/master/src/js/dao/keychain-dao.js#L252

Kind regards,
Tankred

2014-07-10 23:10 GMT+02:00 Daniel Kahn Gillmor <dkg at fifthhorseman.net>:
> On 07/09/2014 02:30 PM, Tom Ritter wrote:
>> Not mine, it's actually Tankred's (cc-ed), but it looked interesting,
>> and as there's been a number of similar things posted lately I'd
>> thought I'd send out a ping about it.
>>
>> https://blog.whiteout.io/2014/07/07/secure-pgp-key-sync-a-proposal/
>
> Thanks for pointing this out, Tom.  It's an interesting project.
>
> I have some questions about parts of the spec that seem unclear to me.
> Tankred, maybe you can clarify?
>
> A) Device Registration Scope says both of these:
>
>  * The device configuration protocol MUST NOT allow a device to
> impersonate another one just with the knowledge of its DeviceSecret.
>
>  * The device configuration protocol WILL NOT protect the user from an
> attacker stealing the DeviceSecret from the server and impersonating the
> device for that DeviceSecret.
>
> The two statements seem in conflict to me, but maybe i'm not
> understanding them.
>
> B) the diagrams use Ea(X,Y) and Es(X,Y), i think meaning "Encrypt Y
> asymmetrically with key X " and "Encrypt Y symmetrically with key X",
> but that's not documented anywhere.
>
> C) it's not clear how Device Registration (as described here) implements
> "The device configuration protocol MUST NOT allow multiple devices with
> the same DeviceSecret."  -- is this true per user?  or globally?  what
> happens if i submit a DeviceSecret that someone else already has used?
>
> D) how is the communication between the client and the server secured
> (if at all)?  I'm assuming from context and the 2XX responses that this
> is a traditional HTTPS tunnel, presumably anchored with traditional
> X.509 trust chain.
>
> E) in all of the documented exchanges, the session keys appear to be
> dictated entirely by the server.  This suggests that a possibility for a
> poorly-implemented or compromised server to regularly use weak or known
> keys.  Is there a reason to avoid, say, a DH-style exchange where both
> parties contribute some entropy to establish a novel session key?  I
> don't have a specific attack in mind, but it does seem unusual to me to
> have an asymmetric arrangement like this.  It also occurs to me that a
> rogue server can force a client to decrypt arbitrary session keys for
> use in any of these communications.
>
>         --dkg
>

-- 
Whiteout Networks GmbH c/o Werk1
Grafinger Str. 6
D-81671 München
Geschäftsführer: Oliver Gajek
RG München HRB 204479