4.10. 暗号化

4.10.1. LUKS のディスク暗号化の使用

Linux Unified Key Setup-on-disk-format (または LUKS) を使うと、Linux コンピューター上のパーティションを暗号化できます。これは特に、モバイルコンピューターやリムーバブルメディアを使う際に重要です。LUKS を使うと、複数のユーザーキーを使って、パーティションのバルク暗号化に使用されるマスターキーの暗号化解除ができるようになります。

LUKS の概要

LUKS の機能
  • LUKS はブロックデバイス全体を暗号化するため、脱着可能なストレージメディアやノート PC のディスクドライブといった、モバイルデバイスのコンテンツ保護に適しています。
  • 暗号化されたブロックデバイスにあるのは任意のコンテンツです。これは、スワップデバイスの暗号化に役立ちます。また、とりわけデータストレージ用にフォーマットしたブロックデバイスを使用する特定のデータベースに関しても有用です。
  • LUKS は既存のデバイスマッパーカーネルサブシステムを使用します。
  • LUKS はパラフレーズの強化を提供し、辞書攻撃から保護します。
  • LUKS デバイスには複数のキースロットが含まれ、ユーザーはこれを使ってバックアップキーやパスフレーズを追加できます。
LUKS でできないこと:
  • LUKS は、多くのユーザー (9 人以上) が同一デバイスに対して別々のアクセスを持つことが必要となるアプリケーションには適していません。
  • LUKS は、ファイルレベルの暗号化を必要とするアプリケーションには適していません。

4.10.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 (XTS モード) と併用する場合の LUKS のデフォルトの鍵のサイズは 512 ビット です。利用可能な暗号は以下の通りです。
  • AES - Advanced Encryption Standard (高度暗号化標準) - FIPS PUB 197
  • Twofish (128 ビットブロック暗号)
  • Serpent
  • cast5 - RFC 2144
  • cast6 - RFC 2612

4.10.1.2. 手動でのディレクトリーの暗号化

警告

以下の手順を実行すると、暗号化しているパーティションの既存データがすべて削除されます。すべての情報が失われてしまうので、この手順を開始する前に、外部ソースへのデータのバックアップを必ず行なってください。
  1. root としてシェルプロンプトに以下を入力し、ランレベル 1 に入ります。
    telinit 1
  2. 既存の /home のマウントを解除します。
    umount /home
  3. 直前の手順のコマンドが失敗した場合は、fuser を使用し、/home を独占しているプロセスを見つけてこれらを止めます。
    fuser -mvk /home
  4. /home がもはやマウントされていないことを確認します。
    grep home /proc/mounts
  5. パーティションをランダムなデータで埋めます。
    shred -v --iterations=1 /dev/VG00/LV_home
    このコマンドは、デバイスの連続書き込み速度で実行され、完了までに時間がかかる場合があります。使用デバイスに暗号化されていないデータが残っていないことを確認した上で、デバイスの暗号化されたデータを含む部分を難読化するのは重要なステップです。
  6. パーティションを初期化します。
    cryptsetup --verbose --verify-passphrase luksFormat /dev/VG00/LV_home
  7. 新たに暗号化したデバイスを開きます。
    cryptsetup luksOpen /dev/VG00/LV_home home
  8. デバイスがあることを確認します。
    ls -l /dev/mapper | grep home
  9. ファイルシステムを作成します。
    mkfs.ext3 /dev/mapper/home
  10. ファイルシステムをマウントします。
    mount /dev/mapper/home /home
  11. ファイルシステムが表示されていることを確認します。
    df -h | grep home
  12. 以下を /etc/crypttab ファイルに追加します。
    home /dev/VG00/LV_home none
  13. /etc/fstab ファイルを編集して、/home の古いエントリを削除し、以下の行を追加します。
    /dev/mapper/home /home ext3 defaults 1 2
  14. デフォルトの SELinux セキュリティーコンテンツを復元します。
    /sbin/restorecon -v -R /home
  15. マシンを再起動します。
    shutdown -r now
  16. /etc/crypttab にあるエントリにより、コンピューターのブート時に luks パスフレーズが尋ねられます。
  17. root としてログインし、バックアップを復元します。
