idnits 2.17.1 draft-urien-lwig-security-classes-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'POSTQUANTUMCRYPTO' is mentioned on line 227, but not defined == Missing Reference: 'DIVKEYS' is mentioned on line 188, but not defined == Unused Reference: 'POSTQUANTUMCRYPO' is defined on line 272, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-09 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG Working Group P. Urien 3 Internet Draft Telecom Paris 4 Intended status: Experimental 6 May 24 2020 7 Expires: November 2020 9 Security Classes for IoT devices 10 draft-urien-lwig-security-classes-03.txt 12 Abstract 14 This draft attempts to define security classes for constraint IoT 15 devices. A device security is characterized by five Boolean security 16 attributes: one time programmable memory (OTP), firmware loader 17 (FLD), secure firmware loader (FLD-SEC), tamper resistant key (TRT- 18 KEY) and diversified key (DIV-KEY). 20 This leads to the definition of 6 classes of devices, embedding or 21 not OTP resource, whose security increases with the class number (0 22 to 5). The suffix + indicates OTP availability. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 2020. 47 . 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 65 Abstract........................................................... 1 66 Requirements Language.............................................. 1 67 Status of this Memo................................................ 1 68 Copyright Notice................................................... 2 69 1 Overview......................................................... 4 70 2 Security Attributes.............................................. 6 71 2.1 One Time Programmable Memory, OTP........................... 6 72 2.2 Firmware Loader, FLD........................................ 6 73 2.3 Secure Firmware Loader, FLD-SEC............................. 6 74 2.4 Tamper Resistant Key, TRT-KEY............................... 7 75 2.5 Diversified Key, DIV-KEY.................................... 7 76 3 IANA Considerations.............................................. 7 77 4 Security Considerations.......................................... 7 78 5 References....................................................... 7 79 5.1 Normative References........................................ 7 80 5.2 Informative References...................................... 7 81 6 Authors' Addresses............................................... 8 82 1 Overview 84 This draft attempts to define security classes for IoT devices, 85 supporting SUIT [SUIT] protocols. The goal is to provide a 86 qualitative estimation of risks induced by firmware remote updates 87 according to device logical and hardware security resources. 89 According to this draft a device comprises a main processor (MP), an 90 optional communication processor (CP), actuators and/or sensors. The 91 communication task may be handled by the main processor. The main 92 processor manages the update of other processor(s). 94 The main processor embeds several types of memories: 95 - One Time Programmable Memory (OTP) 96 - Non Volatile Memory (NVR) 97 The logical architecture of the optional communication processor is 98 similar to those of the main processor. 100 Optional 101 Main Processor Communication Processor 102 +---------------------+ +---------------------+ 103 | | | | 104 | +---- + +-----+ | | +---- + +-----+ | 105 | | NVM | | OTP | | | | NVM | | OTP | | 106 | +-----+ +-----+ | | +-----+ +-----+ | 107 | | <=> | | 108 | +-----------------+ | | +-----------------+ | 109 | | Firmware Loader + | | | Firmware Loader + | 110 | +-----------------+ | | +-----------------+ | 111 | | | | 112 +---------------------+ +---------------------+ 113 Figure1. Device architecture 115 Firmware update MAY be handled by a firmware loader (FLD) entity, 116 and/or by other physical protocols (PHYP), for example Serial 117 Programming (SP) or Parallel Programming (PP). 119 When OTP memory is available, it stores a permanent part of the 120 update procedure (named firmware loader in this draft). 122 Non volatile memory such as FLASH may be fully erased. When no OTP 123 is available the main processor may be totally reprogrammed through 124 physical protocols; i.e. physical access to the device may lead to 125 its full control. 127 A firmware loader enables the remote update of the NVR of the main 128 processor. It MAY be secure (FLD-SEC) or not. If it is secure, a 129 symmetric or asymmetric procedure (and associated keys) is used in 130 order to check the firmware authenticity. The two main classes of 131 security procedures deal with symmetric algorithms (for example AES- 132 CCM) or asymmetric signatures (for example ECDSA). It MAY support 133 post quantum [POSTQUANTUMCRYPTO] cryptographic algorithms. 135 Even if the firmware loader is secure, cryptographic keys may be 136 recovered by side-channel attacks [SIDECHANNEL][DIVKEY]. Therefore 137 Tamper Resistant key (TRT-KEY) is a very important attribute. The 138 impact of a side channel attack may be limited to a single object if 139 the keys are diversified (DIV-KEY). 141 We propose to characterize a device by a set (SecAtt) of five 142 boolean attributes (0/1). 144 SecAtt = {OTP, FLD, FLD-SEC, TRT-KEY, DIV-KEY} 146 No Firmware Loader 147 / 148 / 149 Device o Unsecure 150 No OTP \ / No diversified 151 OTP(+) \ / /keys 152 Firmware o Not tamper o 153 Loader \ /resistant \ 154 \ / Diversified keys 155 Secure o 156 Symmetric key \ No diversified 157 Public Key \ /keys 158 Private Key Tamper o 159 Post Quantum resistant \ 160 Diversified keys 161 Figure2. Security classes 163 This leads to the definition of 6 classes of devices, embedding or 164 not OTP resource, whose security increases with the class number. 165 The suffix + indicates OTP availability. 167 Class0/Class0+ = {0/1,0}, no firmware loader, other attributes 168 (excepted OTP) are not taken into account. 169 Class1/Class1+ = {0/1,1,0,0,0}, unsecure firmware loader 170 Class2/Class2+ = {0/1,1,1,0,0}, secure firmware loader, not tamper 171 resistant, no diversified keys 172 Class3/Class3+ = {0/1,1,1,0,1} secure firmware loader, not tamper 173 resistant, diversified keys 174 Class4/Class4+ = {0/1,1,1,1,0} secure firmware loader, tamper 175 resistant, no diversified keys. 176 Class5/Class5+ = {0/1,1,1,1,1} secure firmware loader, tamper 177 resistant, diversified keys. 179 For example 181 - Class0 objects are uploaded (flashed) thanks to physical 182 protocols, and as an illustration may be updated via HTTPS requests. 184 - Many micro-controller units (MCU) support an unsecure bootloader 185 and belong to Class1. 186 - Some USB flash drives [BADUSB] belong to Class1+; they include an 187 unsecure bootloader stored in ROM. 188 - Some smart bulbs [DIVKEYS] devices are Class2 devices; they use 189 secure bootloader with a single symmetric key shared by multiple 190 devices 191 - SUIT protocols SHOULD target secure bootloader with public key 192 i.e. Class2+, or secure bootloader with diversified symmetric key 193 i.e. Class3+. 194 - Class4 uses a secure bootloader, with a single key shared by 195 multiple devices, and protected by tamper resistant means. 196 - Highly secure devices similar to bank cards belong to Class5+. 198 More details are available in [IOTSEC]. 200 2 Security Attributes 202 2.1 One Time Programmable Memory, OTP 204 The OTP attribute means that the main processor stores permanent 205 software typically a firmware loader or a subset of this entity. 207 If no OTP is available the full memory content of the main processor 208 can be erased and fully updated. No minimum device behavior is 209 guaranteed in this case. 211 2.2 Firmware Loader, FLD 213 A firmware loader is mainly a command interpreter that enables 214 logical/remote firmware update. It avoids the use of physical 215 procedures such as Serial Programming a Parallel Programming. It is 216 stored either in non erasable or erasable non volatile memory. 218 2.3 Secure Firmware Loader, FLD-SEC 220 A secure bootloader checks the authenticity and integrity of 221 firmware updates by cryptographic means. This implies the use of 222 symmetric secret keys, asymmetric private keys, or asymmetric public 223 keys associated to certificates. Most of cryptographic algorithms 224 may be broken by side-channel attacks. 226 If a long term vision is required it MAY support post quantum 227 [POSTQUANTUMCRYPTO] cryptographic algorithms. Quantum computer may 228 break asymmetric algorithm dealing with RSA or elliptic curves. In 229 case of symmetric cryptography the recommended key size is about 256 230 bits. 232 2.4 Tamper Resistant Key, TRT-KEY 234 Cryptographic keys may be recovered by side-channel attacks. A 235 tamper resistant computing environment SHOULD avoid these attacks. 237 2.5 Diversified Key, DIV-KEY 239 The use of diversified secret keys limits the side channel attack 240 scope to a single object. The lack of tamper resistant computing and 241 the use of single secret shared by multiple nodes MAY create major 242 security threats. 244 3 IANA Considerations 246 This draft does not require any action from IANA. 248 4 Security Considerations 250 This draft attempts to define security classes for constraint IoT 251 devices. 253 5 References 255 5.1 Normative References 257 [SUIT], Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A 258 Firmware Update Architecture for Internet of Things Devices", draft- 259 ietf-suit-architecture-09 (work in progress), May 2020. 261 5.2 Informative References 263 [SIDECHANNEL] David Oswald, "IMPLEMENTATION ATTACKS: FROM THEORY TO 264 PRACTICE DISSERTATION", zur Erlangung des Grades eines Doktor 265 ingenieurs der Fakultat fur Elektrotechnik und Informationstechnik 266 an der Ruhr-Universitat Bochum, Bochum, September 2013 268 [DIVKEY] Eyal Ronen and Colin O'Flynn and Adi Shamir and Achi-Or 269 Weingarten, "IoT Goes Nuclear: Creating a ZigBee Chain Reaction", 270 Cryptology ePrint Archive, Report 2016/1047. 272 [POSTQUANTUMCRYPO] Vasileios Mavroeidis, Kamer Vishi, Mateusz D. 273 Zych, Audun Josang, "The Impact of Quantum Computing on Present 274 Cryptography", International Journal of Advanced Computer Science 275 and Applications (IJACSA), 9(3), 405-414, March 2018 277 [BADUSB] Karsten Nohl, Sascha KriBler, Jakob Lell, "BadUSB - On 278 Accessories that Turn Evil", Blackhat USA 2014. 280 [IOTSEC] Pascal Urien, "Integrity Issues for IoT: From Experiment to 281 Classification Introducing Integrity Probes", In proceedings of 4th 282 International Conference on Internet of Things Big Data, and 283 Security, IoTBDS19, May 2019 284 http://www.insticc.org/Primoris/Resources/PaperPdf.ashx?idPaper=7746 285 9 287 6 Authors' Addresses 289 Pascal Urien 290 Telecom Paris 291 19 place Marguerite Perey 292 23 avenue d'Italie 293 91120 Palaiseau Phone: NA 294 France Email: Pascal.Urien@telecom-paris.fr