LWIG Working Group                                           P. Urien
  Internet Draft                                          Telecom Paris
  Intended status: Experimental

                                                           June 14 2020
  Expires: December 2020

                     Security Classes for IoT devices
                  draft-urien-lwig-security-classes-04.txt


Abstract

   This draft attempts to define security classes for constraint IoT
   devices. A device security is characterized by five Boolean security
   attributes: one time programmable memory (OTP), firmware loader
   (FLD), secure firmware loader (FLD-SEC), tamper resistant key (TRT-
   KEY) and diversified key (DIV-KEY).

   This leads to the definition of 6 classes of devices, embedding or
   not OTP resource, whose security increases with the class number (0
   to 5). The suffix + indicates OTP availability.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). Note that other groups may also distribute
   working documents as Internet-Drafts. The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 2020.

   .






   Urien                   Expires December 2020             [Page 1]


Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.







































   Urien                   Expires November 2020              [page 2]


  Security Classes for IoT devices                            May 2020

Table of Contents
   Abstract........................................................... 1
   Requirements Language.............................................. 1
   Status of this Memo................................................ 1
   Copyright Notice................................................... 2
   1 Overview......................................................... 4
   2 Security Attributes.............................................. 6
      2.1 One Time Programmable Memory, OTP........................... 6
      2.2 Firmware Loader, FLD........................................ 6
      2.3 Secure Firmware Loader, FLD-SEC............................. 6
      2.4 Tamper Resistant Key, TRT-KEY............................... 7
      2.5 Diversified Key, DIV-KEY.................................... 7
   3 IANA Considerations.............................................. 7
   4 Security Considerations.......................................... 7
   5 References....................................................... 7
      5.1 Normative References........................................ 7
      5.2 Informative References...................................... 7
   6 Authors' Addresses............................................... 8


































   Urien                    Expires November 2020              [Page 3]


  Security Classes for IoT devices                            May 2020

1 Overview

   This draft attempts to define security classes for IoT devices,
   supporting SUIT [SUIT] protocols. The goal is to provide a
   qualitative estimation of risks induced by firmware remote updates
   according to device logical and hardware security resources.

   According to this draft a device comprises a main processor (MP), an
   optional communication processor (CP), actuators and/or sensors. The
   communication task may be handled by the main processor. The main
   processor manages the update of other processor(s).

   The main processor embeds several types of memories:
   - One Time Programmable Memory (OTP)
   - Non Volatile Memory (NVR)
   The logical architecture of the optional communication processor is
   similar to those of the main processor.

                                                Optional
                Main Processor          Communication Processor
            +---------------------+     +---------------------+
            |                     |     |                     |
            |  +---- +   +-----+  |     |  +---- +   +-----+  |
            |  | NVM |   | OTP |  |     |  | NVM |   | OTP |  |
            |  +-----+   +-----+  |     |  +-----+   +-----+  |
            |                     | <=> |                     |
            | +-----------------+ |     | +-----------------+ |
            | | Firmware Loader + |     | | Firmware Loader + |
            | +-----------------+ |     | +-----------------+ |
            |                     |     |                     |
            +---------------------+     +---------------------+
   Figure1. Device architecture

   Firmware update MAY be handled by a firmware loader (FLD) entity,
   and/or by other physical protocols (PHYP), for example Serial
   Programming (SP) or Parallel Programming (PP).

   When OTP memory is available, it stores a permanent part of the
   update procedure (named firmware loader in this draft).

   Non volatile memory such as FLASH may be fully erased. When no OTP
   is available the main processor may be totally reprogrammed through
   physical protocols; i.e. physical access to the device may lead to
   its full control.

   A firmware loader enables the remote update of the NVR of the main
   processor. It MAY be secure (FLD-SEC) or not. If it is secure, a
   symmetric or asymmetric procedure (and associated keys) is used in
   order to check the firmware authenticity. The two main classes of
   security procedures deal with symmetric algorithms (for example AES-


   Urien                    Expires November 2020              [Page 4]


  Security Classes for IoT devices                            May 2020

   CCM) or asymmetric signatures (for example ECDSA). It MAY support
   post quantum [POSTQUANTUMCRYPTO] cryptographic algorithms.

   Even if the firmware loader is secure, cryptographic keys may be
   recovered by side-channel attacks [SIDECHANNEL][DIVKEY]. Therefore
   Tamper Resistant key (TRT-KEY) is a very important attribute. The
   impact of a side channel attack may be limited to a single object if
   the keys are diversified (DIV-KEY).

   We propose to characterize a device by a set (SecAtt) of five
   boolean attributes (0/1).

   SecAtt = {OTP, FLD, FLD-SEC, TRT-KEY, DIV-KEY}

                No Firmware Loader
               /
              /
      Device o             Unsecure
      No OTP  \           /                       No diversified
      OTP(+)   \         /                       /keys
               Firmware o            Not tamper o
               Loader    \          /resistant   \
                          \        /              Diversified keys
                           Secure o
                  Symmetric key    \               No diversified
                  Public Key        \             /keys
                  Private Key        Tamper      o
                  Post Quantum       resistant    \
                                                   Diversified keys
   Figure2. Security classes

   This leads to the definition of 6 classes of devices, embedding or
   not OTP resource, whose security increases with the class number.
   The suffix + indicates OTP availability.

   Class0/Class0+ = {0/1,0}, no firmware loader, other attributes
   (excepted OTP) are not taken into account.
   Class1/Class1+ = {0/1,1,0,0,0}, unsecure firmware loader
   Class2/Class2+ = {0/1,1,1,0,0}, secure firmware loader, not tamper
   resistant, no diversified keys
   Class3/Class3+ = {0/1,1,1,0,1} secure firmware loader, not tamper
   resistant, diversified keys
   Class4/Class4+ = {0/1,1,1,1,0} secure firmware loader, tamper
   resistant, no diversified keys.
   Class5/Class5+ = {0/1,1,1,1,1} secure firmware loader, tamper
   resistant, diversified keys.

   For example

   - Class0 objects are uploaded (flashed) thanks to physical
   protocols, and as an illustration may be updated via HTTPS requests.

   Urien                    Expires November 2020              [Page 5]


  Security Classes for IoT devices                            May 2020

   - Many micro-controller units (MCU) support an unsecure bootloader
   and belong to Class1.
   - Some USB flash drives [BADUSB] belong to Class1+; they include an
   unsecure bootloader stored in ROM.
   - Some smart bulbs [DIVKEYS] devices are Class2 devices; they use
   secure bootloader with a single symmetric key shared by multiple
   devices
   - SUIT protocols SHOULD target secure bootloader with public key
   i.e. Class2+, or secure bootloader with diversified symmetric key
   i.e. Class3+.
   - Class4 uses a secure bootloader, with a single key shared by
   multiple devices, and protected by tamper resistant means.
   - Highly secure devices similar to bank cards belong to Class5+.

   More details are available in [IOTSEC].

