Earlier this week at the DEF CON security conference, Omar Gull from from Check Point presented an attack against SQLite. The creative technique demonstrated by the security researcher uses a specially modified database to compromise an application querying the database file, facilitating Remote Code Execution.

Since SQLCipher is based on SQLite, users are naturally concerned with whether this also affects SQLCipher. The following comments address these concerns:

1. The underlying issue exploited in the attack using FTS3 was patched by the SQLite team in 3.28.0. As a result, the same fix is present in SQLCipher 4.2.0, since it is based on 3.28.0. We strongly recommend that all applications upgrade to SQLCipher 4.2.0 to take advantage of the latest security updates, especially if an applicaiton interacts with non-encrypted databases using SQLCipher.
2. The standard mode of operation for encrypted SQLCipher databases provides some built-in protection against this attack vector, even if an earlier version of SQLCipher is used. This class of vulnerability takes advantage of the fact that standard SQLite databases can be manipulated prior to use by a target application. By directly modifying the sqlite_master table, the target application is “tricked” into executing the attacker’s statements. Using SQLCipher encryption directly mitigates that risk because SQLCipher databases can’t be manipulated without the database key. Valid database content can’t be created without the key and any attempts to modify the database otherwise would invalidate the per-page signatures (MACs) stored as part of the database. In other words, SQLCipher provides a way for applications to ensure that encrypted databases has not been manipulated externally to inject malicious code.

As a result, most applications using SQLCipher encrypted databases should be secure against this sort of vulnerability even when an attacker has access to the database file, provided that the attacker does not also know the corresponding database key material.

This has been cross-posted from our discussion forum.

There are two options that applications commonly use to manage key material when using SQLCipher:

1. Password or Passphrase - An example of ths type of integration is an application that requires the user to enter password or PIN number with a device keyboard, and the input is provided to SQLCipher for use as a key. SQLCipher includes special functionality to derive an encryption key from user provided input.
2. Raw or “Random” Key Material - In some advanced situations an application might generate random key material for a database (i.e. random bytes) which is separately secured by an enclave, key store, hardware security module, or otherwise encrypted. The application provides this random data to SQLCipher for use as a key.

In the interest of interoperability it is strongly recommended that any key material passed to SQLCipher consist solely of valid UTF-8 encoded strings that do not include zero byte values internally. This recommendation applies universally to all keys, whether random or not, and no matter how they are supplied (e.g. sqlite3_key, PRAGMA key, or any wrapping API).

With Option 1, it is a given that the key material will be a string value because it is entered by the user. However, Option 2 requires additional consideraton on the part of the developer. While it may be technically possible to generate random bytes in code and coerce them to behave like strings in some languages, it must be avoided due to the potential for unpredictable behavior and compatibility problems, for instance:

1. diffuculty opening a database using certain tools with such a key (e.g. one can’t provide raw binary values via SQL statements (e.g. PRAGMA or ATTACH), the SQLCipher command line shell, database GUI application, or using certain programming languages)
2. corruption of key material due to encoding or decoding operations that encounter invalid code pages
3. truncation of key material passed through languages or APIs rely on a NULL terminators when zero-bytes are present in the random key material

For these reasons, SQLCipher has standardized on Raw Key syntax since it’s initial release. It is the supported method for using binary data directly as key material. A Raw Key is simply a fixed length byte array with a standardized BLOB literal representation and hexadecimal encoding that is interpreted by SQLCipher and used directly as an encryption key. Using this feature an application can safely generate random key material and instruct SQLCipher to use the exact 32-byte (256 bits) sequence as a key, for examle:

PRAGMA key = "x'2DD29CA851E7B56E4697B0E1F08507293D761A05CE4D1B628663F411A8086D99'";

Using this approach it is the calling application’s responsibility to ensure that the data provided is a 64-character hex string in BLOB format (i.e. x'hexvalue'). As an added benefit, SQLCipher will bypass the KDF when a Raw Key is provided which can result in a substantial performance enhancement when opening databases.

If it is not possible for an application to use the Raw Key syntax for some reason, it is still the application’s responsibility to guarantee that the passphrase or key material consists of a valid UTF-8 string. This can be accomplished either by converting a random byte to a UTF-8-safe string using an intermediate encoding like Base64, or by constructing the random key from a set of valid UTF-8 code pages.

Finally, for applications that may already be using potentially invalid keys for some subset of users, we recommend converting key material going forward using the “rekey” feature to re-encrypt the database with a new key that is of a valid format, i.e. either a Raw key or a valid UTF-8 string.

