4
$\begingroup$

In the Internet-of-Things world there are certain applications that produce very low volume communications. For example reading a water meter once every hour comes to mind. If the reading could be encoded as a 32 bit unsigned integer and adding a 24 bit serial number this device would transmit only about 614 KBytes of data over an assumed life-time of 10 years (7 bytes * 24 hours * 365 days * 10 years).

I'd like to put for discussion whether a One-Time-Pad (OTP) solution plus HMAC could be a viable solution in this scenario. A key stream of 614 KBytes could be easily pre-generated and stored on the device, although a Hardware Security Module (HSM) implementing "OTP + HMAC" probably does not yet exist.

I am aware of the core problems of using One-Time-Pads in practice. Assuming that these challenges could be overcome (at least in a manner that is sufficiently secure for the purpose of transmitting water meter readings once every hour) the following pseudo-code explains the approach.

# KEYSTREAM is a file containing at least 614 KBytes of random bytes.
# COUNTER is the current offset into KEYSTREAM.
function encrypt_and_hmac(plaintext):
    fp = open(KEYSTREAM)
    fp.seek(COUNTER)

    # Remember the current offset into the KEYSTREAM
    pos = fp.pos()

    # Read bytes from KEYSTREAM for encrypting the plaintext
    cipherpad = fp.read(len(plaintext))
    ciphertext = plaintext XOR cipherpad

    # Read 8 bytes (in this example) from KEYSTREAM for HMAC
    macpad = fp.read(8)
    hmac = hash(ciphertext + macpad)

    # Safely(!) erase the used bytes from the KEYSTRAM
    erase(KEYSTREAM, pos, pos+len(plaintext)+8)

    return pos, ciphertext, hmac

The current offset into the key stream (pos), the ciphertext and HMAC can now be transmitted. Decryption and verification would work like this.

function decrypt_and_verify(pos, ciphertext, hmac):
    fp = open(KEYSTREAM)
    fp.seek(pos)

    cipherpad = fp.read(len(plaintext))

    macpad = fp.read(8)
    assert hash(ciphertext + macpad) == hmac

    plaintext = ciphertext XOR cipherpad

    return plaintext

Just to preempt some potential comments:

  • Yes, AES-EAX and the like may be a better solution.
  • The challenge of safely distributing the KEYSTREAM is no different from using any other shared secret unless a Key-Exchange Protocol is used.
  • Ideally the Encrypt-and-HMAC should be done inside an HSM module or the security could be easily compromised if someone gains access to the water meter.
  • Having a small number of compromised water meters may be an acceptable business risk akin to water meters that are simply faulty. This would eliminate the cost of the HSM module.
  • An interesting challenge arises if the payload size of the transmission channel is very small like in Sigfox (12 bytes) and the smaller packet size options of LoRaWan and Weightless. Could one transmit only the first few bytes of the HMAC???

I am looking forward to your comments, feedback and criticism.

$\endgroup$
1
$\begingroup$

The two main disadvantages that I see are:

  1. You have to predict how many bytes will be encrypted during the device lifecycle. In my opinion, this is quite challenging.
  2. However, let's say you are able to fix an upper bound. In your example, you need to store 614kB inside an IoT device. What would it be if you consider a margin of error? Storing about 1GB inside IoT devices does not seem appropriate since many chips will be low-costs. Thus they will probably not have that storage space available.

Furthermore, since you propose to use HMAC for integrity/authenticity, symmetric keys management is still necessary. Hence, why not using an AEAD cipher?

To answer your question, yes it is a common practice to truncate MACs (this is done in LoRa) as discussed here.

$\endgroup$
  • 1
    $\begingroup$ In some systems it may be possible to predict how many bytes will be encrypted. For instance both LoRaWan and Sigfox operate in the ISM band which limits the duty cycle. In case of Sigfox that equates to about at most 12 bytes * 144 messages per day. $\endgroup$ – Markus Juenemann Jul 13 '17 at 5:51
  • $\begingroup$ I agree, the cost of storage memory will be a factor. $\endgroup$ – Markus Juenemann Jul 13 '17 at 5:54
  • $\begingroup$ Regarding AEAD: there is one advantage a OTP has over stream ciphers as the former can encrypt input that is not multiple of 8 bits. This may(!) be useful if your payload size is a mere 12 bytes like in Sigfox. Apart from that your comment is perfectly valid. $\endgroup$ – Markus Juenemann Jul 13 '17 at 5:54
  • $\begingroup$ Thanks for the link about truncated MACs. That was info I hadn't found before and I am glad to read that it had been done before. $\endgroup$ – Markus Juenemann Jul 13 '17 at 5:56
  • $\begingroup$ PS: This pseudo-Markdown drives me nuts ;-) $\endgroup$ – Markus Juenemann Jul 13 '17 at 5:56
2
$\begingroup$

Two points adding to Raoul's answer are:-

  1. To generate a HMAC you need a key, and this key will have to be stored within the meter. If there's a key, traditional encryption can be used if you can somehow generate IVs. Or don't generate them and accept that repeat readings will be transmitted as repeat cipher text. This probably isn't a particularly serious issue for water consumption. Although, a static reading suggests the occupants are on holiday and the house is unoccupied. So this is an example of information leakage.
  2. You compare OTP distribution to traditional key distribution. That might be true but have you considered the office end? This application of a OTP is about the worst possible kind. OTPs do not perform well in many to one transmissions. There will have to be a huge one time pad at the receiving station to decode readings from (100k+) meters. And how will you decode the reading if the meter ID is encrypted? If you use an IP address as an identifier, that can be intercepted so what's the point of encrypting the meter ID? And what happens if you roll out more meters? More OTP material has to be stored, interwoven with existing OTP material and subsequently tracked at the base office.

In summary, this is not the most appropriate scenario for a OTP. But, it you only had one meter (for lets say a home automation system), OTP is perfect as it eliminates all the cryptographic code /testing issues. Assuming of course that you can estimate the required pad size as Raoul suggests.

$\endgroup$
  • $\begingroup$ Thanks, that's a very good contribution to the discussion. I had a chuckle thinking about "information leakage of water meters" ;-) $\endgroup$ – Markus Juenemann Jul 21 '17 at 3:31

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.