I. 概要
暗号化は最も一般的なデータ セキュリティ保護テクノロジであり、データ ライフ サイクルのすべての段階で適用されます。アプリケーションのシナリオと技術的な実装に関しては、暗号化オブジェクトの寸法、ユーザーが認識するかどうか、暗号化アルゴリズムに応じてさまざまな分類と対応するソリューションがあり、Windows、Linux、Android などの主流のオペレーティング システムで広く使用されています。
この記事は、Linux カーネル セキュリティ テクノロジ シリーズの第 2 部であり、主にディスク暗号化テクノロジと主流の実装ソリューションを紹介します。まず、アプリケーション シナリオ、脅威モデル、技術的ルート分類などを含むディスク暗号化テクノロジの背景を紹介し、次にディスク暗号化の 2 つの実装スキーム、つまりフルディスク暗号化 FDE とファイル システム暗号化 FBE を紹介します。 Linux システムとカーネルの主流の FBE 実装スキーム; 最後に、eCryptfs を例として取り上げ、その原理と応用を詳細に分析します。
Linux カーネル セキュリティ テクノロジー シリーズ パート 1: Linux カーネル セキュリティ テクノロジー - オープンソースの進化のレビュー
1.1. 説明
データには、ライフサイクルの各段階で、偽造、改ざん、漏洩、不正アクセス、DoS によるアクセス拒否など、多くの情報セキュリティ リスクが存在します。一部の成熟したソリューションは、通常、複数のリスクを解決し、軽減できます。この記事では主にディスク暗号化テクノロジを紹介し、主にデータ漏洩と機密性の側面に焦点を当てており、その他のリスクと保護の側面についてはあまり取り上げていません。
1.2. 略語と用語
この文書で使用される略語と用語については、以下で説明します。
2. 技術的背景の紹介
2.1. 脅威モデル
データ ライフサイクル管理 (データ ライフサイクル管理) では、通常、データを生成、保管、使用、共有、破壊、アーカイブのいくつかの段階に分割します。情報セキュリティ保護の観点から、データは通常、使用中のデータ、移動中/転送中のデータ、保存中のデータの 3 つの状態に分類されます。
Data in Motion/Transit、つまりデータ送信シナリオは、最も成熟したテクノロジー開発による最もよく知られたセキュリティ シナリオです。たとえば、SSL/TLS プロトコルに基づく Https アプリケーション、SSH プロトコルに基づく SCP/SFTP アプリケーションなどです。これらのテクノロジーによるデータのセキュリティ保護には、暗号化された送信だけでなく、双方向の ID 認証と完全性保護も含まれます。
Data in Use、つまりデータ使用シナリオ。このとき、データはシステムの DRAM、キャッシュ、CPU レジスタにキャッシュされ、通常はプレーンテキストで存在します。ただし、一部の高度なセキュリティのシナリオでは、サイドチャネル攻撃 (DRAM 内のキー情報を取得するためのコールド ブート攻撃など) を防ぐために、業界は Full Memory Encryption フル メモリ暗号化テクノロジも提案しています。IntelのTME（Total Memory Encryption）、AMDのSME（Secure Memory Encryption）など。FME が有効な場合、すべてのシステム DRAM データが暗号化されて保存されます。CPU は、特定のハードウェア暗号化および復号化エンジンを通じてデータの読み取りおよび書き込み時に復号化および暗号化操作を実行します。暗号化および復号化キーは、通常、起動するたびに一意に生成されます。
保存データ、つまりデータ (永続) ストレージ シナリオ。このとき、データは非アクティブ状態に属し、使用されず、ディスクなどの不揮発性媒体に保存されます。セキュリティリスクとしては、主に不正アクセスや機器紛失によるデータ漏洩などが挙げられます。一般的な保護方法には、物理/ネットワーク レベルでの分離とアクセス制御、およびデータ (ディスク) 暗号化が含まれます。暗号化されたストレージ ディスク データの場合、デバイス (PC/携帯電話など) を紛失し、攻撃者がハードディスクやフラッシュ デバイスを取り外したとしても、デバイス内の暗号文を読み取ることしかできず、キー データの機密性が確保されます。
2.2. テクニカルルート
暗号化は、データ漏洩を防止し、機密性を確保するための効果的な手段です。さまざまな側面に従って、暗号化テクノロジ/スキームはさまざまなカテゴリに分類できます。それらは次のように簡単に要約されます。
いくつかの次元は相互に排他的ではなく、ソリューションは通常、複数の機能/テクノロジーに準拠/採用することに注意してください。たとえば、この記事で紹介するディスク暗号化技術である Disk Encryption は、一般にディスクまたはファイル システム全体を暗号化しますが、データの状態の観点からは Data at Res Encryption 技術に属し、データの状態からは透過的な暗号化技術に属します。ユーザーの知覚の観点から見ると、暗号化アルゴリズムの側面からは透過的暗号化技術に属し、対称暗号化が使用されます。
以下では、いくつかの分類に含まれる技術概念/用語を簡単に紹介しますが、詳細については、記事末尾の参考リンクおよび後続の章の詳細な分析を参照してください。
保存データの暗号化
データを静止状態で暗号化した状態に保つテクノロジーについては、https://wiki.archlinux.org/title/Data-at-rest_encryption の説明を参照してください。暗号化されたオブジェクトは通常、ディスク (ブロック デバイス)、ファイル システム ディレクトリ、および暗号化と復号化のプロセスは透過的な暗号化テクノロジーです。
透過的な暗号化
透過的暗号化。リアルタイム暗号化またはオンザフライ暗号化とも呼ばれます。ユーザーが介入することなく、使用中に自動的にデータの暗号化と復号が行われるのが特徴だ。
3. ディスク暗号化技術
前のセクションで説明したように、ディスク暗号化の目標は、保存データの機密性を保護することです。暗号化の対象は、リアルタイムの暗号化および復号化テクノロジを使用して、ディスク/パーティションまたはファイル システム全体です。詳細については、https://en.wikipedia.org/wiki/Disk_encryption を参照してください。
ディスク暗号化テクノロジは、暗号化オブジェクトの次元、ソフトウェアとハードウェアの実装、ファイル システムの特性からさまざまなカテゴリに分類することもできます。まず、暗号化オブジェクトがディスク全体であるかファイル システムであるかに応じて、フルディスク暗号化とファイルシステム レベルの暗号化 (ファイル ベースの暗号化とも呼ばれます) の 2 つのカテゴリに分類できます。
3.1、FDE
フルディスク暗号化は、ハードウェアとソフトウェアの 2 つの方法で実装できます。この 2 つの基本原理は似ていますが、違いは、暗号化および復号化機能の本体がソフトウェアであるかハードウェアであるかという点です。また、ソフトウェア ソリューションでは一般にハード ディスク全体を実際に暗号化することはできません (ブート パーティションは暗号化されません)。一方、ハードウェア ソリューションのハードウェア ベースのフルディスク暗号化には、ハードディスク全体の暗号化機能があります。ハードウェア FDE ソリューション製品は、主に自己暗号化ドライブ自己暗号化ハードディスクであり、一般にストレージ デバイス メーカーやセキュリティ メーカーから提供されています。ハードウェア FDE ソリューションと SED 製品テクノロジについては、記事の最後にあるハードウェア ベースのフル ディスク暗号化と SED 関連リンクを参照してください。
ハードウェアとソフトウェアの FDE ソリューションの中核となる原則とプロセスは類似しており、統一された抽象的な説明は次のとおりです。
FDE の初期化または作成時に、ディスク データ暗号化 DEK (ユーザーが認識しないディスク暗号化キー) がランダムに生成され、ユーザーは DEK を暗号化して保護するために AK (認証キー) を入力する必要があります。使用する場合、ユーザーは AK を入力して DEK を検証および復号化する必要があります。その後、オペレーティング システムは DEK を使用して、暗号化されたディスク上のデータにアクセスできます。以下の図はソフトウェア FDE の説明です。
ユーザーが AK を入力して確認できるように UI を表示するには、特定のプログラムを実行する必要があるため、スタートアップ コードのこの部分は暗号化できません。したがって、Pre-Boot Authentication と PBA 環境の概念が導入されます。
PBA の実装に関しては、ハードウェア FDE ソリューション (SED 製品) は通常、工場出荷時にプレブート環境 (小規模な OS またはブートローダー) に組み込まれており、電源投入後、最初にプレブート プログラムが実行され、 AK が検証され、通常のロードとブートが実行されます。
ソフトウェア FDE ソリューションはブート パーティションを暗号化しない方法を採用しており、通常は初期 RAM ディスクに PBA 機能を統合して検証を完了します。
ソフトウェア FDE ソリューションには長い開発の歴史があり、主流の OS 環境には、Windows の BitLocker、Apple OS/X の FileVault、Linux/UNIX エコロジーの dm-crypt/LUKS など、成熟したソリューションがあります。さらに、TrueCrypt、VeraCrypt など、オペレーティング システムに依存しないサードパーティ FDE ソリューションもあります。その他のソフトウェア FDE ソリューションについては、リンク https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software と以下の図を参照してください。
Linux での dm-crypt/LUKS ソリューションに興味のある学生は、Ubuntu 仮想マシンでテストと研究を行うことができます。以下は、いくつかの主要なシナリオのスクリーンショットです。Ubuntu 仮想マシンのインストール中のディスク暗号化構成の有効化、起動中の PBA 検証、およびシステムのメイン パーティション sda5 の暗号化されたディスク タイプ (ブート パーティション sda1 が暗号化されていないことがわかります)。
3.2、FBE
ファイルベースの暗号化 (ファイルシステム レベルの暗号化とも呼ばれる)、ファイル システムの暗号化。FBE と比較して、2 番目の名前は、ファイル システムに基づくソリューションの技術的特性をよりよく反映できます。ファイル システムの特性に基づいて、一方ではそれがソフトウェアによってのみ実現可能であると判断され、他方では、さまざまなソリューションの違いは主にファイル システムに関連しています。
一般的な FBE ソリューションは、通常、スタッカブル暗号化ファイルシステムと暗号化を備えたネイティブ/汎用ファイルシステムに分かれています。
1 つ目は、既存のストレージ ソフトウェア スタックの特定の層にスタックされる暗号化および復号化ファイル システムを追加することです。たとえば、Linux カーネルは v2.6.19 からサポートされており、成熟した安定した eCryptfs ソリューションは、VFS -> ネイティブ FS 層の間に新しい暗号化および復号化ファイル システム サポートを追加することです。ユーザーモード ファイル システム FUSE に基づくさまざまなスキームもあります。
2つ目は、既存のファイルシステムに暗号化・復号化機能を導入することです。たとえば、Linux カーネルは、v4.1 以降の Ext4 ファイル システム暗号化、v4.2 以降の F2FS ファイル システム暗号化、v4.10 以降の UBIFS ファイル システム暗号化をサポートしています。カーネル内の Ext4、F2FS、および ubifs は暗号化および復号化機能モジュール、つまりカーネル fscrypt 機能を共有することに注意してください。さらに、Android システムによって導入された FBE スキーム、基礎となるカーネル実装も F2FS+fscrypt に基づいています。
業界における 2 種類以上の FBE 実装については、リンク https://en.wikipedia.org/wiki/List_of_cryptographic_file_systems と次の図を参照してください。
FDE スキームと比較して、FBE にはいくつかの注目すべき機能があります。
1. 個別のディレクトリまたはファイルの暗号化をサポートします。これは、使用および構成が便利で柔軟です。ターゲット オブジェクトのみが暗号化され、ディスク全体は暗号化されないため、システムの暗号化と復号化の負荷オーバーヘッドが軽減されます。
2. 異なる暗号化キーを使用するための異なるディレクトリ/ファイルをサポートします。
3. 暗号化されたディレクトリと暗号化されていないディレクトリが共存します (暗号化されたディレクトリと暗号化されていないファイルも、暗号化されたディレクトリに共存できます)。暗号化されたディレクトリ ファイルのバックアップ送信は柔軟で便利です。
FDE と FBE の詳細な比較、および Linux での FBE の具体的な実装については、後続の章を参照してください。
3.2、FDE 対 FBE
以前の分析から、ソフトウェア FDE と FBE はどちらもファイル システムに基づいていることがわかっており、違いは主にファイル システムの実装にあります。比較は次のとおりです。
【解説】 ソフトウェアFDE/FBEとは、主に暗号化・復号化機能の本体をソフトウェア（ファイルシステム）で実装することを意味しており、ハードウェアを使用しないわけではありません。 Crypto Engine なども高速化に使用されます。
システム全体のソフトウェアおよびハードウェア アーキテクチャの分析から、ハードウェア FDE、ソフトウェア FDE、FBE の実装とシステム ソフトウェアおよびハードウェア アーキテクチャの関係は次のように説明できます。
上図では、ディスク暗号化方式は、上位層になるほどユーザー設定の柔軟性は高くなりますが、パフォーマンスは低下し、下位層になるほど実装の柔軟性は低下しますが、透過的になります。ユーザーにとってメリットがあり、パフォーマンスが向上します。前の説明と組み合わせると、FDE スキームと FBE スキームの違いが次のように比較され、整理されます。
3.3、Linux システム FBE
Linux システム ソフトウェア アーキテクチャの観点から見ると、一般的な FDE および FBE 実装ソリューションは、以下の図に示すように分散されています。これには、dm-crypt に基づくソフトウェア FDE ソリューション、一般的なファイル システムに基づく fscrypt FBE ソリューション、VFS に基づく eCryptfs FBE ソリューションが含まれます。 FUSE に基づく多くの FBE ソリューション。
前の章では、ubuntu 仮想マシン上での dm-crypt ベースの FDE スキームの検証を簡単に紹介しました。ここでは、いくつかのソフトウェア FBE 実装スキームと、Linux システムとカーネルの特性を簡単に紹介します。次の章では、eCryptfs を取り上げます。詳細な分析用の例です。
FUSEベース
FUSE は Userspace の Filesystem、つまりユーザー モード ファイル システムです。FUSE 設計の本来の目的は、ユーザーがコンパイルされたカーネルを変更せずにユーザー空間にカスタム ファイル システムを実装できるようにすることです。FUSE アーキテクチャの原理と実装を次の図に示します。カーネル モード FUSE とユーザー モード libfuse は、アプリ –> VFS –> ユーザー ファイル システム リンクを提供し、ユーザー カスタマイズされた実装は主にユーザー レベルで行われます。ファイルシステム部分。
自然な柔軟性により、gocryptfs、EncFS、CryFS、securefs など、FUSE に基づいて FBE を実装するためのソリューションが多数あります。ただし、FUSE によって導入される複数のシステム コールとコピーのオーバーヘッドも、FUSE に基づく FBE ソリューションのパフォーマンスの低下につながります。gocryptfs プロジェクトにはスタッカブル FBE スキームの比較分析があり (リンク https://nuetzlich.net/gocryptfs/comparison/)、分析データでは FUSE FBE スキームの長所と短所も検証されました。
1 つ目は、さまざまなスタッカブル FBE ソリューションの紹介と全体的な特徴であり、量的には FUSE FBE ソリューションが大部分を占め、FUSE 以外のソリューションには eCryptfs のみが含まれます。
第 2 に、eCryptfs と比較すると、FUSE ソリューションはパフォーマンスの点で全体的に不利です。gocryptfs はシーケンシャルな読み取りと書き込みでは良好なパフォーマンスを発揮しますが、解凍、MD5 計算、ディレクトリの再帰的アクセス/削除などの他のテストでは明らかな欠点があります。これは、第 3.2 章での FDE と FBE の比較、およびソフトウェア スタックのさまざまなレベルでのディスク暗号化の効果の違いの分析と一致しています。
ファイル内容の暗号化やファイル名の暗号化など、各 FUSE FBE ソリューションの機能の詳細については、上記の比較リンクまたは各ソリューションのホームページを参照してください。ここでは詳しく紹介しません。
eCryptfs
eCryptfs は Cryptfs プロジェクトから派生したもので、初期のスキームと設計アイデアは 2005 年と 2007 年の 2 つの論文、つまり「eCryptfs: Linux 用のエンタープライズクラスの暗号化ファイルシステム」と「eCryptfs: スタックされた暗号化ファイルシステム」から来ています。eCryptfs プロジェクトはカーネル部分とユーザー モード部分に分かれており、カーネル モード コードはバージョン v2.6.19 でコミュニティ メインラインにマージされ、ユーザー モード コードはソフトウェア パッケージ ecryptfs-utils で維持されます。
上記で紹介した FUSE ソリューションと同様に、eCryptfs もスタッカブル FBE タイプに属しているため、OS の基盤となるファイル システム タイプに依存せず、さまざまなファイル システムに非常に柔軟にスタックできます。ファイル名の暗号化だけでなく、さまざまなファイルやディレクトリの暗号化もサポートしています。
現在の eCryptfs プロジェクトのオープンソース コミュニティはあまり活発ではなく、初期のユーザー/製品も移行していますが、そのスキームと設計原則は依然として詳細な調査と分析の価値があります。詳細なテスト検証と原理分析については、第 4 章を参照してください。
fscrypt
fscrypt は、カーネル ファイル システムに実装されたネイティブ FBE ソリューションです。fscrypt 機能には、カーネル状態とユーザー状態も含まれます。カーネル状態部分は、fs/crypto ディレクトリに実装されたパブリック暗号化および復号化モジュールであり、ext4、F2FS、および UBIFS ファイル システムの統合使用をサポートします。ユーザー モード ツール fscrypt は、ユーザーの便宜のためにさまざまなコマンド ライン ツールを実装します。
FBE ソリューションとして、fscrypt はディレクトリ/ファイルごとに異なるキーをサポートします。メタデータについては、fscrypt はファイル名の暗号化をサポートしますが、タイムスタンプ、サイズ、属性などの他のメタデータは暗号化されません。fscrypt の最大の用途は、Android で採用されている FBE ソリューションと F2FS ファイル システムを組み合わせて、保存データの暗号化によって携帯電話上のデータを保護することです。この記事は紙面の都合上、詳細な分析は行っておりません。
4. eCryptfの詳細
この章では、誰もがソリューションを全体的に知覚できるように、最初に簡単な使用例を使用して eCryptfs 暗号化効果の特性を検証し、参考として C バージョンの使用例も提供します。次に、テスト結果の予備分析を実行し、次に eCryptfs ソリューションのアーキテクチャ原理とコア メカニズムを詳細に分析し、最後に主要なビジネス プロセス コードを簡単に整理します。
テスト環境では Ubuntu 20.04 仮想マシンを使用します。Ubuntu システムはデフォルトで eCryptfs カーネル構成 (CONFIG_ECRYPT_FS=y) を開くため、ユーザー モード ツール ecryptfs-utils を適切にインストールするだけで済みます。
4.1. テストケース
以下の図は、スクリプト ベースのテスト ケースです。最初にテスト ディレクトリとファイル hello を作成し、次に mount -t ecryptfs メソッドを使用してテスト ディレクトリを暗号化します。コマンド ラインの対話を回避するには、コマンド ラインを介してすべての暗号化パラメータ (passwd、cipher、キー サイズなど) を渡します。 -お。暗号化後、テスト ディレクトリに新しいファイル hello_encrypted を作成します。最後に、umount はディレクトリ暗号化をキャンセルします。
最初のテスト ケースから観察できる現象/特徴は次のとおりです。
1. hello_encrypted ファイルの内容を書き込んだ後、マウントを実行します。ファイルには正しくアクセスできますが、umount 後は暗号文になります。eCryptfs は、スタックされた暗号化ファイル システムとして、マウント/アンマウント操作を通じて有効になることを説明します。この機能をオンにすると、ユーザーは読み取りおよび書き込み操作中にデータの暗号化と復号化のプロセス、つまり透過的な暗号化を認識できなくなります。
2. hello ファイルの内容はマウント前に書き込まれ、マウントの前後で正しくアクセスできます (このユースケースでは読み取り操作のみをテストしており、実際の書き込みも可能です)。eCryptfs は、ディレクトリ内での非暗号化ファイルと暗号化ファイルの混合ストレージをサポートしており、正しくアクセスできることを説明します (実際の操作は強く推奨されません。次の使用例を参照してください)。
3. 暗号化ファイル hello_encrypted の場合、長さは平文状態で 16 バイト、暗号化状態では 12KB であり、その変化は明らかです。
上記のテスト ケースをわずかに変更し、passwd の変更など、mount -t ecryptfs パラメーターを調整し、no_sig_cache=y 構成をキャンセルし、ファイル名暗号化パラメーター (ecryptfs_enable_filename_crypto=y) を有効にすると、テスト結果は次のようになります。 :
2 番目の変更されたユースケースから観察できる現象/特徴は次のとおりです。
4. ecryptfs はファイル名の暗号化をサポートします。ファイル名暗号化キー FNEK がパラメーターで指定されていないため、マウント ヘルパーはファイル コンテンツ暗号化キーを使用するように求めるプロンプト/デフォルトを表示します (つまり、図の fnek_sig と fs_sig は同じです。暗号化キーはパラメータに passwd が含まれていないこと、およびその後のアーキテクチャとキー管理の章で説明します)。
5. ecryptfs_passthrough 機能は引き続き有効になっており、暗号化されたファイルと暗号化されていないファイルの共存が可能になりますが、その効果は前の使用例とは異なります。ファイル名を暗号化してマウントすると、テストでは暗号化されていないファイル hello は表示されなくなり、umount 後は正常にアクセスできるようになりました。パススルー機能は、2 つの使用例で異なるパラメーターの下で異なる動作をするため、実際のアプリケーションでは、暗号化されたファイルと暗号化されていないファイルを同じディレクトリに保存することは強く推奨されません。
別の現象/機能を追加します。
6. アンマウント後、暗号化されたテスト ディレクトリは、保存およびバックアップのために他のホスト/ネットワークに直接転送/コピーできます。他のユーザーがそれを使用する場合、同じパラメータを使用して再マウントするだけで正しくアクセスできます。
ユースケースにおける mount -t ecryptfs コマンドの関連パラメータを以下にまとめると、詳細は man ecryptfs のマニュアルと ecryptfs-utils のソースコードを参照してください。一部のパラメータと意味については、アーキテクチャ分析とキー管理の章で詳しく説明します。
なお、上記のスクリプトユースケースの機能は、基本的にはecryptfs-utilsが提供するインターフェースAPIを利用して実現できます。以下は、作成者によって実装された C ユースケースの部分的なコード リファレンスです。C プログラムは ecryptfs.h ヘッダー ファイルを参照し、関連する API 関数を使用する必要があるため、libecryptfs-dev ソフトウェア パッケージをインストールし、コンパイル時に -lecryptfs を指定して対応するライブラリ ファイルをリンクする必要があります。
C の使用例では、マウント操作の前に ecryptfs_add_passphrase_key_to_keyring を実行する必要があることに注意してください。つまり、パスフレーズが対応するキー (実際には FEKEK、後の分析を参照) に変換され、カーネル キーリングと key_sig に登録されます。その後の使用のためにユーザーに返されます。
4.2. 結果の分析
前節のテスト結果から、関連するテスト項目と eCryptfs の効果特性を以下の表にまとめますが、説明が必要な点は次の 2 点です。
1 つは、テスト ディレクトリを繰り返しマウントし、毎回異なるキーを使用することによる影響です。以下の図の使用例から、対応する passwd マウントの後に生成されたファイルは、マウント コンテキストでのみ正しくアクセスできます。この使用例は単なる例であり、ファイル名の暗号化などのパラメータ変更の場合は、状況がさらに複雑かつ不確実になる可能性があるため、推奨されません。
2 つ目は、暗号化後のファイル サイズの変更の問題であり、その理由は eCryptfs ソリューション自体の設計にあります。以下の図は、2006 年の設計文書「eCryptfs v0.1 Design Document」と 2007 年の論文「eCryptfs: a Stacked Cryptographic Filesystem」からの、eCryptfs の平文と暗号文のマッピング関係と論文内の説明を示しています。暗号化されたファイル形式では追加のヘッダー情報が追加される (ページを予約する) ことがわかります。ファイルの内容については、ページとブロックごとに暗号化されます。総合的なパフォーマンスを考慮して、ファイル サイズはページ単位で最小 12 KB になります。
スキーム設計とファイル形式の観点から見ると、暗号化はファイルが小さい場合は少し高価ですが、ファイルが大きくなるほど影響は小さくなります。以下の図は、それぞれ 4M、40M、400M ファイルでのテスト比較結果を示していますが、ソース ファイルのサイズに関係なく、暗号化されたファイルのサイズは 8KB 増加します。
4.3. 全体構造
eCryptfs の全体的なアーキテクチャを次の図に示します。主にカーネル モジュール eCryptfs とユーザー モード プロセス ecryptfsd が含まれます。ecryptfsd プロセスは、キー タイプが openssl モードの場合にのみ必要であり、パスフレーズ モード (上記のテスト ケースなど) が使用される場合には必要ありません。ecryptfs-utils は、ユーザー モード補助ツールまたは C インターフェイス プログラミング リファレンスとして使用できます。
アプリケーション プログラムがシステム コールを開始すると、まず VFS を通過し、ディレクトリ タイプが eCryptfs であると判断すると、eCryptfs モジュールの登録関数を呼び出します。その後、eCryptfs はマウント セッションに保存されたキー署名パラメータに従ってキーリングから対応するキー (FEKEK) を見つけ、暗号化モジュール API を呼び出してファイルの暗号化と復号化を完了します。
eCryptfs のコア暗号化および復号化メカニズムを次の図に示します。主な機能は次のように要約されます。
1. FEK (File Encryption Key) は一意です。つまり、各ファイルの暗号化キーは異なり、ファイルの作成時に生成される乱数です。
2. 各ファイルの FEK は、FEKEK (File Encryption Key Encryption Key) によって暗号化されて保護されており、暗号化後の FEK は EFEK (Encrypted File Encryption Key) と呼ばれ、eCryptfs 暗号化ファイルのヘッダー情報 (たとえば、前述のページ 0 領域と同様）。
3. パスフレーズ モードでは、ユーザーの passphrase_passwd に基づいて FEKEK が導出されます。導出方法はハッシュ計算です (コード分析セクションを参照)。
4. ファイルの内容は、ページ サイズ (データ範囲) に応じてブロック単位で暗号化されます。
コアプロセスは次のように簡単に説明できます。
1. 新しいファイルが暗号化されると、乱数 FEK が生成され、ファイルの内容が暗号化されてブロックに保存されます。ユーザーが渡した key_sig パラメーターに従ってキーリングから対応する FEKEK を検索し、FEKEK で FEK を暗号化し、EFEK を生成してファイル ヘッダーに保存します。
2. 復号化するときは、key_sig を使用して FEKEK を検索し、FEKEK を使用して EFEK を復号化して FEK を取得し、FEK を使用してファイルのコンテンツを復号化します。
4.4. 鍵の管理
前のセクションから、eCryptfs のコア メカニズムには主に 2 つの KEY、つまり FEKEK と FEK があることがわかりました。前者はユーザー入力 passphrase_passwd に関連し、後者はファイルごとに一意の乱数です。以下では、ecryptfs-utils のソース コードを組み合わせて、これら 2 つの KEY の生成プロセスを紹介します。
1. ユーザー passphrase_passwd から FEKEK への変換
C テスト ケースから、opt パラメーターには key_sig 情報のみが含まれており、FEKEK が指定されていないことがわかります。また、マウント操作の前提条件は、対応するキー (FEKEK) がカーネル キーリングに追加されていることです。スクリプト コマンドは実際には、キーリングの追加操作の完了を (暗黙的に) 支援するマウント ヘルパーです。
コア関数は C ユースケースで呼び出される ecryptfs_add_passphrase_key_to_key_ring であり、この関数の呼び出し関係は次のとおりです。
まず、ecryptfs_generate_passphrase_auth_tok は、ユーザーが入力したパスフレーズ情報とソルト情報 (パラメーターで指定されます。以下の図に示すように、ecryptfs-utils のデフォルト値は ECRYPTFS_DEFAULT_SALT) に従って、generate_passphrase_sig 関数でハッシュ計算を実行し、結果を記録します。変数 fekek を使用して、fekek に対してハッシュ計算を実行します。ハッシュ計算の結果は passphrase_sig/auth_token_sig として記録され、その後の使用のためにユーザーに返されます (key_sig)。
generate_payload は、セッションごとに auth_tok 構造体を作成して、暗号化と復号化に関する詳細情報を記録します。
最後に、ecryptfs_add_auth_tok_to_keyring を呼び出して、対応する FEKEK、key_sig、salt、およびその他の情報をキーリングに追加します。ここまでで、passphrase_passwd から FEKEK への変換とカーネル キーリングの追加が完了しました。
2. FEKの生成プロセス
FEK はファイル コンテンツの暗号化キーとして使用され、ファイルごとに一意の乱数です。生成のタイミングは、create システム コールの段階、特にカーネル関数 ecryptfs_new_file_context および ecryptfs_generate_new_key 内です。以下のコードを参照してください。
4.5、コード分析
このセクションでは、詳細な分析は行わず、読者の参考と比較検討のために、eCryptfs ソリューションのコア プロセスのコード呼び出し関係を単純に整理してリストします。
1. Mount プロセスの主要な関数呼び出し。
mount_crypt_stat キー構造とトークン構造から、mount opt はキー署名情報のみを受け入れることがわかります。
2. Create プロセスの主要な関数呼び出し。
作成処理では新しいファイルが作成されますが、このとき各ファイルの暗号化パラメータ情報が ecryptfs_crypt_stat 構造体に格納されます。
3. オープンプロセスのキー関数呼び出し。
4. 読み取りおよび書き込みプロセスの主要な関数呼び出し。
V. まとめ
このペーパーでは、まず脅威モデル、技術的ルート、特性などのディスク暗号化技術の背景を紹介し、次にソフトウェアとハードウェアの実装、ファイル システムの実装の違いなど、暗号化対象の違いに応じた FDE と FBE の 2 つのディスク暗号化方式を紹介します。 . 比較分析を行います。最後に、Linux システムにおける典型的な FBE スキームと特性を主に紹介し、詳細な分析の例として eCryptfs を取り上げます。
読者がディスク暗号化テクノロジの概念、FDE と FBE の違い、業界における FBE ソリューションの特徴、および FBE 実装の主要テクノロジをより深く理解できるようになれば幸いです。スペースが限られているため、fscrypt などの多くの技術的な詳細やソリューションをこれ以上開発することはできません。今後の記事では、Android FBE と組み合わせた fscrypt をさらに共有できることを願っています。
参考文献:
使用中のデータ https://en.wikipedia.org/wiki/Data_in_use
転送中のデータ https://en.wikipedia.org/wiki/Data_in_transit
保存データ https://en.wikipedia.org/wiki/Data_at_rest
保存データの暗号化 https://wiki.archlinux.org/title/Data-at-rest_encryption
ディスク暗号化 https://en.wikipedia.org/wiki/Disk_encryption
フルディスク暗号化 https://en.wikipedia.org/wiki/Disk_encryption#Full_disk_encryption
起動前認証 https://en.wikipedia.org/wiki/Pre-boot_authentication
フルディスク暗号化とは https://specopssoft.com/blog/what-is-full-disk-encryption/
ハードウェアベースのフルディスク暗号化 https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption
自己暗号化ドライブ https://wiki.archlinux.org/title/Self-encrypting_drives
ディスク暗号化ソフトウェア https://en.wikipedia.org/wiki/Disk_encryption_software
ディスク暗号化ソフトウェアの比較 https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
ファイルシステムレベルの暗号化 https://en.wikipedia.org/wiki/Filesystem-level_encryption
暗号化ファイルシステムのリスト https://en.wikipedia.org/wiki/List_of_cryptographic_file_systems
ユーザー空間のファイルシステム，FUSE https://en.wikipedia.org/wiki/Filesystem_in_Userspace
FUSE ベースの FBE の比較 https://nuetzlich.net/gocryptfs/comparison/
fscrypt カーネルのドキュメント https://docs.kernel.org/filesystems/fscrypt.html
eCryptfs ドキュメント https://www.ecryptfs.org/documentation
eCryptfs Linux マニュアル ページ https://linux.die.net/man/7/ecryptfs
2005.07 eCryptfs: Linux 用のエンタープライズ クラスの暗号化ファイル システム https://web.archive.org/web/20080916022422/http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf
2006.03 eCryptfs v0.1 設計ドキュメント http://www.dubeyko.com/development/FileSystems/eCryptfs/ecryptfs_design_doc_v0_1.pdf
2007.05 eCryptfs: スタックされた暗号化ファイルシステム http://www.dubeyko.com/development/FileSystems/eCryptfs/ecryptfs-article.pdf
2016.01 動的暗号化テクノロジーのレビュー、Liang Jinqian http://blog.nsfocus.net/dynamic-encryption-technology-review/
2017.09 ファイルシステムとブロック層暗号化: 理論、実践、および改善 https://www.snia.org/educational-library/file-system-and-block-layer-encryption- Theory-practice-and-improvement- 2017年
長押ししてカーネル職人WeChatをフォローしてください
Linux カーネル ブラック テクノロジー | 技術記事 | 注目のチュートリアル