BoIP specification

BoIP spec

Header byte:

• Bit 7 (128): Secure mode if 1
• Bit 6 (64) : Bluetooth frame if 0, Host control if 1 (Host control is a separate protocol, RCSMCE in the case of this software) (The following only applies to portable BoIP, excluding RCSMCE frames)
• Bit 5 (32) : Data Frame if 0, Bluetooth control if 1

Note: secure mode indicates whether there is encrypted data or not

Bluetooth Data Frame:

• Header byte (continuation)
  • Bit 4 (16): 1 when last packet of transmission, 0 otherwise
  • Bit 3 (8) : 1 when payload is compressed with zlib
• Length byte [0 - 255]: payload length; in non-secure mode, a 0 length byte can be used as a way to signal a disconnect
• (Optional: if secure mode) Realength DWORD: actual length
• Destination MAC 6bytes
• Sender MAC 6bytes
• Payload

Note: in secure mode, all bytes after the header are encrypted except the length byte Note: the Realength byte indicates the actual length of the encrypted data, since there can be some random padding bytes at the beginning of the payload Note: the payload is XOR'ed with the DH secret; the offset in the secret is the summed length of all the previous packets from the client modulo the secret length Note: the encryption scheme is AES-256 and the key is the DH key XOR'ed with the SHA256 hashes of the previous data frames' decrypted payload

Bluetooth Control Frame:

• Header byte (continuation)
  • Bit 4 (16): 1 for authentication (The following only applies to non auth; see "Auth frame" for auth data)
  • Bit 3 (8): 1 to manage connection flags; 0 to manage pairing (The following applies to connection flags; for pairing, see "Bluetooth pairing")
  • Bit 2 (4): 1 if device wants to be Bluetooth master, 0 if it wants to be a slave
  • Other bits are reserved; must be 0

Note: The actual master/slave relationship is chosen based on the reply advert master/slave bit Note: it is unspecified whether changing the master/slave status after the first data frame has been sent is allowed

Bluetooth pairing:

• Header byte (continuation)
  • Bits 2 and 1 (4 & 2): 0b00 for pairing request, 0b01 for pin request, 0b10 for pin providal, 0b11 for pairing reply
  • Bit 0: on pairing reply, 1 is success, 0 is is failure; unused otherwise and must be 0
  • Destination MAC 6bytes
  • Sender MAC 6bytes (On pairing request):
    • Sender namebytelength
    • Sender name (namebytelength bytes long) (On pin providal)
    • Pin QWORD

Auth frame:

• Header byte (continuation)
  • Bits 3 and 2 (8 & 4): 0b00 for advert, 0b01 for denial, 0b11 for key change
  • Bit 1 (2): Reserved; must be 0 (The following only applies to advert; otherwise next bits are ignored)
  • Bit 0 (1): 1 for SIDH, 0 for ECDH (On advert):
  • Keylen WORD: Bytelength of the public key
  • Pubkey, keybitlen bits long, padded with 0s to the next byte (On keychange):
  • 256 bits AES key

Note: An authentication advert is invalid if it is not the first message of a connection Note: For SIDH, Alice is the whoever sent the first public key of the accepted length Note: Keychange is sent by Alice Note: On keychange, the key is AES256 encrypted with the last 32bytes of the DH secret Note: The Keychange key is reffered as "DH key" in the rest of this document