Expand description
Verifying the identity assertion a peer proves its address with.
The layout is public_key(32) || signature(64) || signed_data, and it has
one home, offline_protocol_sealed::identity_assertion. This module is
the one verifier of it: it parses, checks the signature under the key, and
derives the address from the key, in that order, and returns the derived
address or an error. It is what the verify_identity_assertion FFI
function calls, so a Bluetooth LE central on any platform and a peer-stream
transport on any host run the same four lines against the same bytes.
§What verification proves, and what it does not
A returned address means the peer that served these bytes holds, or once held, the private key that address derives from. It does not mean the peer is live or recent: the assertion is static and replayable, as BLE framing states, and a device in range can serve a value it copied. What it cannot do is sign the frames that address must sign, which is where authenticity is established. A caller MUST NOT treat a verified assertion as proof of liveness or of sole ownership.
§The fourth step is the caller’s
The chapter’s verification has four steps. The first three are here. The fourth, comparing the derived address to the one the peer claimed over some other channel (the Device id characteristic, a DNS-SD TXT record), belongs to whoever read that channel, because this function never sees it. The comparison is exact, and the announced address is always the derived one, never the claimed string: the two are equal whenever verification succeeds, so the derived value costs nothing, and it means no code path announces a name that arrived unauthenticated.
Functions§
- verify_
identity_ assertion - Verifies an identity assertion and returns the address it proves.