Framework for encrypted storage for apps

[Johan Ouwerkerk]

Hi all,

Bhushan asked me to kick off a discussion on frameworks-devel about a
problem we face for otpclient. We are looking for help in deciding how
to best implement storage of the secrets which are needed by the app.
Any insights from people who are more familiar with frameworks would
be much appreciated!

To give a bit of context: otpclient is an app (flatpak) to generate
two factor authentication login codes, similar to Google
Authenticator. One thing the app needs to do is to store the 'secret'
associated with each configured account securely, because the security
of the 2FA relies on it. Effectively, this bit of data is just as
sensitive as the main password to the account.

Right now otpclient does not yet implement this (securely) and one
reason for that is we are still not sure how we should do this in a
KDE context. I suppose from our perspective the main questions are:

 1. What Qt or KDE framework is appropriate for this?
 2. If there is no such framework, then what KDE technology could
possibly serve as the basis for such a library? And should it become
part of frameworks?
 3. How should this work? In particular in the context of apps such as flatpaks?

We are aware that KWallet ant Qt Keychain exist but we have some concerns there:

 1. (On KDE) these libraries wind up calling dbus. We would like to
avoid plain text out-of-process communication of secrets, especially
communication through a 'shared' channel (for obvious reasons).
 2. In particular with KDE Wallet it was suggested that the wallet
itself may, in fact, not be encrypted.

Another possible contender is Plasma Vault, but we don't really know
how that would work in the context of an app, especially a flatpak
app.

Ideally we could use something that offers the following:

 1. Operating on encrypted files, which are encrypted and decrypted on
the fly. This would facilitate an easy import/export scheme for the
app (backups!), and should also work in the context of flatpaks.
 2. Ideally while being unopinionated about what is stored "inside"
the encrypted file
 3. Easy to present to the user in terms of UX. It should not be
necessary to do some kind of local setup first before being able to
use the app, the otpclient should work as secure as we can make it out
of the box.
 4. Consumed as a library which does not need to 'talk' over unsecured
channels. This would help avoid leaking secrets and make it easier for
otpclient to control the lifetime of secrets held in memory. I.e. we
would be able to flush secrets if we detect that the computer is about
to suspend or on idling for too long.

In particular we do not need lots of system integration, and we do not
necessarily have to be super portable yet.

So with all that said: what do you think? How should we tackle this?
Can KDE offer framework level support for this? And if so, what would
be the framework for that?