One document matched: draft-procter-vipr-privacy-concerns-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfcXXXX.dtd">
<?rfc compact="yes" ?> <!-- Conserve vertical whitespace -->
<?rfc strict="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<rfc category="info" ipr="trust200902" docName="draft-procter-vipr-privacy-concerns-00">

    <front>
        <title abbrev="VIPR Privacy">
			Privacy Concerns relating to the
            PSTN Validation Protocol (PVP)
        </title>
        <author initials="M." surname="Procter"
                fullname="Michael Procter">
            <organization>VoIP.co.uk</organization>
            <address>
                <postal>
                    <street>Commerce House</street>
                    <street>Telford Road</street>
                    <city>Bicester</city>
                    <region>Oxfordshire</region>
                    <code>OX26 4LD</code>
                    <country>UK</country>
                </postal>
                <email>michael@voip.co.uk</email>
                <uri>http://www.voip.co.uk</uri>
            </address>
        </author>

        <date day="21" month="October" year="2011"/>

        <workgroup>VIPR</workgroup>

        <abstract><t>
This document describes some issues with privacy leaks (real or imagined) 
associated with VIPR, and also some of the countermeasures that could be
deployed to avoid them.
</t></abstract>
    </front>

<middle>
<section title="Leaks during validation">
  <section title="Caller ID">
    <t>PVP<xref target="I-D.petithuguenin-vipr-pvp" /> defines a validation
method A that encodes the calling and called numbers in the username of
a TLS-SRP secured session.  This seems to open up an interesting information
leak, since the resulting username is sent in the clear.
    </t>
    <t>Let's assume EvilCorp registers its
node-id against the hash of the sales number of its competitor,
VictimCorp.  Then, whenever a ViPR-enabled caller tries to call
VictimCorp to buy something, a few hours later their ViPR server will
attempt to establish a connection to EvilCorp.  Even assuming that
EvilCorp can't complete the handshake because it has no idea of the call
details, EvilCorp still ends up with a list of Caller IDs for people who
called their competitor's sales line.
    </t>
    <section title="Mitigation: Hash the Caller ID">
      <t>To make the Caller ID harder to extract, we could hash it before
constructing the SRP username.  We could choose an expensive hash such as
bcrypt and 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.
      </t>
    </section>
    <section title="Mitigation: Reverse the direction of the lookup">
      <t>This attack leaks information about who calls a specific
number, in no small part because the calling party initiates the
verification protocol.  We can easily avoid this by requiring the called
party to perform the verification of the calling party instead.
      </t>
      <t>However, whilst this may prevent an attacker learning the
Caller ID of calls to the attacked number, a trivial change to the
attack will allow an attacker to learn what calls are made from the 
attacked number.
Instead of EvilCorp registering against VictimCorp's sales line, they
could register against VictimCorp's CEO's number.  Incoming PVP attempts
would then correspond to calls made by the CEO, which might be used to
inform a balanced investment portfolio.
      </t>
    </section>
    <section title="Mitigation: Use the times in the username instead">
      <t>The current proposal uses the calling and called party numbers
along with the start and end times of the call to validate both parties.
The times are used as the shared secret, and the numbers as the
username in the TLS SRP handshake.  We could swap this information
around so to use the times as the username and the numbers as the shared
secret.  Sending the times in the clear is less of a problem since they
are generally not as sensitive as the Caller ID.
      </t>
      <t>In the pranking scenario (discussed below), the calling and
called party numbers are generally known in advance.  The only thing to
prevent calls being intercepted for prank purposes is that the call
timing information is not trivial to obtain.  By sending the timing
information as the SRP username, pranking becomes almost trivial to
achieve.
      </t>
    </section>
  </section>
  <section title="Source IP identification">
    <t>Assuming the Caller ID can be obscured by some means, there
is still a leak of the source IP address for the validation attempt.
EvilCorp is likely to be able to identify medium and large organisations
by simply performing a 'whois' lookup on the source IP address of the
validation attempt.  Smaller organisations may be identifiable from the
reverse DNS, or even a traceroute, depending on how their ISP configures
their network.
    </t>
    <section title="Mitigation: Anonymising the validation attempt">
      <t>It should not be too difficult to define a RELOAD Link Layer
that uses TURN TCP to hide the source of a PVP connection.
      </t>
      <t>As the PVP stream will go through the TURN node, it is 
susceptible to eavesdropping.  Therefore 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).
      </t>
    </section>
  </section>
  <section title="Traffic statistics leakage">
    <t>Assuming the source IP address of a validation attempt could be
obscured, the fact that a validation attempt is being performed leaks
statistical information.  Spotting a
noticeable spike in competitor's sales line traffic following one ad
campaign, but not another, is perfectly feasible and useful once you
have a statistically significant number of calls.  No doubt far more
information can be extracted given time and inspiration.
    </t>
    <section title="Mitigation: Random validations">
      <t>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.
      </t>
      <t>Measuring and removing the background noise from this sort of
approach would be quite straightforward, unfortunately.  Registering a
couple of numbers for which no service is provided would give a baseline
noise figure to subtract.  Far more powerful statistical methods also
exist to remove noise since this is a common problem in many fields.
      </t>
    </section>
  </section>
