One of Ciphr’s most distinctive features is the lock screen. During activation, you are prompted for a complex password. Later, after restarting your phone, or locking the Ciphr app, you are required to enter this password to continue. As we will see, this feature does more than just prevent casual snooping.
As you may know, Ciphr allows you to send emails, text messages, attachments and other information to your contacts. Ciphr stores these messages and other data entirely on your device, and they exist on our servers only long enough to deliver them to somebody. So, we have to protect the data at two critical moments:
- when it is moving across networks from the sender’s device to your own, also known as data-in-transit
- when it is written to your device’s persistent storage (saved on your device), then becoming data-at-rest
Protection whilst in transit is provided by several end-to-end encryption schemes, which will be topics for future articles. For now, let’s focus on data-at-rest. The ideal solution is for all sensitive data to be encrypted, and for that data to only be decrypted for authorized users. However, encryption requires a key, and so the safe management of this key becomes the linchpin of the entire system.
Modern smartphones come with many software and hardware solutions to the problem of where to store keys. Apple devices, for example, have the Secure Enclave, capable of storing encryption keys and even isolating secure operations from the rest of the system. Android devices, for many years, have had a hardware-backed keystore. Many apps and even full-device encryption use these to store keys, controlling access by a simple pin, pattern, or biometric security.
However, these approaches can lead to serious issues: if a flaw is found in hardware, sometimes the issue is literally unfixable without buying a new device. For example, Checkra1n’s jailbreaking work may eventually lead to tools that can exfiltrate encryption keys and thus decrypt FileVault data, and nothing short of buying a device with a newer chip will protect users.
Software solutions do not always fare much better. Weak methods of deriving keys from user passwords can render a secure environment vulnerable to brute force attacks.
A Better Solution?
So does Ciphr’s lock feature provide better security than existing hardware or software solutions? Like most things, it depends.
Ciphr tends to lean more extremely toward security than most apps on the convenience-vs-security spectrum, but it is only a different approach, not necessarily better – it should be just another part of defense-in-depth. It is the strength of the lock feature in combination with all other security-first features that leads to better security. So, let us explore how it works.
Ciphr uses the concept of a master key: where a single top-level key is used to derive/decrypt additional subkeys that are used for specific purposes. This approach makes the security of the system easier to harden and reason about: all keys and encrypted data can be assumed secure if the master key is secure.
As savvy readers may have guessed, the password entered on the lock screen is used to derive the master key, which is then involved in encrypting and decrypting the Ciphr app’s data-at-rest. Where Ciphr differs is how that key is derived.
Many secure apps such as password managers use PBKDF2 to derive the key from a master password. The trouble with this scheme is that it requires little memory to run, and can only crunch the password into a key using a single CPU core, which puts a mobile phone at a huge disadvantage to GPU- or even ASIC-equipped attackers. PBKDF2 is also trivial to parallelize, meaning attackers can conduct hundreds of simultaneous cracking attempts even on commodity hardware. So even with complex password requirements like those of Ciphr, a brute force attack on a PBKDF2-based key may still be feasible (although expensive!).
A much better choice, and the one used by Ciphr, is Argon2. Argon2 better plays to the strengths of mobile devices in two ways:
- It can require the use of arbitrary amounts of memory during key derivation, meaning attackers must dedicate at least that much memory per brute force attempt. Modern smartphones pack in around as much RAM as a mid-range laptop, so by using a significant fraction of that RAM, a phone and more powerful computers are on more even footing.
- It can use multiple CPU cores to derive a single key, tapping into much more compute power. As single-core performance has long since plateaued, manufacturers are focused now on ramping up core counts. By using Argon2 across all cores, Ciphr’s security will continue to scale as core counts increase.
Ciphr picks parameters that balance reasonably fast unlock times against presenting a substantial challenge for attackers. New versions of Ciphr can also increase these parameters via the Additional Password Hashing setting.
Key and Data Management
So we’ve seen how Ciphr derives a strong master key from a password. Extra measures are then taken to keep this key and related data secure.
First, the master key is only kept in memory while the app is unlocked. This provides protection in situations where an attacker somehow manages to dump the memory of a device. It also means incoming messages can only be decrypted after unlocking, which sometimes leads to a flurry of activity if you haven’t unlocked for a while! Second, multiple subkeys are derived from the master key, then used with AES to encrypt practically everything that touches local storage. SQLCipher is employed, along with several other schemes for attachments and other data. While this provides comprehensive encryption of all data, it also carries a performance cost, as deleted data needs to be scrubbed, and every use of local storage must decrypt or encrypt data on-the-fly.
Server Brute-Force Protection / Composite Key
This option, also known as Composite Key, in combination with Argon2, makes brute force attacks effectively impossible. The nuts-and-bolts are coming in a future article, but it’s worth getting a high-level picture. Composite key splits the master key across your device and Ciphr’s servers. This split prevents attackers from guessing passwords against an offline device, as they need to prove possession of the correct password to get the other key component from the server. This severely limits the number of guesses per second an attacker can perform, and gives us an opportunity to block requests suspected to be part of an attack.
We have seen how many different features come together to provide comprehensive security for data-at-rest, and hopefully have given you assurance that the data stored by Ciphr is nearly uncrackable. After all, we build for security first and protecting the data stored in Ciphr is just as important as protecting the data sent in messages and emails.