Encryption at rest in Drizzle Storage module

[ankita-p17]

Earlier while using Askar for record storage, encryption at rest was handled inherently by the built-in encrypted wallet storage, ensuring that sensitive records/ details in the records(connections keys, credentials details, messages etc.) are encrypted automatically without requiring additional implementation effort.

However, when using the Drizzle Storage Module, encryption at rest is not inherently provided by the storage layer. Data is stored in plaintext unless the implementer adds custom encryption logic.

This creates a security gap compared to the Askar-based setup.

Implementing an optional, configurable field-level encryption at rest in the Drizzle Storage module would help address this gap and improve the overall security posture.

Proposal -

1. Field-Level Encryption

• Only configured columns are encrypted
• Avoids encrypting queryable/indexed fields
• Supports selective protection of sensitive attributes

2. Transparent Operation

• Automatic encryption on save and update
• Automatic decryption on get, find etc.

3. Use this feature configuration based

• Enable this while configuring agent; get from agentContext or from DrizzleStorageModule

Sample configuration -

DrizzleStorageModule({
  encryption: {
    key: process.env.STORAGE_ENCRYPTION_KEY,
    fields: {
      DidCommConnectionRecord: ['metadata', 'invitation'],
      CredentialExchangeRecord: ['metadata'],
      BasicMessage: ['content']
    }
  }
})

I would appreciate feedback and thoughts on this.

[TimoGlastra]

I agree. This is something we didn't have time for in the first implementation, but that would be great to support.

Question is whether you want to store which fields to encrypt on the record, or as you proposed in the module.

I wanted to look at azure cosmos db (see https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-always-encrypted?tabs=dotnet) as i think that also supported client side encryption, maybe we can learn some patterns from it.

I think limiting it to only top level field (so not nested field encryption), with the exception of metadata (allow encryption per metadata key).

Another thing to consider is how tags are encrypted and queried. I'd say to keep things simple and not require deterministic encryption (for comparison) we do not allow querying on encrypted fields. I think in most cases this is not a problem (but we should check if we query by sensitive fields).

[TimoGlastra]

I think allowing the encryption key to be provided by the kms is also beneficial. And maybe even allow multiple encryption keys (we've noticed that companies have different policies for different types of data, which may require e.g. an hsm to decrypt)