Security Classes for IoT devices
draft-urien-lwig-security-classes-07

LWIG Working Group                                           P. Urien 
  Internet Draft                                          Telecom Paris 
  Intended status: Experimental                                         
                                                                        
                                                       December 16 2021 
  Expires: June 2022 
 
                     Security Classes for IoT devices 
                  draft-urien-lwig-security-classes-07.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 June 2022. 
    
   . 

   Urien                       Expires June 2022             [Page 1] 

    

Copyright Notice 
    
   Copyright (c) 2021 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 June 2022              [page 2] 

 
  Security Classes for IoT devices                       December 2021 
 
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 June 2022              [Page 3] 

 
  Security Classes for IoT devices                       December 2021 
 
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 June 2022              [Page 4] 

 
  Security Classes for IoT devices                       December 2021 
 
   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 June 2022              [Page 5] 

 
  Security Classes for IoT devices                       December 2021 
 
   - 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 June 2022              [Page 6] 

 
  Security Classes for IoT devices                       December 2021 
 
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 June 2022              [Page 7] 

 
  Security Classes for IoT devices                       December 2021 
 
   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 June 2022              [Page 8]