Re: Framework for encrypted storage for apps
El divendres, 11 d’octubre de 2019, a les 17:59:17 CEST, Johan Ouwerkerk va escriure: > So basically I guess that what I am asking: any examples, suggestions > or other pointers which I can use as further starting points/context > to figure this out? Thanks a lot in advance for all your help! CipherUnitTest::aes256 does encryption and decryption as far as i can see. Cheers, Albert > > Kind regards, > > - Johan Ouwerkerk > > > > > - > > On Sat, Oct 5, 2019 at 9:09 AM Ivan Čukić wrote: > > > > Hi Johan, > > > > One important question here is how do you want the secrets to be unlocked. > > Is the user going to type in some master password every time the otpclient > > is > > started? > > > > If that is the case, you can use QCA to encrypt and decrypt the data you > > need > > to store securely. > > > > If that is not the case - if you don't want to always ask the user for the > > password, then you can expect quite a complicated story of how to make > > something like kwallet safe. > > > > > 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 huge problem of kwallet is that it can not authenticate which > > application is asking for the password. I was told that this could be easier > > to do with flatpaks, but it will still need significant changes to how > > kwallet > > works. > > > > > 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. > > > > An approach like the one taken in Plasma Vault could work for applications, > > but it would (like the QCA option previously mentioned) require the user to > > type in the password every time. The problem with using Plasma Vault is > > that it works with fuse mounts - so the decrypted data si visible through > > the > > filesystem. (though, flatpaks could maybe have some solution there as well, > > not my area) > > > > Cheers, > > Ivan > > > > > > -- > > dr Ivan Čukić > > KDE, ivan.cu...@kde.org, https://cukic.co/ > > gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12 > > > > > > >
Re: Framework for encrypted storage for apps
Hi all, Many thanks for the responses so far. To address the various points raised: It is acceptable for me if the user must type their password. Keychain integration etc. are optional extras. QCA looks like it might be a good fit for what I need. One question I have with regards to keychain integration here is: are the Windows and MacOS X platforms "properly" secure or at least properly designed for this? That is: would it be a good addition to use Qt Keychain for integrating with Keychains optionally on MacOS X and/or Windows, and wail and gnash teeth for the fact it won't work on Linux/FreeBSD? However I feel somewhat intimidated by QCA's lack of proper publicly accessible documentation. To give an overview of what I have tried thus far: - KDE apidox which appeared to consist of a single overview page, with a broken image (dead URL) and a dead link to examples (404): https://api.kde.org/kdesupport-api/qca-apidocs/ - inqlude (https://inqlude.org/libraries/qca.html) which had a link that redirects via someone's private site to KDE Userbase which appears to be about Qt 4.2 times (https://userbase.kde.org/QCA) and another link that is dead (404) - On the advice of tsdegos on Matrix, I tried figuring out via the headers /include what is was supposed to do. I did not get very far. I am probably just too unfamiliar with the code structure and especially how this is supposed to interact with the backing plugins to figure out by myself how to do e.g. "key derivation", "salting" or "encryption" by just looking at these headers. - However I did find an example on the Internet which at first glance looks to explain how to do PBKDF#2 with QCA at least: https://developersarea.wordpress.com/2014/11/27/cryptographic-hashes-in-qt-hmac-sha1-pbkdf2-md5/ (Scroll to the bottom of that blog post for the PBKDF#2 bits) Does that also look reasonable to you, or are there glaring issues beside the uses of QStrings for nearly everything? - I find it fairly hard to Google for this, because search terms like "qca qt secure random" simply don't appear to return useful results here. My background here is mostly some familiarity with JCA, so I'm looking for things like "key derivation", "pbkdf", "secure random" in combination with "qca" and "qt". I So suppose I use QCA, I still have a few questions about how to go about this: - How do I obtain a "secure random" primitive in QCA? I can of course make do by reading bytes from /dev/random on Linux, but it would be nicer to have a portable primitive -- especially since the OpenSSL plugin should be able to access such an implementation (OpenSSL). - How do I set up padding? I mean, sure I can pad my input manually until I have a next multiple of #keysize bits/bytes. Is that solid practice or does QCA already provide proper padding schemes out of the box like PKCS#7? - How do I even construct the encryption itself? I can't seem to find anything other thant public/private key encryption examples (using some public key with OAEP), but I would like AES with a suitable scheme/mode here. Mainly I would like a MAC on the encrypted data because I want to be able to assert that the ciphertext is not accidentally corrupted, say. After all if I can store the secrets in an encrypted and robust fashion, then I can let the user export their data safely for backup purposes. So basically I guess that what I am asking: any examples, suggestions or other pointers which I can use as further starting points/context to figure this out? Thanks a lot in advance for all your help! Kind regards, - Johan Ouwerkerk - On Sat, Oct 5, 2019 at 9:09 AM Ivan Čukić wrote: > > Hi Johan, > > One important question here is how do you want the secrets to be unlocked. > Is the user going to type in some master password every time the otpclient is > started? > > If that is the case, you can use QCA to encrypt and decrypt the data you need > to store securely. > > If that is not the case - if you don't want to always ask the user for the > password, then you can expect quite a complicated story of how to make > something like kwallet safe. > > > 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 huge problem of kwallet is that it can not authenticate which > application is asking for the password. I was told that this could be easier > to do with flatpaks, but it will still need significant changes to how kwallet > works. > > > 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. > > An approach like the one taken in Plasma Vault could work for applications, > but it would (like the QCA option previously mentioned) require the user
Re: Framework for encrypted storage for apps
Hi Johan, One important question here is how do you want the secrets to be unlocked. Is the user going to type in some master password every time the otpclient is started? If that is the case, you can use QCA to encrypt and decrypt the data you need to store securely. If that is not the case - if you don't want to always ask the user for the password, then you can expect quite a complicated story of how to make something like kwallet safe. > 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 huge problem of kwallet is that it can not authenticate which application is asking for the password. I was told that this could be easier to do with flatpaks, but it will still need significant changes to how kwallet works. > 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. An approach like the one taken in Plasma Vault could work for applications, but it would (like the QCA option previously mentioned) require the user to type in the password every time. The problem with using Plasma Vault is that it works with fuse mounts - so the decrypted data si visible through the filesystem. (though, flatpaks could maybe have some solution there as well, not my area) Cheers, Ivan -- dr Ivan Čukić KDE, ivan.cu...@kde.org, https://cukic.co/ gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
Re: Framework for encrypted storage for apps
El divendres, 4 d’octubre de 2019, a les 18:53:15 CEST, Johan Ouwerkerk va escriure: > 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! Would qca be something like what you're looking for? I.e. something you do cryptography in-app? Cheers, Albert
Framework for encrypted storage for apps
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?
