Support password-protected encryption of`atKeys` files

[gkc]

Is your feature request related to a problem? Please describe.

atKeys files are not encrypted, thus they need careful management; I'd like it not to be a security problem if my atKeys file is somehow leaked.

Describe the solution you'd like

Support password-protected encryption of atKeys in the same way as for ssh private keys

Describe alternatives you've considered

No response

Additional context

No response

[purnimavenkatasubbu]

Sample dart code for atkeys encryption atkeys_encryption.dart

[gkc]

@purnimavenkatasubbu Next steps:

• Find the functions in our packages which load atKeys files. Add them as a task list in this ticket's description. For each function we will need a ticket to do the following:
  • add an optional password parameter to the functions which are doing the load, and rippling that new parameter addition back down the stack to wherever user input is provided
  • check if the atKeys file is encrypted
  • if it is encrypted
    • use the password parameter and decrypt
    • or throw an exception if no password parameter was supplied
  • add unit tests covering each if condition above
• add a task to this ticket for updating cli/auth_cli in at_onboarding_cli adding an option to supply an encryption password when using onboard / enroll
• add a task to this ticket for updating CLIBase in at_cli_commons adding an optional encryption password command-line argument
• Find all of our command-line programmes. Add as a task list in this ticket. For each programme we will need a ticket as follows:
  • If it's not using CLIBase from at_cli_commons, consider using CLIBase
  • If it's not feasible to use CLIBase, add an optional encryption password command-line argument

For every task you've added, create a ticket and add the link to the task item

There's a reasonable amount of analysis to do here and a lot of admin / ticket creation; I'm going to estimate it as 8 SP

[gkc]

Since this has come up multiple times in conversations with customers, I've increase its priority to P1 and moved it into Triage for discussion at next sprint planning

[gkc]

@purnimavenkatasubbu What I described above is a broad-based bottom-up approach to getting this feature rolled out. A better approach is probably to first focus on getting this feature into all of the NoPorts distro's binaries (including at_activate) and treat all of the required work as P1; and then treat the remainder as P2

[purnimavenkatasubbu]

• [ ] In no-ports, add parameter to pass password to srvd.dart, sshnp.dart, sshnpd.dart and npt.dart files in noports/packages/dart/sshnoports/bin folder which should propagate the password to the package which decrypts the password protected atKeys file : https://github.com/atsign-foundation/noports/issues/1465
• [ ] Update cli/auth_cli in at_onboarding_cli adding an option to supply an encryption password when using onboard / enroll #691
• [ ] Update CLIBase in at_cli_commons adding an optional encryption password command-line argument
  #692
• [ ] _readAtKeysFIle --> at_auth_impl.dart
• [ ] Add unit tests

[sitaram-kalluri]

@gkc and @cpswan : Here are the proposed approaches for generating a hash from a passphrase to encrypt or decrypt the atKeys file. Kindly review these options and let us know which one would be the most suitable for our needs:

Approach 1: PBKDF2 with IV stored with the key file: PBKDF2 (Password-Based Key Derivation Function) uses HMAC to hash the password. With PBKDF2, we can specify the number of iterations the hash function should perform and provide a nonce, which strengthens the hash and reduces the risk of brute-force attacks.

However, one limitation of PBKDF2 is its susceptibility to brute-force attacks when executed on GPUs.

Approach 2: Argon2id with IV stored with the key file: Argon2id is a more advanced alternative to PBKDF2 and is resistant to brute-force attacks even when executed on GPUs. Like PBKDF2, Argon2id allows us to specify the number of iterations and a nonce, but it also allows to define the amount of memory the algorithm can use. Allocating more memory makes the algorithm more resistant to brute-force attacks. Argon2id gives us the flexibility to adjust memory usage, iteration count, and the degree of parallelism, enabling us to balance performance and security based on your needs.

The Dart Cryptography package provides implementations of both algorithms: https://pub.dev/packages/cryptography .

For both approaches, an Initialization Vector (IV) must be provided to the encrypter. During encryption, a randomly generated IV of fixed length can be used, and this IV must be retained for decryption. One way to achieve this is by appending the IV to the encrypted atKeys content and storing them together in the atKeys file. During decryption, the IV and the encrypted atKeys are used to retrieve the decrypted version of atKeys. Through decrypting we get the atKeys file back

