3
$\begingroup$

For regular traffic in mesh network (between Internet of Thing devices) customer decided to use one of two options:

  1. DTLS PSK ciphersuite - DTLS based on pre-shared symmetric key
  2. or direct use of AES - customer wants to minimize traffic between sleepy devices (battery should be alive for several months)

Questions:

  1. What are the additional threats of second option (AES) that do not exist for first option (DTLS-PSK)?
  2. How to mitigate these threats (say using AES in CBC or another mode and change IV, etc)? Not reinventing DTLS protocol manually and not with the same overheads as DTLS has.

There is mandatory requirement to share symmetric key between IoT devices within mesh network for regular traffic. This key fits for both options. (First joining of new device will use DTLS-PAKE - I mentioned this just in case - this is not important for this question).

Let's specify DTLS-PSK mode more exactly - I'm going to use mbedTLS crypto library with define MBEDTLS_TLS_PSK_WITH_AES_128_CCM_8 is specified in cipher suite. Where CCM is mode for block ciphers that provides both authentication and confidentiality.

$\endgroup$
  • $\begingroup$ This question depends a lot on how AES is used in the second option. In principle one could probably imagine a cut-down DTLS version where all the moving parts are removed (yielding smaller records and a smaller handshake). $\endgroup$ – SEJPM Jun 18 at 11:22
  • $\begingroup$ "regular traffic" is an odd term. Generally, your transceiver power dominates. Are your payloads large? That will depend on what you do in this case. $\endgroup$ – b degnan Jun 19 at 0:41
  • $\begingroup$ I'm responsible only for security part and the customer didn't give me this information. But as far as I know smart devices (IoT) exchange small control messages - like turn on/off the lamp or send integer from temperature sensor. Usually (because IoT device may sleep to minimize power consumption) controller may send series of identical messages during some period - window. Device should wake up once during this period and consume control message. I'm not sure that exacly this algorithm is used in this case but messages are neither not large nor intensive. $\endgroup$ – Vlad Novakovsky Jun 19 at 0:50
3
+100
$\begingroup$

You appear to be quite familiar with the issues you face already, but I'm going to answer your question as literally stated nevertheless.

  1. AES is a block cipher, so it needs to be used in a mode-of-operation in order to provide proper privacy (IND-CPA).

  2. AES is a block cipher, so it needs to be used in a mode-of-operation in order to provide proper integrity (IND-CTXT).

  3. Even with a good mode-of-operation (like AES-CCM), you don't get protection from replaying, reordering, and dropping of messages. For this you need a stateful mode-of-operation. What should this state be? It could simply be a number, but it doesn't necessarily have to be. In any case, this state needs to be managed and synchronized correctly between the two communicating parties. Can be tricky.

    But in addition to this, you also need a choice of policy: do you allow messages to be dropped, but not reordered? Do you allow messages to be reordered, but not replayed? Do you allow some messages to be replayed/reordered within some window of acceptance? ...and so on, for any complicated combination of the above. Suffice it to say, getting this right can be subtle.

DTLS gives you all of the above. The question is, can you do it better? In theory it is certainly possible. But in the end you would probably end up with something which is very close to DTLS anyway. However, now you would have to implement all of this by yourself, giving you all of the problems associated with implementing cryptography that you are probably well aware of.

Ultimately, if DTLS gives you all of this out-of-the box, then trying to come up with something that replaces it strikes me as having a high risk of introducing problems and for relatively little reward. Thus, why not simply use DTLS? Or even better, use something built on top of (D)TLS which is explicitly designed for the IoT domain (like E4)?

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thank you! Is this complete list of drawbacks: replaying, reordering and dropping? Will adding order number (counter) to message solve replaying and reordering? Say, if node obtains the message with the same number then replaying occurs and the whole chain of packages of command/message should be ignored. Say, valid message should consist from packages with subsequent series of numbers, node stores last number and next message should start from number greater then last valid number. $\endgroup$ – Vlad Novakovsky Jun 24 at 23:47
  • $\begingroup$ That is numbers should be monotonically increased. First package may contain first and last number for the whole message and gaps signal about dropping. This way it's possible to avoid handshakes. State of protocol is limited to these 3 numbers. The space is not small for integer but its possible to renew it to zero with special command $\endgroup$ – Vlad Novakovsky Jun 24 at 23:47
  • $\begingroup$ Authentication is not an issue - if server knows master key - symmetric key - then server or client is authenticated. Mode of operation like CBC or CCM allows to calculate MAC and pass it in the end for message authentication. $\endgroup$ – Vlad Novakovsky Jun 24 at 23:53
  • $\begingroup$ This answer may add some value: security.stackexchange.com/questions/233048/… $\endgroup$ – Vlad Novakovsky Jun 25 at 2:06

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.