We’re very excited and pleased to announce that we’ve begun beta testing Codebook 4, the next major version release of our password manager! This upgrade has been in the works for some time, due to the critical nature of some of the features being updated, specifically the encryption and sync features. In addition, we’re pleased to have a great group of beta testers signed up, outside of our usual beta channels. This post will discuss what we’re up to and how we’re going about it.

The Beta Testers

Back towards the beginning of the year we put out several calls for folks who wanted to beta test Codebook 4 specifically, as opposed to people who get regular beta updates from us in TestFlight for maintenance releases, for example. Codebook 4 will not sync with Codebook 3, requiring the user to update on all platforms, so we didn’t want to surprise anybody with such a big update.

We’ve broken the list of testers up into two groups. We just sent out the information to download Codebook 4 to Group 1 on Monday. If you signed up and haven’t heard from us yet it’s because you’re in Group 2, we haven’t snubbed you!

So far, so good, no major issues have been reported as of yet, knock on wood. We plan to collect feedback for the next two weeks while we make adjustments as necessary (a few minor issues have already been caught and fixed). Then, assuming all is still going well, we’ll send out download information to Group 2 to get a fresh perspective and expand the number of testers.

If you’d like to join the Codebook 4 beta test, there’s still time to sign up! We’ll be taking our time, and the more people who try out the new Sync system, the sooner we’ll identify and work out any remaining kinks.

Distribution

We’re distributing the iOS beta through Apple’s TestFlight service, which requires you to have an Apple ID and the TestFlight app installed on your iOS device. Similarly, Android betas are being distributed through the Google Play store and require a Google account to access. The macOS and Windows betas are being made available via direct download over HTTPS (as always, the installer packages are signed).

Staying in Touch

We’re using Campaign Monitor to email Groups 1 and 2 updates about beta testing directly. However, we’ll also be posting further information (like the Codebook 4 Beta Release Notes) in the Beta section of our discussion forum. Accessing this requires an account on Discuss, and a quick message to us to add your username to the Beta section. Beta testers are encouraged to send us feedback as soon as they can, either by emailing us directly, or posting to the Beta discussion forum.

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.