Vendor/product description:-----------------------------oBike is (was) a Singaporean stationless bicycle-sharing system with operationsin several countries [1].

Introduction:-------------The bikes have a built-in Bluetooth lock [2]. Clients use their smartphone tolocate a bicycle. Once nearby, they unlock the bicycle directly from the app orby scanning a QR code. Unlike traditional rental services, which require bikesto be returned to a fixed docking station, users are free to leave the bikesat any suitable bike parking spot.

Affected:---------As of August 2018, this issue seems to affect the whole oBike fleet (or what isleft of it).

Technical Description:----------------------The oBike lock consists of a TI CC2541 microcontroller, a power-optimizedSystem on a Chip (SoC) used for Bluetooth Low Energy (BLE) applications. Thelock itself has no IP connectivity; it piggybacks the mobile device's 3G/4Gconnection to communicate with the oBike backend. The lock communicates viaBLE with the oBike app on the mobile device. Protocol messages are then relayedto the oBike backend via a REST API.

Steps:(1) BLE send `hello` message, push GPS coordinates to lock.(2) BLE receive `keySource`, a 32bit value used as a challenge.(3) HTTPS send `keySource` to oBike backend via the `unlockPass` REST call.(4) HTTPS receive `encKey` (key index) and a 128bit ciphertext in `keys`.(5) BLE send `keys` (truncated to 96bits) and the `encKey`. At that point, the bike will unlock.(6) BLE receive `macKey` and `index`, an acknowledgement that the unlocking was successful.(7) HTTPS send `lockMessage`, with the corresponding values (`macKey` and `index`). At that point, the oBike backend will register the ride and start billing.

A first vulnerability [3] was found prior to this advisory, which consists inleaving out the acknowledgement in step (7). By omitting this message, thelock is opened but the ride is not registered at the oBike backend, thereforenot being billed.

Analysis of the `keySource` field (32 bit challenge) in step (2) showed thatthe values generated by the lock are not random as expected. Rather, thevalues represent the number of milliseconds since the chip was powered on. Thiscorresponds to a time window of roughly 50 days (2^32 milliseconds).

The 128bit ciphertext in `keys` from step (5) is used to unlock the bike. Itsvalue as returned by the oBike backend is the result of an unknown cryptographicoperation based on the `keySource` field (generated by the lock), and the`encKey` value (given by the backend). Taken from the CC2541 specificationsand the length of `keys`, the value corresponds most probably to an AES-128ciphertext. The `encKey` in turn selects the encryption key from a set of64 distinct indices, which is chosen randomly by the backend.

Given fixed `keySource` and `encKey` values it was observed that the resulting`keys` value is always equal, allowing for replay attacks. To this end, allpossible `keySource` values are enumerated and the corresponding `keys` and`encKey` values captured. It is possible to replay these values offline at alater point in time.

To limit the number of values to be enumerated, A BLE command was discoveredthat provokes a chip reset. Given this condition, the generated `keySource`lies within a predictable time window, which greatly simplifies the attack.Now, only several seconds worth of `keySource` values are needed to implementthe replay attack.

A description of the BLE and REST protocols can be found in [4].

Workaround / Fix:-----------------No known fix/workaround available. The attack works offline, there is no knownpossiblity to detect or to prevent it on the backend.