2
$\begingroup$

I have several IOT devices that transmits nearly 200 bytes of data every 10 seconds. I want to make the data secured but i also want to keep the data size nearly same. Ofcourse for IOT devices computations should be lightweight. I have been considering AES 128 for this job and RSA for key exchange. I am wondering if i am on the right track or there are better options.

i saw NIST have called for lightweight encryption algorithm for IOT devices. until that is standardized which encryption should i use.

in summary, i want to get the overview of different encryption scheme with minimal overheads and computations. I looked around but there seems to be no this type of comparisons.

I am very much new in this field so forgive me if i have done any silly mistake.

Improve this question
$\endgroup$
3
  • $\begingroup$ What are your goals? Prevent an adversary from reading the data? Provide authentication for the data? Keep in mind that if an adversary could easily snatch one of your IOT devices and examine it at leasure, there is almost nothing you can do to secure it. $\endgroup$
    – Roland Smith
    Commented Jul 29, 2018 at 14:12
  • $\begingroup$ i am not worried about snatching. devices are at pretty secure location. all i am worried about is the data it reads and sends to server every 5-10 seconds. right now it sends data through http request, although i am planning to implement mqtt(lightweight). my worry is if someone manages to get his hands on the data during device to server communication. so i am thinking about encrypting "the data" inside the iot device before sending it to server. so that if someone manages to get the data it would be hard for him to extract the original information from it $\endgroup$
    – mosharaf13
    Commented Jul 30, 2018 at 4:39
  • $\begingroup$ You'll also need to tell us about the capabilities of the device you're using. Is it a Linux machine like a raspberry pi, an arduino-like platform or something even more basic? How much storage does it have, and how much of the 200 bytes payload is actually variable data? $\endgroup$
    – Roland Smith
    Commented Jul 30, 2018 at 11:51

3 Answers 3

Reset to default
2
$\begingroup$

For passively powered RFID tags, I settled on 160-bit ECC (Curve25519) to exchange the keys and SPECK for the actual encryption on a software platform. If I make my own hardware, I use SIMON instead of SPECK. For an IoT application, I see no reason not to do something similar.

If you are looking for comparisons of symmetric ciphers regarding throughput and power, I would suggest the SIMON and SPECK paper and the paper on PRESENT as both have good power tables and comparisons.

Improve this answer
$\endgroup$
5
  • $\begingroup$ I can give this answer a +1 if you add more specifics. (Modes, key sizes, block sizes, and authentication algorithm. I'll also be a bit annoyed if you say something smaller than Speck128.) $\endgroup$
    – Future Security
    Commented Jul 30, 2018 at 21:14
  • 1
    $\begingroup$ The problem with ECC is which curve to use. Not all are good. Also, SIMON and SPECK were rejected for ISO standardization because of the way the NSA handled them. Not something to fill one with confidence... $\endgroup$
    – Roland Smith
    Commented Jul 30, 2018 at 21:15
  • 1
    $\begingroup$ @FutureSecurity I added the curve that I use, Curve25519, which is because it has a nice hardware implementation and I primarily do hardware. I worked with the Simon and Speck team as the unclassified member, so you are welcome to be annoyed as much as you want. (<128b) Simon and Speck were basically rejected for the Z constant explanation; however, I don't find much merit in that as they were simply based on the key expansion strength and a simple LFSR. There's over 90 papers trying to pick apart Simon and Speck, but nothing so far. It's super simple, so I doubt anything will be found. $\endgroup$
    – b degnan
    Commented Jul 31, 2018 at 0:53
  • $\begingroup$ @FutureSecurity Did I comment "Horses for courses"? Hmm. <128b is perfectly fine for 99% of IoT applications. Don't forget Einstein's simplicity quote. $\endgroup$
    – Paul Uszak
    Commented Jul 31, 2018 at 11:30
  • 2
    $\begingroup$ Basically, most of things come down to economics. When I make RFID ICs, do you really need \$1B of security for a $10 t-shirt? Generally due to silicon costs, the answers is no. Many choices of cryptographers are perfect on paper but impractical from the economic standpoint in the context of hardware. It's sad but it's ultimately about how cheap I can make my silicon. $\endgroup$
    – b degnan
    Commented Jul 31, 2018 at 17:39
-1
$\begingroup$

If you can be reasonably sure that an attacker will not be able to get access to the hardware/software, you could easily obfuscate the data so that it's hard to decipher.

Note that this technically security through obscurity; it is only safe as long as an attacker doesn't have the code.

The sender:

  • Uses the pseudo-random number generator of your IOT platform to generate a specified number of bytes.
  • Compresses the extended message using whatever compression method your platform makes available.
  • Removes the header that compression programs usually prepend to the output. (this is the obfuscation bit; compression headers are a dead giveaway)
  • Sends it.

The receiver;

  • Receives the message.
  • Adds the header back to the compressed data.
  • Uncompresses it.
  • Discards the specified number of speudo-random bytes from the beginning of the message.

An example in Python 3:

In [1]: from os import urandom

In [2]: salt = urandom(8)

In [3]: salt
Out[3]: b'Wa=\xd4\xc0\x15^\xef'

In [4]:  message = "This is a test. Since I am not sure what the real message should be.".encode('utf-8')
   ...: 

In [5]: combination = salt + message

In [6]:  import zlib

In [7]: out = zlib.compress(combination)

In [8]: to_send = out[2:]  # Cut off the header

In [9]: to_send  # This is what is sent out.
Out[9]: b"\x0bO\xb4\xbdr@4\xee}HFf\xb1\x02\x10%*\x94\xa4\x16\x97\xe8)\x04g\xe6%\xa7*x*$\xe6*\xe4\xe5\x97(\x14\x97\x16\xa5*\x94g$\x96(\x94d\xa4*\x14\xa5&\xe6(\xe4\xa6\x16\x17'\xa6\xa7*\x14g\xe4\x97\xe6\xa4($\xa5\xea\x01\x00<z\x1b\x8a"

In [10]: zlib.decompress(b'x\x9c' + to_send)
Out[10]: b'Wa=\xd4\xc0\x15^\xefThis is a test. Since I am not sure what the real message should be.'

In [11]: zlib.decompress(b'x\x9c' + to_send)[8:]
Out[11]: b'This is a test. Since I am not sure what the real message should be.'

As you can see, the message that is sent does not look like the original message!

Note that because of the pseudo-random salt, the compressed string changes a lot even when you send the same message multiple times.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Interesting use of a salt /IV. $\endgroup$
    – Paul Uszak
    Commented Jul 30, 2018 at 21:28
  • 2
    $\begingroup$ " it is only safe as long as an attacker doesn't have the code" and the person that uses said obfuscation doesn't post it as an answer on the cryptography site? $\endgroup$
    – Maarten Bodewes ♦
    Commented Jul 31, 2018 at 4:03
-1
$\begingroup$

Use TLS - it's specified for HTTP and MQTT. If you have long-lived connections use a cipher suite using an asymmetric scheme. If you are in a very constraint hardware environment, use a TLS PSK cipher suite. You could also take a look at using session resumption.

Improve this answer
$\endgroup$
1
  • $\begingroup$ This answer completely ignores the requirement for keeping the data size nearly the same, which is often a hard requirement for low-datarate radio protocols. Compared to a 200 bytes message size, TLS‘ overhead is massive. $\endgroup$
    – K. Biermann
    Commented Dec 3 at 11:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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