idnits 2.17.1 draft-moskowitz-mobile-privacy-attack-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 (November 14, 2017) is 2353 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- 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 IDEAS R. Moskowitz 3 Internet-Draft Huawei 4 Intended status: Informational November 14, 2017 5 Expires: May 18, 2018 7 An Attack on Privacy in Mobile Devices 8 draft-moskowitz-mobile-privacy-attack-01 10 Abstract 12 This memo outlines an attack against the privacy of the Identities of 13 mobile devices with all the IETF secure enveloping technologies. It 14 describes necessary steps to be taken with those technologies, the 15 underlying address assignment strategies, and role of secure 3rd 16 party introducers. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 18, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 55 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. The Call ID Privacy Attack . . . . . . . . . . . . . . . . . 3 58 4. Identifiers leaked by the Data Channel . . . . . . . . . . . 3 59 4.1. TLS 1.3 Data Channels . . . . . . . . . . . . . . . . . . 4 60 4.2. Unsecured Data Channels . . . . . . . . . . . . . . . . . 4 61 5. Identifiers leaked by the Control Channel . . . . . . . . . . 4 62 5.1. Unguarded Diffie-Hellman in Control Channels . . . . . . 5 63 6. 3rd Party Introducer . . . . . . . . . . . . . . . . . . . . 5 64 7. The Role of IP Addresses . . . . . . . . . . . . . . . . . . 5 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 68 11. Normative References . . . . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 In recent years there has been a drastic increase of theft of 74 Personal Identifying Information (PII). This has resulted in an 75 increase scrutiny of new work in the IETF, not to add new attack 76 vectors. Most of this attention has been on work associated to 77 people owned devices like mobile computing platforms. It also 78 impacts work on 'machines' that are not operated directly by people, 79 but in the end, owned by people (or corporations). 81 The privacy concern arises in that along with the PII, the device 82 location information is also stolen. Thus where a person or 83 corporation's devices are is strongly bound to the stolen PII. NATed 84 addresses are also often in the stolen information, as the client 85 applications have been observed to query the OS for the local address 86 and pass that to the server for storage along with the collected PII. 87 No information about the device seems to be safe from harvesting and 88 theft. 90 This memo will describe a linked, privacy attack, tracing a device 91 through all of its connections to other devices. The attack is 92 pernicious. ALL existing secure communication protocols contribute 93 to the attack. Current IP address allocation practices further 94 compound the attack that can obviate any attack mitigation 95 implemented at higher layers. 97 2. Terms and Definitions 99 2.1. Requirements Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 2.2. Notations 107 This section will contain notations 109 2.3. Definitions 111 TBD 113 3. The Call ID Privacy Attack 115 The name, "Call ID", is taken from the process where all connections 116 are identified in some way. These IDs can be collected and linked 117 back to PII. 119 There are two players in this attack, Mal and Eve. Mal maliciously 120 steals PII from wherever it is kept weakly guarded. He does not have 121 to harvest it from a service provider's records of what devices are 122 on the network. Practically all the information needed is in web 123 sites where users and corporations store information and with that 124 information is the IP address and other identifiers of the device. 126 Eve is patiently eavesdropping on traffic over the Internet, 127 collecting packet identifying information. Eve sees all the exposed 128 headers in every packet. She may even have tapped into IPFIX flows 129 to simplify her work. 131 Mal and Eve put their data together and are able to construct all 132 communications, including peer-to-peer ones. Nothing is private to 133 the these two. 135 4. Identifiers leaked by the Data Channel 137 All secure data channels (e.g. ESP, SRTP, and TLS) have an 138 Identifier to link the packet to the security information. Eve uses 139 these Identifiers to link seemingly disparate flows together so that 140 changing IP addresses (as the result of a move in the network) does 141 not break her knowledge of whom or what is talking to whom or what. 143 Identifiers MUST be changed by both parties whenever one party 144 changes its address. Further, all other exposed values, particularly 145 sequence numbers must be changed from the expected value. For 146 example, the sequence number may be jumped in value a random amount 147 but still within the numbering window specified by the protocol. 149 One approach to change Identifiers is to treat the agreed upon 150 Identifiers as masters and construct a keyed hash-chain for the 151 actual values sent. 153 4.1. TLS 1.3 Data Channels 155 TLS 1.3 may well have made the transition to decoupling separate 156 connection 'pieces' as the devices change addresses. It does this 157 through its key scheduling and other security state management 158 components. Further study will be need to see if all needed 159 decoupling hygenics are followed. 161 4.2. Unsecured Data Channels 163 It is important to note that there are unsecure data channels (e.g. 164 ILA, IPnIP, LISP) that make no security claims and leak information 165 that can be linked to PII. It will be a separate exercise to see 166 what can be done to minimize the leakage with them. 168 5. Identifiers leaked by the Control Channel 170 Secure control channels (e.g. HIP, IKE, and TLS) carry Identities, 171 often in the clear during some part of the exchange, and Identifiers 172 that link all the packets for the control channel 'session'. 174 It is close to impossible to protect all Identities in the control 175 channels without opening up some significant DOS attacks. Thus other 176 mitigations will be needed. In some cases, short-term Identities may 177 work. In others a 3rd party Introducer will be needed. Both parties 178 to a control channel could have secure connections to a 3rd party. 179 They would exchange their real Identities over this proxied 180 connection before switching to agreed upon one-time Identities on 181 their real control channel. This shifts the risk to the 3rd party. 183 The Identifiers in the control channel can be masked just like in a 184 data channel. In some cases, like HIP, special care will be needed 185 either through a physical side channel (e.g. QR codes displayed real 186 time with one-time keys) or a 3rd party Introducer to exchange a key 187 used in the keyed hash-chain. 189 5.1. Unguarded Diffie-Hellman in Control Channels 191 TLS 1.3 and IKE make use of an "unguarded" Diffie-Hellman exchange to 192 hide identity information. This is also called opportunistic Diffie- 193 Hellman. There are two risks with this. It can be subject to a Man- 194 in-the-Middle attack and it is a great DDOS tool. 196 The MITM attack against exposing identities will require more study. 197 There are methods to manage the DDOS attack, but this is not a help 198 for small devices that any extra DH is beyond their processing/ 199 battery capability. 201 6. 3rd Party Introducer 203 A trusted, 3rd party Introducer can go a long way to mask information 204 in packets to block Eve. A device would maintain a long-lived secure 205 connection to the Introducer. This connection would be established 206 using some agreed upon Identity for both the Introducer and the 207 device. 209 Over this secure channel, the device would register Identities, 210 discovery information, and access policies. It is this information 211 that other registered devices would use to 'link up' and then shift 212 to a direct peer connection. 214 This Introducer would have to take significant steps to defend 215 against Mal, as it holds real information about connected parties. 216 Best practices (e.g. Format Preserving Encryption) can go a long way 217 to defeat Mal. 219 7. The Role of IP Addresses 221 Any work to mask the various protocol information discussed above 222 will be defeated if all connections for a device come from a single 223 IP address or a single /64 IPv6 prefix. Eve will be able to link all 224 the devices packets together, and Mal will be able to link some of 225 them to PII and the 'game is over'. 227 Minimally 2 addresses per device are required. One for device to 228 server with PII and one for peer communications. Since it is hard to 229 know what communication will result in storing traceable information, 230 the more addresses used, the better the level of detachment. 232 8. IANA Considerations 234 There is no IANA considerations at this time for this document. 236 9. Security Considerations 238 This document details a privacy attack and some efforts to mitigate 239 the attack. These efforts could be for naught if the basic provider 240 mapping of devices to access authentication is stolen by Mal. 242 Further, MAC address harvesting is not discussed. This could 243 potentially be a more serious weakness that IP addresses. Web 244 servers should NOT store any MAC addresses collected from attached 245 clients. 247 10. Acknowledgments 249 This attack was first discussed on the IDEAS mailing list. It was 250 developed through discussions with Padmadevi Pillay Esnault of Huawei 251 and her IDEAS team. 253 11. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, 257 DOI 10.17487/RFC2119, March 1997, . 260 Author's Address 262 Robert Moskowitz 263 Huawei 264 Oak Park, MI 48237 266 Email: rgm@labs.htt-consult.com