Posted inDatabase

SQLCipherによるSQLiteデータの保護：デスクトップおよびモバイル向け完全暗号化ガイド

Database tutorial - IT technology blog
Database tutorial - IT technology blog

なぜローカルデータベースの暗号化が重要なのか？

デスクトップアプリケーション（Electron、Flutter、C#）やモバイルアプリ（React Native、iOS、Android）を開発する際、SQLiteファイルはユーザーのローカルストレージに直接配置されます。もし端末がマルウェアに感染したり、.dbファイルが不正に抽出された場合、DB Browser for SQLiteなどのツールを使えば、認証トークンや個人メッセージ、オフラインデータが一瞬で閲覧されてしまいます。

ローカルデータを保護するために、開発者には主に以下の3つの選択肢があります。

  • アプリケーション層での暗号化（Field-Level）: INSERT前に各文字列を独自に暗号化（AES-GCM）し、SELECT時に復号する方式。
  • OSのセキュリティ機能への依存（File System Encryption）: BitLockerやFileVault、またはiOS/Androidの標準サンドボックス機能に依存する方式。
  • SQLCipherによる完全暗号化（Full Database）: 4KBごとのデータページ、スキーマ、インデックス、さらにはWrite-Ahead Log（WAL）ファイル全体をAES-256-CBCアルゴリズムで透過的に暗号化する方式。

3つのアプローチの詳細比較

各アプローチには、パフォーマンス、実装の複雑さ、セキュリティレベルにおいて明確なトレードオフがあります。

1. フィールド単位の暗号化（Field-Level）

  • メリット: 実装が容易。Node.jsのcryptoやPythonのcryptographyなど、ランタイム標準の暗号化モジュールを直接活用できる。
  • デメリット: SQL本来の機能を失う。暗号化されたカラムにはB-treeインデックスを作成できず、WHERE email LIKE '%@gmail.com%'による部分一致検索やBETWEENによる範囲検索が使えない。また、スキーマやテーブル名は平文のまま露出する。

2. OSの暗号化機能への依存

  • メリット: 開発者が追加でコードを書く必要がなく、ネイティブレベルの高速な読み書き速度を維持できる。
  • デメリット: 防御が崩れやすい。端末がルート化／脱獄（Jailbreak）された場合や、暗号化なしでバックアップが取得された場合、DBファイルは即座に平文として抽出されてしまう。

3. SQLCipherによる完全暗号化

  • メリット: すべてのテーブル、インデックス、メタデータ、WALログファイルを保護できる。クエリ構文は100%変更不要。SQLCipher v4ではAES-256-CBCと256,000回の反復処理を行うPBKDF2-HMAC-SHA512を組み合わせ、総当たり（ブルートフォース）攻撃を強力に防御する。
  • デメリット: OpenSSL/libcryptoをバンドルする必要があるため、アプリサイズが約1.5MB〜3MB増加する。ディスクへの書き込み頻度に応じて、I/Oパフォーマンスが約5%〜15%低下する。

どのような場合にSQLCipherを採用すべきか？

SQLCipherは、クライアントサイドに機密データを保存しつつ、インデックスを活用した高速なクエリ実行が求められる場合に最適なソリューションです。Prisma、TypeORM、Room、SQLAlchemyなどのORM層を一切変更することなく、SQLiteドライバを差し替えるだけで導入可能です。

実践的なSQLCipher導入手順

ステップ 1: ドライバのインストール

PythonやNode.js/Electronの場合、パッケージマネージャ経由でSQLCipher対応パッケージをインストールします。

# Python向け
pip install sqlcipher3-wheels

# Node.js / Electron向け
npm install @journeyapps/sqlcipher

ステップ 2: 接続の確立とキー認証

接続を開いた直後、他のSQL文を実行する前に必ずPRAGMA keyコマンドを実行する必要があります。キーが指定されない場合、SQLCipherはデータの読み込みを拒否し、file is not a databaseエラーを返します。

from sqlcipher3 import dbapi2 as sqlite3

db_path = "secure_vault.db"
conn = sqlite3.connect(db_path)
cursor = conn.cursor()