これですべてのデータ用に暗号化されたパーティションを設定できたので、コンピューターをオフにしている間もデータを安全に保管できます。

4.10.1.3. 既存デバイスへの新規パスフレーズの追加

既存デバイスに新規パスフレーズを追加するには、以下のコマンドを使用します。
cryptsetup luksAddKey device
認証のために既存のパスフレーズが尋ねられた後に、新規パスフレーズの入力を求めるプロンプトが出されます。

4.10.1.4. 既存のデバイスからのパスフレーズ削除

既存のデバイスからパスフレーズを削除するには、以下のコマンドを使用します。
cryptsetup luksRemoveKey device
削除したいパスフレーズを求めるプロンプトの後に、認証に必要な残りのパスフレーズを求めるプロンプトが表示されます。

4.10.1.5. Anaconda での暗号化したブロックデバイスの作成

システムのインストール時に、暗号化されたデバイスを作成することができます。これにより、 暗号化パーティションを含むシステムを簡単に設定することができます。
ブロックデバイスの暗号化を有効にするには、自動パーティション設定を選択している場合は システムの暗号化 チェックボックスに、個別パーティション、ソフトウェア RAID アレイまたは論理ボリュームを作成している場合は 暗号化 チェックボックスにチェックを入れます。パーティション設定が終了したら、暗号化のパスフレーズが尋ねられます。このパスフレーズは暗号化したデバイスへのアクセスに必要となります。LUKS デバイスが事前に存在しており、インストールプロセスの当初にそれらの正しいパスフレーズを指定している場合には、チェックボックスのあるパスフレーズ入力ダイアログが表示されます。このチェックボックスにチェックを入れると、既存の暗号化ブロックデバイスの利用可能なスロットに新規パスフレーズを追加することになります。

注記

自動パーティション設定 画面の システムの暗号化 チェックボックスにチェックを入れた後に カスタムレイアウトの作成 を選択しても、ブロックデバイスは自動的に暗号化されません。

注記

kickstart を使用すると、新たに暗号化されたブロックデバイスのパスフレーズを個別に設定することができます。

4.10.2. GPG 鍵の作成

GnuPG (GPG) は、ユーザーを識別し、通信 (確認できない人々との通信も含む) を認証するために使われます。GPG は、GPG 署名のある電子メールを読む人がその真正性を検証できるようにします。つまり、GPG は、あなたが署名した通信が実際にあなたからのものであることをかなりの精度で確認できるようにします。GPG は、第三者がコードを変更したり、会話を傍受したり、メッセージを改ざんしたりすることを防ぐ点で役に立ちます。

4.10.2.1. GNOME での GPG 鍵の生成

GNOME で GPG 鍵を作成するには、以下の手順にしたがいます。
  1. Seahorse ユーティリティーをインストールします。これにより GPG 鍵の管理が容易になります。
    ~]# yum install seahorse
  2. 鍵を作成するには、アプリケーションアクセサリメニューから、パスワードと暗号鍵を選択します。これでアプリケーション Seahorse が起動します。
  3. ファイルメニューから新規を選択し、PGP 鍵を選択した後に続行をクリックします。
  4. 氏名、電子メールアドレスおよび自身についての説明のオプションのコメント (例: John C. Smith, , Software Engineer) を入力します。生成をクリックします。鍵のパスフレーズを問い合わせるダイアログが表示されます。パスフレーズは強固なだけでなく覚えやすいものを選択してください。OK をクリックすると鍵が作成されます。

警告

パスフレーズを忘れると、データの暗号解除ができなくなります。
GPG 鍵 の ID を見つけるには、新規に作成された鍵の横にある 鍵の ID コラムを確認します。多くの場合、鍵 の ID を求められたら、0x6789ABCD などのように鍵の ID の前に 0x を付けます。秘密鍵のバックアップを取り、安全な場所に保管してください。

