Re: [VIPR] VIPR privacy issue

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

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

On 01/24/2012 02:20 PM, Kevin P. Fleming wrote:
> On 01/24/2012 02:53 PM, Marc Petit-Huguenin wrote:
>> -----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.
> 
> A very similar point was raised during the last in-person VIPR meeting that
> I attended (two IETFs ago, I think). I commented that we had personal
> experience with this problem in the Asterisk world, years ago when we had a
> public DUNDi cloud for routing E.164-numbered traffic. It is one of the
> primary reasons that many of us (I was not with Digium at the time) stopped
> using that cloud.
> 
> I'm certain that as you say, these problems are not intractable, but
> providing solutions for them may very well make VIPR (and similar
> mechanisms) so complex to implement and deploy that nobody will choose to
> do so.
> 

Perhaps, but my current concern is not complexity.  VIPR is highly dependent
on RELOAD, and half of the leakages come from RELOAD itself.  We have a good
design team in VIPR and we - slowly but steadily - find consensus on a lot of
of the issues that are pure VIPR.  But on the RELOAD side, no amount of energy
spent seems to help accelerate things.  I even considered forking the RELOAD
spec to have at least a decent subset that VIPR can use and adapt to its
needs, but it's probably not legal, and anyway prevent reusing standard
implementations of RELOAD for VIPR.

So our options as I see them:

- - Stop the work on VIPR until RELOAD reaches a point it is usable.
- - Forget RELOAD and replace it with another mechanism.
- - Close VIPR.

We will probably spend the whole of our conference call next Friday on this
subject (everybody is welcome to join, just send an email to the chairs and I,
and I will send back an invitation).

Thanks.

- -- 
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)

iQIcBAEBCAAGBQJPIEHdAAoJECnERZXWan7EJhAP/AiDXuH63mMvgES+qd/Jgl5Y
Z94tyL05aYvsuFT8QjOVPI1aSyQ8Ngv3HvGrMLZhWEEPuv7eWGUmu9WBpZtuWJ5z
a3gRZTfxeqH1qCS95+fBfbK77FjyQFBi9oaca1v/RugF7Vs2Xo/0Lb3HfD/vNGiL
OO0H0sOBqtUKXPq0eJqjrhbmt0q1yLoYe3IZJR7jbx1YUuMDlop46ADOxUOGhGCM
DlK0zZ67t4CyE+eqvLV5PRoMnziHzZHFoO+U/XROmVPf93sOKYhSq13Jvn6MLfq0
ZNnD8AD+1sSO3FsjV135wpF8Kpm8E5PCh4jZGHmDBlhmXEa0LuKc8KXVzgLy3B+Y
1iKzYrhMLqd2tGBOVelyoHFSiPv8gf4K7AHJT7lw/H14MA/a4ZxgJHLk0eZqN+63
IKx/M5X5VMqW6H1HdlSozIjzHVcYEa4uMn7EFNyzsnUOv2OdcfgNgr/kMQoFCwLO
2IVxn0f0rt5x/5x7PRE5pGIx2ALqa2l1xKaJxUCHU6w5c38/KWphLNsePfMmpkVM
EPtad/aKRz0IblIFlsvPMmJMDKLZjwGfJkb9y1PrxDyMduGTKomZH+yq/fmaXUxO
f3VckfrzRHf3mhqNU2DdGk2aBrnPKbCCdCEiZf5UgypqONWftS55s3PR3xDuPUGG
rlyrRaBzidTkhT1JyieV
=xJmH
-----END PGP SIGNATURE-----