Internet of Things Stack Exchange is a question and answer site for builders and users of networked sensors and control devices in the contexts of smart homes, industry automation, or environmental sensors. It only takes a minute to sign up.
Sign up to join this community
I have been reading about XMPP and its extensions. One of them called (XEP-xxxx: Sensor-Over-XMPP) which is really interesting.
I have read also about another XMPP extension which is OMEMO protocol for End-to-end encryption.
Is it possible to combine both? to have sensor data that End-to-end encrypted? And what are the considerations that I should take into account?
Yes, you should be encrypting your sensor messages.
No, you shouldn't be thinking about using a roll-your-own approach to add encryption on top of an existing re-used protocol.
Security isn't just about the messages, you ideally want to trust the server, to trust your firmware updates, etc.
The easy way around this is to use a full device firmware stack which already provides some guarantees about security, aimed specifically at IoT applications. Rather than encrypting your sensor data, you probably want to use a secure channel (for everything). TLS seems to be the default answer to this.
Related question.
Please consider to use ZeroMQ because that platform will give you option to have end2end encryption and can carry messages across inproc, IPC, TCP, TIPC, multicast. In addition - it is really tiny library with interfaces ready for many programming languages.
When we are about security please check out bellow:
The core C/C+++ library implements the NULL and PLAIN mechanisms (those were easy), and also CURVE and GSSAPI (rather harder). CURVE is the CurveZMQ.org protocol for authentication and encryption. GSSAPI lets us plug into Kerberos. The core library has an authentication API called "ZAP" that lets you add, e.g. your own IP address blacklisting at the connection level.