4.10.2.2. KDE での GPG 鍵の作成

KDE で GPG 鍵を作成するには、以下の手順にしたがいます。
  1. メインメニューからアプリケーションユーティリティ暗号ツールを選択して KGpg プログラムを起動します。これまで KGpg を使用したことがなければ、プログラムが独自の GPG 鍵ペアを生成するプロセスを詳しく説明します。
  2. ダイアログボックスで、新しい鍵ペアを生成するよう求められます。名前、電子メールアドレス、およびオプションのコメントを入力します。鍵の長さ (ビット数) とアルゴリズムに加え、鍵の有効期限も選択できます。
  3. 次のダイアログでパスフレーズを入力します。この時点で、鍵が KGpg のメインウィンドウに表示されます。

警告

パスフレーズを忘れると、データの暗号解除ができなくなります。
GPG 鍵 の ID を見つけるには、新規に作成された鍵の横にある 鍵の ID コラムを確認します。多くの場合、鍵 の ID を求められたら、0x6789ABCD などのように鍵の ID の前に 0x を付けます。秘密鍵のバックアップを取り、安全な場所に保管してください。

4.10.2.3. コマンドラインを用いた GPG 鍵の生成

  1. 次のシェルコマンドを使用します。
    ~]$ gpg2 --gen-key
    このコマンドは、公開鍵と秘密鍵で構成される鍵ペアを生成します。受信側では、ユーザーからの通信の認証や暗号化解除を行うためにこのユーザーの公開鍵を使用します。そのため、とりわけメーリングリストのように、送信者からの認証済みの通信を受け取ることを希望すると思われる人々に向けて、できる限り幅広く公開鍵を配布してください。
  2. 一連のプロンプトにしたがってプロセスを進めます。デフォルト値を割り当てる場合は 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 鍵を選択すると、通信に署名するだけでなく、ファイルを暗号化することができます。
  3. 鍵のサイズを選択します。
    RSA keys may be between 1024 and 4096 bits long.
    What keysize do you want? (2048)
    ここでも、デフォルトの 2048 はほとんどすべてのユーザーに適しており、これは極めて強いレベルのセキュリティーになります。
  4. 鍵の有効期限を選択します。デフォルトの none を使用するのではなく、失効日を選択する方がよいでしょう。例えば、鍵にある電子メールアドレスが無効になると、失効日が設定されているために、他の人々はその公開鍵を使用するのを止めるように通知されます。
    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 年間になります (鍵の生成後にこの失効日を変更することができます)。
  5. gpg2 プログラムが署名情報を尋ねる前に、以下のプロンプトが表示されます。
    Is this correct (y/N)?
    y を入力してプロセスを終了します。
  6. GPG 鍵用に氏名と電子メールアドレスを入力します。このプロセスは、ユーザーを個人として認証するためのものです。このため、本当の名前を入力してください。偽の電子メールアドレスを選択すると、他の人があなたの公開鍵を見つけにくくなります。これにより、通信の認証が困難になります。例えば、メーリングリストの自己紹介にこの GPG 鍵を使用する場合、そのリストで使用している電子メールアドレスを入力します。
    コメントフィールドには、エイリアスやその他の情報を記載します。(一部の人は、目的別に複数の鍵を使用しており、「オフィス」または「オープンソースプロジェクト」などのコメントを付けてそれぞれの鍵を識別しています。)
  7. すべてのエントリーが正しければ、確認プロンプトで O と入力して続行するか、または問題がある場合はそれを修正するために他のオプションを使用します。最後に、秘密鍵のパスフレーズを入力します。gpg2 プログラムは、入力エラーがないことを確認するためにパスフレーズを 2 回入力するように指示します。
  8. 最後に、 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]
    
  9. 鍵のフィンガープリントは、鍵の「署名」の短縮版です。これを使って、他の人々が実際の公開鍵を (改ざんされない状態で) 受け取ったことを確認することができます。このフィンガープリントを書き留めておく必要はありません。フィンガープリントを表示するには、以下のコマンドをあなたの電子メールアドレスに置き換えて使用します。
    ~]$ gpg2 --fingerprint jqdoe@example.com
    「GPG 鍵 の ID」は、公開鍵を識別する 16 進法の 8 文字で構成されます。上記の例では、GPG 鍵 ID は 1B2AFA1C です。多くの場合、鍵 ID を求められる際には、0x6789ABCD などのように、鍵 ID の前に 0x を付けます。

