idnits 2.17.1 draft-huang-ace-hiding-communication-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 'Intended status' indicated for this document; assuming Proposed Standard 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 22, 2017) is 2613 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7228' is defined on line 257, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ACE Working Group Q. Huang 2 Internet Draft M. Wei 3 Interned status: Standards Track H. Wang 4 Expires: August 26, 2017 S. Li 5 P. Wang 6 Y. Li 7 Chongqing University of 8 Posts and Telecommunications 9 February 22, 2017 11 Subliminal Channel Hiding Communication for Constrained-Node 12 Networks 13 draft-huang-ace-hiding-communication-00 15 Abstract 17 Due to the computation and storage limitations of constrained-node 18 networks, it is costly to apply those security mechanisms based on 19 public key algorithm. This document proposed a subliminal channel 20 hiding communication method, which can provide message 21 authentication service and protect the transmission of the sensitive 22 data. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on August 26, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction ................................................ 2 65 1.1. Requirements Notation................................... 3 66 1.2. Terms Used ............................................. 3 67 2. Subliminal Channel Hiding Communication ..................... 4 68 2.1. Overview of the scheme.................................. 4 69 2.2. The implementation of the scheme ....................... 5 70 3. Security Considerations...................................... 6 71 4. IANA Considerations ......................................... 6 72 5. References .................................................. 6 73 5.1. Normative References.................................... 6 74 5.2. Informative References.................................. 6 76 1. Introduction 78 In the existing networks, the processing of the sensitive data has 79 mainly used a variety of encryption technologies, and the sensitive 80 data is transmitted through the public channel. The attacker could 81 easily detect the communication process, hence, the man-in-middle 82 attack, the DoS attack or the Sybil attack can be applied to 83 interfere the communication, which makes the legal receiver cannot 84 obtain the encrypted sensitive data, and leads to the failure of the 85 communication process eventually. 87 The subliminal channel hiding communication is to hide the sensitive 88 data into the ordinary data. The attacker is hard to analyze whether 89 there is any sensitive data in the ordinary data. In this way, the 90 transmitted ordinary data would not cause attacker's attentions and 91 doubts. The subliminal channel hiding communication decreased the 92 intercept rate of the sensitive data and guaranteed the security of 93 the sensitive data fundamentally. 95 The traditional subliminal channel hiding communication is not 96 suitable for the constrained-node networks due to its high 97 computational overhead. Many existing subliminal channel 98 communications are based on public key mechanisms, such as: Scheme 99 of subliminal channel based on Schnorr digital signature and 100 analysis, and the Subliminal Channel Protocol based on Elliptic 101 Curve Digital Signature Algorithm, both of them hides the sensitive 102 data into the digital signature by using embedding algorithm. 103 Although the message authentication mechanism is introduced in the 104 communication process, the asymmetric encryption technology is 105 adopted in the existing embedding algorithm, which increases the 106 calculation costs of the node, and makes the distribution of the 107 public key and the private key very complex. 109 The purpose of this document is to solve the problems of low 110 security and high energy consumption in constrained-node networks 111 communication process. A subliminal channel hiding communication 112 method based on Message Authentication Code (MAC) has been put 113 forward. By using the data hiding technology, the confidentiality 114 and integrity of the sensitive data can be protected, where the 115 sensitive data is less vulnerable to be attacked in the 116 communication process. 118 1.1. Requirements Notation 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119] 124 1.2. Terms Used 126 MAC: Message Authentication Code. 128 Ordinary data: The data is divided into different grades according 129 to its importance, the ordinary data is low-grade. 131 Sensitive data: The data is divided into different grades according 132 to its importance, the sensitive data is high-grade. Such as the key 133 update messages, time synchronization messages, etc. 135 Broadcast packet: A 2-tuple packets contains the ordinary data and 136 MAC. 138 Cluster head node: Resource-rich node with high computation and 139 storage capacity. 141 Cluster node: Constrained node with constrained computation and 142 storage capacity. 144 2. Subliminal Channel Hiding Communication 146 2.1. Overview of the scheme 148 There are two types of nodes in this document, the cluster head node 149 which is a resource-rich node, and the cluster node which is a 150 constrained-node. The topology of the network is shown in Figure 1. 151 Node A is cluster head node, node B, C and N etc. are cluster nodes. 153 +---+ 154 +---->| A |<------+ 155 | +---+ | 156 | | | 157 v v v 158 +---+ +---+ +---+ 159 | B | | C | ... | N | 160 +---+ +---+ +---+ 161 Figure 1. The network topology 163 There is a trust third party with high computation and storage 164 capacity in the network used to distribute the key materials and 165 other necessary materials to the cluster head node and the cluster 166 nodes at the initialization phase. The mode of the third party is 167 shown in Figure 2. 169 Key/Prime number +-------------------+ 170 +--------------| Trust third party | 171 | +-------------------+ 172 | | 173 | | Key/Prime number 174 v v 175 +-------------------+ +--------------+ 176 | Cluster head node |<---------->| Cluster node | 177 +-------------------+ +--------------+ 178 Figure 2. The third-party mode 180 The cluster head node hides the sensitive data into MAC and 181 constructs a broadcast packet by using Chinese Remainder Theorem 182 (CRT). Then the cluster head node sends the broadcast packet to the 183 cluster nodes. While the cluster nodes receive the broadcast packet 184 it SHOULD have the message authenticated before, and then it can 185 extract the sensitive data from the MAC if the message is certified. 186 The attacker cannot know whether the MAC contains a sensitive data 187 and cannot get any data from the MAC. This method increased the 188 difficulty of decoding the sensitive data. 190 2.2. The implementation of the scheme 192 The communication process is divided into several steps: (1) 193 Initialization phase; (2) Preprocessing phase; (3) Constructing 194 broadcast packets; (4) Message authentication; (5) Recovering the 195 sensitive data. 197 (1) Initialization phase: In order to realize authentication and 198 information hiding, the trust third party needs to generate the key 199 parameters. The trust third party generates a key k shared by the 200 whole network nodes, and a series keysrespectively shared by the 201 cluster nodes and the cluster head node. The trust third party also 202 generates a large prime number m shared by the whole network nodes, 203 and a series of large prime numberrespectively shared by the cluster 204 node and the cluster head nodes. 206 (2) Preprocessing phase: when the cluster head node broadcasts the 207 ordinary data v, it utilizes hash algorithm and key k to generate a 208 preprocessed data b. 210 If the cluster head node wants to send a sensitive data u to the 211 cluster node A, it utilizes the individual key KA and the identity 212 of the receiving node A through a symmetric encryption algorithm to 213 generate an encrypted sensitive data U. 215 (3) Constructing broadcast packets phase: the cluster head node 216 utilizes the preprocessed data b, the prime number m, the encrypted 217 sensitive data U and the prime number mA which is shared by the 218 cluster node A and the cluster head node to calculate the congruence 219 equation according to the Chinese Remainder Theorem algorithm. 221 The cluster head node calculates the solution of the congruence 222 equation as the MAC which is embedded the sensitive data. Then the 223 cluster head node constructs a 2-tuple packets P and broadcasts to 224 the cluster nodes. 226 (4) Message authentication phase: when the cluster node A received 227 the 2-tuple packets P, it SHOULD first authenticate the packet. If 228 the packet P is certified, which means the packet p is credible; 229 otherwise, it will discard the packet. 231 (5) Recovering the sensitive data phase: If the packet P passed the 232 verification, the cluster node A will calculate the encrypted 233 sensitive data U by using its prime number mA from the MAC, then it 234 uses key KA to decrypt the data U, and finally obtains the sensitive 235 data u. 237 3. Security Considerations 239 TBD. 241 4. IANA Considerations 243 This memo includes no request to IANA. 245 5. References 247 5.1. Normative References 249 5.2. Informative References 251 [RFC2119] 252 Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119,DOI 10.17487/RFC2119, 254 March 1997, 255 . 257 [RFC7228] 258 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 259 Constrained-Node Networks", RFC 7228,DOI 10.17487/RFC7228, 260 May 2014, 261 . 263 Authors' Addresses 265 QingQing Huang 266 Key Laboratory of Industrial Internet of Things & Networked Control 267 Ministry of Education 268 Chongqing University of Posts and Telecommunications 269 2 Chongwen Road 270 Chongqing, 400065 271 China 273 Email: huangqq@cqupt.edu.cn 275 Min Wei 276 Key Laboratory of Industrial Internet of Things & Networked Control 277 Ministry of Education 278 Chongqing University of Posts and Telecommunications 279 2 Chongwen Road 280 Chongqing, 400065 281 China 283 Email: weimin@cqupt.edu.cn 285 Hao Wang 286 Key Laboratory of Industrial Internet of Things & Networked Control 287 Ministry of Education 288 Chongqing University of Posts and Telecommunications 289 2 Chongwen Road 290 Chongqing, 400065 291 China 293 Email: wanghao@cqupt.edu.cn 295 Shuaiyong Li 296 Key Laboratory of Industrial Internet of Things & Networked Control 297 Ministry of Education 298 Chongqing University of Posts and Telecommunications 299 2 Chongwen Road 300 Chongqing, 400065 301 China 303 Email: lishuaiyong@cqupt.edu.cn 305 Ping Wang 306 Key Laboratory of Industrial Internet of Things & Networked Control 307 Ministry of Education 308 Chongqing University of Posts and Telecommunications 309 2 Chongwen Road 310 Chongqing, 400065 311 China 313 Phone: (86)-23-6246-1061 314 Email: wangping@cqupt.edu.cn 316 Yong Li 317 Key Laboratory of Industrial Internet of Things & Networked Control 318 Ministry of Education 319 Chongqing University of Posts and Telecommunications 320 2 Chongwen Road 321 Chongqing, 400065 322 China 324 Email: 13101279737@126.com