As I see no password to encrypt and protect local data.
iOS have a vulnerability that is possible to access the keys in the keychains with forensic tools than doesn’t need the password to read the content saved offline.
Apps as Protonmail and Wickr are using their own way to protect loca data.
XX Messenger has the best encryption and forward protocol through the internet than need to protect also the user privacy local.
Please note that in order to ensure security for our users, other than the security system that iOS utilizes, we have also implemented our own encryption layer for our app called the AppKey Protection System, that adds additional layer of security.
This system works by encrypting all sensitive local data with a per-login local key called AppKey, which is not stored in a place that can be compromised. Users can activate this protection system by turning on TouchID, FaceID, or PIN protection in their app settings.
For more in-depth overview of this system, please read the following article:
Thanks for your feedback, As I thought need improve the code.
EKV is a directory and file-based encrypted key value storage library with metadata protection written in golang. It is intended for use in mobile and desktop applications where one may want to transfer protected files to a new device while protecting the nature of the information of what is stored in addition to the contents.
Features:
Both the key and the contents behind the key are protected on disk.
A best-effort approach is used to store and flush changes to disk.
Thread-safety within the same EKV instance.
EKV is not a secured memory enclave. Data is protected when stored to disk, not RAM. Please see Memguard and similar projects if that is what you need.
EKV requires a cryptographically secure random number generator. We recommend Elixxir’s fastRNG.
EKV is released under the simplified BSD License.
Known Limitations and Roadmap
EKV has several known limitations at this time:
The code is currently in beta and has not been audited.
The password to open and close the store is a string that can be dumped from memory. We would like to improve that by storing the password in a secured memory enclave (e.g.,Memguard).
EKV protects keys and contents, it doesn’t protect the size of those files or the number of unique keys being stored in the database. We would like to include controls for EKV users to hide that information by setting a block size for files and adding a number of fake files to the directory.
Users are currently limited to the number of files the operating system can support in a single directory.
The underlying file system must support hex encoded 256 bit file names.
Thank you for your comments – EKV does have a roadmap that we have not been able to execute on, but we hope to in the future.
We had a password in earlier versions of the app, but requiring a password was one of the big complaints we got from testers… We decided to remove it in favor of a generated secret stored in the secure app storage area (e.g., iOS keychain). I believe this is what protonmail and wickr do as well. You can see a technical writeup about the details of protonmail’s iOS app here: ProtonMail : forensic decryption of iOS App | by Matthieu Regnery | Medium
I would like to see the security of this improved with an optional password/pin/biometric. We are certainly thinking about the design to support improved protections. What is there right now is comparable to what other apps do, and it is what was possible given our constrained resources. I’m looking forward to improving this in the future, specifically by using memguard to protect secret data in RAM along with options for protecting secrets that is better than the plain vanilla keychain solution.
Very good when you can implement memguard, cos I saw EKV with some weak point that can be unsafe.
Protonmail improved other way to prevent keys saved in secure enclave be extracted from forensic tools, as Well Wickr, when you use password than the decryption keys are not saved in the secure enclave once it’s vulnerable.
Wickr: What you should always remember is that with your password, or with access to your app which you’ve conveniently configured for autologin, forensic tools are just as capable as hackers or anyone else of accessing your app data. So, keep your password strong and use things like autologin wisely.
Decrypt app data using the iOS Keychain and GrayKey
I agree with you that we should add password/pin/biometrics to derive the secret used by ekv and the encrypted SQL database used by the apps. We had discussed how one might change the secret used by EKV but haven’t had time to build it yet. I hope to roll that out eventually but it is not clear when right now.
Can you elaborate on the weak points you see in EKV? I don’t see weaknesses when compared with other apps. Memguard is useful as a protection measure but I don’t believe any other apps use anything like it. My understanding of the app security containers is that they are pretty good, so it provides limited utility. For example, If an attacker has presence on the device that can read app memory then the device is most likely rooted, meaning they can read the password when it is typed/crash the app to force entering the password/etc.
It definitely is useful and makes it harder. Our plan is to do it a little differently (which is admittedly more complicated) by using a key derivation function leveraging the secret in the keychain alongside the provided pin/password/biometric, but this is still vulnerable to compromise via attacks that read device memory.
In other words, this stuff is complicated. Thanks again for your comments and the discussion.
PIN code : AppKey is encrypted with a derivation of this PIN. Even if the derivation is quite slow, we have a limited number of combination and bruteforcing it is a matter of time and complexity. Strong PIN can level up time needed to access data.
I read that article last year, although you can brute-force the pin code the app allows set a PIN code of 21 characters that just make it harder but still possible cos still only numbers, I dunno why Proton doesn’t allow use a alpha numeric password to protect that key than was better to avoid brute-force and only quantum computers to crack it in future.
I choose those apps as example to show you ways to protect your app, once I saw Quantum encryption I thought must be safe as the protocol encryption.
Thanks to you to reply and see that’s possible to improve security in the xx app.
EKV is not a secured memory enclave. Data is protected when stored to disk, not RAM. Please see Memguard and similar projects if that is what you need.
EKV requires a cryptographically secure random number generator. We recommend Elixxir’s fastRNG.
The password to open and close the store is a string that can be dumped from memory. We would like to improve that by storing the password in a secured memory enclave (e.g.,Memguard).
EKV protects keys and contents, it doesn’t protect the size of those files or the number of unique keys being stored in the database. We would like to include controls for EKV users to hide that information by setting a block size for files and adding a number of fake files to the directory.
Users are currently limited to the number of files the operating system can support in a single directory.
The underlying file system must support hex encoded 256 bit file names.
I understood what tou said comparing to other apps regarding other apps can be dumped as well, than the point is nock your door to make ir better, and I believe you all will once you had started before the quantum computers become popular.
OK I think I understand that you see the additional features listed in the limitations & roadmap section of the README (README.md · master · elixxir / Encrypted KV Store · GitLab) as the weaknesses. I think we may be disagreeing on the meaning of words, but what I mean is that a “weakness” implies something is not comparable and is not as good compared to the existing solutions and that the existing solutions should be used instead of what is there. That is not true here.
The current EKV features are comparable with the existing solutions. The AppKey feature you cite for secret storage is something that would be done outside the library. Meaning that Protonmail could use EKV for its storage without modifying the AppKey system. It’s a separate feature that is separate from the EKV. Thus that should not be considered a weakness of EKV.
The features you copied from the roadmap are planned features that are intended to improve security even further over other existing solutions when storing secrets to disk. I really appreciate your comments and I do hope to finish these features over the next year as well as a direct iOS/Android interface to the library. I am also looking for someone who can do an audit and would appreciate any pointers to folks who can do that work.
We are releasing Janus, a mobile threat intelligence platform http://appscan.io. Find intro doc at http://doc.appscan.io/en/. Our team is now conducting security research on mobile apps. If you need security auditing for your apps, please contact us.