8

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?

  • 1
    Why you want to encrypt sensor data at first place?? – Shubhendu Yadav Aug 27 '18 at 20:15
  • 4
    Because of these data are important for example iot.stackexchange.com/a/683/7138 – Kashan Aug 27 '18 at 20:20
  • 1
    Nice examples and explanation but do you really think that you need encryption in your system. Thats what I wanted to ask. – Shubhendu Yadav Aug 27 '18 at 20:23
  • 1
    I honestly don't know .. What my question was about is the check the possibility to have end to end encryption .. Implementing such a system is not my priority at this point – Kashan Aug 27 '18 at 20:30
  • 1
    Than i ll try my level best to answer your queries – Shubhendu Yadav Aug 27 '18 at 20:31
3

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.

1

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.

  • 3
    thanks for the hint. I will check it out. However, that doesn't really answer the question – Kashan Aug 29 '18 at 19:45
  • 1
    in the FAQ of ZeroQ it's written (What security features does ZeroMQ support? None at the moment but this is being added to the next version of the protocol. People have successfully built DTLS, CurveCP, and other security protocols over ZeroMQ.) – Kashan Aug 29 '18 at 19:49

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.