</section>

<section title="Office Pranks">
  <t>VIPR offers some interesting possibilities for playing jokes on
colleagues.  Whilst this attack is described in terms of a prank, the
underlying mechanisms may be used to eavesdrop or misroute calls for
less benign reasons.
  </t>
  <t>PVP<xref target="I-D.petithuguenin-vipr-pvp" /> method A requires
knowledge of the called number, calling number, and call start and end
times.  Method B dispenses with the calling number.  The VIPR Overview
<xref target="I-D.jennings-vipr-overview" /> hints at the problems of
securing this information within a typical enterprise environment in
the last paragraph of section 6.2, but the full scale of the problem is
not explored.
  </t>
  <section title="Obtaining the PVP credentials">
    <t>If a colleague makes a call, then a moderately dedicated prankster
will find the called and calling numbers easy to discover.  The
called number can be obtained from the phone's dialled call list (next
time the victim makes some tea, for example), and the calling number is
easy to obtain since it will almost certainly be fixed for calls from
that deskphone.  If this isn't already locally known, a quick test call
to a mobile phone will suffice.  All that remains are the start and end
time of the call.  
    </t>
    <t>Since PVP only requires times to be accurate to the
nearest two seconds, this isn't too difficult.  A prankster in an
open-plan office, or an adjacent cubicle should have little difficulty in
determining the start and end times with a stop-watch to sufficient
accuracy.  Improved timing might be possible if the office uses bridged
line appearances, or busy lamps.  For the more technical prankster, a
dialog event package<xref target="RFC4235"/> subscription to the 
victim's deskphone will provide all the necessary details with more
than enough accuracy.
    </t>
    <t>Once these details have been collected, the prankster will have an
hour or so to enter them in a website such as
http://prank.your.coworker.example.com, which will make the necessary
entries in the DHT and await the validation attempts.  Once validated,
the prank server may perform a number of amusing pranks for future
calls, including forwarding to another SIP URI, or onward routing to the
original called number with media copied to the prankster.
    </t>
    <section title="Mitigation: Don't share validations between phones">
      <t>To prevent a compromise of one phone affecting all phones within
an enterprise, we can ensure that validations are not shared between
phones.  This protects against certain types of attack (e.g. abusing a
visitor's phone in reception to set up a VIPR route to catch later calls
from the CEO's office), but doesn't protect against in-house prank
attacks as described above, which use the victim's own phone, and indeed
a call made by the victim themselves.  Not sharing validations also may give rise
to odd situations when enhanced calls are available to some destinations from
certain phones but not others.  Whether this is an acceptable trade-off
will depend very much on the nature of the enterprise.
      </t>
    </section>
  </section>
  <section title="Increasing the time tolerances">
    <t>PVP at present transforms the start and end times into pairs of
times rounded to the nearest second, which represent a 2-second interval
which spans the measured start or end time.  These are called Tstart-1,
Tstart-2, Tend-1 and Tend-2.  To handle a certain amount of uncertainty in
timing, four validation attempts are made, with different
combinations of start and end times.  These are given in the draft as:
    </t>
    <figure>
<artwork><![CDATA[
   1.  Try Tstart-1 and Tend-1.
   2.  Try Tstart-2 and Tend-1.
   3.  Try Tstart-1 and Tend-2.
   4.  Try Tstart-2 and Tend-2.
]]></artwork>
    </figure>
    <t>A server answers each of these four attempts with the start and end
times rounded down to the nearest second.  For prank purposes, these are
best guesses, and we will call them Gs and Ge.  If they were good
guesses, then one of these four attempts will succeed.
    </t>
    <t>Since the group of four validation attempts will be performed
against each registration in the DHT, we can take advantage by
registering multiple times and trying variations on Gs and Ge.  For
example, registering twice will get a second set of validation attempts,
which would allow us to try Gs, Ge+2.  Two more registrations would
allow us to test Gs+2, Ge and Gs+2, Ge+2 meaning that with four
registrations, we have relaxed the accuracy requirements from 2 seconds
to 4 seconds.  9 registrations allows times within 6 seconds to work and 16
registrations will allow times with 8 seconds to work.  Whilst further
registrations will permit the timing to be relaxed even more, timing a
call to the nearest 8 seconds is remarkably easy if you are in the same
room.
    </t>
    <t>Finally, now that the start and end time guesses have been
corrected (by successfully validating against a PVP client), these
corrected times could be used to validate against the true owner of the
called number, allowing the prank server to execute a Man-In-The-Middle
attack, eavesdropping on all signalling and media during future calls.
    </t>
  </section>
</section>

<section title="Acknowledgements">
<t>Much of the text of this draft is taken from emails on the vipr list
between myself, Marc Petit-Huguenin and Cullen Jennings.</t>
</section>

</middle>
<back>
    <!--references title="Normative References">
    </references-->
    <references title="Informative References">
        <?rfc include='reference.I-D.petithuguenin-vipr-pvp'?>
        <?rfc include='reference.I-D.jennings-vipr-overview'?>
        <?rfc include='reference.RFC.4235'?>
    </references>
</back>
</rfc>
<!-- vim:set ts=4 et tw=72:  -->