警告

パスフレーズを忘れると、鍵を使うことができなくなり、その鍵で暗号化されたすべてのデータが失われます。

4.10.2.4. 公開鍵の暗号化について

4.10.3. 公開鍵暗号化における openCryptoki の使用

openCryptokiPKCS#11 の Linux 実装で、トークンと呼ばれる暗号化デバイスへのアプリケーションプログラミングインターフェース (API) を定義する 公開鍵暗号標準 です。トークンは、ハードウェアまたはソフトウェアに実装することが可能です。本章では、Red Hat Enterprise Linux 7 での openCryptoki システムのインストール、設定および使用についての概要を説明します。

4.10.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 システム管理者のガイドの systemd によるサービス管理 の章を参照してください。

4.10.3.2. openCryptoki の設定と使用

pkcsslotd デーモンは起動後に /etc/opencryptoki/opencryptoki.conf 設定ファイルを読み込みます。このファイルは、システムと機能するように設定されたトークンとそのスロットについての情報を収集するために使用されます。
The file defines the individual slots using key-value pairs. Each slot definition can contain a description, a specification of the token library to be used, and an ID of the slot's manufacturer. Optionally, the version of the slot's hardware and firmware may be defined. See the opencryptoki.conf(5) manual page for a description of the file's format and for a more detailed description of the individual keys and the values that can be assigned to them.
ランタイム時の pkcsslotd デーモンの動作を修正するには、pkcsconf ユーティリティーを使用します。このツールを使うと、デーモンの状態の表示と設定に加え、現在設定されているスロットとトークンの一覧表示と修正がでいます。たとえば、トークンについての情報を表示するには、以下のコマンドを実行します。(pkcsslotd デーモンと通信する必要のある root 以外のユーザーは、pkcs11 システムグループに属している必要があることに注意してください)
~]$ pkcsconf -t
See the pkcsconf(1) manual page for a list of arguments available with the pkcsconf tool.

警告

pkcs11 グループには、完全に信頼できるユーザーのみを割り当ててください。このグループのメンバーは、openCryptoki サービスの他のユーザーが設定済み PKCS#11 トークンへアクセスできなくすることができます。またこのグループのメンバーは、openCryptoki の他のユーザーの権限で任意のコードを実行することができます。

4.10.4. OpenSSH に認証情報を提供するスマートカードの使用

スマートカードは、USB スティック、MicroSD またはスマートカードのフォームファクター形式の軽量のハードウェアセキュリティーモジュールです。スマートカードにより、セキュアなキーストアをリモートで管理できます。Red Hat Enterprise Linux 7 では OpenSSH はスマートカードを使用した認証をサポートします。
OpenSSH でスマートカードを使用するには、カードの公開鍵を ~/.ssh/authorized_keys ファイルに保存して、クライアント上で opensc パッケージで提供される PKCS#11 ライブラリーをインストールします。PKCS#11 は Public-Key Cryptography Standard のことで、トークンと呼ばれる暗号化デバイスにアプリケーションプログラミングインターフェース (API) を定義します。root として以下のコマンドを実行してください。
~]# yum install opensc
opensc (CoolKey and CAC) でサポートされないスマートカードを使用するには、root として以下のコマンドを実行して coolkey パッケージをインストールします。
~]# yum install coolkey

4.10.4.1. カードからの公開鍵の取得

カードの鍵を表示するには、ssh-keygen コマンドを使用します。-D ディレクティブで共有ライブラリー (以下の例では OpenSC) を指定します。
~]$ ssh-keygen -D /usr/lib64/pkcs11/opensc-pkcs11.so
ssh-rsa AAAAB3NzaC1yc[...]+g4Mb9

