Skip to content

IoT Security

Assumptions

  • Limited CPU, memory, disk and network capabilities
  • Possibly battery-driven (e.g. low-power devices)
    • Transmission use a lot of power.

  • Transport: Radio, bluetooth, SMS

  • Request-reply/handshake protocols are probably not suited. 2-way communication like TLS is probably not suited.

    • Expecting a "connection less", asynchronous fire-and-forget solution for many use cases.

'location/situational awareness *

Requirements / Features

  • Authentication to confirm Identity
  • Confidentiality, encrypted communication
  • Integrity, detect if anyone has tampered with the message
  • Handle partial/corrupt messages?
  • Protected against message replay

  • (Authorization), server side only, is this device allowed to send message to this service?

  • If too costly, which requirements can be reduced?

Solution pointers

  • Encrypted message content

    • Symmetric encryption. Shared key per device.
    • Device without keys. Send key to device, only possible to set key once.

  • Each message must contain

    • deviceId
    • Initialization Vector (IV)
    • messageId (unique for a device) OR other fields which together form an unique identifier (e.g. timestamp + sequence number) to handle scenarios where the device state is reset (e.g. the deviceId/sequence number counter is reset).
    • checksum or metadata about content to detect tampering and/or partial/corrupt messages. e.g. HMAC-SHA256
    • mac address

  • Shared-key distribution

    • Generated by secret algorithm from unique device ID
    • Randomly generated (and stored centrally) per device-id and uploaded upon software update.

  • Which encryption algorithms require little hardware performance and little battery?

    • AES. 3-DES less secure, computational heavier.

Food for thought

  • Add deviceId and shared key to device during production and have a repository of deviceIds and keys available.
    • hardcoded keys will be doomed at some point in time
  • Devices can be disabled by default and must be enabled in central repository before use.

Impl

[PRINCE { A Low-latency Block Cipher for Pervasive Computing Applications|https://eprint.iacr.org/2012/529.pdf]