Bug 34976 - Encryption keys should not be shared between modules
Summary: Encryption keys should not be shared between modules
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-03 14:50 UTC by Marcel de Rooy
Modified: 2024-04-23 13:15 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel de Rooy 2023-10-03 14:50:50 UTC
At this time we are using the encryption key in koha-conf to encrypt stuff for 2FA, EDI and Acquisition already. The key was introduced for 2FA.

I think that it would be better to differentiate and use separate keys for various processes in Koha. For instance, the key for 2FA should be used exclusively for that purpose.
We could consider if that is needed also for EDI and Acq since these are related modules. They could use one or two new keys.

When adding a new call to Encryption, we should think about it. Perhaps this would be forced a bit more by passing a parameter to K::E indicating which key to use?

Opening the discussion :) What do you think?
Comment 1 Jonathan Druart 2023-10-03 15:02:20 UTC
Why that? Security?
Comment 2 David Cook 2023-10-03 22:35:14 UTC
Having a single master key isn't uncommon, but it could be nice to be able to have multiple encryption keys and to specify which one is needed for what feature.

I think that this mechanism could be especially useful for key rotation. (I notice Marcel has already commented on bug 32078 where we had talked a bit about key rotation.) I've used other systems where I've rotated encryption keys in this way. 

Another future use could be data interchange. Perhaps you'd want to share encrypted data with another system without giving that other system your master key. You could just encrypt that particular information with a shared key while keeping most other data encrypted using a master key. This scenario is pretty hypothetical though.
Comment 3 Marcel de Rooy 2023-10-04 12:22:14 UTC
Using one encryption key for whole Koha is obviously more convenient than carrying a large keychain but is unsafer too. If you get that key, you can decrypt everything.

Interesting question though would be: How would you get one key and not the others? And underlying, is koha-conf the best place to save them? Easy to ask, harder to answer. If you would get secrets from some vault, you still need a token for that, etc.

As David referred to the rotation bug, the management of data encrypted with which key and what version becomes a bit harder.. Security always has a price.
Comment 4 Liz Rea 2024-02-12 22:36:47 UTC
At the point  you have access to root to get the koha-conf, you have everything including the database and all of the keys anyway (because you can become koha-mysql or koha-dump the whole thing) and all of the keys are right there in the koha-conf. 

While I agree that one key does allow access to more things, the added complexity of multiple keys... the idea of it makes me very tired, for a really negligible gain in security.
Comment 5 Marcel de Rooy 2024-04-23 13:15:40 UTC
(In reply to Liz Rea from comment #4)
> complexity of multiple keys... the idea of it makes me very tired, for a
> really negligible gain in security.

Thx for your contribution. Still not having enough energy to respond on its content :)