Skip to main content
No single mechanism protects a Neuro IoT interaction. Security is layered.

Layers

Bindings

Clients can connect through supported XMPP bindings such as TCP, WebSocket, or BOSH depending on the implementation. Use a secure transport and validate the broker certificate/host name. Browser constraints do not weaken the authorization model.

End-to-end encryption

The Neuro E2E interface publishes asymmetric key material, negotiates supported algorithms, and protects message and IQ stanzas with hybrid encryption. Supported families can include RSA, elliptic-curve and post-quantum algorithms, with AES-256 or ChaCha20/Poly1305 symmetric protection depending on endpoints. Feature-detect algorithms, reject downgrade, rotate compromised keys, and bind keys to the authenticated peer.

Federation

In federation, brokers validate each other’s domains and forward stanzas between clients on different domains. An application must still authenticate the end actor and authorize the requested operation; a valid remote domain is not blanket trust.

Threat checklist

  • replayed commands and stale tokens;
  • malicious or compromised broker/package;
  • device claim-code theft;
  • over-broad provisioning cache entries;
  • prompt/script injection through sensor labels or messages;
  • metadata/location leakage through discovery;
  • unsafe control retries;
  • lost key revocation and software-update signing keys.