Skip to content

Commit

Permalink
Merge pull request #6 from huitema/kaiserd
Browse files Browse the repository at this point in the history 
summary of 2-stage privacy extension
  • Loading branch information
@huitema
huitema committed May 31, 2016
2 parents a1083d0 + 485335c commit f8bb444
Showing 1 changed file with 101 additions and 27 deletions.
128 changes: 101 additions & 27 deletions draft-huitema-dnssd-privacy.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -744,38 +744,112 @@ instance discovery key
Both problems can be mitigated by using the method described in the following.
</t>
<t>
Privacy Preserving Service Discovery can be divided into three independent layers <xref target="KW14b" />.
</t>
<t>
<list style="symbols">
<t>
Device Pairing: In this step users pair their devices.
There are two kinds of pairings: (1) intra-user pairing, which
is a pairing of devices of the same user; this can be done
without any configuration by a meta-service (pairing data synchronization service) in
a trusted (home) network;
(2) inter-user pairing is a pairing between devices of "friends".
Since this has to be done manually - e.g. by verifying a fingerprint leveraging QR-Codes -
it is important to limit it to once per pair of friends.
</t>
<t>
Directory Discovery: The set of devices that offer service instances can be seen as a distributed service directory.
When a user wants to discover services, she first discovers the part of the service directory she is authorized to use,
meaning the devices of her online friends.
This is done using an other meta service (private service directory service, PSDS) whose task it is to handle queries for actual services.
The connection to this service is done using private mutual authentication guaranteeing the privacy of both parties.
</t>
<t>
Service Querying: The PSDS is offered by a small DNS server running on each user's device that can be queried for the service instances offered by the
corresponding user.
</t>
</list>
Privacy Preserving Service Discovery can be divided into three independent layers: Device Pairing, Directory Discovery, and Service Querying <xref target="KW14b" />.
</t>

<section title="Device Pairing">
<t>
Device pairing is a must for privacy preserving service discovery, as devices need means for (private) mutual authentication.
To this end, each user has a public/private key pair.
The purpose of device pairing is both obtaining the public key of a "friend" and verifying the authenticity of this key.
</t>
<t>
Since several other applications apart from service discovery also need a pairing that allows later
authentication of another user, we propose to outsource device pairing to a dedicated component, e.g.
a device pairing daemon [see Chapter 5 of my thesis].
</t>
<t>
Obtaining and verifying this key, can be achieved by different means.
For obtaining the keys, we can either leverage an existing PKI, e.g. the PGP web of trust,
or generate our own key pairs (and exchange them right before verifying).

For authenticating the keys, which boils down to comparing fingerprints on an off-channel,
we distinguish between means that demand users to be in close proximity of each other,
and means where users do not have to meet in person.
The former can e.g. be realized by verifying a fingerprint leveraging QR-Codes,
the latter by reading a fingerprint during a phone call or using the socialist millionaires protocol.
</t>
<t>
There are two kinds of pairings:
(1) inter-user pairing is a pairing between devices of "friends".
Since this has to be done manually, e.g. by the means described above,
it is important to limit it to once per pair of friends.
(2) intra-user pairing
is a pairing of devices of the same user. It can be performed
without any configuration by a meta-service (pairing data synchronization service) in
a trusted (home) network.
</t>
</section>

<section title="Directory Discovery">
<t>
The set of devices that offer service instances can be seen as a distributed service directory.
When a user wants to discover services, she first discovers the part of the service directory she is authorized to use, meaning the devices of her online friends.
This is done using another meta service (private service directory service, PSDS) whose task it is to handle queries for actual services.
</t>

<t>
In order to be privacy preserving, the PSDS has to transmit the necessary data over an encrypted and mutually authenticated channel.
To retrieve information (PTR, TXT, SRV) about private services offered by friends, first these friends' PSDSes have to
be discovered (directory discovery), and secondly, the users have to use private mutual authentication guaranteeing the privacy of both parties.
</t>

<t>
For the discovery part, there is need for a service instance name that allows authorized friends to efficiently determine whether the service instance
is meant for them or not. Further, this instance name should not be traceable and be updated according to <xref target="timing" />.
To generate this instance name, we currently use hash(public_key || time stamp).
This has two disadvantages: Everyone knowing of the public_key can trace the user (which is especially a problem when using a PKI), and
it is dependent on time stamps, calling for hash table recalculations each time the time stamp runs out and is prone to time skew problems.
The first problem can be mitigated using a shared secret exchanged during pairing and renewing this secret after each connection.
(It really depends on what level of privacy is longed for; if we want to grant untraceability, we need unlinkable service instance names.
There is a paper on that matter by Pang et al.; I also did some research on making this more efficient but did not find a solution yet.)
Replay is no problem, as the following private mutual authentication will only work if both parties are who they claim to be; and neither party will
disclose the identity to an imposter.
</t>

<t>
A simple way for private mutual authentication between Alice and Bob can performed in a three way handshake as follows.
After Alice has discovered Bob's PSDS, she contacts Bob's PSDS by (simplified explanation)
</t>
<t>
<list style="symbols">
<t>
sending to Bob: g^a, prvSID_A=hash(secret||timestamp)
the prvSID lets Bob know that the message is a session start request most likely sent from Alice.
</t>
<t>
Bob answers: g^a, enc_A(sig_B(g^{ab}))
At this point the DH key exchange is complete. Further, Bob can verify Alice's identity (if he really is Bob) by
decrypting the corresponding block and checking Alice's signature.
</t>
<t>
Alice answers: enc_B(sig_A(g^{ab}))
Now Alice can verify Bob (is she really if Alice) decrypting the corresponding block and checking Bob's signature.
</t>
</list>
</t>

</section>

<section title="Service Querying">
<t>
Service Querying: The PSDS is offered by a small DNS server running on each user's device; this DNS server can be queried for the service instances offered by the
corresponding user. Messages sent during the process of service querying are encrypted using authenticated encryption with keys derived from g^{ab}, the DH key exchanged during directory discovery.
</t>
</section>

<section title="Summarizing Thoughts">
<t>
This mitigates both afore mentioned problems as it reduces pairing to one pairing per pair of friends and allows to offer services in
This solution mitigates both afore mentioned problems as it reduces pairing to one pairing per pair of friends and allows to offer services in
a privacy preserving way whose existence was unknown at the time of pairing.
This grants an almost zeroconf user experience.
An other disadvantage of the 1-stage approach it that either it needs a service instance key per service instance and user; or it uses the same key for all users.
The former is more privacy preserving but has the huge disadvantage of demanding a huge load of multicast messages, which are inefficient anyway.
The latter makes friend revocations very complicated -> repairing for each friend that should still be able to de-obfuscate the instance.
(It would be possible to use keys for groups of friends, finding a compromise between these two extremes.)
</t>
</section>

</section>


Expand Down

0 comments on commit f8bb444

Please sign in to comment.