|
|
BQP is a key agreement protocol that establishes an ephemeral secure channel between a pair of mobile devices equipped with screens and cameras.
|
|
|
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 connection information to establish an insecure duplex channel. The devices 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 keys derived from the shared secret are used to secure the channel. Further information, such as long-term public keys, may then be exchanged over the secure 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 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.
|
|
|
|
|
|
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 the 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 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.
|
|
|
|
|
|
### Notation
|
|
|
|
... | ... | @@ -30,11 +30,13 @@ All hashes are HASH_LEN bytes, all symmetric keys are KEY_LEN bytes, and the out |
|
|
|
|
|
### Key generation
|
|
|
|
|
|
Each device starts by generating a fresh ephemeral key pair (pri, pub). The commitment to the public key is HASH("COMMIT", pub).
|
|
|
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.
|
|
|
|
|
|
### QR codes
|
|
|
|
|
|
Each device creates a QR code with a binary payload. The payload is encoded using Base32, as defined in [RFC 4648](https://tools.ietf.org/html/rfc4648), and the QR code uses alphanumeric mode. The first byte of the binary payload is the protocol version, which is 1 for the current version of BQP. The next HASH_LEN bytes of the payload are the public key commitment. The remainder of the payload consists of zero or more transport descriptors.
|
|
|
Each device creates a QR code with a binary payload. The payload is encoded using Base32, as defined in [RFC 4648](https://tools.ietf.org/html/rfc4648), and the QR code uses alphanumeric mode. The first byte of the binary payload is the protocol version, which is 1 for the current version of BQP. The next COMMIT_LEN bytes of the payload are the public key commitment. The remainder of the payload consists of zero or more transport descriptors.
|
|
|
|
|
|
### Transport descriptors
|
|
|
|
... | ... | @@ -74,7 +76,7 @@ If no connections can be established within CONNECTION_TIMEOUT seconds of scanni |
|
|
|
|
|
The devices are assigned roles according to the lexicographic order of their public key commitments: the device with the earlier commitment takes the role of Alice, while the device with the later commitment takes the role of Bob. If multiple transport connections are established, Alice decides which connection to use and closes any other connections.
|
|
|
|
|
|
> Implementation note: We propose to use CONNECTION_TIMEOUT = 20 seconds.
|
|
|
> Implementation note: We propose to use CONNECTION_TIMEOUT = 20 seconds as a reasonable tradeoff between reliability and responsiveness.
|
|
|
|
|
|
### Records
|
|
|
|
... | ... | @@ -94,9 +96,9 @@ The current version of the protocol is 1, which has three record types: |
|
|
|
|
|
### Key exchange
|
|
|
|
|
|
Alice begins by sending a KEY record containing her ephemeral public key, pub_a. Bob compares HASH("COMMIT", pub_a) to the commitment in Alice's QR code. If the key does not match the commitment, Bob sends an ABORT record and aborts the protocol.
|
|
|
Alice begins by sending a KEY record containing her ephemeral public key, pub_a. Bob compares the first COMMIT_LEN bytes of HASH("COMMIT", pub_a) to the commitment in Alice's QR code. If the key does not match the commitment, Bob sends an ABORT record and aborts the protocol.
|
|
|
|
|
|
Bob sends a KEY record containing his ephemeral public key, pub_b. Alice compares HASH("COMMIT", pub_b) to the commitment in Bob's QR code. If the key does not match the commitment, Alice sends an ABORT record and aborts the protocol.
|
|
|
Bob sends a KEY record containing his ephemeral public key, pub_b. Alice compares the first COMMIT_LEN bytes of HASH("COMMIT", pub_b) to the commitment in Bob's QR code. If the key does not match the commitment, Alice sends an ABORT record and aborts the protocol.
|
|
|
|
|
|
Alice and Bob calculate the shared secret as follows:
|
|
|
|
... | ... | @@ -107,23 +109,22 @@ If the adversary has not modified the KEY records, both devices should calculate |
|
|
|
|
|
### Confirmation
|
|
|
|
|
|
Each device knows it has calculated the correct shared secret because it has compared the received public key to the commitment in the QR code. However, each device also needs to know that the other device has calculated the correct shared secret. To confirm this, both devices derive a confirmation key from the shared secret and use it to calculate two message authentication codes over the payloads of the QR codes, q_a and q_b, and the public keys, pub_a and pub_b:
|
|
|
Each device knows it has received the correct public key because it has compared the received public key to the commitment in the QR code. However, each device also needs to know that the other device has received the correct public key. To confirm this, both devices derive a confirmation key from the shared secret and use it to calculate two message authentication codes over the binary payloads of the QR codes, q_a and q_b, and the public keys, pub_a and pub_b:
|
|
|
|
|
|
* `k_c = KDF(s, "CONFIRMATION_KEY")`
|
|
|
* `ck = KDF(s, "CONFIRMATION_KEY")`
|
|
|
* `sent_a = len(q_a) || q_a || len(pub_a) || pub_a`
|
|
|
* `sent_b = len(q_b) || q_b || len(pub_b) || pub_b`
|
|
|
* `mac_a = MAC(k_c, sent_a || sent_b)`
|
|
|
* `mac_b = MAC(k_c, sent_b || sent_a)`
|
|
|
* `mac_a = MAC(ck, sent_a || sent_b)`
|
|
|
* `mac_b = MAC(ck, sent_b || sent_a)`
|
|
|
|
|
|
Alice sends a CONFIRM record containing mac_a. Bob compares the received mac_a to the mac_a he calculated. If the codes do not match, Bob sends an ABORT record and aborts the protocol.
|
|
|
Alice sends a CONFIRM record containing mac_a. Bob compares the received mac_a to the mac_a he calculated. If the values do not match, Bob sends an ABORT record and aborts the protocol.
|
|
|
|
|
|
Bob sends a CONFIRM record containing mac_b. Alice compares the received mac_b to the mac_b she calculated. If the codes do not match, Alice sends an ABORT record and aborts the protocol.
|
|
|
Bob sends a CONFIRM record containing mac_b. Alice compares the received mac_b to the mac_b she calculated. If the values do not match, Alice sends an ABORT record and aborts the protocol.
|
|
|
|
|
|
### Securing the channel
|
|
|
### Master key derivation
|
|
|
|
|
|
Finally, the devices upgrade the insecure channel to a secure channel by deriving two keys from the shared secret:
|
|
|
Finally, both devices derive the master key:
|
|
|
|
|
|
* `k_a = KDF(s, "ALICE_STREAM_KEY")`
|
|
|
* `k_b = KDF(s, "BOB_STREAM_KEY")`
|
|
|
* `mk = KDF(s, "MASTER_KEY")`
|
|
|
|
|
|
Alice uses k_a to encrypt and authenticate a [BTP] stream to Bob over one side of the transport connection, and Bob uses k_b to encrypt and authenticate a BTP stream to Alice over the other side of the connection. The streams do not have pseudo-random tags or stream headers: each stream just consists of one or more BTP frames. |
|
|
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. |