|
|
BQP is a key agreement protocol that establishes an ephemeral symmetric key between a pair of mobile devices equipped with screens and cameras.
|
|
|
|
|
|
Each device displays a QR code containing a commitment to an ephemeral public key and information about how to connect to the device over various short-range transports. The devices scan each other's codes and use the transport information to establish an insecure duplex channel. The devices then exchange public keys matching their commitments over the insecure channel. Each device derives the shared secret from its own private key and the received public key, and a master key is derived from the shared secret. The master key may be used to derive keys for securing the channel.
|
|
|
Each device displays a QR code containing a commitment to an ephemeral public key and information about how to connect to the device over various short-range transports. The devices scan each other's codes and use the transport information to establish an insecure duplex connection. The devices then exchange public keys matching their commitments over the insecure connection. Each device derives the shared secret from its own private key and the received public key, and a master key is derived from the shared secret. The master key may be used to derive keys for communicating securely over the transport connection.
|
|
|
|
|
|
The initial exchange of QR codes is assumed to be secure against man-in-the-middle attacks because the users can see which devices they are scanning. Man-in-the-middle attacks against the subsequent exchange of public keys over the insecure channel can be detected by comparing the keys to the commitments contained in the QR codes. We assume the adversary can read, modify, delete and insert traffic on all transports at will.
|
|
|
The initial exchange of QR codes is assumed to be secure against man-in-the-middle attacks because the users can see which devices they are scanning. Man-in-the-middle attacks against the subsequent exchange of public keys over the insecure connection can be detected by comparing the keys to the commitments contained in the QR codes. We assume the adversary can read, modify, delete and insert traffic on all transports at will.
|
|
|
|
|
|
### Notation
|
|
|
|
... | ... | @@ -32,7 +32,7 @@ All hashes are HASH_LEN bytes, all symmetric keys are KEY_LEN bytes, and the out |
|
|
|
|
|
Each device starts by generating a fresh ephemeral key pair (pri, pub). The commitment to the public key is the first COMMIT_LEN bytes of HASH("COMMIT", pub). We require that COMMIT_LEN <= HASH_LEN.
|
|
|
|
|
|
> Implementation note: COMMIT_LEN = 16 is sufficient for a 128-bit security level because the adversary cannot make use of the birthday paradox: a successful man-in-the-middle attack requires a public key with a commitment that matches the victim's commitment, rather than two public keys with commitments that match each other.
|
|
|
> Implementation note: COMMIT_LEN = 16 is sufficient for 128-bit security because the adversary cannot make use of the birthday paradox: a successful man-in-the-middle attack requires a public key with a commitment that matches the victim's commitment, rather than two public keys with commitments that match each other.
|
|
|
|
|
|
### QR codes
|
|
|
|
... | ... | @@ -70,7 +70,7 @@ New transports may be defined in future without incrementing the protocol versio |
|
|
|
|
|
### Connection establishment
|
|
|
|
|
|
When a device has scanned a QR code it may immediately connect to the other device over any transports supported by both devices, simultaneously or in any order. This may result in one or more transport connections being established.
|
|
|
When a device has scanned a QR code it may immediately connect to the other device over any transports supported by both devices, simultaneously or in any order. This may result in one or more transport connections being established by either or both of the devices.
|
|
|
|
|
|
If no connections can be established within CONNECTION_TIMEOUT seconds of scanning the QR code, the device aborts the protocol.
|
|
|
|
... | ... | @@ -102,8 +102,8 @@ Bob sends a KEY record containing his ephemeral public key, pub_b. Alice compare |
|
|
|
|
|
Alice and Bob calculate the shared secret as follows:
|
|
|
|
|
|
* Alice calculates `s = HASH("SECRET", DH(pri_a, pub_b), pub_a, pub_b)`
|
|
|
* Bob calculates `s = HASH("SECRET", DH(pri_b, pub_a), pub_a, pub_b)`
|
|
|
* Alice calculates `s = HASH("SHARED_SECRET", DH(pri_a, pub_b), pub_a, pub_b)`
|
|
|
* Bob calculates `s = HASH("SHARED_SECRET", DH(pri_b, pub_a), pub_a, pub_b)`
|
|
|
|
|
|
If the adversary has not modified the KEY records, both devices should calculate the same shared secret.
|
|
|
|
... | ... | @@ -127,4 +127,4 @@ Finally, both devices derive the master key: |
|
|
|
|
|
* `mk = KDF(s, "MASTER_KEY")`
|
|
|
|
|
|
The master key is retured to the calling application together with a flag indicating whether the device played the role of Alice or Bob. The application may use the master key and flag to derive encryption and authentication keys for secure communication over the transport connection. |
|
|
The master key is retured to the calling application, together with the transport connection and a flag indicating whether the device played the role of Alice or Bob. The application may use the master key and flag to derive encryption and authentication keys for communicating securely over the transport connection. |