2 Security Attributes

2.1 One Time Programmable Memory, OTP

   The OTP attribute means that the main processor stores permanent
   software typically a firmware loader or a subset of this entity.

   If no OTP is available the full memory content of the main processor
   can be erased and fully updated. No minimum device behavior is
   guaranteed in this case.

2.2 Firmware Loader, FLD

   A firmware loader is mainly a command interpreter that enables
   logical/remote firmware update. It avoids the use of physical
   procedures such as Serial Programming a Parallel Programming. It is
   stored either in non erasable or erasable non volatile memory.

2.3 Secure Firmware Loader, FLD-SEC

   A secure bootloader checks the authenticity and integrity of
   firmware updates by cryptographic means. This implies the use of
   symmetric secret keys, asymmetric private keys, or asymmetric public
   keys associated to certificates. Most of cryptographic algorithms
   may be broken by side-channel attacks.

   If a long term vision is required it MAY support post quantum
   [POSTQUANTUMCRYPTO] cryptographic algorithms. Quantum computer may
   break asymmetric algorithm dealing with RSA or elliptic curves. In
   case of symmetric cryptography the recommended key size is about 256
   bits.





   Urien                    Expires November 2020              [Page 6]


  Security Classes for IoT devices                            May 2020

2.4 Tamper Resistant Key, TRT-KEY

   Cryptographic keys may be recovered by side-channel attacks. A
   tamper resistant computing environment SHOULD avoid these attacks.

2.5 Diversified Key, DIV-KEY

   The use of diversified secret keys limits the side channel attack
   scope to a single object. The lack of tamper resistant computing and
   the use of single secret shared by multiple nodes MAY create major
   security threats.

3 IANA Considerations

   This draft does not require any action from IANA.

4 Security Considerations

   This draft attempts to define security classes for constraint IoT
   devices.

5 References

5.1 Normative References

   [SUIT], Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A
   Firmware Update Architecture for Internet of Things Devices", draft-
   ietf-suit-architecture-09 (work in progress), May 2020.

5.2 Informative References

   [SIDECHANNEL] David Oswald, "IMPLEMENTATION ATTACKS: FROM THEORY TO
   PRACTICE DISSERTATION", zur Erlangung des Grades eines Doktor
   ingenieurs der Fakultat fur Elektrotechnik und Informationstechnik
   an der Ruhr-Universitat Bochum, Bochum, September 2013

   [DIVKEY] Eyal Ronen and Colin O'Flynn and Adi Shamir and Achi-Or
   Weingarten, "IoT Goes Nuclear: Creating a ZigBee Chain Reaction",
   Cryptology ePrint Archive, Report 2016/1047.

   [POSTQUANTUMCRYPO] Vasileios Mavroeidis, Kamer Vishi, Mateusz D.
   Zych, Audun Josang, "The Impact of Quantum Computing on Present
   Cryptography", International Journal of Advanced Computer Science
   and Applications (IJACSA), 9(3), 405-414, March 2018

   [BADUSB] Karsten Nohl, Sascha KriBler, Jakob Lell, "BadUSB - On
   Accessories that Turn Evil", Blackhat USA 2014.

   [IOTSEC] Pascal Urien, "Integrity Issues for IoT: From Experiment to
   Classification Introducing Integrity Probes", In proceedings of 4th


   Urien                    Expires November 2020              [Page 7]


  Security Classes for IoT devices                            May 2020

   International Conference on Internet of Things Big Data, and
   Security, IoTBDS19, May 2019

6 Authors' Addresses

   Pascal Urien
   Telecom Paris
   19 place Marguerite Perey
   23 avenue d'Italie
   91120 Palaiseau           Phone: NA
   France                    Email: Pascal.Urien@telecom-paris.fr









































   Urien                    Expires November 2020              [Page 8]