# 1. DBのロック解除用パスフレーズを設定（Keychain / KeyStoreから取得し、決してハードコードしないこと）
cursor.execute("PRAGMA key = 'K#9vT!m2$xL7@pQ4_2026';")

# 2. KDF反復回数を設定（SQLCipher v4のデフォルトは256,000）
cursor.execute("PRAGMA kdf_iter = 256000;")

# 3. 通常通りデータベース操作を実行
cursor.execute("""
CREATE TABLE IF NOT EXISTS api_credentials (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    service_name TEXT UNIQUE,
    api_token TEXT NOT NULL
);
""")

cursor.execute("INSERT OR REPLACE INTO api_credentials (service_name, api_token) VALUES (?, ?)", 
               ("openai", "sk-live-sample-token-abc123xyz"))
conn.commit()

# データの検証
cursor.execute("SELECT * FROM api_credentials;")
print("読み取られたデータ:", cursor.fetchall())
conn.close()

ステップ 3: 既存データベースのSQLCipherへの移行（マイグレーション）

アプリケーションに暗号化されていない既存のlegacy.dbファイルがある場合、わざわざJSON等にエクスポートして再インポートする必要はありません。sqlcipher_exportコマンドを活用しましょう。

from sqlcipher3 import dbapi2 as sqlite3

def encrypt_plain_database(source_path, target_encrypted_path, master_key):
    # 既存のDB（非暗号化）を開く
    conn = sqlite3.connect(source_path)
    cursor = conn.cursor()
    
    # 現在のセッションに暗号化キー付きで新規DBをアタッチ
    cursor.execute(f"ATTACH DATABASE '{target_encrypted_path}' AS encrypted KEY '{master_key}';")
    
    # すべてのスキーマ、インデックス、データを新規DBに複製
    cursor.execute("SELECT sqlcipher_export('encrypted');")
    
    # DBをデタッチして接続を閉じる
    cursor.execute("DETACH DATABASE encrypted;")
    conn.close()
    print(f"[OK] {target_encrypted_path} への暗号化移行が完了しました")

encrypt_plain_database("data_plain.db", "data_encrypted.db", "SuperSecureKey_2026!")

最適化ノウハウと実践的なベストプラクティス

1. 端末上でのマスターキー管理

どれほど強力なAES-256暗号化を使用していても、ソースコード内にパスフレーズをハードコードしていれば意味がありません。攻撃者はAPKファイルの逆コンパイルやElectronアプリのアンパックによって簡単にキーを抽出できます。キーは各プラットフォームの安全な領域に保存してください。

  • iOS / macOS: Keychain Servicesにキーを保存（kSecAccessControlBiometryAnyフラグを併用してFace ID/Touch ID認証と紐付け）。
  • Android: Android Keystore SystemとEncryptedSharedPreferencesまたはSQLCipher for Androidライブラリを併用。
  • Windows: Data Protection API（DPAPI）を使用してユーザーセッションごとにマスターキーを暗号化。
  • Linux: Secret Service API（libsecret / GNOME Keyring / KWallet）と連携。

2. データエクスポート不要のマスターキー変更

ユーザーがアプリのパスワードを変更した際は、古いキーでDBを開いた後にPRAGMA rekeyを呼び出すだけです。SQLCipherがディスク上の全データベースページを直接新しいキーで再暗号化します。

PRAGMA key = 'OldMasterPassword_2025';
PRAGMA rekey = 'NewMasterPassword_2026';

3. WALモードの有効化による暗号化オーバーヘッドの抑制

4KBブロック単位での暗号化処理により、通常のSQLiteに比べて書き込みが遅くなる傾向があります。スループットを最適化するには、読み取り（readers）と書き込み（writers）が互いにブロックし合わないWrite-Ahead Logging（WAL）モードを有効化します。

PRAGMA key = 'YourMasterKey';
PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;

この設定によりディスクへのfsync()呼び出し回数が大幅に削減され、読み書きが混在する処理においてSQLCipherの全体的なパフォーマンスを通常のSQLiteに近い水準まで引き上げることができます。

Share:
Tags: