Secure Serendipity: A Multi-Factor Trust Protocol for Proximity-Based Social Networks

TL;DR

Mobile social networking in physical proximity (PMSN) offers great potential for spontaneous connection but carries high privacy risks. This paper introduces a protocol that calculates a Trust Value by combining mutual friends, user history (credibility), and the safety of the current environment (e.g., workplace vs. subway). By utilizing advanced cryptography like Paillier and Commutative Encryption, the system ensures you can verify a stranger's trustworthiness without ever exposing your private friend list or real identity to them—or even to the central servers.

Problem & Motivation: The Danger of the "Digital Handshake"

Proximity-Based Mobile Social Networks (PMSNs) allow users to connect via Bluetooth or Wi-Fi at conferences, concerts, or transit hubs. However, the "stranger danger" is real:

1. Sybil Attacks: One malicious user creates multiple fake identities to manipulate trust.
2. Privacy Leakage: Standard "mutual friend" checks often require uploading your entire contact list to a server.
3. Context Blindness: Most models treat a "match" in a dark alley the same as a "match" in a high-security office building.

The authors argue that trust should be subjective and context-aware, allowing users to weigh different factors based on where they are and who they are meeting.

Methodology: The Three Pillars of Trust

The core innovation is a weighted trust equation: $Trust=\alpha \cdot FoF+\beta \cdot Cr+\gamma \cdot SST$

1. Friend of Friend (FoF) - Private Set Intersection

The protocol uses Commutative Encryption ($E_{k1}(E_{k2}(m))=E_{k2}(E_{k1}(m))$). Both users encrypt their friend lists; they exchange these, encrypt them again with their own keys, and look for matches. This ensures that:

• If we have a mutual friend, we find out.
• If we don't, I learn nothing about who your friends are.

2. Credibility (Cr)

This is a reputation score managed by a Registration Server (RegS). Every time a user completes a successful, "clean" interaction, their credibility increases. This score is embedded in an AuthToken, preventing users from "whitewashing" their reputation by creating new accounts (since accounts are tied to encrypted SSNs).

3. Social Spot Type (SST)

The "where" matters. The protocol allows users to assign a "safety rating" to locations. A match found at a university ($\gamma =10$) might be inherently more trusted than one found in a subway ($\gamma =1$).

System Architecture

The system relies on two servers designed to be "Honest-but-Curious."

• RegS (Registration): Handles tokens but only sees encrypted SSNs.
• RevS (Revocation): Holds the keys to decrypt SSNs but has no access to the user database. This separation of duties ensures that even if one server is hacked, your real-world identity remains protected.

Security Analysis: Resilience Against Attacks

The paper provides a rigorous analysis of various attack scenarios:

• MITM Attacks: Prevented because the AuthToken contains a unique random number $N$ that must be verified against the RegS in real-time.
• Identity Theft: Because the RegS deletes plaintext SSNs immediately after registration, there is no "master list" for hackers to steal.
• Revocation: If a user is caught cheating, the victim submits a "recording" (signed log) of the protocol. The RegS and RevS collaborate to blacklist that SSN permanently.

Critical Analysis & Conclusion

Takeaway

This work moves trust evaluation from a binary "yes/no" to a nuanced, sliding scale. By integrating environmental context (SST) into the mathematical model, it better reflects how humans actually build trust in the real world.

Limitations

1. Server Dependency: While the servers are semi-trusted, the system still requires an active internet connection to verify tokens with the RegS, which might be a bottleneck in purely "off-grid" proximity scenarios.
2. Computational Overhead: Using both Paillier and Elliptic Curve Cryptography on mobile devices may impact battery life during frequent discovery scans.

Future Work

The authors plan to implement this as a mobile application to test "real-world" latency and battery consumption, potentially optimizing the cryptographic handshake for resource-constrained IoT devices.