[Feature] Enhancing Privacy Protection in ONS: Session Subaccount as a Unidirectional Privacy Firewall to Protect the Main Account

[venezuela01]

Enhancing Privacy Protection in ONS: Session Subaccount as a Unidirectional Privacy Firewall to Protect the Main Account

Background

This is a follow up of Addressing the Risk of Dictionary Attacks on ONS.

While the current ONS design provides ease-of-use by letting any user fetch a Session ID using an ONS name, this poses an opening for dictionary attacks. Such vulnerabilities could lead to spam and, more importantly, potentially expose users' social graphs.

With the increasing number of data breaches and the rise of highly sophisticated attacks, it's imperative to adopt a Defense in Depth strategy, offering multiple layers of protection. Even if one layer is compromised, the remaining layers continue to provide robust defense.

Proposal: ONS Session Subaccounts

To fortify privacy, we suggest to introduce the concept of subaccounts. These function as one-way gateways for incoming message requests, shielding the main account ID.

Creation of Subaccounts

When Alice creates a new Session account, she generates a main identity with private key sk_main and public key pk_main. Using a deterministic key derivation function, we produce a secondary identity, the ONS subaccount, with a private key sk_ons = KDF(HASH(sk_main||constant_ons), salt) and the matching public key pk_ons.

ONS Registration with Subaccounts

For enhanced privacy, when Alice registers on ONS, her username is mapped to the subaccount, not the main account. This subaccount is exclusive for ONS mapping only and will not engage in any open groups, closed groups, or 1-1 chats.

Communication Process

1. Message Request: Bob, wanting to contact Alice, fetches her ONS subaccount ID. He creates a message, adds his greeting and main account public key, signs with his private key, encrypts with Alice’s ONS subaccount public key pk_ons, and dispatches it to her subaccount.

2. Incoming Request Polling: Alice's client periodically checks her associated swarm for incoming messages. Upon receiving one, Alice can verify its authenticity, read the greeting, and choose to engage or ignore. If she accepts, her main account will be used for replying. Alice should never use her subaccount to response to any messages.

3. Optional Pause: Alice can halt the polling if she's not anticipating any new connections.

Key Benefits

• Enhanced Privacy: The segregation of the main account and ONS subaccount ensures Alice’s primary identity remains shielded, particularly from potential ONS name guesses.

• Robustness Against Unknown Weaknesses: If vulnerabilities emerge in open groups, closed groups, or 1-1 chats that unintentionally expose social graphs, this design provides an additional layer of protection. When cross-referenced with third-party data leaks, recovering user identities becomes considerably easier if many nodes are associated with a known ONS username. By making the link between ONS and main_account invisible to any unidentified attacker, we substantially increase the challenge of successful de-anonymization.

Prioritizing the Protection of Social Graphs

While enhancement measures are in place, our main focus should always be on preventing the exposure of social graphs. Techniques such as Robust De-anonymization of Large Sparse Datasets have shown their efficacy. The unidirectional privacy firewall between ONS and user main accounts offers an added layer of security. Nonetheless, it's essential to remember that this layer is a supplementary safeguard, and it should not diminish the paramount importance of directly preventing social graph leaks.

Related Proposals

This proposal complements Addressing the Risk of Dictionary Attacks on ONS. While both can be implemented individually or concurrently for optimal protection, it's crucial to understand that neither should be perceived as a replacement for the other.

[tycode]

When Alice clicks her picture in the top left to get her Session ID to copypaste to send to a Bob on another channel, a different ID should be displayed every time.

When a potential Bob sends a message request to the Session ID supposedly sent to him by Alice, and it appears in Alice's client, Alice should be able to see which Session ID the message request was sent to, before accepting or rejecting it.

Preferably, Alice should also be able to see a list of all the Session IDs that have ever been generated for her, and deactivate (or otherwise block) any that she is not using, to prevent spam requests if an ID gets leaked.

I'm not sure what this has to do with ONS but if your proposal boils down to the above then 👍 . As you point out, the ability to have arbitrarily many different identifiers that can be generated and deactivated at any time allows people to invite others to add them without leaking their social graph. This is something I've been wishing for years that mainstream services would do (e.g. discord, gmail, heck even github).

[venezuela01]

Some centralized messenger apps include a feature referred to as "Scan my QR code to connect" or "Save my QR code for sharing." This is an easy, secure method for users to add new contacts or share their contact information.

These QR codes are often set to rotate or expire after a certain period. This ensures that an outdated QR code can't be used maliciously for spam or unsolicited messages. By implementing a time limit on QR codes, these platform adds an extra layer of protection for users against unwanted communications.

[tycode]

• Does Session also support this QR code feature?
• Does it have a way to do the equivalent with a plain ASCII string? QR codes are great for sharing with people face-to-face, but I want to be able to copy-paste a string to someone on the internet, not take a photo of my screen with my phone.
• If you've already sent your (main) Session ID somewhere, is there a way to rotate this after the fact, without creating a completely new account?

[venezuela01]

• Does Session also support this QR code feature?

Session supports Scan Me, Share / Save my QR Code and Scan QR Code, however, it doesn't support rotation with the current design. I'd love to see Session to support QR code rotation.

• Does it have a way to do the equivalent with a plain ASCII string? QR codes are great for sharing with people face-to-face, but I want to be able to copy-paste a string to someone on the internet, not take a photo of my screen with my phone.

Session does not support ASCII string user ID rotation, I'm also not aware of any centralized messenger app supports ASCII string user ID rotation, but I'd love to see Session to support user ID rotation.

• If you've already sent your (main) Session ID somewhere, is there a way to rotate this after the fact, without creating a completely new account?

Not with the current design, the same as you, I hope the Session team will take this into consideration for future versions as well.