Encryption
The idOS uses asymmetric encryption by default to secure user data. For encryption, the user's public key is used that he or she derived when setting up an idOS profile.
In the absence of a stronger, more recent recommendation, we follow Latacora’s 2018 standards using the asymmetric encryption methods NaCl/libsodium (Curve25519 + ChaPoly AEAD).
As users are in control of their idOS profile, they can also choose to add data without encryption, even though this is highly discouraged.
When is data encrypted?
Data encryption happens when 1) identity verification providers issue to users Verifiable Credentials that are then added to the idOS in a guided process or 2) the user adds data through the User Data Dashboard or 3) when data access is granted. The idOS is open source and provides SDKs to enable third parties to perform these actions. As a default encryption will be built into these components.
The initial identity verification provider, Fractal ID, will encrypt the content of all credential records before writing them in the idOS. The idOS User Data Dashboard will encrypt by default when creating an attribute record.
Derived key generation
The idOS uses passwords as a common non-technical approach to derive keys that can be used for encryption by employing a key derivation function like scrypt. The following process is deployed to derive the key:
User is asked to choose a password
Password is normalize it for consistency
Password is used with Scrypt-js to derive a 32-byte key
Password is used with tweetnacl-js to generate a new asymmetric keypair (x25519-xsalsa20-poly1305)
To ensure determinism, scrypt parameters are kept constant (CPU/memory cost, block size, parallelization costs, and salt), but using the same salt across all users would weaken this method beyond any reasonable standards because it would easily enable rainbow table attacks, which is why we scope determinism to each user. For mitigation, we start by using the user’s idOS ID as a salt by default and will upgrade the idOS by generating a bip39 mnemonic seed phrase for each user.
Encryption flows
Let us walk through two of the encryption flows:
Encryption flow #1: Using derived keys (from seed or password)
Encryption flow #2: Creating a data access grant (using re-encryption)
Last updated