4.10.4.2. サーバーへの公開鍵の保存

リモートサーバーでスマートカードを使用した認証を有効化するには、公開鍵をリモートサーバーに移動します。これには、取得した文字列 (鍵) をコピーして、リモートのシェルにペーストするか、ファイル (以下の例では smartcard.pub) にキーを保存して、ssh-copy-id コマンドを使用してください。
~]$ SSH_COPY_ID_LEGACY=1 ssh-copy-id -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 の環境変数を使用する必要があります。

4.10.4.3. スマートカード上の鍵を使用したサーバーの認証

OpenSSH は、スマートカードから公開鍵を読み込み、鍵自体を公開せずに秘密鍵を使用して操作を行います。つまり、秘密鍵がカードから出ることはありません。認証のためにスマートカードを使用してリモートサーバーに接続するには、以下のコマンドを実行してカードを保護する PIN を入力します。
[localhost ~]$ ssh -I /usr/lib64/pkcs11/opensc-pkcs11.so hostname
Enter PIN for 'Test (UserPIN)':
[hostname ~]$
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.10.4.4. PIN でのログインを自動化するための ssh-agent の使用

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

4.10.4.5. その他のリソース

ハードウェアまたはソフトウェアトークンの設定は「Smart Card support in Red Hat Enterprise Linux 7」の記事に記載されています。

4.10.5. 信頼できる鍵および暗号化された鍵

信頼できる鍵および暗号化された鍵 は、カーネルキーリングサービスを使用するカーネルが生成する可変長のシンメトリックキーです。この鍵はユーザースペースでは暗号解除された形式で表示されないので、その整合性が検証可能になります。このため、たとえば拡張検証モジュール (EVM) がこの鍵を使用して稼働中のシステムの整合性を検証かつ確認することができるようになります。ユーザーレベルのプログラムがアクセス可能なのは、暗号化された ブロブ の形式での鍵のみです。
信頼できる鍵は、Trusted Platform Module (TPM) チップというハードウェアが必要になります。これは、鍵の作成と暗号化 (保護) の両方に使用されます。TPM は、storage root key (SRK) と呼ばれる 2048 ビットの RSA 鍵を使ってこの鍵を保護します。
さらに、信頼できる鍵は TPMプラットホーム構成レジスター (PCR) の特定の値のセットを使って保護される場合があります。PCR には、BIOS を反映する整合性管理の値、ブートローダー、およびオペレーティングシステムのセットが含まれています。つまり、PCR で保護された鍵は、これが暗号化された全く同一システム上の TPM でしか暗号解除できないことになります。ただし、PCR で保護された信頼できる鍵が読み込まれると (キーリングに追加されると)、すなわちそれに関連付けられている PCR の値が確認されると、新たな (または将来の) PCR の値で更新可能となります。このため、たとえば、新規カーネルのブートが可能になります。また、ひとつの鍵は異なる PCR の値を持つ複数のブロブとして保存することもできます。
暗号化された鍵は、カーネル AES 暗号化を使用するので、TPM を必要とせず、信頼できる鍵よりもスピーディーになります。暗号化された鍵は、カーネル生成の任意の数を使って作成され、ユーザースペースブロブにエクスポートされる際に マスターキー で暗号化されます。このマスターキーは、信頼できる鍵かユーザーキーとすることができます。後者の場合、暗号化された鍵の安全性は、ユーザーキーによる暗号化と同等のものでしかないという欠点があります。

4.10.5.1. 鍵を使った作業

鍵を使う操作の前には、関連するカーネルモジュールの読み込みが必要になります。信頼できる鍵の場合は trusted モジュール、暗号化された鍵の場合は encrypted-keys モジュールです。root ユーザーで以下のコマンドを実行して、これらモジュールの両方を同時に読み込みます。
~]# modprobe trusted encrypted-keys
Trusted and encrypted keys can be created, loaded, exported, and updated using the keyctl utility. For detailed information about using keyctl, see keyctl(1).

