[noise] SAS (was: Explicit nonces (for lossy transports)

[Trevor Perrin]

On Wed, Jul 12, 2017 at 7:30 AM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> On Wed, Jul 12, 2017 at 11:13 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> Thinking about this more:
>>
>> Short Auth Strings are useful for things like "pairing" two devices by
>> checking that they display the same short code, or maybe even for
>> voice authentication between two parties, where their phones display a
>> short string which they verbally compare.
>
>
> Bluetooth Secure Simple Pairing (SSP) is another example of such a pairing
> protocol which is used in devices everywhere.  You can find the Core spec
> online for the gory details, but summarising: the two devices perform a
> crypto dance with ECDH and a bit commitment scheme to agree upon a shared
> secret and a 6-digit number to display on the screens for cross-checking.

Oh interesting, AFAICT they do this [1]:

-> e
<- e
-> hash(nonce1)
<- nonce2
-> nonce1, ee

I was suggesting below, which seemed easy to bolt on to existing
patterns without adding round-trips, but does add another DH (f: SAS
DH key pair):

-> e, hash(f)
<- e, ee
-> f, fe


If we were willing to change handling of ephemerals, we could get even simpler:

-> hash(e)
<- e
-> e

They're all pretty similar, just a 3-step commit/choose/reveal process
to determine the SAS, and some way of binding it to a secret DH
output.

So I guess there's more to think about, but this seems doable to add sometime.


> In Noise terms, the shared secret is a PSK generated from the pairing
> session which is then used to set up subsequent sessions between those two
> devices.
>
> SSP also has support for incorporating the hash of a password/pin into the
> crypto dance.  Useful if the headset or whatever comes with a pin printed on
> it.

To do that properly you want a "PAKE".  I'm not sure Bluetooth does a
good job there, e.g. [2].  That's another thing we could tackle.


> A rough analogue in Noise for SSP would be "Noise_NNpsk0+sas" where
> Hash(pin) is the input PSK.

Unless 'pin' has 256 bits entropy, that's a bad PSK - hence the need for PAKE.


>  Then generate a PSK from that session for use
> in setting up subsequent Noise_XXpsk0 or whatever sessions.
>
> As an aside, maybe generated PSK's can be incorporated as a "genpsk"
> modifier and token:
>
>     Noise_NNgenpsk+psk0+sas:
>       -> psk, e, commit
>       <- e, ee
>       -> reveal, genpsk
>
> Where the "genpsk" token is defined as:
>
>     ck, generated_psk = HKDF(ck, zeroes, 2)
>
> I know we've discussed before how to generate PSK's from the Split() cipher
> states, but I do sort of see PSK generation as a handshake function rather
> than a transport function.  A token fits better.  IMHO.

I was thinking we might get by without a special PSK derivation
process, since we can get PSKs out of Noise a couple other ways:

 (A) If you're using the Noise handshake phase but not the transport
phase (like this Bluetooth case), I'm not sure it makes sense to throw
away the transport keys but add a special derivation process for a
PSK.  Seems easier to repurpose the unused transport key(s).

 (B) One party can just transmit a PSK to the other.  There's some
subtlety in that you might want to "channel-bind" the PSK by hashing
it with the handshake-hash, or using the handshake-hash as prologue
when such a PSK is used for resumption, to prevent PSKs being relayed
between sessions.  But I'm thinking that might be OK, and transmitting
the PSK gives flexibility to send multiple PSKs, and works well with
rekey (since PSKs sent before a rekey will be protected by the rekey).

At least, I was hoping to try (B) in the context of PSK resumption and
see if it's adequate before adding new PSK derivation.


Trevor

[1] http://www.springer.com/cda/content/document/cda_downloaddocument/9783642406454-c2.pdf?SGWID=0-0-45-1434420-p175453762
[2] https://www.blackhat.com/presentations/bh-usa-08/Lindell/BH_US_08_Lindell_Bluetooth_2.1_New_Vulnerabilities.pdf