| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Paul: The most obvious privacy issues include- temporal: traceability in the same network (e.g., consumer does groceries and crosses same isle with same wifi access point from one visit to next) - spatial: traceability from on network to the next (e.g., person walks around in town and can be pinpointed) [1][2]
Personally, I would be interested in schemes that address privacy concerns, but also can be leveraged to allow authentication, where this roughly means the following:
- privacy against passive adversaries (both spatially and temporally);- authentication to active nodes that are in a device's "buddy list"; no authentication to other nodes - deniability (i.e., loosely speaking, no node can prove that another node has been "active" to a third party)
If one can address some of the [address] privacy issues while getting the other features more or less for free, that may be worth pursuing
Best regards, Rene[1] lots of social apps do the same thing, but that is "supposedly" voluntary (or people do not know their coordinates are being tracked) [2] not sure how this pans out for some of the mobility scenarios, e.g., where a device wanders around campus and hops from one wifi router to the next
On 12/2/2014 12:14 PM, Paul Lambert wrote:
On 11/26/14, 3:58 PM, "Christian Huitema"<huitema@xxxxxxxxxxxxx> wrote:Simple version of suggested exchange below Š. Minus some other features: csi = cipher suite identifier H = secure hash determined by cipher suite f = key derivation function determined by cipher suite s_i + secret for Œi¹ G = group generator (using additive notation) P_i = s_i*G m_j = scalar random mask value (jth for i) Q_ij = m_j*P_i MAC_ij = H(csi, Q_ij, f(TSF))[0:6] MAC_kl = same as above but kth MAC of P_l Exchange MAC_ij ‹- csi, Q_ij ‹> MAC_kl MAC_ij <‹- Q_kl ‹- MAC_kl Keys now calculated on both sides K_ij=K_kl= f(csi, m_j*s_i*Q_kl) = f(csi, m_k*s_l*Q_kij) Sharing m_j encrypted under derived key shows binding of Q_ij to P_i MAC_ij ‹- encr(k_ij, m_j, P_i, etc) ‹> MAC_kl MAC_kl can validate that Q_ij = m_j*P_iThe problem of course is that when you do that, you reveal the public key P_i to the other party. This has an obvious privacy effect, which depends on the lifetime of that public key. If the lifetime is "forever," then we have a long term identifier and a privacy issue. Of course, the privacy effect could be mitigated by picking a different public key for each "session," but that supposes cipher suites in which picking such random keys is easy. Before we go further, we should be clear about what problem we are trying to solve. Clearly, this type of exchanges can be used to prove that the device "owns" a particular random number. But what does that ownership mean? If two devices claim the same key, who wins? Who decides?Two Œdevices¹ that prove they have the same key must be treated as the same device. But to the main point, what are we problems are we trying to solve? I may have taken us away from just MAC address randomization to a specific approach to both randomize an address and support an ability to find and authenticate devices. Privacy is not the same as anonymity. Authentication and authorization must still be supported for some scenarios. It¹s just that at a minimum there should be privacy from third party observation of wireless frames disclosing private information. Not sending a long term public key in the clear also helps, but does not fully solve how to determine which key/identity to show under the key exchange to another device. Paul-- Christian Huitema
-- email:rstruik.ext@xxxxxxxxx | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363