idnits 2.17.1 draft-urien-core-blockchain-transaction-protocol-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 (September 01, 2018) is 2057 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE Working Group P. Urien 3 Internet Draft Telecom ParisTech 4 Intended status: Experimental 6 September 01, 2018 7 Expires: March 2019 9 Blockchain Transaction Protocol for Constraint Nodes 10 draft-urien-core-blockchain-transaction-protocol-01.txt 12 Abstract 14 The goal of the blockchain transaction protocol for constraint nodes 15 is to enable the generation of blockchain transactions by constraint 16 nodes, according to the following principles : 17 - transactions are triggered by Provisioning-Messages that include 18 the needed blockchain parameters. 19 - binary encoded transactions are returned in Transaction-Messages, 20 which include sensors/actuators data. Constraint nodes, associated 21 with blockchain addresses, compute the transaction signature. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 2019. 46 . 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Blockchain Transaction Protocol for Constraint Nodes September 2018 65 Table of Contents 66 Abstract........................................................... 1 67 Requirements Language.............................................. 1 68 Status of this Memo................................................ 1 69 Copyright Notice................................................... 2 70 1 Overview......................................................... 4 71 2 Overview of the Blockchain Transaction Protocol for Constraint 72 Nodes.............................................................. 4 73 2.1 Architecture................................................ 4 74 2.2 An Ethereum Use Case........................................ 5 75 3 Blockchain Transaction Protocol Messages Definition.............. 6 76 3.1 Provisioning Message........................................ 6 77 3.1.1 Encoding example in JSON syntax ...................... 6 78 3.2 Transaction Message......................................... 6 79 3.2.1 Encoding example in JSON syntax ...................... 6 80 4. Blockchain Transaction Protocol Messages Binary Encoding........ 7 81 4.1 CoAP messages............................................... 7 82 4.2 HTTP Messages............................................... 7 83 5 IANA Considerations.............................................. 7 84 6 Security Considerations.......................................... 7 85 6 References....................................................... 7 86 6.1 Normative References........................................ 7 87 6.2 Informative References...................................... 7 88 7 Authors' Addresses............................................... 7 89 Blockchain Transaction Protocol for Constraint Nodes September 2018 91 1 Overview 93 In the context of this draft sensors/actuators are powered by micro- 94 controllers comprising about 10KB of RAM and 100KB of non volatile 95 memory. The node electronic board may include a radio SoC (System On 96 Chip) or the micro-controller can be part of the SoC. The radio chip 97 manages IP connectivity with another device, typically acting as a 98 controller, which provides a full internet access with standard 99 computing resources. 101 A constraint node driving sensors and/or actuators may deliver 102 critical data dealing with safety (fire detection,...) or legacy 103 (pollution measurement,...) information. 105 Blockchain infrastructure provides two important features in an 106 Internet of Things (IoT) context: 108 - Authentication of data in P2P context. Blockchain signed 109 transactions are checked by numerous nodes. 110 - Information publication. Transactions are stored in duplicated and 111 distributed databases. 112 - Dating information. Transactions are dated during the mining 113 process. 115 The goal of the blockchain transaction protocol for constraint nodes 116 is to enable the generation of blockchain transactions by constraint 117 nodes, according to the following principles: 118 - transactions are triggered by controllers. Needed blockchain 119 parameters are included in provisioning messages. 120 - binary encoded transaction messages are returned by constraint 121 nodes. A node has the ability to compute the transaction signature. 123 2 Overview of the Blockchain Transaction Protocol for Constraint Nodes 125 2.1 Architecture 127 <--Provisioning-Message 128 +--------------------+ IP +----------------------+ +------------+ 129 | Constraint Node | link | Controller | | Blockchain | 130 + Blockchain Address +------+ Full IP connectivity +--+ Network | 131 + Private Key | | Access to blockchain | | | 132 +--------------------+ +----------------------+ +------------+ 133 Transaction-Message--> 135 Figure 1. Functional architecture for the Blockchain Transaction 136 Protocol for Constraint Nodes 138 A constraint node holds a blockchain address (BA). The blockchain 139 address is computed from a private key (Pk). Most of today 140 blockchain infrastructures deal with ECDSA signatures, generated 141 Blockchain Transaction Protocol for Constraint Nodes September 2018 143 over the Secp256k1 elliptic curve. The private key is a 32 bytes 144 number, stored in the constraint node. The computation of hash 145 procedures such a SHA2 or KECCAK-256 can be handled by 146 microcontrollers. Although ECDSA signature may be generated by a 147 microcontroller, a tamper resistant resource could be used, either 148 embedded in the CPU, or in a chip such as a secure element[ISO7816]. 149 As an illustration an architecture based on micro-controller, radio 150 SoC and secure element was demonstrated in [IEEE-CCNC2018]. 152 The controller is a device with full IP connectivity. It typically 153 communicates with the constraint node thanks to the CoAP [RFC7252] 154 protocol, or other legacy protocols such as HTTPS. The controller 155 has access to the blockchain infrastructure, to which it is able to 156 forward a binary encoded transaction, signed by the constraint node. 158 2.2 An Ethereum Use Case. 160 The following figure 2, illustrates an Ethereum transaction 161 generated by a constraint node, whose total length is 118 bytes. 163 F8 74 // RLP List, length= 116 bytes 164 0C // nonce 1 byte =12 decimal 165 85 06FC23AC00 // gasPrice = 30 GWei 166 83 013880 // gasLimit = 80000 gas 167 // recipient address 20 bytes 168 94 6BAC1B75185D9051AF740AB909F81C71BBB221A6 169 80 // Null Ether Value 170 // Data 15 bytes "Temperature=25C" 171 8F 54656D70657261747572653D323543 172 1B // recovery parameter, 1 byte 173 A0 // r, 32 bytes, ECDSA r paramter 174 A9B58980F76EE6284800B82A2B5DF13E456887EC0CF426A5E5D6A738EB1784ED 175 A0 // s, 32 bytes, ECDSA s parameter 176 629633C6A3ED5FEE0FB40E2D1CF251345B885D372857B1A6C4762C9BE914281F 178 Figure 2. Illustration of an Ethereum transaction, generated by a 179 constraint node. 181 The identifier (TxId) of this transaction (i.e. its KECCAK-256 182 digest) is: 184 0xd6904d832462ae17718c69e9caa0c3f3bed458382ac1f4e43b1aadd8e94744ad 186 Given this TxId, the transaction can be retrieved in any Ethereum 187 blockchain database, like for example: 189 https://etherscan.io/tx/0xd6904d832462ae17718c69e9caa0c3f3bed458382a 190 c1f4e43b1aadd8e94744ad 192 The transaction date (20-2018 09:52:42 PM +UTC) is published and 193 certified by the blockchain. 195 Blockchain Transaction Protocol for Constraint Nodes September 2018 197 The binary encoded transaction comprises two parts, 198 - information relying on the Ethereum blockchain context, such as 199 the nonce, the gasPrice, the gasLimit, the recipient address, and an 200 Ether value. 201 - information delivered by the constraint node, data (a temperature 202 measurement), and the ECDSA signature computed from the 32 bytes 203 private key. 205 Parameters relying on the Ethereum blockchain context MUST be 206 included in the Provisioning-Message. 207 The signed transaction MUST be included in the Transaction-Message. 209 3 Blockchain Transaction Protocol Messages Definition 211 The Blockchain Transaction Protocol comprises two messages, to be 212 included in transport protocols, such as CoAP or HTTP. 214 3.1 Provisioning Message 216 This message includes the following attributes : 217 - A type, an integer value, specifying the message content. 218 - An ordered list of values, storing the parameters of the 219 blockchain context. 221 3.1.1 Encoding example in JSON syntax 223 Here is an illustration of the provisioning message associated to 224 the Ethereum blockchain. 226 { 227 "type": 1, 228 "nonce": 12, 229 "gasPrice": 30, 230 "gasLimit": 80000, 231 "address": "6BAC1B75185D9051AF740AB909F81C71BBB221A6", 232 "value": 0 233 } 235 3.2 Transaction Message 237 This message include the following attributes 238 - A type, an integer value, specifying the message content. The zero 239 value indicates an error. 240 - The binary encoded transaction, including the signature. 242 3.2.1 Encoding example in JSON syntax 244 Here is an illustration of the transaction message associated to the 245 Ethereum blockchain. 247 Blockchain Transaction Protocol for Constraint Nodes September 2018 249 { 250 "type": 1, 251 "transaction": 252 "F8740C8506FC23AC0083013880946BAC1B75185D9051AF740AB909F81C71BBB221A 253 6808F54656D70657261747572653D3235431BA0A9B58980F76EE6284800B82A2B5DF 254 13E456887EC0CF426A5E5D6A738EB1784EDA0629633C6A3ED5FEE0FB40E2D1CF2513 255 45B885D372857B1A6C4762C9BE914281F" 256 } 258 4. Blockchain Transaction Protocol Messages Binary Encoding 260 4.1 CoAP messages 262 To be Done 264 4.2 HTTP Messages 266 To be Done 268 5 IANA Considerations 270 TODO 272 6 Security Considerations 274 TODO 276 6 References 278 6.1 Normative References 280 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 281 Application Protocol (CoAP)", RFC 7252, June 2014. 283 [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards 284 with Contacts", The International Organization for Standardization 285 (ISO). 287 6.2 Informative References 289 [IEEE-CCNC2018] Urien,P., "An Innovative Security Architecture for 290 Low Cost Low Power IoT Devices Based on Secure Elements", IEEE CCNC 291 2018 293 7 Authors' Addresses 295 Pascal Urien 296 Telecom ParisTech 297 23 avenue d'Italie 298 75013 Paris Phone: NA 299 France Email: Pascal.Urien@telecom-paristech.fr