Re: [VIPR] Review of draft-jennings-vipr-overview-01

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/22/2011 01:42 PM, Michael Procter wrote:
> On 11 July 2011 19:54, Cullen Jennings <[e-mail]> wrote:
>>
>> Thee are excellent points. The first few were easy and fixed in next version but on to some of the harder issues you raised ...
>>
>> On May 13, 2011, at 1:37 , Michael Procter wrote:
>>
>>> Section 8.2
>>>  The TLS-SRP uses the caller ID and called number as a "username"
> [Discussion of CLI leaks of callers to a specific number]
> 
>> I think we need to protect against the attack you describe. It's been
>> awhile since have looked at SRP. Perhaps hashing the username would
>> solve this?
> 
> I don't think hashing would be enough.  I hashed the entire UK number
> space in a few hours using a naive piece of Python and my
> not-exactly-state-of-the-art computer.  Then I googled and found out
> about using graphics cards for number crunching, which apparently can
> do the same job in a couple of seconds.  Hashing the CLI doesn't sound
> like a sufficient deterrent to me.

But I am not a security specialist, but here's an idea:  VIPR servers on both
side use bcrypt to hash the phone numbers, using a key common to everybody, and
a salt that is derived from the time of the day, modulo 48 hours.  Because the
complexity of the bcrypt hash (and so the time it takes to generate it) can be
increased as the processing power becomes available, we can define a minimum
time that it will take to generate all the hashes for the E.164 space.  Changing
the salt each 48 hours increases the difficulty of precomputing the hashes.  The
key itself and bcrypt complexity can be stored in the RELOAD config file, and be
changed in a safe way from time to time.

> 
> In fact, whatever technique used to obscure the CLI is probably only
> slightly helpful as the source IP address of the validation attempt
> would probably leak too much information for larger users (I accept
> that smaller users will probably have fairly generic reverse IP
> information and probably their ISP's info in whois).

It should not be too difficult to define a RELOAD Link Layer that use TURN TCP
to hide the source of a PVP connection.

As the PVP stream will go over TURN node susceptible to eavesdropping, we may
want to be sure that there is no difference between a successful and a failed
validation when looking at the encrypted stream (packet length for example).

> 
> Going a step further, even without knowing the source IP (validation
> over TOR anyone?), I still think there is a worrying leak.  Spotting a
> noticeable spike in competitor's sales line traffic following this ad
> campaign, but not that one, is perfectly doable once you have a
> statistically significant number of calls.  No doubt far more
> information can be extracted given time and inspiration.

An additional protection could be that VIPR servers have a standard process that
randomly select VIPR registrations and try to establish a PVP connection that
will always fail.  That should add enough noise so the real origin of a
validation cannot be pinpointed.

The reverse is problably also useful:  VIPR servers would want to randomly
register E.164 phone numbers from other providers, so the real owner of a phone
number cannot be discovered by looking at the messages in transit through peers.

This two techniques obviously increase the load on the VIPR servers, but as long
this is specified from the beginning the cost is known so it should be fine to
do so.

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

iEUEARECAAYFAk4txnYACgkQ9RoMZyVa61f4ywCYrARc0E6wl/otnQx90/FTGntZ
/wCfX2NJnlUD4jarmS/fvYRSlKKxxkY=
=vqLY
-----END PGP SIGNATURE-----