venezuela01
commented
1 year ago Open venezuela01 opened 1 year ago
venezuela01
commented
1 year ago 
beantaco
commented
1 year ago The proposal critiques an assumption in Session's threat model, namely absolute safety of the Session private key (the thing that is recovered using the recovery seed), a critique which I agree with.
I don't think I have sufficiently understood the proposal, but I have some comments and questions.
Firstly, given that the proposed security enhancement necessitates a registration process to the Oxen blockchain, this would require users to obtain Oxen cryptocurrency. By involving Oxen payments, I imagine that KYC and other financial surveillance threats would come into play, either already in existence or in the future. This would exclude Session users who can't or won't engage in digital payments or cryptocurrencies (no matter how cheap Oxen is or how aggressively it is marketed) or who simply cannot afford the required Oxen. It's probably obvious that I'm not a cryptocurrency user... Is anyone able to clarify the current process of obtaining Oxen?
Secondly, given that the proposed security enhancement necessitates a registration process to the Oxen blockchain, the registered information would become a permanent and publicly-viewable record. The proposal appears to propose mapping the user's hashed Session ID HASH(session_id) to their device ID device_id, but how is device_id generated? Is it deterministic from identifying features of the device? I'm concerned about the security implications of the Session ID and device ID being made public. Hashing the Session ID is a good idea, but the hashing might need to be something more than just an unsalted single-iteration hash using a typical cryptographic hash function and be something considered best practice for storing passwords.
Thirdly, the proposal is designed to reduce the risk of the Session private key (which could exist on multiple devices) falling in the hands of adversaries. If this proposal is implemented, would Session's threat model change to assume absolute safety of the Session private key on the primary device and absolute safety of the Oxen wallet? What would happen if the primary device or Oxen wallet are compromised?
Lastly, what would be the implications for Session users who don't opt in?
venezuela01
commented
1 year ago Thanks for comments @beantaco, would you mind delete your comment about PFS and move it to https://github.com/oxen-io/session-desktop/issues/2844 instead? I'll response there then. Thanks!
beantaco
commented
1 year ago I moved my comment about perfect forward secrecy to #2844 as requested. However, I believe discussion about the proposed multi-device security enhancement should stay here.
Session Standard: Multi-device Security Enhancement
The current Session threat model assumes the absolute safety of the Session private key. However, this assumption may not always hold. For example, the private key of a targeted user might be exposed if their home or office is physically inspected by a state agent. This exposure could happen if paper documents or metal devices, like Cobo tablets storing recovery phrases, or one of the user's devices link to the same Session ID, are found by the agent. If private keys are compromised, there is no way to alert the user, potentially leading to a false sense of security while an attacker secretly monitors all conversations.
This proposal introduces several security enhancements, including:
These enhancements necessitate a registration process similar to ONS that maps a user's Session ID to their device ID (device identity public key) on the Oxen blockchain. This process helps prevent race conditions that could arise from multiple devices competing to be the primary device and enables a potential Session Standard payment business model. In this model, a user pays a certain amount of Oxen to register their primary device. The Oxen paid is then burned, which could reduce the Oxen supply and increase its value. This paid ONS mapping is both necessary and sufficient for these security enhancements.
The usage of group signatures might potentially be altered by ring signatures with pre-generated key pairs, the actual implementation details require further research.
1. Multi-device Security Enhancement
1.0 Abstraction of Multi-devices as Device Group Members
In the current Session whitepaper, multiple devices linked to the same Session ID are considered equal. This proposal, however, requires each device to create its unique device identity public key and corresponding private key.
We perceive the relationship between multiple devices as akin to the relationship between multiple members in a closed group, where different devices of the same user communicate control messages with each other. For this concept, we use the term "Device Group" where the primary device is the admin, and one or more secondary devices act as group members. Unlike regular groups, where each group identity public key unambiguously represents a group, multi-device management necessitates on-chain registration because multiple devices share the same Session ID. Unlike regular groups where group members exchange conversational messages, in a device group, different devices exchange control messages.
The primary device generates a BBS04 group public key, combines it with the latest Oxen block height and block hash, and then signs it using its device private key. The device then submits
(bbs04_group_public_key, oxen_block_height, oxen_block_hash, signature)to the Session swarm. The Session swarm first checks the Oxen blockchain to retrieve the primary device ID, which is mapped to the Session ID. It then verifies the signature of the BBS04 group public key to confirm that it was indeed signed by the primary device; if not, it rejects the BBS04 group public key declaration.The oxen_block_height and oxen_block_hash serve as timestamp proofs. The Swarm permanently saves the last BBS04 group public key it encounters. Only newer keys can replace old ones, not the reverse, as a measure to prevent replay attacks from a removed device. If the Session swarm accepts the BBS04 group public key declaration, it will use this BBS04 group public key to verify group signatures for conversational message read/write requests from any device.
However, control messages that are intended for metadata communication, such as key exchanges, are not subject to group signature authentication. This exception allows for new device membership applications.
Devices in the same device group share the same BBS04 group public key, while the primary device issues unique private keys to secondary devices in the device group. If an existing secondary device is removed from the device group, the primary device will rotate the BBS04 group key pairs, inform the Session swarm with the new BBS04 group public key, and distribute new BBS04 group private keys to the remaining members.
Note: The BBS04 group public key should not be confused with the Device Group identity public key. The Device Group identity public key is the same as the primary device’s device identity public key, usually is persistent, while the BBS04 group public key can change.
1.1 Primary Device On-Chain Registration
When a user creates a new Session ID, no primary device is declared yet. Any device can register itself as the primary device. To do this, the user must first create an integrated Oxen wallet in Session, or use a third-party Oxen wallet which, while theoretically possible, is less convenient. The integrated Oxen wallet private key is not derived from the Session private key, otherwise it might compromise our security model. After creating the integrated Oxen wallet, a device public/private key pair can be automatically derived from the Oxen wallet private key, or created separately, the trade-off and security implications is yet to researched.
The first device that registers a device group on the Oxen blockchain identifies itself as the primary device associated with that Session ID. This process establishes an ONS mapping from
HASH(session_id)to(device_id||signature). The hash function is utilized to protect Session IDs from being scraped by an Oxen service node while it assists clients in primary device registration. The signature is intended to validate authorized registration of the session_id. In this context, the signature is equivalent toSIGN((key||value), session_private_key), wherekeycorresponds to the ONS mapping key, which in this case equalsHASH(session_id), andvaluerepresents the unsigned ONS value, matchingdevice_idin this situation. A similar concept for a different use case has been proposed in https://github.com/oxen-io/session-desktop/issues/2803.Users must carefully back up their Oxen wallet private key and potentially their primary device private key; otherwise, if the primary device is lost, there is no way to restore either the wallet or the primary device qualification. The Session ID private key alone is insufficient for recovering the primary device qualification.
1.2 Secondary Device Creation, Naming, and Activation
When a user restores a Session ID on a new device using the Session private key, the new device first generates a device ID and its corresponding device private key. It then prompts the user to name this device, e.g., "Ubuntu@NewYork", "Android@Tokyo", etc.
The secondary device then sends a control message signed with its device private key, which includes its device ID and device name, to its own Session swarm. We refer to this message as a "Device Group Membership Application."
The primary device polls control messages from the Session swarm. If it detects a "Device Group Membership Application," it verifies the signature and prompts the user to decide whether to approve the secondary device’s membership request.
If the primary device approves the membership application of a secondary device, it will issue a BBS04 group private key, encrypt it using the applicant's device public key, and send it to its Session swarm as a control message. The applicant device then queries the Session swarm to obtain the new control message, decrypts it using its device private key. This BBS04 group private key will be used in the future to respond to group signature challenges for accessing conversational messages in the Session swarm. This process completes the activation of a secondary device.
1.3 Swarm Authentication Per Device ID Using Group Signature and Short-Term Nonce Challenge
Once a primary device is registered and a BBS04 group public key is stored on the swarm, the swarm will protect any incoming read/write request to conversational messages. However, write protection is more complicated and will be discussed more in a separate proposal. Each time a device attempts to read a conversational message from its swarm, the swarm will generate a short-term random nonce to challenge the device. The device needs to respond with a signature signed using its BBS04 group private key. The swarm can verify the signature using the BBS04 group public key but cannot distinguish one device from another device of the same user.
As mentioned above, control messages are not subject to group signature authentication so new device can apply for membership.
1.4 Device Deactivation and Alert for Unauthorized Read Request
Devices can deactivate themselves or be deactivated by a primary device. Either the device voluntarily sends a control message to the primary device to ask to be removed, or the primary device removes the secondary device from the device group. By removing a device, we mean rotating the BBS04 group key pairs, inform the swarm with the new group public key, redistributing BBS04 group private keys to the remaining devices, and excluding the invalid device. Remember that we encrypt the BBS04 group private key using device public keys, so the invalid device is not able to decrypt any new BBS04 group private keys. This completes the deactivation process of a secondary device.
After rotating BBS04 group key pairs, the swarm will reject any read/write request of conversational messages from a device not in the updated device group, even if it previously used to be a valid member of the old device group. Instead, it will report any attempt of read/write requests from invalid devices. If an unauthorized read/write request is detected, the swarm will construct an alert message, encrypting it using the user’s Session ID, storing it in the user’s swarm, and potentially sending a push notification to the user. The next time when the user queries the swarm, they will find the alert message and can examine their devices and decide on an appropriate action. Again, write protection is more complicated and more details will be discussed in a separate proposal.
At the time of device deactivation, we could consider a mechanism that triggers a complete local message deletion on a secondary device when it is involuntarily deactivated by a primary device. This action would be initiated either upon receiving a push notification or upon polling the notification from the swarm.
In the context of device deactivation, we could potentially integrate a Double Ratchet-style key update mechanism. This would enable us to use the occasion of a secondary device being removed as an opportunity. It would not only facilitate the rotation of new Swarm authentication keys from the primary device to the remaining secondary devices, but also allow for the rotation of encryption keys with the remaining secondary device and the user's contacts.
While this approach does not provide perfect forward secrecy, it does increase security. This mitigates the risk of a deactivated device being compromised at a later date, and the Session identity private key from that deactivated device being used to decrypt future conversation messages. A further enhancement of this concept towards achieving Perfect Forward Secrecy is conceivable and will be suggested in a separate proposal.
1.5 Device Login History Auditing Using Group Signatures on Mid-Term Nonce Challenges
Every time a device attempts to read a conversational message from its Session swarm, the swarm generates two challenges simultaneously. One is the short-term nonce, as described in 1.4, and the other is a mid-term nonce, which is used repeatedly in many read requests until it expires, for instance, rotating once per day. This approach is analogous to a replay attack, where the device can reuse the same signature repeatedly. In our case, however, we do this purposefully. This strategy collects device fingerprints, enabling the swarm to inform the user about the number of devices accessing the swarm in a period of time. If a new fingerprint is discovered, or if an old fingerprint that hasn't been seen for a long time reappears, the swarm will notify the user to be cautious. The user can then determine whether they are using that device or if the device might have been compromised.
One property of BBS04 group signature is that the group manager has the ability to trace a signature back to its private key. Therefore, the primary device can parse the device fingerprint saved by the swarm to determine which device recently logged in. This completes the device login history auditing feature.
Certain highly targeted users with serve threat model might prefer not to leave any device fingerprints on the swarm at all, foregoing the convenience of auditing device login history. These two preferences can't occur simultaneously; they are mutually exclusive. As a result, we could implement device login history auditing as an optional feature, allowing the user to decide on the trade-off themselves.
1.6 Primary Device Deregistration
Primary devices can deregister themselves or transfer their qualification to another device if needed. This process is achieved through an ONS record update.
1.7 Additional Primary Device On-Chain Registration
The possibility of having multiple primary devices could be considered. However, the actual scope of this feature and its implementation is yet to be discussed.
1.9 On-Chain Self-Destruction for Potentially Compromised Account
A user can publish an on-chain transaction to map their Session ID to a special value encoding a dead record, which instructs the swarm to permanently reject any read or write requests associated with their account. The next time a contact of the user tries to send a message, they will receive an error message from the swarm / ONS resolver, informing them, "this account is permanently closed." This prevents a long-time-no-see contact from unknowingly sending sensitive messages to a compromised account.
1.10 Smooth Migration from Unpaid Account
A migration process from unpaid to paid accounts is crucial and might be simple or complicated; this is yet to be researched.
Conclusion
This proposal recommends a security enhancement to the current Session protocol and implements a business model centered around ONS mapping. This serves as a natural method for primary device registration and aids in device management. We recommend that every serious user register their primary device on the chain, even if they only have one device. This is to mitigate the damage from inadvertent leakage of Session private keys, prevent covert conversation monitoring, and facilitate early detection of malicious activity.
Since Session users are typically more privacy and security-conscious, we propose that a business model employing Oxen as an anonymous payment for security enhancement features might be accepted by a substantial portion of Session users. This, in turn, could support the long-term development of the Session project.