Concept of Authentication and Encryption for qaul

[claddyy]

Background

Currently qaul supports only one user per node, but with this project, we plan to extend the capabilities to support multiple users per node , organised with authenticated and encrypted sessions. This project lays the foundation for a secure and scalable system that accommodates various users, and is crucial for the potential development of a web interface.

Objective

Design a user authentication layer, which has these listed features:

• Secure authentication system with optional use password
• zero-config for the use. (password/session key would be cached)
• support multiple sessions per node
• support multiple user per node
• session should be transport encrypted via Noise protocol

[claddyy]

References for the initial work were taken from research papers based on Authentication in p2p Networks which were downloadable pdfs. Do you think that the focus should be on creating a prototype based on it, and making the modifications on the way? I would be grateful for any help and suggestions. Moreover, I think that the rest will be figured out while we discuss based on the progress. If you think there's a loophole in the concept or thought process, please point it out and provide feedback. Looking for some guidance for the next steps though.

Initial work:

1. Public Key Infrastructure(PKI) for Identity verification

   Each user and node in the network has a unique pair of public/private keys. The public key serves as the user’s identity, while the private key is used for signing and encryption tasks, ensuring secure communication. We use rand to provide cryptographically secure random numbers for key generation. To generate and manage cryptographic we can use any other crate example ed25519-dalek.

2. Secure Registration and Key Exchange

   Upon joining the network, a user generates a new key pair and exchanges it using DH key exchange. The public key is broadcasted or shared with the network using a secure channel.

3. Token-based Authentication for sessions

   After initial key exchange, generate a session token for the user. This token is encrypted with the user’s public key ensuring that only the holder of the corresponding private key can decrypt it and use it. Also, this session token is used for subsequent authentication during the session. It can contain information like the session expiry time, the user’s public key, and a unique session identifier. Since the token-based authentication is stateless, this reduces the need for central session management. It allows flexible session management, therefore would support multiple sessions per user.

   And creating custom tokens would indeed a better approach for this rather than trying to use something standard like JWTs due to obvious concerns and issues which isn’t suitable for an internet independent P2P applications. An pseudocode of this implementation is provided in a prototype here

   use ed25519_dalek::{PublicKey, SecretKey, Signature, Signer, Verifier};
   use serde::{Serialize, Deserialize};
   use bincode;
   
   #[derive(Serialize, Deserialize)]
   struct CustomToken {
       user_id: String,
       session_id: String,
       expires_at: u64,
       // more fields
   }
   
   fn generate_token(user_id: &str, session_id: &str, secret_key: &SecretKey) -> Vec<u8> {
       let token = CustomToken {
           user_id: user_id.to_owned(),
           session_id: session_id.to_owned(),
           expires_at: /*logic*/,
       };
   
       let encoded = bincode::serialize(&token).unwrap();
       let signature = secret_key.sign(&encoded);
   
       // concatenate the encoded token and signature into one Vec<u8>
       [encoded, signature.to_bytes().as_slice()].concat()
   }
   
   fn verify_token(token_bytes: &[u8], public_key: &PublicKey) -> Result<CustomToken, &'static str> {
       let (encoded, signature) = token_bytes.split_at(token_bytes.len() - 64); // Assuming signature is always the last 64 bytes
       let signature = Signature::from_bytes(signature).unwrap();
   
       public_key.verify(encoded, &signature).map_err(|_| "Verification failed")?;
   
       bincode::deserialize(encoded).map_err(|_| "Deserialization failed")
   }

4. Optional Password Support

   For additional security, user can opt to protect their private keys with a password. This password will never be transmitted over the network, and would be used locally ot encrypt the private key on the user’s device.

   We can also implement a secure password-based key derivation function(PBKDF) to strengthen the security of password-protected keys.

5. Noise Protocol for Secure Communication

   The noise protocol framework would be used to encrypt all communication between nodes, including the initial key exchange, session token transmission, and any data exchange thereafter. This obviously provides a flexible and robust cryptographic primitives for ensuring the confidentiality, integrity, and the authenticity of messages.

   It defines several handshake patterns that negotiate the cryptographic keys between parties, and when a handshake is complete it generates a pair of symmetric keys for encrypting and decrypting the messages. It also has forward secrecy that ensures that session keys are not compromised even if the long-term keys are. We will use snow for the implementation.

6. Zero-Configuration User Experience

   The process of discovery and initial connection process among nodes, is already implemented using the mDNS and other local discovery protocols.

   We would design the underlying systems to automatically manage key generation, exchange, and session management processes, requiring minimal inputs from the user.

   We will implement caching mechanism for session tokens and user preferences.

[MathJud]

The possibility to support multiple users per node already exists in libqaul.
You can test it be using the qaul-cli client and

https://github.com/qaul/qaul.net/blob/main/rust/clients/cli/README.md

The user details are saved in the file config.yaml: Name, cryptographic Keys, ID-hash
The Node's information is saved there too.

Each user has a cryptographic ed25519 key pair, the user id the hash of the public key.

The node also has a crpytographic ed25519 key pair.

The following system could sketch :

• transport encryption against the node's keys
• authentication against the users identity
• It would be optimal IMHO, to have two authentication methods
  • password
  • some kind of UI authentication pub key

The current security & cryptographic system within the qaul network is described here:
http://qaul.github.io/qaul.net/#/qaul/rust/security

It might be interesting to use some of the concepts/protocols/libraries for the encryption/authentication towards the UI too.

[claddyy]

It might be interesting to use some of the concepts/protocols/libraries for the encryption/authentication towards the UI too.

By UI you mean the cli-tool (as of now), or the actual flutter UI of qaul?
Thanks a lot for your feedback.
I've explored the current security & cryptographic system in depth. I'll also update my GSoC application timeline, and will ping you once I do it.
As we talked in our call, about decoupling the qauld and qaul-cli, and also to make qauld interactive. It's interesting, and I think we can attempt this post-GSoC. For the scope of the project, I've included test coverage as well.

[MathJud]

It might be interesting to use some of the concepts/protocols/libraries for the encryption/authentication towards the UI too.

By UI you mean the cli-tool (as of now), or the actual flutter UI of qaul? Thanks a lot for your feedback. I've explored the current security & cryptographic system in depth.

This means every possible UI, which uses our Protobuf RPC to interact with libqaul.

I suggest the following approach:

A) Create a new CLI control binary qauld-ctl in rust, which implements and tests all the concepts and controls qauld.
B) The concepts developed there need to work for the flutter UI too, and should afterwards be ported to it. (this could though be out of scope for a GSoC project).

[claddyy]

This sounds great, I researched over it, and it seems quite doable.
What do you think, shall we create a basic structure for qauld-ctl in earlier weeks and then continue with the authentication part, or shall we do it other way around?