[VIPR] VIPR privacy issue

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Michael Procter explained on the last VIPR design team weekly conference call
a privacy attack that I think is devastating.  The end result is simple to
explain:  VIPR turns the Internet into a "trap and trace device"[1], allowing
anybody to record the phone numbers called by any entities using VIPR, and
this for a relatively low cost.

Let's say that VIPR is well deployed in US enterprises and that a spying group
is willing to spend the money to know about the phone calls made by these
enterprises.  This spying group just have to add enough VIPR servers to the
RELOAD overlay to register all the phone numbers in the USA.  Because all
registrations are considered equally untrusted, they will all be verified by
establishing a TCP connection between the VIPR server of the source of the
call and the VIPR server that stored the registration for a particular phone
number.  There is multiple pieces of information that are leaked but it is
easy for example to find the enterprise that is originating the TCP connection
by looking at the source address and to enter it in whois.

As Michael pointed out, you have to be on VIPR to protect your privacy, i.e
destination numbers that are *not* using VIPR are especially at risk.  If the
destination number is using VIPR, the TCP connection used to verify the first
call from any enterprise has a lower probability to be directed to the spying
group, because the real owner of the number may be tried first and prevent
other registrations to be tried if successful.  And as soon the real owner
sends a SIP route and ticket back, the spying group will no longer receive any
information about the calls between this enterprise and this destination
number, excepted for the periodic renewal of the ticket.

Note that the information leaked go deeper than just the verification
connection.  Here's the various places where privacy information leakage
happens with this attack:

- - If the spying group uses a different VServiceId for each registered phone
number, the called number is always leaked.
- - The called number is also leaked for methods A and B.
- - For method "A", the Caller-ID is leaked (the bcrypt hash is hard to crack,
but it is not impossible).
- - For method "B", a random time in the middle of the call is leaked.
- - For method "C", the rounded start and stop time of the call are leaked.
- - The source IP address of the TCP connection for the PVP transaction is
always leaked.
- - The addr_port in the AppAttachReq RELOAD message that was used to establish
the TCP connection is leaked.
- - The certificate of the signer of the AppAttachReq RELOAD message is leaked.
Even if the certificate does not contain information about the sender
(subject, subjectAltName), it always contains the Node-ID, which can always be
resolved to an IP address by using an Attach request.
- - The Node-ID is leaked a second time in the via_list of the AppAttachReq
message, unless an intermediary RELOAD peer replaced it with a compressed ID.

There is probably ways to fix all of these leakages, and I found solutions for
most of them, but they make RELOAD and VIPR much, much more complex, to the
point that I am starting to think that RELOAD itself is not up to the task.
Using TURN to anonymize, as I proposed, does not work because of the multiple
places where data is leaked and fixing RELOAD itself, which will require among
other things adding something like onion routing, will probably take years[2].

At a minimum, we will need to add a strong requirement about required
anonymization in -overview, but it is clear to me that the standardization of
VIPR will take a much longer time than expected.


[1] http://en.wikipedia.org/wiki/Trap_and_trace_device
[2] http://www.ietf.org/mail-archive/web/p2psip/current/msg06166.html

- -- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPHxo6AAoJECnERZXWan7EV0kQALf+0G+bdOj4t3GiNSk1rjKC
7Zbnz4cqiJrmmJl3PjISQy8t+yXEngEO2vmM9ewkb9i4tZV0fV+UNv4Wpxfs2XF1
p/VRZ8gKAGiNfSgY2aGXDtErEaV33Rkuh+iQUVd+FsYTc2lSUDPnRFXD9dfO4GuK
FIJKnf3Wm9yK37zN8X+kS9ynrEzTXDKD1V1kfW8JgEne6KkL7wwhH/NWAXKbT3F+
o0RsWbM2Kft9aCmzRtBSgzNRiVb1G6asD8LaETXImEPhP0ScySnul7sqeXg4un5o
ipVwjiAuKy6sPsOJoXD26fePzMbymrtKL6R3Lv/YM9W9ae3cQo3JrjShEwYhVETY
c0leYotFBSDELu3jv2sqfF1ij9I+XXD9gUT8eOd/XV/xBKvvEr06xQ9tc7E72e1C
hEpINusiMYNW1nWvL7WvJNbQU4KaojyF6I2uGLQss8UKBYvYBU4+oIkg6F0bF3GA
c5yxdEVOg1Tkn88yiUI4O3pOS1yuscsUBlduOKQsNvKZQWd6Y1eikODU44Ea2hRr
JlsQz5Azh7PY07a6dD7VmdS36wA0N+JbPpL6pvgf0r5tfxoWAcfoyZ2gtgEsFf6Y
CLaySla7kUaVVzjhe9tsccG3FmdpnDS8wQjJ/47FI/hnCUfv02FOAHWzALRNZgfF
nTxixgP8OeOKecgd8ll8
=LV2v
-----END PGP SIGNATURE-----