Session establishment protocol

7.4.1. Generic protocol

0. C → S : i ni t

C indicates to S that a newBALSASession should be established.

1. S → C : SI D, Snonce

Snonceis changed by S every time a valid Bt okenis received (cf. Message 4).

2. C → B : CI D, SI D, Snonce

C forwards the information received from S to B , along with its ID.

3. B → C : KS, Br nd, Bt oken, Bt oken_mac. With:

B_{t oken}:= {K^S||Snonce||CI D||Br nd}KB S_E NC

Bt oken_mac:= [Bt oken]KB S_M AC

B randomly generates the shared secret KSand the random value Br nd. 4. C → S : Bt oken, Bt oken_mac, Ct oken. With: Ct oken:= {Snonce}KS

S can validate the integrity of Bt oken using Bt oken_mac. Then it can decrypt it and check that the extracted value of Snonce corresponds the one in Message 1, which ensure fresh involvement of B . S authenticates C by checking that decryption of Ct okenusing KSyields Snonce. CI Dis recovered from Bt oken, which ensures that B has vouched for C to communicate with S in theBALSASession identified by Snonce

using KS.

5. S → C : {Br nd}KS

C authenticates S by comparing the decryption of Message 5 with the value of Br nd

received from B in Message 3.

Upon decrypting Bt oken as received in Message 3, S could check that the extracted Snonce matches the corresponding value sent in Message 1. If that is not the case, then Bt okenwas tampered with or corrupted. Consequently, Bt oken_mac in Message 3 appears superfluous. We have decided to include it on the grounds that authenticity should be ex-plicitly asserted and not obtained as a by-product of decryption.

7.4. Session establishment protocol 123

Security properties. The security of the tunnel onBLEis based on the confidential-ity of KS, which is generated by B and shared between C and S at the end of the session establishment protocol execution. KSis freshly generated at random on every such proto-col execution.

An attacker needs to compromise at least one of these entities orI nternet_{to gain} access to KS, neither of which is possible according to the attacker model described in Section 7.2.3. Man In The Middle (MITM) attacks are similarly prevented by the inability of the attacker to access KS.

Generation of a spurious Bt oken is prevented by generating and sending Bt oken_mac

along in messages 3 and 4. A valid Bt oken_macimplies fresh involvement of B .

C does not authenticate directly to S. Instead it is “vouched" for by B to whom it must authenticate prior to receiving Bt oken(tight Backend-based access control).

Even though Snonce is public information, only an entity with which B has shared KS, in this case C , is able to generate Ct okenin Message 4. As a consequence, attempting to re-play a round of the session establishment protocol will fail because Ct okenis derived from Snonce, which changes with every valid Bt okenreceived by S. Conversely, S authenticates to C by being able to encrypt Br nd using KS in Message 5. By doing so, S demonstrates possession of KB S_E NC.

7.4.2.

Service-based protocol

(1.1q) C → S : R^EAD(Get Sensor I D) (1.1a) C ← S : SI D

1.2q C → S : R^EAD(Get Sensor Nonce) 1.2a C ← S : Snonce

These two reads (and responses) correspond to Messages 0 and 1 in the generic pro-tocol. 1 ≤ |SI D| ≤ 20 × 8; |Snonce| = 128;

2 C → B : CI D, SI D, Snonce

3 C ← B : K^S, Br nd, Bt oken, Bt oken_mac. With:

Bt oken:=^AES_CBC(KB S_E NC, #»_{0 , K}

S|| Snonce|| CI D|| Br nd), and Bt oken_mac:=^AES_CMAC(KB S_M AC, Bt oken)

This message corresponds to the information that the Client receives from the Back-end. The details of how this information is received is out of scope for the purposes of this protocol definition. What is important is that KS, KB S_E NC, and KB S_M ACare 128 bitAESkeys, and |Br nd| = |CI D| = 128.

4.1 C → S : W^RITE(SetC l i ent D at a, 1 ||^EXTRACT(Bt oken, 0, 16)) 4.2 C → S : W^RITE(SetC l i ent D at a, 2 ||^EXTRACT(Bt oken, 16, 16))

4.3 C → S : W^RITE(SetC l i ent D at a, 3 ||^EXTRACT(Bt oken, 32, 16))

4.4 C → S : W^RITE(SetC l i ent D at a, 4 ||^EXTRACT(Bt oken, 48, 16))

4.5 C → S : W^RITE(SetC l i ent D at a, 5 || Ct oken|| T Bt oken_mac)). With:

Ct oken:=^AES_ECB(KS, Snonce), and T Bt oken_mac:=^RIGHT(Bt oken_mac, 3).

These messages correspond to Message 4 in the generic protocol. It is sent to the Sensor by doing repeated writes to the SetClientData characteristic.

5.1q C → S : R^EAD(Get Sensor Response)

5.1r C ← S :^AES_ECB(KS, Br nd)

These messages correspond to Message 5 in the generic protocol.

6.1 C → S : S^UBSCRIBE(Not i f y M AC )

To terminate, C subscribes to the NotifyMAC characteristic, which will be used by S to send theMACsof the notifications/indications sent to the client.

READing the GetSensorID characteristic (messages 1.1_) is not essential and it is per-mitted to skip it. In particular, when the Client already knows the identity of the Sensor, which may be the case when the Client can resolve SI Dfrom the Bluetooth address, or it has cached such an identifier from previous connections.

Upon receiving Message 5.1q, the Sensor will validate that all expected messages have been received and that their contents satisfy its expectations. If a deviation or failure is encountered, all remaining checks and validations will be executed, but the contents of Message 5.1r will contain a random 128 bit string that will terminate the protocol in fail-ure at the Client side.

Security properties. The implementation requires Bt oken (Message 4) to be split in five messages when sent from the Client to the Sensor as a result of the payload size limi-tation. This does not have any consequence in terms of security as this channel is assumed to be under full adversarial control. Messages 4.x do not necessarily need to be sent in or-der, but are expected to have been all sent prior to Message 5.1q.

There is a limit on how many sessions can be established with a given Sensor deter-mined by the bit length of Snonce. If the Sensor advertises a Snonceafter it has already been used in a previousBALSASession, replaying such a session becomes possible. In our current proposal the number of sessions is limited to 2¹²⁸, which is acceptable for the envisioned usage scenarios.