Применение расширения SQLite Encryption

SQLite Encryption Extension обеспечивает легкий способ создать, прочитать и написать зашифрованные файлы базы данных. Это может использоваться с SQLite Android bindings, чтобы добавить поддержку зашифрованной базы данных к любому приложению.

1. Сборка версии с SEE

Если вы не будете использовать предсобранный файл aar, чтобы использовать расширение SEE с SQLite Android bindings, необходимо будет построить свою версию как свой файл aar иои напрямую встроив код в приложение.

Чтобы сделать это, следуйте инструкциям выше. Но прежде, чем выполнить команду ndk-build, чтобы построить нативные библиотеки:

1. Замените файлы sqlite3.c и sqlite3.h с версией SEE (то есть, объедините sqlite3.c и see.c).
2. Исправьте файл Android.mk, чтобы раскомментировать вторую из этих двух строк:

   # If using SEE, uncomment the following:
   # LOCAL_CFLAGS += -DSQLITE_HAS_CODEC
   

2. Примечания кода приложения

2.1. Открытие зашифрованной базы данных

Лучший способ открыть существующую зашифрованную базу данных или создать новую, состоит в том, чтобы определить ключ шифрования как часть идентификатора БД в SQLite URI. Например, вместо "DatabaseName.db" в:

file:DatabaseName.db?key=secret
file:DatabaseName.db?hexkey=0123ABCD

Первая форма выше, определяя текстовый ключ, требует версии 3.19.0 SQLite.

Альтернативно, после открытия или создания зашифрованной базы данных, приложение может немедленно выполнить PRAGMA, чтобы формировать ключ шифрования. Это должно быть сделано прежде, чем любые другие методы базы данных вызывают. Например:

import org.sqlite.database.sqlite.SQLiteDatabase;

...

SQLiteDatabase db = SQLiteDatabase.openOrCreateDatabase("my.db", null);
db.execSQL("PRAGMA key = 'secretkey'");

Или, если вы используете вспомогательный класс SQLiteOpenHelper, PRAGMA должен быть первой вещью, выполненной в отзыве onConfigure(). Например:

import org.sqlite.database.sqlite.SQLiteDatabase;
import org.sqlite.database.sqlite.SQLiteHelper;

...

class MyHelper extends SQLiteOpenHelper
{
  ...
  void onConfigure(SQLiteDatabase db)
  {
    db.execSQL("PRAGMA key = 'secretkey'");
  }
  ...
}

Обратите внимание на то, что использование PRAGMA, чтобы определить ключ шифрования, как описано выше, несовместимо с режимом WAL. В Android включение режима WAL также позволяет пул связи под капотом. Это увеличивает параллелизм для многопоточных приложений, но также делает формирование ключа шифрования с SQLite, непосредственно используя небезопасное PRAGMA (поскольку Android может создать и использовать новые связи SQLite, которые не формировались никогда).

Обратитесь к документации SEE для получения дальнейшей информации относительно ключей шифрования.

2.2. Шифрование существующей базы данных или изменение ключа шифрования

Незашифрованная база данных может быть зашифрована, или ключ шифрования существующей базы данных изменен, с использованием "PRAGMA rekey" или "PRAGMA rehexkey", как описано в разделе "Using the "key" PRAGMA" в документации SEE.

В режиме WAL это страдает от той же самой проблемы как "PRAGMA key", после (пере)шифрования базы данных, это только изменяет ключ, используемый внутренне одной связью в пуле связи. То есть, когда Android пытается использовать иную связь, чтобы получить доступ к базе данных, это бросит исключение "file is encrypted or not a database" (SQLITE_NOTADB). Приложения, которые должны изменить ключ шифрования базы данных в режиме WAL, должны поэтому создать новый объект SQLiteDatabase (или SQLiteOpenHelper), чтобы получить доступ к базе данных, определяя новый ключ как часть нового идентификатора URI, немедленно после "PRAGMA rekey".

2.3. Другие отличия от не-SEE сборки

Кроме поддержки зашифрованных баз данных, SEE-сборка ведет себя по-другому еще в двух отношениях:

1. В Android если сталкиваются с повреждением базы данных или если предпринята попытка открыть файл, который не является базой данных SQLite, поведение по умолчанию состоит в том, чтобы удалить файл и создать пустой файл базы данных на его месте. В SEE-сборках поведение по умолчанию состоит в том, чтобы бросить исключение. Причина этого в том, что предоставление неправильного ключа шифрования неотличимо от открытия файла, который не является файлом базы данных. И кажется слишком опасным просто удалить файл в этом случае. Поведение по умолчанию может быть отвергнуто, используя интерфейс DatabaseErrorHandler.

2. Более ранние версии этого модуля отключали в режиме WAL пул связи в целом для SEE-сборок. Это изменено здесь как часть цикла разработки 3.19.0.