Skip to main content
start

Managing Keys

This page outlines a structured approach to managing private keys (in case of e.g. changing a password), ensuring secure authentication and data access integrity.

Step 1: Private Key Generation and Storage​

Step 1A: Generating Private Key from Password and Username​

  • Private key is generated automatically using password and username.
  • Password Change Impact: Changing the password automatically results in generating a new private key, as it is derived directly from the updated password and username.

Step 1B: Private Key Stored on Application Server​

  • Password and username are used for authentication with the application server.
  • The private key is stored securely on the server, encrypted with either the user's password or a key derived from the password.

Password Change Process:​

  1. Password is updated on the server only.
  2. The old private key is re-encrypted on the client side using the new password or a derived key, and then saved back on the server.
  3. If the private key requires regeneration:
    • The new private key is encrypted (with the new password or derived key) and replaces the private key stored on the server.
  4. If regeneration is not required, the process ends.

Step 1C: Regenerating Private Key Without Changing Password​

  • A new private key is generated.
  • The new key replaces the existing private key on the server, encrypted with the current password or a derived key.

Step 2: Updating Public Key​

  • The new public key is sent to the application server.

Step 3: Registering Public Key in Bridge​

  • The application server registers the new public key in PrivMX Bridge.

Data Access Impact:

  • The user temporarily loses access to existing data (containers like Thread or Store) they previously had access to.
  • The application server has to notify the Container Manager that access to the data must be refreshed.
  • Only the users with management access to the specific container can restore access for the user.

Step 4: Restoring Data Access​

  • The Container Manager in the Endpoint initiates a recovery procedure to refresh data access.

Recovery Procedure:​

  1. All containers are updated with functions such as threadUpdate or storeUpdate etc.
  2. The old public key associated with the specific user is replaced with a new public key in the containers.
  3. The option force while updating should be set to True.

This structured approach ensures secure management of private and public keys while maintaining data access integrity during key updates or password changes.