#49525 Improve attr encryption key rollover
Opened a year ago by firstyear. Modified 4 months ago

Issue Description

The current design of attribute encryption has a reasonably complex key rollover process - the key rollover process is related to changes of the Server-Cert.

Right now we generate a key from the NSSDB with pk11_TokenKeyGenWithFlags. We'll call this the "secret value". We take this "secret value" and then encrypt that with our Server-Cert - the result is the "encrypted secret value".

In the server when we replace the Server-Cert, we no longer can decrypt the "encrypted secret value". This leads to the counter intuitive advice of "delete the encrypted secret value" on certificate change. Once we delete this, the server starts and calls pk11_TokenKeyGenWithFlags again, returning the "secret value" (the same original value) and we then encrypt that again.

What is important to note is that the "secret value" is stored twice here: once in the NSSDB, encrypted with the nss pin.txt. And again with our certificate with "encrypted secret value".

Because this leads to pointless admin overhead for attribute encryption - we have a value that needs deleting counter intutivalely on key rollover, when NSS gives us a way to access it always provided the pin is available.

As a result we should remove our caching of "encrypted secret value", and rely on NSS to do it's job - to store and give us the "secret value".

This means in our documentation
We should discuss the NSSDB files are CRITICAL to the attr encryption system
We should remove the key rollover section once this is implemented.

For us, we should just read nssdb's "secret value" on start up rather than trying to encrypt / decrypt ourselves.

This would be a huge usability gain for attr encryption, making it much much easier to deploy and use, with simple instructions.

Metadata Update from @firstyear:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

a year ago

Sounds like a good idea. One RFE if I could ask for would be including NSSDB in the DS backup (if not yet -- sorry, I don't recall... :).

At the moment db2bak only does the bdb db, but I planned to add nssdb to the dsctl backup tool I'm going to add :)

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4 backlog

a year ago

are you sure that always the same symmetric key is generated ?
would this mean that the keys generated and used for attribute encryption and changelog encryption would be identical ? In the procedure described for changelog encryption and cert renewal it says that the changelog needs to be exported in clear and after renewal reimported - so this would be wrong.

do we have any test cases for attr and/or changelog encryption and cert renewal ?

@lkrispen It's not generated, it's stored in the nssdb and retrieved on lookup of a certain "name". This means that given the same "name", both will use the same "static key" aka token.

What this means is that the ENTIRE process we have for using our certs to protect the nssdb token output we have requested is pointless, and we can remove all of that code - our security is solely tied to the pin.txt / password on the nssdb, and we can retrieve the token by name. This hugely improves the usability because we can completely remove the requirement for the complex key rollover process.

This would obliviate the need for cert renewal test cases because they "go away". For older installs we would still required them. Today we have no test cases for this space that I am aware of, and that would absolutely be step one in the process of resolving this ticket to create these test cases to ensure that it works 100% on upgrade, import, export and others.

Thanks for the explanation. this makes sense and I am all for this change.

I only need to investigate if this really applies to changelog encryption as we have the recommendation there to export, change cert, reimport - which would indicate that a new key is used, and what should be avoided

@lkrispen I will investigate as part of this change if that makes it easier. :)

I opened https://pagure.io/389-ds-base/issue/50250 that is likely a duplicate of that ticket. Using the nssdb as storage to the symmetric key rather than in the config (attribute/changelog entry) looks a very good idea.
To protect the symmetric key we currently rely on private key (from Server-Cert) or from the nssdb pin password. If someone has access to the nssdb file, @firstyear do you know if private key encryption (current behavior) would be "stronger" than breaking nssdb ?

@tbordaz They are cryptographically equivalent. NSSDB uses aes128 if I recall, and we use similar in the storage that encrypts using the RSA key.

Remember, we are only protecting the symmetric key in dse.ldif as a cached copy of the value that is in the NSSDB as well. So there are technically two possible attack surfaces, and it all relies on the NSSDB protection. Additionally, even if we were storing this value only in dse.ldif, the security of the private key still depends on the security of the NSSDB to access it, so they are equivalent again.

A part of this that is worth discussing is the threats and what the encryption protects from. In our case, the encyrpted database does NOT protect against offline attacks (since pin.txt is often present). It protects against attribute value disclosure (encrypted attrs can only be sent via SSF > 1 channels), attacks against the backups of the system (which may/may not have pin.txt), and code-execution attacks trying to disclose data (but only through obscurity of the required steps to decrypt).

So in these cases, we need to consider the protection of the NSSDB and pin.txt as well, and asses how that relates to the protections attribute encryption is providing. IMO there is no change in the threats and security profile regardless of if we simplify this system, since all of these still hinge on the pin.txt and nssdb encryption.

My summary is the strength of the system, and the threats it protects against is the same in both situations - and infact may be improved by having a simple administration process allowing people to feel more confident to use the attribute encryption mechanism.

Login to comment on this ticket.