4.9. 暗号化
4.9.1. LUKS ディスクの暗号化の使用
Linux Unified Key Setup-on-disk-format (または LUKS) を使用すると、Linux コンピューター上のパーティションを暗号化できます。特に、モバイル PC やリムーバブルメディアに関しては特に重要です。LUKS を使用すれば、複数のユーザー鍵が、パーティションのバルク暗号化に使用されるマスター鍵を複号できるようになります。
LUKS の概要
- LUKS の機能
- LUKS は、ブロックデバイス全体を暗号化するため、脱着可能なストレージメディアやノート PC のディスクドライブといった、モバイルデバイスのコンテンツの保護に適しています。
- 暗号化されたブロックデバイスの基本的な内容は任意です。これにより、スワップ デバイスの暗号化に役立ちます。また、とりわけデータストレージ用にフォーマットしたブロックデバイスを使用する特定のデータベースに関しても有用です。
- LUKS は、既存のデバイスマッパーのカーネルサブシステムを使用します。
- LUKS は、パラフレーズの強化を提供し、辞書攻撃から保護します。
- LUKS デバイスには複数のキースロットが含まれ、ユーザーはこれを使用してバックアップキーやパスフレーズを追加できます。
- LUKS が 行わない こと
- LUKS は、多くのユーザー (8 人以上) が同じデバイスへの個別のアクセスキーを持つことを必要とするシナリオには適していません。
- LUKS は、ファイルレベルの暗号化を必要とするアプリケーションには適していません。
重要
LUKS などのディスク暗号化ソリューションは、システムの停止時にしかデータを保護しません。システムの電源がオンになり、LUKS がディスクを復号すると、そのディスクのファイルは、通常、そのファイルにアクセスできるすべてのユーザーが使用できます。
4.9.1.1. Red Hat Enterprise Linux における LUKS の実装
Red Hat Enterprise Linux 7 は LUKS を利用してファイルシステム暗号化を実行します。デフォルトではインストール時に、ファイルシステムを暗号化するオプションが指定されていません。ハードドライブを暗号化するオプションを選択すると、コンピューターを起動するたびに尋ねられるパスフレーズの入力を求められます。このパスフレーズは、あなたのパーティションを復号化するために使用されるバルク暗号化キーの "ロックを解除" します。デフォルトのパーティションテーブルの変更を選択すると、暗号化するパーティションを選択できます。この設定は、パーティションテーブル設定で行われます。
LUKS に使用されるデフォルトの暗号( cryptsetup --helpを参照)は aes-cbc-essiv:sha256 (ESSIV - Encrypted Salt-Sector Initialization Vector)です。インストールプログラム Anaconda は、デフォルトで XTS モード(aes-xts-plain64)を使用することに注意してください。LUKS のデフォルトの鍵サイズは 256 ビットです。Anaconda を使用した LUKS のデフォルトの鍵サイズ(XTS モード)は 512 ビットです。利用可能な暗号は以下のとおりです。
- AES (Advanced Encryption Standard) - FIPS PUB 197
- Twofish (128 ビットブロック暗号)
- Serpent
- cast5 - RFC 2144
- cast6 - RFC 2612
4.9.1.2. 手動でのディレクトリーの暗号化
警告
この手順を実行すると、暗号化するパーティションにあるすべてのデータが削除されます。すべての情報を失うことになります。この手順を開始する前に、必ずデータを外部ソースにバックアップしてください。
- root でシェルプロンプトに次のように入力し、ランレベル 1 に入ります。
telinit 1 - 既存の
/homeをアンマウントします。umount /home - 前の手順のコマンドが失敗した場合は、fuser を使用して、
/homeを占有しているプロセスを見つけ、それらを強制終了します。fuser -mvk /home /homeがマウントされていないことを確認します。grep home /proc/mounts- パーティションをランダムなデータで埋めます。
shred -v --iterations=1 /dev/VG00/LV_homeこのコマンドは、デバイスのシーケンシャル書き込み速度で進行し、完了するまでに時間がかかる場合があります。使用済みのデバイスに暗号化されていないデータが残らないようにし、ランダムなデータだけでなく、暗号化されたデータを含むデバイスの部分を難読化することが重要なステップとなります。 - パーティションを初期化します。
cryptsetup --verbose --verify-passphrase luksFormat /dev/VG00/LV_home - 新たに暗号化したデバイスを開きます。
cryptsetup luksOpen /dev/VG00/LV_home home - デバイスがあることを確認します。
ls -l /dev/mapper | grep home - ファイルシステムを作成します。
mkfs.ext3 /dev/mapper/home - ファイルシステムをマウントします。
mount /dev/mapper/home /home - ファイルシステムが表示されていることを確認します。
df -h | grep home - 以下を
/etc/crypttabファイルに追加します。home /dev/VG00/LV_home none
/etc/fstabファイルを編集し、/homeの古いエントリーを削除し、以下の行を追加します。/dev/mapper/home /home ext3 defaults 1 2
- SELinux のセキュリティーコンテキストをデフォルトに戻します。
/sbin/restorecon -v -R /home - マシンを再起動します。
shutdown -r now /etc/crypttabのエントリーにより、コンピューターが起動時にluksのパスフレーズを要求します。- root でログインして、バックアップを復元してください。
これで、コンピューターの電源がオフのときにすべてのデータを安全に保管するための暗号化されたパーティションができました。
4.9.1.3. 既存のデバイスへの新しいパスフレーズの追加
既存のデバイスに新しいパスフレーズを追加するには、次のコマンドを使用します。
cryptsetup luksAddKey device
認証のために既存のパスフレーズのいずれかを入力するように求められた後、新しいパスフレーズを入力するように求められます。
4.9.1.4. 既存のデバイスからのパスフレーズ削除
既存のデバイスからパスフレーズを削除するには、次のコマンドを使用します。
cryptsetup luksRemoveKey device
削除するパスフレーズの入力を求められ、次に認証用にに残りのパスフレーズのいずれかを入力するように求められます。
4.9.1.5. Anaconda での暗号化したブロックデバイスの作成
システムインストール時に、暗号化されたデバイスを作成することができます。これにより、暗号化されたパーティションを持つシステムを簡単に設定することができます。
ブロックデバイスの暗号化を有効にするには、自動パーティション設定を選択する際に Encrypt System チェックボックスをオンにするか、個別のパーティション、ソフトウェア RAID アレイ、または論理ボリュームを作成するときに Encrypt チェックボックスをオンにします。パーティション設定が完了すると、暗号化用のパスフレーズの入力が求められます。このパスフレーズは、暗号化されたデバイスにアクセスする際に必要となります。既存の LUKS デバイスがあり、インストール時に正しいパスフレーズを入力した場合、パスフレーズ入力ダイアログにもチェックボックスが表示されます。このチェックボックスをオンにすると、既存の各暗号化ブロックデバイスの使用可能なスロットに、新しいパスフレーズを追加する必要があることを意味します。
注記
自動パーティション設定 画面の システムの暗号化 チェックボックスを選択し、カスタムレイアウトの作成 を選択しても、ブロックデバイスは自動的に暗号化されません。
注記
キックスタート を使用して、新しい暗号化ブロックデバイスごとに個別のパスフレーズを設定できます。
4.9.1.6. 関連情報
LUKS または Red Hat Enterprise Linux 7 でのハードドライブの暗号化に関する詳細情報については、以下のリンクのいずれかを参照してください。
4.9.2. GPG 鍵の作成
GPG は、あなた自身を識別し、あなたの知らない人とのコミュニケーションを含むあなたのコミュニケーションを認証するために使用されます。GPG を使用すると、GPG で署名された電子メールを読んでいる人は誰でも、その信頼性を確認できます。言い換えれば、GPG は、あなたが署名した通信が実際にあなたからのものであることを合理的に確信できるようにします。GPG は、サードパーティーがコードを変更したり、会話を傍受したり、メッセージを変更したりすることを阻止できるので便利です。
4.9.2.1. GNOME での GPG 鍵の作成
GNOME で GPG キーを作成するには、以下の手順に従います。
- Seahorse ユーティリティーをインストールします。これにより、GPG キーの管理が容易になります。
~]# yum install seahorse - キーを作成するには、
メニューから を選択します。これにより、アプリケーションの Seahorse が起動します。 - メニューから を選択してから PGP Key を選択します。次に、 をクリックします。
- フルネーム、メールアドレス、および自身に関して説明するオプションのコメントを入力します (例:John C. Smith、
jsmith@example.com、ソフトウェアエンジニア)。 をクリックします。キーのパスフレーズを要求するダイアログが表示されます。強力かつ覚えやすいパスフレーズを選んでください。 をクリックすると、キーが作成されます。
警告
パスフレーズを忘れると、データの暗号解除ができなくなります。
GPG キー ID を見つけるには、新しく作成された鍵の横にある Key ID 列を確認します。ほとんどの場合、キー ID を求められた場合は、
0x 6789ABCD のように、キー ID の前に 0x を付けます。秘密鍵のバックアップを取り、安全な場所に保管してください。
4.9.2.2. KDE での GPG 鍵の作成
KDE で GPG キーを作成するには、以下の手順に従います。
- メインメニューから
を選択して、KGpg プログラムを起動します。以前に KGpg を使用したことがない場合、プログラムは独自の GPG キーペアを作成するプロセスを順を追って説明します。 - 新しいキーペアを作成するように求めるダイアログボックスが表示されます。名前、メールアドレス、およびオプションのコメントを入力します。キーの有効期限、キーの強度 (ビット数) およびアルゴリズムを選択することもできます。
- 次のダイアログボックスでパスフレーズを入力します。この時点で、キーが KGpg のメインウィンドウに表示されます。
警告
パスフレーズを忘れると、データの暗号解除ができなくなります。
GPG キー ID を見つけるには、新しく作成された鍵の横にある Key ID 列を確認します。ほとんどの場合、キー ID を求められた場合は、
0x 6789ABCD のように、キー ID の前に 0x を付けます。秘密鍵のバックアップを取り、安全な場所に保管してください。
4.9.2.3. コマンドラインを用いた GPG 鍵の生成
- 次のシェルコマンドを使用します。
~]$ gpg2 --gen-keyこのコマンドは、公開鍵と秘密鍵からなるキーペアを生成します。他の人はあなたの公開鍵を使用してあなたの通信を認証および復号化します。公開鍵をできるだけ広く配布します。特に、メーリングリストなど、認証された通信の受信希望者に配布します。 - 一連のプロンプトがプロセスを指示します。必要に応じて、Enter キーを押してデフォルト値を割り当てます。最初のプロンプトでは、希望するキーの種類を選択するように求められます。
Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection?
ほとんどすべての場合、デフォルトが適切な選択となります。RSA/RSA 鍵は、通信の署名だけでなく、ファイルの暗号化も可能にします。 - 鍵のサイズを選択します。
RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048)
この場合も、デフォルトの 2048 は、ほとんどすべてのユーザーにとって十分であり、非常に強力なセキュリティーレベルを表しています。 - 鍵の有効期限を選択します。デフォルトの なし を使用する代わりに、有効期限を選択することが推奨され
ます。たとえば、キーの電子メールアドレスが無効になった場合、有効期限があると、他の人にその公開キーの使用を停止するように知らせることができます。Please specify how long the key should be valid. 0 = key does not expire d = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years key is valid for? (0)
たとえば、1y の値を入力すると、キーは 1 年間有効になります。(気が変わった場合は、キーが生成された後にこの有効期限を変更できます。) - gpg2 アプリケーションが署名情報を要求する前に、以下のプロンプトが表示されます。
Is this correct (y/N)?
yを入力してプロセスを終了します。 - GPG 鍵用に氏名と電子メールアドレスを入力します。このプロセスは、あなたが実在する人物であることを証明するためのものであることを忘れないでください。このため、本当の名前を入力してください。偽の電子メールアドレスを選択すると、他の人があなたの公開鍵を見つけるのがより困難になります。これにより、通信の認証が困難になります。たとえば、この GPG キーをメーリングリストでの自己紹介に使用している場合は、そのリストで使用している電子メールアドレスを入力します。コメントフィールドには、エイリアスなどの情報を記載してください。(人によっては、目的別にキーを使い分け、それぞれのキーに "Office" または "Open Source Projects" などのコメントをつけて識別しています)。
- すべてのエントリーが正しい場合は、確認プロンプトで
Oを入力して続行するか、他のオプションを使用して問題を修正します。最後に、秘密鍵のパスフレーズを入力します。gpg2 プログラムでは、入力エラーが発生しないようにパスフレーズを 2 回入力するように求められます。 - 最後に、gpg2 はランダムなデータを生成して、キーを可能な限り一意にします。この手順では、マウスを動かしたり、ランダムキーを入力したり、システムで他のタスクを実行したりして、プロセスを高速化します。この手順が終わると、キーは完成し、すぐに使えるようになります。
pub 1024D/1B2AFA1C 2005-03-31 John Q. Doe <jqdoe@example.com> Key fingerprint = 117C FE83 22EA B843 3E86 6486 4320 545E 1B2A FA1C sub 1024g/CEA4B22E 2005-03-31 [expires: 2006-03-31]
- キーのフィンガープリントは、キーの省略形の "署名" です。これにより、実際の公開鍵を改ざんされることなく受け取ったことを他者に確認することができるのです。このフィンガープリントを書き留める必要はありません。いつでもフィンガープリントを表示するには、以下のコマンドを使用し、電子メールアドレスは置き換えます。
~]$ gpg2 --fingerprint jqdoe@example.com"GPG キー ID" は、公開鍵を識別する 8 桁の 16 進数で設定されています。上記の例では、GPG キー ID は1B2AFA1Cです。ほとんどの場合、キー ID を求められた場合は、0x6789ABCD
警告
パスフレーズを忘れると、キーは使用できなくなり、そのキーを使用して暗号化されたデータはすべて失われます。
4.9.2.4. 公開鍵の暗号化について
4.9.3. 公開鍵暗号化における openCryptoki の使用
openCryptoki は PKCS#11 の Linux 実装で、トークンと呼ばれる暗号化デバイスへのアプリケーションプログラミングインターフェイス(API)を定義する 公開鍵暗号化標準 です。トークンは、ハードウェアまたはソフトウェアに実装することが可能です。本章では、openCryptoki システムを Red Hat Enterprise Linux 7 でインストール、設定、および使用する方法の概要を説明します。
4.9.3.1. openCryptoki のインストールとサービスの起動
テスト目的でトークンのソフトウェア実装を含む、基本的な openCryptoki パッケージをシステムにインストールするには、
root で以下のコマンドを実行します。
~]# yum install opencryptoki
使用する予定のハードウェアトークンの種類によっては、特定のユースケースをサポートする追加のパッケージをインストールする必要がある場合があります。たとえば、Trusted Platform Module (TPM) デバイスのサポートを取得するには、opencryptoki-tpmtok パッケージをインストールする必要があります。
Yum パッケージマネージャーを 使用 してパッケージをインストールする方法は、Red Hat Enterprise Linux 7 システム管理者のガイドのパッケージのインストールセクションを参照してください。
openCryptoki サービスを有効にするには、
pkcsslotd デーモンを実行する必要があります。root で以下のコマンドを実行して、現行セッションで デーモンを起動します。
~]# systemctl start pkcsslotd
起動時に自動的にサービスが開始されるようにするには、次のコマンドを入力します。
~]# systemctl enable pkcsslotd
systemd ターゲットを使ってサービスを管理する方法の詳細については、Red Hat Enterprise Linux 7 システム管理者ガイド の Managing Services with systemd の章を参照してください。
4.9.3.2. openCryptoki の設定と使用
起動すると、
pkcsslotd デーモンは /etc/opencryptoki/opencryptoki.conf 設定ファイルを読み取ります。このファイルは、システムで動作するように設定されたトークンとスロットに関する情報を収集します。
このファイルは、キーと値のペアを使用して個々のスロットを定義します。各スロット定義には、説明、使用するトークンライブラリーの仕様、およびスロットの製造元の ID を含めることができます。オプションで、スロットのハードウェアとファームウェアのバージョンを定義できます。ファイルのフォーマットや、個々のキーとそれに割り当てられる値の詳細については、opencryptoki.conf(5) の man ページを参照してください。
ランタイム時に
pkcsslotd デーモンの動作を変更するには、pkcsconf ユーティリティーを使用します。このツールでは、デーモンの状態の表示や設定、現在設定されているスロットやトークンの一覧表示や変更を行うことができます。たとえば、トークンに関する情報を表示するには、以下のコマンドを実行します( pkcsslotd デーモンと通信する必要があるすべての非 root ユーザーは、pkcs11 システムグループの一部である必要があることに注意してください)。
~]$ pkcsconf -t
pkcsconf ツールで利用可能な引数の一覧は、pkcsconf(1) の man ページを参照してください。
警告
このグループのすべてのメンバーには、openCryptoki サービスの他のユーザーが設定済みの PKCS#11 トークンにアクセスできないようにブロックする権利があるため、完全に信頼できるユーザーのみが
pkcs11 グループのメンバーシップを割り当てる必要があることに注意してください。このグループのすべてのメンバーは、openCryptoki の他のユーザーの権限で任意のコードを実行することもできます。
4.9.4. OpenSSH に認証情報を提供するスマートカードの使用
スマートカードは、USB メモリー、MicroSD、または SmartCard のフォームファクターを持つ軽量のハードウェアセキュリティーモジュールです。リモートで管理可能なセキュアなキーストアを提供します。Red Hat Enterprise Linux 7 では、OpenSSH はスマートカードを使用した認証をサポートしています。
OpenSSH でスマートカードを使用するには、カードからの公開鍵を
~/.ssh/authorized_keys ファイルに保存します。opensc パッケージが提供する PKCS#11 ライブラリーをクライアントにインストールします。PKCS#11 は、トークンと呼ばれる暗号化デバイスへのアプリケーションプログラミングインターフェイス(API)を定義する公開鍵暗号化標準です。root で以下のコマンドを入力します。
~]# yum install opensc4.9.4.1. カードからの公開鍵の取得
カードの鍵を一覧表示するには、ssh-keygen コマンドを使用します。共有ライブラリー (以下の例では OpenSC) を
-D ディレクティブで指定します。
~]$ ssh-keygen -D /usr/lib64/pkcs11/opensc-pkcs11.so
ssh-rsa AAAAB3NzaC1yc[...]+g4Mb94.9.4.2. サーバーへの公開鍵の保存
リモートサーバーでスマートカードを使用した認証を有効にするには、公開鍵をリモートサーバーに転送します。これを行うには、取得した文字列（キー）をコピーしてリモートシェルに貼り付けるか、鍵をファイル（以下の例では
smartcard.pub ）に保存し、ssh-copy-id コマンドを使用します。
~]$ ssh-copy-id -f -i smartcard.pub user@hostname
user@hostname's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh user@hostname"
and check to make sure that only the key(s) you wanted were added.
秘密鍵ファイルなしで公開鍵を保存するには、環境変数
SSH_COPY_ID_LEGACY=1 または -f オプションを使用する必要があります。
4.9.4.3. スマートカードのキーを使用したサーバーへの認証
OpenSSH は、スマートカードからあなたの公開鍵を読み取り、鍵そのものを公開することなく、あなたの秘密鍵を使った操作を実行することができます。これは、秘密鍵がカードを離れないことを意味します。スマートカードを認証に使用してリモートサーバーに接続するには、次のコマンドを入力し、カードを保護する PIN を入力してください。
[localhost ~]$ssh -I /usr/lib64/pkcs11/opensc-pkcs11.so hostname Enter PIN for 'Test (UserPIN)':[hostname ~]$
ホスト名 を、接続する実際のホスト名に置き換えます。
次回リモートサーバーに接続する際に不要な入力を保存するには、
~/.ssh/config ファイルの PKCS#11 ライブラリーへのパスを保存します。
Host hostname
PKCS11Provider /usr/lib64/pkcs11/opensc-pkcs11.so
追加オプションを指定せずに ssh コマンドを実行して接続します。
[localhost ~]$ssh hostname Enter PIN for 'Test (UserPIN)':[hostname ~]$
4.9.4.4. ssh-agent を使用した PIN ログインの自動化
ssh-agent の使用を開始するための環境変数を設定します。ssh-agent は通常のセッションですでに実行されているため、ほとんどの場合、この手順をスキップできます。以下のコマンドを使用して、認証エージェントに接続できるかどうかを確認します。
~]$ssh-add -l Could not open a connection to your authentication agent.~]$eval `ssh-agent`
このキーを使って接続するたびに PIN を書き込まないようにするには、次のコマンドを実行してカードをエージェントに追加してください。
~]$ ssh-add -s /usr/lib64/pkcs11/opensc-pkcs11.so
Enter PIN for 'Test (UserPIN)':
Card added: /usr/lib64/pkcs11/opensc-pkcs11.so
カードを ssh-agent から削除するには、次のコマンドを使用します。
~]$ ssh-add -e /usr/lib64/pkcs11/opensc-pkcs11.so
Card removed: /usr/lib64/pkcs11/opensc-pkcs11.so注記
FIPS 201-2 は、カードに格納されたデジタル署名鍵の使用条件として、Personal Identity Verification (PIV) カード保持者による明示的なユーザーアクションを要求します。OpenSC には、この要件が正しく適用されます。
しかし、アプリケーションによっては、カード保有者が署名のたびに PIN を入力することを要求するのは現実的ではありません。スマートカード PIN をキャッシュするには、
/etc/opensc-x86_64.conf の pin_cache_ignore_user_consent = true; オプションの前に # 文字を削除します。
詳細は、Cardholder Authentication for the PIV Digital Signature Key (NISTIR 7863) レポートを参照してください。
4.9.4.5. 関連情報
ハードウェアまたはソフトウェアトークンのセットアップについては、Smart Card support in Red Hat Enterprise Linux 7 の記事で説明されています。
スマートカードや同様の
PKCS# 11 セキュリティートークンを管理および使用する pkcs11-tool ユーティリティーの詳細は、pkcs11-tool (1) の man ページを参照してください。
4.9.5. 信頼できる鍵および暗号化された鍵
信頼できる鍵と暗号化された鍵は、カーネルキーリングサービスを使用するカーネルが生成する可変長の対称鍵です。キーが暗号化されていない形式でユーザースペースに表示されないという事実は、キーの整合性を検証できることを意味します。つまり、拡張検証モジュール (EVM) などで実行中のシステムの整合性を検証および確認するために使用できます。ユーザーレベルのプログラムは、暗号化された blobs の形式でのみキーにアクセスできます。
信頼できる鍵は、Trusted Platform Module (TPM) チップというハードウェアが必要になります。これは、鍵を作成し、暗号化 (保護) するために使用されます。TPM は、ストレージルートキー(SK)と呼ばれる 2048 ビットの
RSA キーを使用して鍵 を保護します。
それに加えて、信頼できるキーは、TPM の プラットフォーム設定レジスター (PCR) 値の特定のセットを使用してシールすることもできます。PCR には、BIOS、ブートローダー、およびオペレーティングシステムを反映する一連の整合性管理値が含まれています。つまり、PCR でシールされたキーは、暗号化されたのとまったく同じシステム上の TPM でのみ復号化できます。ただし、PCR で保護された信頼できる鍵が読み込まれると (キーリングに追加されると)、新しいカーネルなどを起動できるように、関連する PCR 値が検証され、新しい (または今後の) PCR 値に更新されます。1 つの鍵を複数の blobs として保存することもできますが、それぞれ PCR 値が異なります。
暗号化鍵はカーネルの
AES 暗号化を使用するため、TPM は必要ありません。これにより、信頼できる鍵よりも高速になります。暗号化鍵は、カーネルが生成した乱数を使用して作成され、ユーザー空間の blobs へのエクスポート時に マスターキー により暗号化されます。このマスターキーは、信頼できるキーでもユーザーキーでも構いませんが、これが主な欠点となっています。マスターキーが信頼できるキーでない場合、暗号化されたキーは、それを暗号化するために使用したユーザーキーと同等の安全性しか得られません。
4.9.5.1. 鍵を使った作業
鍵を使用して操作を実行する前に、trusted および encrypted-keys カーネルモジュールがシステムに読み込まれていることを確認してください。さまざまな RHEL カーネルアーキテクチャーでカーネルモジュールをロードするときは、次の点を考慮してください。
x86_64アーキテクチャーを持つ RHEL カーネルの場合、TRUSTED_KEYS および ENCRYPTED_KEYS コードはコアカーネルコードの一部として組み込まれています。その結果、x86_64システムユーザーは、trusted モジュールおよび encrypted-keys モジュールを読み込むことなく、これらの鍵を使用できます。- その他のアーキテクチャーでは、鍵で操作を実行する前に、trusted および encrypted-keys カーネルモジュールを読み込む必要があります。カーネルモジュールをロードするには、以下のコマンドを実行します。
~]# modprobe trusted encrypted-keys
信頼できる鍵および暗号化された鍵は、keyctl ユーティリティーを使用して作成、読み込み、エクスポート、および更新できます。keyctl の使用に関する詳細は、keyctl(1) を参照してください。
注記
TPM を使用するには (信頼できる鍵の作成および保護目的など)、これを有効かつアクティブにする必要があります。これは通常、マシンの BIOS の設定、またはユーティリティーの tpm-tools パッケージから tpm_setactive コマンドを使用して実行できます。また、TPM と通信するには、TrouSers アプリケーション( trousers パッケージ)と、TrouSers スイートの一部である
tcsd デーモンをインストールする必要があります。
TPM を使用して信頼できる鍵を作成するには、次の構文で keyctl コマンドを実行します。
~]$ keyctl add trusted name "new keylength [options]" keyring
上記の構文を使用すると、コマンドの例を次のように作成できます。
~]$ keyctl add trusted kmk "new 32" @u
642500861
上記の例では、
kmk と呼ばれる信頼できる鍵を作成し、長さが 32 バイト(256 ビット)で、ユーザーのキーリング(@u)に配置します。鍵の長さは 32 から 128 バイト (256 から 1024 ビット) です。show サブコマンドを使用して、カーネルキーリングの現在の構造を一覧表示します。
~]$ keyctl show
Session Keyring
-3 --alswrv 500 500 keyring: _ses
97833714 --alswrv 500 -1 \_ keyring: _uid.1000
642500861 --alswrv 500 500 \_ trusted: kmk
print サブコマンドは、暗号化されたキーを標準出力に出力します。キーをユーザー空間のブロブにエクスポートするには、以下のように pipe サブコマンドを使用します。
~]$ keyctl pipe 642500861 > kmk.blob
ユーザー空間のブロブから信頼できる鍵を読み込むには、ブロブを引数として add コマンドを再度使用します。
~]$ keyctl add trusted kmk "load `cat kmk.blob`" @u
268728824
次に、TPM でシールされた信頼できる鍵を使用して、安全な暗号化された鍵を作成できます。暗号化された鍵の生成には、以下のコマンド構文を使用します。
~]$ keyctl add encrypted name "new [format] key-type:master-key-name keylength" keyring
上記の構文に基づいて、すでに作成済みの信頼できるキーを使用して暗号化されたキーを生成するコマンドは、次のように設定できます。
~]$ keyctl add encrypted encr-key "new trusted:kmk 32" @u
159771175
TPM が使用できないシステムで暗号化されたキーを作成するには、ランダムな数字のシーケンスを使用してユーザーキーを生成し、次にこれを使用して実際の暗号化されたキーをシールします。
~]$ keyctl add user kmk-user "`dd if=/dev/urandom bs=1 count=32 2>/dev/null`" @u
427069434
次に、乱数ユーザーキーを使用して暗号化されたキーを生成します。
~]$ keyctl add encrypted encr-key "new user:kmk-user 32" @u
1012412758
list サブコマンドは、指定されたカーネルキーリング内のすべてのキーを一覧表示するために使用できます。
~]$ keyctl list @u
2 keys in keyring:
427069434: --alswrv 1000 1000 user: kmk-user
1012412758: --alswrv 1000 1000 encrypted: encr-key重要
暗号化鍵がマスターの信頼できる鍵で保護されていない場合には、そのセキュリティーは、ユーザーのマスターキー (乱数キー) を使用して暗号化したものと同じでしかない点に注意してください。そのため、マスターユーザーキーはできるだけ安全に、システムの起動プロセスの早い段階で読み込む必要があります。
4.9.5.2. 関連情報
次のオフラインおよびオンラインリソースを使用して、信頼できる暗号化されたキーの使用に関する追加情報を取得できます。
インストールされているドキュメント
- keyctl(1) : keyctl ユーティリティーとそのサブコマンドの使用を説明します。
オンラインドキュメント
- Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理者のガイド: Red Hat Enterprise Linux 7 『の SELinux ユーザーおよび管理者のガイド』 では、SELinux の原則と、SELinux を Apache HTTP Server などのさまざまなサービスで設定および使用する方法を説明します。
- https://www.kernel.org/doc/Documentation/security/keys-trusted-encrypted.txt — Linux カーネルの信頼できる鍵および暗号化された鍵機能に関する公式ドキュメントです。
関連項目
- 「高度暗号化標準 — AES」
Advanced Encryption Standardの簡潔な説明を提供します。 - 「公開鍵の暗号化」 は、公開鍵暗号化アプローチとそれが使用するさまざまな暗号化プロトコルについて説明します。
4.9.6. 乱数ジェネレーターの使用
簡単に破ることができない安全な暗号化キーを生成できるようにするには、乱数のソースが必要です。一般に、番号がランダムであるほど、一意のキーを取得する可能性が高くなります。乱数を生成するための エントロピー は、通常、環境の "ノイズ" を計算するか、ハードウェア 乱数ジェネレーター を使用して取得されます。
rng-tools パッケージの一部である
rngd デーモンは、エントロピーを抽出するために環境ノイズとハードウェア乱数ジェネレーターの両方を使用できます。デーモンは、乱数性のソースによって供給されるデータが十分にランダムなものかどうかをチェックしてから、カーネルの乱数エントロピープールにデータを格納します。生成する乱数は、/dev/random および /dev/urandom キャラクターデバイスで利用できます。
/dev/random と /dev/urandom の違いは、前者はブロッキングデバイスであることです。つまり、エントロピーの量が適切なランダム出力を生成するのに不十分なと判断すると、番号の供給を停止します。逆に、/dev/urandom はノンブロッキングソースであり、カーネルのエントロピープールを再利用するため、エントロピーが少ない疑似乱数を無制限に提供できます。そのため、/dev/urandom は、長期暗号化キーの作成には使用しないでください。
rng-tools パッケージをインストールするには、
root で以下のコマンドを発行します。
~]# yum install rng-toolsrngd デーモンを起動するには、root で以下のコマンドを実行します。
~]# systemctl start rngd
デーモンの状態を問い合わせるには、次のコマンドを使用します。
~]# systemctl status rngd
オプションのパラメーターを使用して
rngd デーモンを起動するには、直接実行します。たとえば、乱数入力の代替ソース( /dev/hwrandom以外)を指定するには、以下のコマンドを使用します。
~]# rngd --rng-device=/dev/hwrng
上記のコマンドは、乱数が読み取られるデバイスとして、
/dev/hwrng で rngd デーモンを起動します。同様に、-o （または --random-device）オプションを使用して、乱数出力用のカーネルデバイスを選択できます（デフォルトの /dev/random以外）。利用可能なすべてのオプションの一覧は、rngd(8) の man ページを参照してください。
特定のシステムで利用可能なエントロピーのソースを確認するには、
root で以下のコマンドを実行します。
~]# rngd -vf
Unable to open file: /dev/tpm0
Available entropy sources:
DRNG注記
rngd -v コマンドを入力すると、以下のプロセスがバックグラウンドで実行を継続します。
-b, --background オプション (デーモンになる) はデフォルトで適用されます。
TPM デバイスが存在しない場合は、エントロピーのソースとして Intel Digital Random Number Generator (DRNG) のみが表示されます。お使いの CPU が RDRAND プロセッサー命令をサポートしているかどうかを確認するには、以下のコマンドを入力します。
~]$ cat /proc/cpuinfo | grep rdrand注記
詳細およびソフトウェアコードの例については、Intel Digital Random Number Generator (DRNG) Software Implementation Guide. を参照してください。
rng-tools パッケージには、データのランダム性を確認するために使用できる rngtest ユーティリティーも含まれています。
/dev/random の出力のランダム性のレベルをテストするには、次のように rngtest ツールを使用します。
~]$ cat /dev/random | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 2
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=1.171; avg=8.453; max=11.374)Mibits/s
rngtest: FIPS tests speed: (min=15.545; avg=143.126; max=157.632)Mibits/s
rngtest: Program run time: 2390520 microseconds
rngtest ツールの出力に表示される多数の障害は、テストされたデータのランダム性が不十分であり、依存しないことを示しています。rngtest ユーティリティーで利用可能なオプションの一覧は、rngtest(1) の man ページを参照してください。
Red Hat Enterprise Linux 7 では、ホストマシンからエントロピーにアクセスできる KVM 仮想マシンを提供する virtio RNG （乱数ジェネレーター）デバイスが導入されました。推奨される設定では、hwrng はホスト Linux カーネルのエントロピープールに(
/dev/randomを介して)フィードし、QEMU はゲストが要求するエントロピーのソースとして /dev/random を使用します。
図4.1 virtio RNG デバイス
[D]
以前は、Red Hat Enterprise Linux 7.0 ゲストおよび Red Hat Enterprise Linux 6 ゲストは、rngd ユーザースペースデーモンを介してホストからのエントロピーを利用できました。デーモンの設定は、Red Hat Enterprise Linux のインストールごとに手作業で行っていました。Red Hat Enterprise Linux 7.1 では、手動の手順が不要になり、プロセス全体がシームレスかつ自動化されています。rngd を使用する必要がなくなり、使用可能なエントロピーが特定のしきい値を下回ると、ゲストカーネル自体がホストからエントロピーをフェッチします。これにより、ゲストカーネルは、アプリケーションが要求するとすぐに乱数を使用できるようにします。
Red Hat Enterprise Linux インストーラーである Anaconda は、インストーラーイメージに virtio-rng モジュールを提供し、Red Hat Enterprise Linux のインストール時にホストエントロピーを利用できるようにするようになりました。
重要
シナリオで使用する乱数ジェネレーターを正しく決定するには、Understanding the Red Hat Enterprise Linux random number generator interface の記事を参照してください。