Our password manager Codebook got a nice shout-out on the Mac Geek Gab podcast from MacObserver.com on a recent episode, our thanks to them and whomever brought us to their attention! It’s an enjoyable weekly show with a lot of great tips, and being Mac buffs ourselves it’s a nice forum for us to appear in. We work hard to make sure that Codebook is a good Mac app, conforming to the interface standards while providing features that power users expect on the platform (our eyes are peeled to this week’s exciting announcements from WWDC). You can catch the bit about Codebook 29 minutes in by listening here, or subscribing on iTunes.

SQLCipher 4.2.0, which includes the following important changes, is now available:

SQLCipher Core

• Adds a new PRAGMA cipher_integrity_check which performs an independent verification of page HMACs
• Updates SQLite baseline to upstream SQLite 3.28.0
• Improves PRAGMA cipher_migrate to handle keys containing non-terminating zero bytes

Availability

Commercial Edition - On-demand access to new releases of SQLCipher Commercial Edition are available to licensees with an active CipherCare subscriber subscription, along with private, prioritized support directly from Zetetic. CipherCare subscribers will receive a separate email notification regarding the update and can contact us to request the latest SQLCipher distribution and applicable software license codes.

SQLCipher Enterprise Program - Enterprise Program Subscription customers will receive a separate email notification about the release, and the latest SQLCipher packages and license codes will be provided directly via your organization’s private online software delivery share.

Community Edition - SQLCipher 4.2.0 in source format is directly available on GitHub. The Community Edition of SQLCipher for Android (4.2.0) is available via AAR packaging. The Community Edition of SQLCipher for iOS can be compiled from source or using CocoaPods.

SQLCipher 4.1.0 is now available, the first minor release in the 4 series of the library. This update to SQLCipher 4.1.0 includes the following important changes to the library:

SQLCipher Core

• Based on upstream SQLite 3.27.2 (current latest)
• Defer reading salt from database header until key derivation is required
• Add PRAGMA commands: cipher_settings and cipher_default_settings to query current runtime configurations
• Disable backup API for encrypted databases
• Deprecate the following PRAGMA commands: fast_kdf_iter, cipher_hmac_pgno, cipher_hmac_salt_mask
• Improve sqlcipher_export routine and restore all database flags
• Clear buffer if cipher operation fails

SQLCipher Core Details

SQLCipher now defers reading the salt from the database header until key derivation occurs. Previously, SQLCipher would read the database header when the codec was attached to determine the per database salt. Unfortunately, this could present a problem where a client library which creates multiple connections to the same database file that do not initially exist. When the first connection triggers a codec to attach, SQLCipher would attempt to read the database salt from the file, or create a salt when not present, however the salt is not written to disk at this point. Subsequently, if a secondary connection is used with the same database file, when the codec attaches and the salt value determined, a different salt value will be created if the first connection hasn’t written to disk. SQLCipher now defers determining a salt value from the database until the key derivation process occurs, this prevents the scenario above from occurring.

Two new convenience PRAGMA’s were added that target the runtime configuration settings for SQLCipher. The new PRAGMA commands cipher_settings and cipher_default_settings allow a user to read at runtime the exact configuration settings used for the current connection.

The SQLite backup API has never been supported within SQLCipher for encrypted databases due to incompatibility of the API within the context of SQLCipher. We now disable this feature when the database is encrypted. Alternatively, the sqlcipher_export(...) convenience function may be a solution for those looking for a backup of an encrypted database.

The sqlcipher_export routine has improved sourcing of table naming which addresses scenarios where the sqlite_master table are modified externally by users. The database flags are fully restored now following the completion of the export process.

Finally, we have deprecated several PRAGMA commands which will be removed in a future release of SQLCipher: fast_kdf_iter, cipher_hmac_pgno, cipher_hmac_salt_mask.

SQLCipher for Android (4.1.3)

• Add support for keying database from byte array
• Fix to release the lock when an exception is thrown

SQLCipher for .NET, Xamarin, and Windows

For client developers integrating with the popular sqlite-net client library, a fix is in place for those using the asynchronous variant of the library via SQLiteAsyncConnection which addresses a situation where creating a new database file may have caused an error in some situations.

Availability

Commercial Edition - On-demand access to new releases of SQLCipher Commercial Edition are available to licensees with an active CipherCare subscriber subscription, along with private, prioritized support directly from Zetetic. CipherCare subscribers will receive a separate email notification regarding the update and can contact us to request the latest SQLCipher distribution and applicable software license codes.

SQLCipher Enterprise Program - Enterprise Program Subscription customers will receive a separate email notification about the release, and the latest SQLCipher packages and license codes will be provided directly via your organization’s private online software delivery share.

Community Edition - SQLCipher 4.1.0 in source format is directly available on GitHub. The Community Edition of SQLCipher for Android (4.1.3) is available via AAR packaging. The Community Edition of SQLCipher for iOS can be compiled from source or using CocoaPods.