0
\$\begingroup\$

Is it possible to secure I2C communication between slave and master so nobody else can connect their devices to the master. Basically encrypting the message.

Is this feasible by software or hardware?

Note: I have a sensor that connects to ADC(there are amplifier and filter before this) which I communicate with I2C to read the sensor data. I would like to make sure nobody can use my sensor without my controller.

Base on everyone feedback I will try to use a microcontroller with precision ADC to send data. but does anybody know a small and cheap microcontroller that has precision ADC with I2C port?

enter image description here

\$\endgroup\$
  • 3
    \$\begingroup\$ I2C is just a way to exchange data between devices, so as long as you control the behavior of both devices (IE, you're writing the code that will run on two MCUs), you can exchange whatever data in whatever format you want. Robust cryptographic authentication, however, is tricky, and you'll need to provide more information to get useful advice. At a minimum, both devices will need to be able to perform cryptographic operations on the exchanged data based on a shared (symmetric or asymmetric) key. \$\endgroup\$ – ajb Sep 8 '18 at 19:32
  • \$\begingroup\$ You could actually encrypt the message. But i2c isn't really designed for messages that are long enough for encryption to make sense. What problem are you actually trying to solve? \$\endgroup\$ – The Photon Sep 8 '18 at 19:33
  • 2
    \$\begingroup\$ If you're using an off-the-shelf I2C device like an ADC, then you're stuck with whatever behavior the device comes with from the factory. If you are trying to authenticate a plug-in module or something you could add an authentication device in addition to the ADC. The master would check for the authentication device before reading from the sensor. There are devices designed specifically for this purpose. \$\endgroup\$ – ajb Sep 8 '18 at 19:41
  • 2
    \$\begingroup\$ You've described two different problems that require different solutions. Keeping your sensor from being used on someone else's master device while using an off-the-shelf I2C ADC is a much more difficult problem than preventing other people's sensors from being used with your master device. \$\endgroup\$ – ajb Sep 8 '18 at 19:48
  • 2
    \$\begingroup\$ You could embed a small microcontroller in the sensor and then have uC to uC communication. That communication could be whatever you want. It could be encrypted and authenticated in both directions. The drawback would be more cost and the sensor would need to be protected by something like potting. \$\endgroup\$ – vini_i Sep 8 '18 at 19:53
1
\$\begingroup\$

Since you probably won't find an ADC with built-in encryption, your best bet is to use a microcontroller (MCU) that includes an ADC, and encrypt (or at least obscure) its output data. (This seems to be what you are saying in your edited question, but the diagram you provided still shows a separate ADC.)

You need to specify what you mean by "precision". While many MCUs contain ADCs, ADCs built in to MCUs usually aren't "precision" compared to stand-alone devices.

If all you want is to make it difficult for someone to reverse-engineer your system, you don't need state of the art cryptography. A fairly simple scheme to obscure a data stream is to generate a pseudorandom sequence with an LFSR, and XOR your data with the sequence. This will increase the cost of reverse-engineering your data stream.

Make your LFSR long enough (32 bit) and perhaps don't choose the one maximal-length sequence, choose one of many less than maximal length ones.

You will need to figure out how to synchronize your receiver's sequence with your transmitter's, or what to do if they become desynchronized.

\$\endgroup\$
  • 1
    \$\begingroup\$ You could use a diffie hellman key exchange to resynchronize. Possibly taking a random reading from an open ADC to generate the hidden keys. \$\endgroup\$ – vini_i Sep 9 '18 at 0:49
  • \$\begingroup\$ That's "real cryptography", and only worth doing if you use a serious crypto algorithm. You could also just send a message saying start the sequence over again. \$\endgroup\$ – Eamon Sep 9 '18 at 1:42
  • \$\begingroup\$ It doesn't have to be full to the tilt cryptography but it could be used to seed an LFSR. That would make reverse engineering, not impossible, but much harder. \$\endgroup\$ – vini_i Sep 9 '18 at 12:08
  • \$\begingroup\$ I had the impression DH was a bit complicated but I've never looked into it. \$\endgroup\$ – Eamon Sep 9 '18 at 14:42
  • \$\begingroup\$ You can use a self-synchronizing LFSR - a k-bit self-synchronizing LFSR will result in reading the first k bits as garbage, but after that it will maintain synchronization. This is a commonly-used technique to scramble serial data for electrical reasons (see 64b/66b encoding), but it is not secure by any means. \$\endgroup\$ – alex.forencich Jun 11 '19 at 19:37

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.