Example of the encrypted file: {"content":" < encrypted atKeys file content > ","IV":" < IV encoded to base64 > "}

Alternatively, in both approaches mentioned above, the IV for the encrypted atKeys file can be set to all zeros to avoid storing it within the file. However, this method provides weaker security.

[gkc]

I think argon2id is the way to go here. @cconstab any thoughts?

[cpswan]

My first inclination is also towards argon2id, but we should check first how things look in C land given our progress with the SDK there.

We should also have a view on whether this is expected to be used primarily with clients (where the password can be entered interactively) or also on devices?

[sitaram-kalluri]

This GitHub repository includes Argon2id implementation in C-Language and provides an example demonstrating its usage.

[VJag]

@gkc @cpswan Please share your thoughts on how to go about managing the IV

[gkc]

@gkc @cpswan Please share your thoughts on how to go about managing the IV

Store in encrypted atKeys file as per @sitaram-kalluri's suggestion {"content":" < encrypted atKeys file content > ","IV":" < IV encoded to base64 > "}

[sitaram-kalluri]

The analysis is complete, and the below are the conclusions drawn for implementation:

• Use the Argon2id algorithm for encryption and decryption of the atKeys file when a passphrase is provided.

• The proposed structure for storing encrypted data in the atKeys file is as follows:

{
  "content": "<encrypted atKeys content>",
  "IV": "<IV encoded in base64>",
  "Algorithm": "<Algorithm used for encryption>"
}

Including the encryption algorithm in the atKeys file allows for future flexibility, enabling the use of different algorithms or support for multiple algorithms. This information will help determine which algorithm to use for decryption.

• To determine if the atKeys file is encrypted, decode the JSON string and check for the presence of the "IV" key/"Algo" Key. If the key is present, the file is encrypted, and decryption should occur during authentication. If not, the file is unencrypted and the decryption process can be skipped.

Following are the tickets to track the implementation progress:

• [x] https://github.com/atsign-foundation/noports/issues/1465
• [x] #691
• [x] #692
• [ ] Add a command to "activate_cli.dart" which will encrypt the existing atKeys file with the pass-phrase.
• [ ] Add a command to "activate_cli.dart" which will write the decrypted version of atKeys file to standard output when encrypted version of atKeys file and passphrase are supplied.

[sitaram-kalluri]

Spent 8SP in PR-98:

1. Completed analysis in no-ports code and identified the places to add the "passPhrase" and as a parameters.
2. Explored and finalized the algorithm to use for hashing the passPhrase which is subsequently used to encrypt/decrypt the atKeys file.
3. Modified code in no-ports to add the optional param - "passPhrase" to srvd and sshnp processes.
4. Completed code changes in the at_onboarding_cli to accept the passPhrase and propagate it to the at_auth package to decrypt the encrypted atKeys file for authentication.
5. Completed the code changes in the at_auth package.
6. Added encryption/decryption and hashing of passPhrase in the at_chops package.

Pending work to do in PR: 99

1. Add information logs when passing the passPhrase.
2. Add exception handling when the passPhrase is not provided for the encrypted atKeys file.
3. Add a command to "activate_cli.dart" which will encrypt the existing atKeys file with the pass-phrase.
4. Add a command to "activate_cli.dart" which will write the decrypted version of atKeys file to standard output when encrypted version of atKeys file and passphrase are supplied.
5. Add unit and functional tests to assert the changes.

[sitaram-kalluri]

Work accomplished in PR-99

1. Added information logs when passing the pass-phrase.
2. Completed adding exception handling when pass-phrase is not supplied to password protected atKeys.
3. Added "encrypt" and "decrypt" commands in at_onboarding_cli which will password-protect the existing atKeys file and decrypt the password protected atKeys file respectively.
4. Completed updating the functional tests.
5. Tested the changes with no-ports and works fine.

Pending work in PR-100.

1. Merged the code changes and publish the packages.

[sitaram-kalluri]

Work accomplished in PR-100.

1. The changes in at_chops are published in v2.2.0
2. The changes in at_auth are published in v2.0.8
3. Completed addressing the review comments in at_onboarding_cli and are ready for review

[sitaram-kalluri]

The changes in the at_onboarding_cli are released in the v1.8.0.

We have https://github.com/atsign-foundation/noports/issues/1465 to track changes in the no-ports. Hence closing this ticket here.