Heartbleed Security Statement for SQLCipher

Like most service and software providers, we've been working hard at Zetetic to assess the impact for our customers resulting from this week's OpenSSL security disclosure, commonly known as the OpenSSL Heartbleed bug. More specifically referred to as CVE-2014-0160, this issue has undermined the security of many internet platforms by allowing attackers to read arbitrary memory from services using the popular OpenSSL library to provide secure communications over the web. This attack can allow extraction of private keys, session data, and user information from affected websites.

We are pleased to report that SQLCipher is not directly impacted by the Heartbleed bug and subsequent disclosure. Many SQLCipher platforms, including SQLCipher for Mac OS X, Android, Xamarin.Android, ADO.NET, and Windows C++ do make extensive use of OpenSSL. However, they only utilize the low level "libcrypto" interfaces to access encryption algorithms. Specifically, SQLCipher's OpenSSL provider uses the EVP interfaces, random number generator, and PKCS5_PBKDF2_HMAC_SHA1. There is no use of OpenSSL's SSL functions, and thus nothing that would expose SQLCipher to direct attack via Heartbleed.

As a result, applications that currently rely on SQLCipher for local data security need not be concerned with Heartbleed exposure as a result of the SQLCipher library. Of course, application and service providers should be sure to carefully audit their software and infrastructure to ensure that there aren't other components or services that rely on affected versions of OpenSSL.

Finally, even though Heartbleed does not impact SQLCipher, we will include the latest OpenSSL 1.0.1g in upcoming releases of SQLCipher Commercial Edition for those customers using our commercially supported libraries to ensure dependency on the latest stable version.

We take security seriously and we are happy to communicate with customers about the details of this issue, so please don't hesitate to contact us if you have any questions.


Could SQLCipher Improve WhatsApp Security?

WhatsApp, a popular cross platform messaging application, has been in the news recently, not only for the high-profile acquisition from Facebook, but also due to security concerns. A recently published article disclosed the WhatsApp database is exposed to third-party access and is not properly secured.

The Issues

The published analysis showed that WhatsApp can store both plain-text and encrypted databases on the SD card, where they could be accessed by malicious 3rd party applications. The only protection for the database is a simple AES cipher with an easily derived key, which leads to real security issues.

Because the database is encrypted as a whole, it’s very likely that at some point during application usage, the entire database itself must exist somewhere in a plain text form in order for the SQLite library to use it. This could pose a risk if the raw data became available to an attacker.

However, the most significant issue is that WhatsApp uses easily discoverable keys on the the encrypted database. Originally a static key was used to perform the encryption on all Android installations, though WhatsApp has now been updated to use a derived key based on the name of the email account on the device. In either case, this renders the encryption key available to applications running on the device, allowing exploits.

A Note on Key Management

Key management is a difficult issue, requiring careful consideration during application design. Storing the key directly within the application, or derived solely based on data on the device, is a poor practice. Decompiling a binary to access the key or determine the process used to create it is a rather straight forward process. Once the key has been identified, the data is at risk.

We strongly recommend that applications ensure that key data is provided by the user (e.g. a user supplied password). It’s fine to combine that with with device data to generate a password, but that is an additional precaution. It’s equally important to pass the key material through a key derivation function with a salt in to generate the actual key for encryption. This helps protect against dictionary and brute force attacks.

How SQLCipher Could Help

In the case of WhatsApp, SQLCipher can help address some of the factors above by providing a more secure environment for application data. Coupled with a user-supplied password or pin, SQLCipher’s built in security controls would automatically provide key derivation and encryption using a unique per-database salt. This would ensure that even if two databases are created with the same password they will not have the same encryption key. Furthermore, using SQLCipher, data is only decrypted as needed, decreasing the risk of plain-text data exposure. Finally, using SQLCipher would provide additional security features to ensure the integrity of the data, preventing tampering and closing off other potential attack vectors.

Many companies both small and large depend on SQLCipher to protect their data across a variety of platforms. Because WhatsApp is already using SQLite to store data, converting to use SQLCipher in its place would require minimal modifications, something WhatsApp might consider.


Introducing SQLCipher for Windows Phone 8 and Windows Runtime

We are happy to announce the immediate availability of new SQLCipher Commercial Edition packages for Windows Phone 8 and Windows Runtime 8/8.1. Over the past year, interest and adoption of these platforms has increased dramatically, and SQLCipher is now able to provide a quick and easy way to secure application data. This is particularly exciting because SQLCipher libraries now offer a common, interoperable, secure database solution across major mobile, tablet, and desktop platforms.

Application Integration

