idnits 2.17.1 draft-urien-suit-security-classes-01.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 -- The document date (April 21, 2019) is 1830 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT Working Group P. Urien 3 Internet Draft Telecom ParisTech 4 Intended status: Experimental 6 April 21, 2019 7 Expires: October 2019 9 Security Classes For Software Updates for IoT 10 draft-urien-suit-security-classes-01.txt 12 Abstract 14 This draft attempts to define security classes for devices targeted 15 by SUIT protocols. A device security is characterized by five 16 Boolean security attributes: firmware loader (FLD), one time 17 programmable memory (OTP), secure firmware loader (FLD-SEC), tamper 18 resistant key (TRT-KEY) and diversified key (DIV-KEY). This 19 classification creates 18 device classes. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 2019. 44 . 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Table of Contents 62 Abstract........................................................... 1 63 Requirements Language.............................................. 1 64 Status of this Memo................................................ 1 65 Copyright Notice................................................... 2 66 1 Overview......................................................... 4 67 2 Security Considerations for Firmware Update...................... 5 68 2.1 Firmware Loader, FLD........................................ 5 69 2.2 One Time Programmable Memory, OTP........................... 5 70 2.3 Secure Firmware Loader, FLD-SEC............................. 5 71 2.4 Tamper Resistant Key, TRT-KEY............................... 6 72 2.5 Diversified Key, DIV-KEY.................................... 6 73 3 IANA Considerations.............................................. 6 74 4 Security Considerations.......................................... 6 75 5 References....................................................... 6 76 5.1 Normative References........................................ 6 77 5.2 Informative References...................................... 6 78 6 Authors' Addresses............................................... 6 79 1 Overview 81 The [SUIT] working focuses on firmware update for Class 1 (as 82 defined in RFC 7228) devices, i.e., devices with ~10 KB RAM and ~100 83 KB flash. 85 This draft attempts to define security classes for devices targeted 86 by SUIT protocols. The goal is to provide a qualitative estimation 87 of risk induced by firmware remote updates according to device 88 logical and hardware security resources. 90 According to this draft a device comprises a main processor (MP), an 91 optional communication processor (CP), actuators and/or sensors. The 92 communication task MAY be handled by the main processor. The main 93 processor SHOULD manage the update of other processor. 95 The main processor embeds several types of memories: 96 - One Time Programmable Memory (OTP) 97 - Non Volatile Memory (NVR) 98 The logical architecture of the optional communication processor is 99 similar to those of the main processor. 101 Optional 102 Main Processor Communication Processor 103 +---------------------+ +---------------------+ 104 | | | | 105 | +---- + +-----+ | | +---- + +-----+ | 106 | | NVM | | OTP | | | | NVM | | OTP | | 107 | +-----+ +-----+ | | +-----+ +-----+ | 108 | | <=> | | 109 | +-----------------+ | | +-----------------+ | 110 | | Firmware Loader + | | | Firmware Loader + | 111 | +-----------------+ | | +-----------------+ | 112 | | | | 113 +---------------------+ +---------------------+ 114 Figure1. Device architecture 116 Firmware update MAY be handled by a firmware loader (FLD) entity, 117 and/or by other physical protocol (PHYP), for example Serial 118 Programming (SP) or Parallel Programming (PP). 120 When OTP memory is available, it MAY stores a permanent part of the 121 update procedure (named firmware loader in this draft). 123 Non volatile memory such as FLASH MAY be fully erased. When no OTP 124 is available the main processor MAY be totally reprogrammed through 125 physical protocols; i.e. physical access to the device MAY lead to 126 its full control. 128 A firmware loader enables the remote update of the NVR of the main 129 processor. It MAY be secure (FLD-SEC) or not. If it is secure, a 130 symmetric or asymmetric procedure (and associated keys) is used in 131 order to check the firmware authenticity. The two main classes of 132 security procedures deal with symmetric algorithms (for example AES- 133 CCM) or asymmetric signatures (for example ECDSA). It MAY support 134 post quantum cryptographic algorithms. 136 Even if the firmware loader is secure, cryptographic keys MAY be 137 recovered by side-channel attacks [SIDECHANNEL][DIVKEY]. Therefore 138 Tamper Resistant key (TRT-KEY) is a very important attribute. The 139 impact of a side channel attack may be limited to a single object if 140 the keys are diversified (DIV-KEY). 142 We propose to characterize a device by a set (SecAtt) of five 143 Boolean attributes (0/1): 145 SecAtt = {FML, OTP, FLD-SEC, TRT-KEY, DIV-KEY} 147 This leads to the definition of 2 + 16 = 18 classes of objects. 148 - {0,0,0,0,0}, no firmware loader, no OTP. 149 - {0,1,0,0,0}, no firmware loader, OTP available. 150 - {1,1/0,1/0,1/0,1/0}, firmware loader available. 152 For example some objects firmware (class = {0,0,0,0,0}) are just 153 updated via HTTPS requests. 155 Some highly secure devices similar to banking cards, SHOULD have all 156 the security attributes (class = {1,1,1,1,1}); 158 2 Security Considerations for Firmware Update 160 2.1 Firmware Loader, FLD 162 A firmware loader is mainly a command interpreter that enables a 163 logical/remote firmware update. It avoids the use of physical 164 procedures such as Serial Programming a Parallel Programming. It is 165 store either in non erasable or erasable non volatile memory. 167 2.2 One Time Programmable Memory, OTP 169 The OTP attribute means that the main processor stores permanent 170 software typically a firmware loader or a subset of this entity. 172 If no OTP is available the full memory content of the main processor 173 can be erased and fully updated. No minimum device behavior is 174 guaranteed in this case. 176 2.3 Secure Firmware Loader, FLD-SEC 178 A secure bootloader checks the authenticity and integrity of the 179 firmware update by cryptographic means. This implies the use of 180 symmetric secret keys, asymmetric private keys, or asymmetric public 181 keys associated to certificates. Most of cryptographic algorithms 182 MAY be broken by side-channel attacks. If a long term vision is 183 required it MAY support post quantum cryptographic algorithms. 185 2.4 Tamper Resistant Key, TRT-KEY 187 Cryptographic keys may be recovered by side-channel attack. A Tamper 188 Resistant computing environment SHOULD avoid these attacks. 190 2.5 Diversified Key, DIV-KEY 192 The use of diversified secrets keys limits the side channel attack 193 scope to a single object. The lack of tamper resistant computing and 194 the use of single secret shared by multiple nodes MAY create major 195 security threats. 197 3 IANA Considerations 199 TODO 201 4 Security Considerations 203 TODO 205 5 References 207 5.1 Normative References 209 [SUIT], Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A 210 Firmware Update Architecture for Internet of Things Devices", draft- 211 ietf-suit-architecture-01 (work in progress), July 2018. 213 5.2 Informative References 215 [SIDECHANNEL] David Oswald, "IMPLEMENTATION ATTACKS: FROM THEORY TO 216 PRACTICE DISSERTATION", zur Erlangung des Grades eines Doktor 217 ingenieurs der Fakultat fur Elektrotechnik und Informationstechnik 218 an der Ruhr-Universitat Bochum, Bochum, September 2013 220 [DIVKEY] Eyal Ronen, Adi Shamir, "Extended Functionality Attacks on 221 IoT Devices: The Case of Smart Lights", 2016 IEEE European Symposium 222 on Security and Privacy (EuroS&P) 224 6 Authors' Addresses 226 Pascal Urien 227 Telecom ParisTech 228 23 avenue d'Italie 229 75013 Paris Phone: NA 230 France Email: Pascal.Urien@telecom-paristech.fr