注記

TPM を使用するには (信頼できる鍵の作成および保護目的など)、これを有効かつアクティブにする必要があります。これは通常、マシンの BIOS で設定するか、ユーティリティーの tpm-tools パッケージから tpm_setactive コマンドを使用するとできます。また、TrouSers アプリケーション (trousers パッケージ) のインストールと、TrouSers スイートの一部である tcsd デーモンが稼働して TPM と通信している必要もあります。
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.10.5.2. その他のリソース

以下のオフラインおよびオンラインのリソースでは、信頼できる鍵および暗号化された鍵に関する追加情報が提供されています。

インストールされているドキュメント

  • keyctl(1) — Describes the use of the keyctl utility and its subcommands.

オンラインのドキュメント

関連項目

  • 「高度暗号化標準 — AES」 では、Advanced Encryption Standard (高度暗号化標準) について簡単に説明しています。
  • 「公開鍵暗号」 では、公開鍵の暗号化のアプローチとそこで使用される様々な暗号化プロトコルについて説明しています。

4.10.6. 乱数ジェネレーターの使用

簡単に解読されない安全な暗号鍵を生成するには、乱数のソースが必要になります。一般的に、番号がよりランダムであればあるほど、一意の鍵を得られる可能性が高まります。乱数生成のエントロピー は通常、コンピューティング環境の「ノイズ」または 乱数ジェネレーター のハードウェアを使用することで獲得されます。
rng-tools パッケージの一部である rngd デーモンは、エントロピーを引き出すために環境ノイズと乱数ジェネレーターの両方が使えます。このデーモンは、乱数度のソースが提供したデータがランダムかどうかをチェックし、その後にカーネルの乱数エントロピープールに保存します。これが生成した乱数は、/dev/random および /dev/urandom の各キャラクターデバイスから利用できます。
/dev/random/dev/urandom の違いは、前者はブロックデバイスであり、適切な乱数出力の生成にエントロピーが不十分だと判断すると、乱数の提供が停止される一方で、/dev/urandom は非ブロックソースであり、カーネルのエントロピープールを再利用して無制限の仮の乱数を提供できる、という点です。ただし、この場合のエントロピーは低くなります。このため、長期の暗号鍵の作成には、/dev/urandom は使用しないでください。
rng-tools パッケージをインストールするには、root で以下のコマンドを実行します。
~]# yum install rng-tools
rngd デーモンを起動するには、root で以下のコマンドを実行します。
~]# systemctl start rngd
デーモンのステータスを確認するには、以下のコマンドを実行します。
~]# systemctl status rngd
オプションのパラメーターを使って rngd デーモンを起動するには、直接これを実行します。たとえば、乱数入力の代替ソース (/dev/hwrandom 以外) を指定するには、以下のコマンドを実行します。
~]# rngd --rng-device=/dev/hwrng
The above command starts the rngd daemon with /dev/hwrng as the device from which random numbers are read. Similarly, you can use the -o (or --random-device) option to choose the kernel device for random-number output (other than the default /dev/random). See the rngd(8) manual page for a list of all available options.
任意のシステムでどのソースのエントロピーが利用可能であるかを確認するには、以下のコマンドを root として実行します。
~]# rngd -v
Unable to open file: /dev/tpm0
Available entropy sources:
	DRNG
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
A high number of failures shown in the output of the rngtest tool indicates that the randomness of the tested data is insufficient and should not be relied upon. See the rngtest(1) manual page for a list of options available for the rngtest utility.
Red Hat Enterprise Linux 7 では virtio RNG (乱数ジェネレーター) デバイスが導入され、ホストマシンからエントロピーにアクセスできる KVM 仮想マシンが提供されています。推奨の設定では、hwrng はホストの Linux カーネルのエントロピープールに (/dev/random 経由で) フィードし、QEMU は、ゲストが要求したエントロピーのソースとして /dev/random を使用します。
virtio RNG デバイス

図4.3 virtio RNG デバイス

以前は 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 インストール時にホストのエントロピーが提供されます。