idnits 2.17.1 draft-urien-lwig-security-classes-00.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 233, but not defined == Missing Reference: 'DIVKEYS' is mentioned on line 196, but not defined == Unused Reference: 'POSTQUANTUMCRYPO' is defined on line 279, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-01 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 ParisTech 4 Intended status: Experimental 6 November 22 2018 7 Expires: May 2019 9 Security Classes for IoT devices 10 draft-urien-lwig-security-classes-00.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 May 2019. 47 . 49 Copyright Notice 51 Copyright (c) 2018 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 Security Classes for IoT devices November 2018 66 Table of Contents 67 Abstract........................................................... 1 68 Requirements Language.............................................. 1 69 Status of this Memo................................................ 1 70 Copyright Notice................................................... 2 71 1 Overview......................................................... 4 72 2 Security Attributes.............................................. 6 73 2.1 One Time Programmable Memory, OTP........................... 6 74 2.2 Firmware Loader, FLD........................................ 6 75 2.3 Secure Firmware Loader, FLD-SEC............................. 6 76 2.4 Tamper Resistant Key, TRT-KEY............................... 6 77 2.5 Diversified Key, DIV-KEY.................................... 7 78 3 IANA Considerations.............................................. 7 79 4 Security Considerations.......................................... 7 80 5 References....................................................... 7 81 5.1 Normative References........................................ 7 82 5.2 Informative References...................................... 7 83 6 Authors' Addresses............................................... 7 84 Security Classes for IoT devices November 2018 86 1 Overview 88 This draft attempts to define security classes for IoT devices, 89 supporting SUIT [SUIT] protocols. The goal is to provide a 90 qualitative estimation of risks induced by firmware remote updates 91 according to device logical and hardware security resources. 93 According to this draft a device comprises a main processor (MP), an 94 optional communication processor (CP), actuators and/or sensors. The 95 communication task may be handled by the main processor. The main 96 processor manages the update of other processor(s). 98 The main processor embeds several types of memories: 99 - One Time Programmable Memory (OTP) 100 - Non Volatile Memory (NVR) 101 The logical architecture of the optional communication processor is 102 similar to those of the main processor. 104 Optional 105 Main Processor Communication Processor 106 +---------------------+ +---------------------+ 107 | | | | 108 | +---- + +-----+ | | +---- + +-----+ | 109 | | NVM | | OTP | | | | NVM | | OTP | | 110 | +-----+ +-----+ | | +-----+ +-----+ | 111 | | <=> | | 112 | +-----------------+ | | +-----------------+ | 113 | | Firmware Loader + | | | Firmware Loader + | 114 | +-----------------+ | | +-----------------+ | 115 | | | | 116 +---------------------+ +---------------------+ 117 Figure1. Device architecture 119 Firmware update MAY be handled by a firmware loader (FLD) entity, 120 and/or by other physical protocols (PHYP), for example Serial 121 Programming (SP) or Parallel Programming (PP). 123 When OTP memory is available, it stores a permanent part of the 124 update procedure (named firmware loader in this draft). 126 Non volatile memory such as FLASH may be fully erased. When no OTP 127 is available the main processor may be totally reprogrammed through 128 physical protocols; i.e. physical access to the device may lead to 129 its full control. 131 A firmware loader enables the remote update of the NVR of the main 132 processor. It MAY be secure (FLD-SEC) or not. If it is secure, a 133 symmetric or asymmetric procedure (and associated keys) is used in 134 order to check the firmware authenticity. The two main classes of 135 security procedures deal with symmetric algorithms (for example AES- 136 Security Classes for IoT devices November 2018 138 CCM) or asymmetric signatures (for example ECDSA). It MAY support 139 post quantum [POSTQUANTUMCRYPTO] cryptographic algorithms. 141 Even if the firmware loader is secure, cryptographic keys may be 142 recovered by side-channel attacks [SIDECHANNEL][DIVKEY]. Therefore 143 Tamper Resistant key (TRT-KEY) is a very important attribute. The 144 impact of a side channel attack may be limited to a single object if 145 the keys are diversified (DIV-KEY). 147 We propose to characterize a device by a set (SecAtt) of five 148 boolean attributes (0/1). 150 SecAtt = {OTP, FLD, FLD-SEC, TRT-KEY, DIV-KEY} 152 No Firmware Loader 153 / 154 / 155 Device o Unsecure 156 No OTP \ / No diversified 157 OTP(+) \ / /keys 158 Firmware o Not tamper o 159 Loader \ /resistant \ 160 \ / Diversified keys 161 Secure o 162 Symmetric key \ No diversified 163 Public Key \ /keys 164 Private Key Tamper o 165 Post Quantum resistant \ 166 Diversified keys 167 Figure2. Security classes 169 This leads to the definition of 6 classes of devices, embedding or 170 not OTP resource, whose security increases with the class number. 171 The suffix + indicates OTP availability. 173 Class0/Class0+ = {0/1,0}, no firmware loader, other attributes 174 (excepted OTP) are not taken into account. 175 Class1/Class1+ = {0/1,1,0,0,0}, unsecure firmware loader 176 Class2/Class2+ = {0/1,1,1,0,0}, secure firmware loader, not tamper 177 resistant, no diversified keys 178 Class3/Class3+ = {0/1,1,1,0,1} secure firmware loader, not tamper 179 resistant, diversified keys 180 Class4/Class4+ = {0/1,1,1,1,0} secure firmware loader, tamper 181 resistant, no diversified keys. 182 Class5/Class5+ = {0/1,1,1,1,1} secure firmware loader, tamper 183 resistant, diversified keys. 185 For example 187 - Class0 objects are uploaded (flashed) thanks to physical 188 protocols, and as an illustration may be updated via HTTPS requests. 190 Security Classes for IoT devices November 2018 192 - Many micro-controller units (MCU) support an unsecure bootloader 193 and belong to Class1. 194 - Some USB flash drives [BADUSB] belong to Class1+; they include an 195 unsecure bootloader stored in ROM. 196 - Some smart bulbs [DIVKEYS] devices are Class2 devices; they use 197 secure bootloader with a single symmetric key shared by multiple 198 devices 199 - SUIT protocols SHOULD target secure bootloader with public key 200 i.e. Class2+, or secure bootloader with diversified symmetric key 201 i.e. Class3+. 202 - Class4 uses a secure bootloader, with a single key shared by 203 multiple devices, and protected by tamper resistant means. 204 - Highly secure devices similar to bank cards belong to Class5+. 206 2 Security Attributes 208 2.1 One Time Programmable Memory, OTP 210 The OTP attribute means that the main processor stores permanent 211 software typically a firmware loader or a subset of this entity. 213 If no OTP is available the full memory content of the main processor 214 can be erased and fully updated. No minimum device behavior is 215 guaranteed in this case. 217 2.2 Firmware Loader, FLD 219 A firmware loader is mainly a command interpreter that enables 220 logical/remote firmware update. It avoids the use of physical 221 procedures such as Serial Programming a Parallel Programming. It is 222 stored either in non erasable or erasable non volatile memory. 224 2.3 Secure Firmware Loader, FLD-SEC 226 A secure bootloader checks the authenticity and integrity of 227 firmware updates by cryptographic means. This implies the use of 228 symmetric secret keys, asymmetric private keys, or asymmetric public 229 keys associated to certificates. Most of cryptographic algorithms 230 may be broken by side-channel attacks. 232 If a long term vision is required it MAY support post quantum 233 [POSTQUANTUMCRYPTO] cryptographic algorithms. Quantum computer may 234 break asymmetric algorithm dealing with RSA or elliptic curves. In 235 case of symmetric cryptography the recommended key size is about 256 236 bits. 238 2.4 Tamper Resistant Key, TRT-KEY 240 Cryptographic keys may be recovered by side-channel attacks. A 241 tamper resistant computing environment SHOULD avoid these attacks. 243 Security Classes for IoT devices November 2018 245 2.5 Diversified Key, DIV-KEY 247 The use of diversified secret keys limits the side channel attack 248 scope to a single object. The lack of tamper resistant computing and 249 the use of single secret shared by multiple nodes MAY create major 250 security threats. 252 3 IANA Considerations 254 TODO 256 4 Security Considerations 258 TODO 260 5 References 262 5.1 Normative References 264 [SUIT], Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A 265 Firmware Update Architecture for Internet of Things Devices", draft- 266 ietf-suit-architecture-01 (work in progress), July 2018. 268 5.2 Informative References 270 [SIDECHANNEL] David Oswald, "IMPLEMENTATION ATTACKS: FROM THEORY TO 271 PRACTICE DISSERTATION", zur Erlangung des Grades eines Doktor 272 ingenieurs der Fakultat fur Elektrotechnik und Informationstechnik 273 an der Ruhr-Universitat Bochum, Bochum, September 2013 275 [DIVKEY] Eyal Ronen and Colin O'Flynn and Adi Shamir and Achi-Or 276 Weingarten, "IoT Goes Nuclear: Creating a ZigBee Chain Reaction", 277 Cryptology ePrint Archive, Report 2016/1047. 279 [POSTQUANTUMCRYPO] Vasileios Mavroeidis, Kamer Vishi, Mateusz D. 280 Zych, Audun Josang, "The Impact of Quantum Computing on Present 281 Cryptography", International Journal of Advanced Computer Science 282 and Applications (IJACSA), 9(3), 405-414, March 2018 284 [BADUSB] Karsten Nohl, Sascha KriBler, Jakob Lell, "BadUSB - On 285 Accessories that Turn Evil", Blackhat USA 2014. 287 6 Authors' Addresses 289 Pascal Urien 290 Telecom ParisTech 291 23 avenue d'Italie 292 75013 Paris Phone: NA 293 France Email: Pascal.Urien@telecom-paristech.fr