SQLCipher 4.3.0, which includes the following important changes, is now available:
- Updates baseline to upstream SQLite 3.30.1
PRAGMA key now returns text result value “ok” after execution (consistent with upstream)
- Adjusts backup API so that encrypted-to-encrypted backups are permitted
- Adds a NSS crypto provider implementation
- Improves OpenSSL provider compatibility with BoringSSL
- Corrects output of
PRAGMA cipher_integrity_check on big endian platforms
- General cryptographic provider interface cleanup
- Improvements to mutex allocation and management
- Separates memory related traces to reduce verbosity of logging
- Resolves miscellaneous build warnings
- Forces error state at database pager level if SQLCipher initialization fails
SQLCipher for Android
SQLCipher for Android now includes support for utilizing Android Room. Room is a Google supported ORM library that provides an abstraction layer over direct database access. Integration instructions for the library can be found here. Thank you to Mark Murphy for providing the necessary contributions from the CWAC-SafeRoom project for this addition.
SQLCipher Commercial and Enterprise
Starting with the release of SQLCipher 4.3.0, Commercial and Enterprise packages now include exclusive features that are not available in Community Edition distributions:
The SQLCipher Value Level Encryption (VLE) and Encrypted Virtual Table features extend SQLCipher to allow partial encryption of data. Instead of applying encryption to the entire database, they selectively expose convenient SQL Functions and a Virtual Table module that operate transparently to encrypt and decrypt data. These features still use SQLCipher’s well-trusted underlying cryptographic providers. While not intended as a substitute for full-database encryption, these features can serve the needs of several classes of applications, for instance when:
- Only a subset of database information needs to be secured
- Multiple overlapping layers of security with separate keys are required (e.g. multiple keys for different data sets)
- Full-database encryption is not appropriate due to other considerations (e.g. performance, compression, etc.)
The new 4.3.0 features also include a special extension that exposes internal performance counters for SQLCipher’s encryption module. These additional statistics provide deeper insight to applications which can be useful for performance optimization and tuning purposes.
In additon to these new features, the official iOS native package for Xcode now include framework support for Mac Catalyst, which allows iPad applications to be built for and run on macOS computers.
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.3.0 in source format is directly available on GitHub. The Community Edition of SQLCipher for Android (4.3.0) is available via AAR packaging. The Community Edition of SQLCipher for iOS can be compiled from source or using CocoaPods.
Today we’re excited to announce the release of Codebook 4, the next major version update of our password manager, featuring significant enhancements in security and the Sync feature. It’s a free upgrade, and the product of nearly a year’s worth of work that lays the groundwork for many more improvements to come.
Here’s a quick listing of what’s changed in Codebook 4 on all four platforms:
- Updates the Sync feature with a new, faster, and more secure replication system
- Updates the encryption Codebook uses to SQLCipher 4 (4.3.0)
- Updates key derivation algorithm to PBKDF2-HMAC-SHA512 (previously PBKDF2-HMAC-SHA1)
- Updates key derivation to use 250,000 iterations (previously 64,000)
- Updates HMAC page protection algorithm to HMAC-SHA512 (previously HMAC-SHA1)
Note: Codebook 4 cannot sync with Codebook 3, so you’ll want to update Codebook on all your devices as soon as possible. Codebook 4 supports all the same minimum operating system versions as Codebook 3.
Downloading the Update
Codebook 4 is now available via all auto-update channels. Follow the links below on your device to install directly.
*If you purchased Codebook for macOS from the Mac App Store, use this link to view the update on your Mac.
New Sync System
Codebook 4 updates the Sync feature used to replicate your data. The highest impact change it introduces (in addition to being much faster and more secure) is the Sync Key. In Codebook 4, all sync data is encrypted with your Sync Key, a unique random key that is separate from your Master Password.
Every user that upgrades to Codebook 4 will be prompted to either 1) generate a new Sync Key, or 2) scan the Sync Key they’ve already created on another device (via QR code). To be clear, you should only generate the Sync Key once. When setting up Codebook 4 for the first time on any other device, you’ll scan that Sync Key using your device’s camera.
Here is a demonstration video we’ve prepared that will walk you through creating your Sync Key and adding it to your other devices:
Once you start using the new Sync system you should notice right away that it’s much faster than it had been in the past (after the initial syncing of data). Previously, Codebook needed to download a full copy of the remote database to perform replication and then upload it again on every sync. In Codebook 4 changes are instead replicated in much smaller encrypted updates. Each of these files is an encrypted SQLCipher 4 database using the latest security settings.
Sync Key Backup
Because the Sync Key is required to encrypt and decrypt all sync data, losing access to it would leave the user unable to decrypt any backed-up sync data. To help prevent this from ever happening we’re encouraging each user to save a physical (like in the real world) backup copy of their Sync Key in a safe place. There are two options for doing this: printing an encrypted QR code, and writing down a Word List.
The option to print is most convenient, but may not be ideal if you don’t have a secure or direct connection to the printer in question. The Word List serves as an alternative to printing. Because the word list is an unencrypted representation of your Sync Key you should not photograph or screenshot it, it really is meant to be written down!
Having a physical backup of your Sync Key can come in handy if you ever have a need to recover from data loss at some point in the future.
Update Cloud Services
After you setup your Sync Key in Codebook 4, Codebook will offer to update any cloud services you sync with (i.e. Google Drive and Dropbox). When it does this it upgrades the data stored on the service to the encryption and format used by the new Sync system. It also deletes the
strip.db file previously stored on the service by Codebook 3. You may wish to copy this file or rename it to serve as a backup of your Codebook 3 data before syncing Codebook 4 with the cloud service. The first time you sync Codebook 4 with a Dropbox or Google Drive account it will check for a Codebook 3 database and attempt to upgrade it.
Codebook 4 encrypts your passwords and other data with the latest version of SQLCipher 4. This means we’re using much stronger security settings, taking better advantage of the computing power available on modern mobile and desktop devices. Among these:
- PBKDF2-HMAC-SHA512 is the new KDF algorithm (previously PBKDF2-HMAC-SHA1)
- HMAC-SHA512 is now used for per-page HMACs (previously HMAC-SHA1)
- KDF iteration count has been increased to 256,000 from 64,000
- Improved memory sanitization features
- Significant performance improvements for common use cases on platforms including iOS, Android, and Windows
Codebook’s encryption is stronger and faster than ever.
Desktop Backups feature removed
There is no longer a Backups feature and view in Codebook for macOS and Windows. We recommend that any users relying on this feature look to other common commercial and open-source techniques for regularly making a backup copy of the local database file,
Delete Obsolete Backups prompt
Because the Backups feature has been removed, it would be prudent to delete any of the old backup files stored locally on the desktop, which use an older version of the encryption used in Codebook 4. Thus, Codebook 4 for macOS and Windows will prompt you to inquire if it can delete these files.
Sync Operation feature removed
The Sync menus in Codebook 4 no longer provide an Operation setting that allows the user to change the “direction” of a sync to be an Overwrite or a Restore. This feature has been obsoleted by the new Sync system and is removed. If you think you do need this anyway, please get in touch, we should be able to help.
Help Buttons and Documentation
We’ve put a lot of work into the new documentation for Codebook 4 and updating our existing documentation. The documentation index got a big overhaul, as did the style we use on all the Help pages. We’ve included a platform selector on pages with multiple sets of steps for each platform, and included lots of new short demonstration videos. Accordingly, many of the new interfaces and prompts in Codebook 4 feature a Help button that will launch a URL to documentation on our website.
Password Review on macOS
The Password Review feature in Codebook for macOS has been updated to work on-demand, in addition to while you edit a password. Right-click or control-click on a password field and select the option “Review Password”. Any Weakness Warnings will be displayed as well.
The default toolbar button set has been given a rearrangment in Codebook for macOS. We think this is a nice improvement over the previous layout. However, you can set it back to the way it was before, or to another configuration! Right-click (or control-click) on the Toolbar and select Customize Toolbar to change the buttons displayed.
Updated Getting Started UI on iOS
There is an improved interface for first-time setup in Codebook for iOS, which is used frequently by existing users setting up a new device, as well as new users of the app. This should make it a lot easier to get started quickly, and it’s an approach we’re adopting across all four apps.
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.
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:
- 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.
- 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:
- 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.
- 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.
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:
- 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)
- corruption of key material due to encoding or decoding operations that encounter invalid code pages
- 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.