The new SQLCipher libraries integrate seamlessly within Visual Studio. The client API based is on the popular sqlite-net library that provides a compact ORM and both synchronous and asynchronous interfaces. As with other integrations, applications use the high level API to manipulate data using the ORM and/or SQL, while SQLCipher works behind the scenes to manage all aspects of security, including key derivation and on-the-fly encryption and decryption of the database pages.

This architecture supports rapid implementation on both platforms, and applications that already use SQLite on Windows Phone or Windows Runtime can be converted to SQLCipher in as little as a few hours. Application using these new SQLCipher libraries for Windows Runtime can easily inter-operate and access SQLCipher databases generated on other platforms, including iOS, Android, and Windows Desktop. Furthermore, both packages include CipherCare Plus, providing prioritized and confidential email support directly from the SQLCipher development team to help integrators get up and running quickly.

Technical Details

SQLCipher for Windows Phone 8 and Windows Runtime are based on the latest version of SQLCipher 3, and take advantage of many of the newest features. For example, porting SQLCipher to run on Windows Phone 8 and Windows Runtime introduced some unique challenges. On some other platforms, SQLCipher relies on OpenSSL for underlying cryptographic operations, however, it is not easily supported on either Windows Phone 8 or Windows Runtime. Thus, the new packages take advantage of SQLCipher's pluggable crypto providers, allowing the use of LibTomCrypt's AES implementation and the Fortuna PRNG. Particular care is taken to seed the PRNG entropy pool with a rich, externally sourced cryptographically secure random data block, which is feed into the the crypto provider using the new PRAGMA cipher_add_random. Finally, databases created using SQLCipher benefit from strong default key derivation using 64,000 iterations of PBKDF2 to protect against brute force and dictionary based attacks.

Get Started

SQLCipher continues to support critical application developer requirements for easy to use data storage security. If you are interested in using SQLCipher on Windows Phone 8 or Windows Runtime, please checkout our Commercial Edition page to order now or request a trial. If you have any questions reach out to us and we'd glad to help!


SQLCipher 3.0.1 Release

This release contains a fix for the PRAGMA cipher_migrate feature we added with the 3.0.0 release. A migration issue existed when a passphrase that was longer than 64 characters, or a raw hex key was provided which caused a failure during migration. In addition to the bug fix, we've added a new PRAGMA called cipher_add_random that allows one to add externally sourced entropy to the entropy pool of your configured crypto provider. Currently there is support for this via the OpenSSL and libtomcrypt providers. The format must be provided as blob literal containing a hex sequence. An example would look like this:

sqlite> PRAGMA key = 'test';
sqlite> PRAGMA cipher_add_random = "x'deadbaad'";

Please take a look at the 3.0.1 release and let us know if you have any questions or feedback.


SQLCipher 3.0.0 Release

We're excited to announce that SQLCipher 3 is now available. This release includes several substantial improvements:

  • New default key derivation iteration count of 64,000, a 16x PBKDF2 work factor increase over the previous version
  • New PRAGMA cipher_migrate, a simple utility command to upgrade an existing 1.x or 2x. database in place
  • New sqlite3_key_v2 and sqlite3_rekey_v2 functions to allow keying and rekeying of named databases
  • New ATTACH behavior, requiring an explicit key to be passed for encrypted databases
  • Extended Raw Key/Salt feature, making it possible to set both the encryption key and database salt via a raw key specification
  • Based on SQLite, a recent stable release of SQLite

Detailed notes about the differences are available in the original SQLCipher 3 beta announcement post.

It's important to note that these key derivation changes enable a much higher level of security than previous versions though, by default, SQLCipher 3 will not open older database. To enable backwards-compatibility, it is possible to adjust settings at runtime or migrate older databases:

  1. To open an older database using SQLCipher 3, set the KDF iterations back to the old value of 4000 using PRAGMA kdf_iter = 4000
  2. To attach and export data to a new database, use the sqlcipher_export() convenience function
  3. To migrate and upgrade an existing database in place, use the new PRAGMA cipher_migrate feature

Finally, as a result of the increased key derivation count, users may notice that opening and keying a database takes longer in SQLCipher 3 than with previous release. Noticeable performance issues can almost always be avoided by ensuring that applications do not frequently open and close connections. That said, while we strongly recommend using the new default KDF settings, it is possible to set the default back to 4,000 iterations before any databases are open by calling the global PRAGMA cipher_default_kdf_iter = 4000; before invoking the SQLCipher library.

The latest source code can be found in the official project repository, and SQLCipher Commercial Edition libraries are already available in the SQLCipher Store. Commercial edition customers with CipherCare may contact us with their original order number for details on how to download an update.

Please take a look, try out the new library changes, and let us know if you have any feedback. Thanks!