コンテンツにスキップ

6. Linuxの暗号化

6.1. 暗号化の基礎

6.1.1. 暗号化とは

暗号化は暗号文を使用して通信と情報を保護する手法のこと。

コンピュータサイエンスにおいて、暗号化は、解読が困難な方法でメッセージを変換するための、数学的概念とアルゴリズムと呼ばれる一連のルールベースの計算から派生した安全な情報および通信技術を指す。 これらの決定論的アルゴリズムは、暗号キーの生成、デジタル署名、データ プライバシーを保護するための検証、インターネット上の Web ブラウジング、クレジット カード取引や電子メールなどの機密通信に使用される。

暗号化の用途

  • 暗号化 ... 情報をその本当の意味を隠す秘密コードに変換する方法。情報の暗号化と復号化の仕組みは暗号化と呼ばれる
  • 完全性 .... 情報は、変更が検出されない限り、保存中または送信者と目的の受信者の間での転送中に変更されることはないことを保証する
  • 認証 ... 送信者と受信者は、互いの身元と情報の発信元/宛先を確認できる

暗号化の主要な要素

暗号化には2つの主要な要素がある。

  • キー ... データの暗号化に使用されるもの。秘密にしておく必要がある。
  • アルゴリズム ... メッセージのエンコードとデコードに使用されるメソッドのこと。

共通鍵暗号方式(対称暗号方式)

共通鍵暗号方式は暗号化と復号を同じ鍵で行うもの。

AESやDES、blowfishなどが代表例としてある。

このタイプの暗号化は、平文を暗号文に暗号化し、その暗号文を平文に復号化するために同じ鍵が使われるため対称と言える。 一般的に、非対称暗号化よりも高速となる。

公開鍵暗号方式(非対称暗号方式)

公開鍵暗号は暗号化/復号化に公開鍵ペアを使用する暗号。 対になる鍵の一方が公開鍵で、もう一方が秘密鍵となる。

鍵 説明
公開鍵 一般にアクセス可能なリポジトリで公開され、公開鍵ペアの所有者と通信する必要がある人は誰でもアクセス可能
秘密鍵 秘密鍵は所有者のみが所有する

これらの鍵はそれぞれ平文を暗号化された暗号文に変換することができるが、 一方の鍵で暗号化された暗号文はもう一方の鍵でしか復号できない。

特徴は以下の通り。

  • 公開鍵で暗号化された暗号文は秘密鍵でしか復号化できない
  • 秘密鍵で暗号化された暗号文は公開鍵を使ってのみ復号できる
  • 共有秘密鍵を交換することなくメッセージを送信できる

またRSA暗号方式による秘密鍵の生成に関しては「512bitや1024bit程度の長さは容易に計算できる」とされているため、2048bit以上の長さを用いることが推奨されている。

ハッシュによるデータの整合性

ハッシュ関数を用いた暗号化では特定のデータを一定長の固定サイズの値に変換する暗号化を行う。この変換された値はハッシュ値と呼ばれる。

ハッシュの特徴は以下の通り。

  • ハッシュ関数は固定長の出力を生成する
  • ハッシュ値から元のデータを再構築するのは困難(一方向性)
  • セキュリティを向上させるためにソルトを使用してハッシュ化する方法がある
  • ハッシュアルゴリズムにはCRC2(非推奨)、md5、*sha-1などがある

6.1.2. 公開鍵基盤(PKI)とトラストチェーン

公開鍵基盤(PKI)

PKI(公開鍵基盤)は異なるコンピュータシステム間の通信を保護するために使用されるシステムのこと。 暗号化に用いられる「公開鍵」と「公開鍵の持ち主」の関係を保証する仕組みともいえる。

PKIは暗号化キーのペアとデジタル証明書に基づき、公開鍵基盤は認証局の階層と証明書署名要求プロセスで構成される。

認証局(CA)

認証局(CA)はWeb サイト、電子メール アドレス、企業、個人などの身元を検証するために機能する組織のこと。 公開キーの信頼性を検証する第三者といえる。

デジタル証明書として知られる電子文書の発行を通じて、それらを暗号キーにバインドする。 公開キーの信頼性を検証する信頼できる第三者機関と言える。

認証局には以下の役割がある。

  • 有効なCSRに署名する
  • 秘密鍵のセキュリティを維持する
  • 侵害された証明書または悪用された証明書を取り消す

証明書署名要求(CSR)

証明書署名要求(CSR) は基本的に生成される公開キーであり、CA に送信して署名を受けることができるもの。

CAがCSRに署名すると、署名したCAによって信頼される証明書が生成される。

OCSP/CRL

OCSP (オンライン証明書ステータス プロトコル) または CRL (証明書失効リスト) を使用して証明書を無効にするための仕組み。

CAによって使用される。

トラストチェーン

トラストチェーンはX.509が想定する認証局のシステムも、認証局が下位の証明局を認証し、その下位の認証局がさらにその下に位置する認証局を認証する...といった証明の連鎖で成り立つことを想定し「信頼できるものが署名したものは信頼の連鎖に加えられる」という前提に成り立っている様子のこと。

6.1.3. 公開鍵証明書(ディジタル証明書)と認証局

公開鍵暗号方式においては公開鍵証明書によって公開された鍵が意図している所有者のものであることが保証されている必要がある。

公開鍵証明書は、信頼できる第三者として認証局（CA：Certification Authority）によりデジタル署名（後述）されて発行され、その証明書に含まれる公開鍵の真正性と有効性（公開鍵の所有者が正当な所有者であること、証明書が有効期限内であること等）を保証する仕組みです。ちょうど、公的身分証明書が、信頼できる公的機関の発行証明によって信頼性を担保するのと似ている。

公開鍵証明書には、公開鍵そのものに加えて発行者の情報や有効期間などの情報が含まれる。

ディジタル署名

デジタル署名はデータが通信の途中で改ざんされていないこと、またメッセージが作成者本人のものであることを証明するための技術。

デジタル署名は送信するメッセージからハッシュ関数を用いてメッセージダイジェスト（MD）を求め、MDから秘密鍵を用いて署名を生成し送信する。 受信者は、公開鍵を用いて署名を検証（MDを復号）する。

またメッセージからMDを求め、復号したものと照合し、一致していることを確認するという仕組みといえる。

認証局(CA)

認証局(CA)はWeb サイト、電子メール アドレス、企業、個人などの身元を検証するために機能する組織のこと。

デジタル証明書として知られる電子文書の発行を通じて、それらを暗号キーにバインドする。 公開キーの信頼性を検証する信頼できる第三者機関と言える。

認証局には以下の役割がある。

  • 公開鍵証明書の発行
    • 認証局は電子証明書の発行依頼を受けて、申請内容と証明書署名要求（CSR※）と呼ばれる情報を精査した上で公開鍵証明書を発行する
  • 公開鍵証明書の失効、CRLの発行
    • 認証局は申請を受けて証明書の失効手続きを行い、証明書が失効されていることを以下の二つの手段で公開する
      • 証明書失効リスト（CRL：Certificate Revocation List）の発行
      • OCSP（Online Certificate Status Protocol）への応答

また認証局にはパブリック認証局とプライベート認証局(オレオレ認証局,自己証明認証局)がある。 パブリック認証局の発行したルート証明書（認証局が自らの正当性を証明するために発行するデジタル証明書）は、いわゆる公的機関の証明書の扱いであり一般的なメーラやブラウザに組み込まれている。対してプライベート認証局は社内などの制限された場だけで利用することを想定されたもの。運用規定を自由に設定できるという柔軟性がある。

6.1.4. サーバ証明書とクライアント証明書

サーバ証明書

サーバ証明書はでクライアントがアクセスしているサーバが確かに目的の相手に間違いないことを確認するために使用されるもので、サーバの公開鍵を含んだ証明書に認証局が署名をして発行されているのが一般的となる。企業内などでは、プライベート認証局を使って自己署名が行われる場合もある。

Webサイトなどにアクセスする際に提示される。

クライアント証明書

クライアント証明書は企業内LANや外部から自社内にアクセスする場合、クライアント側が正当な権利を持っているか確認する必要がある場合に用いられるもの。

6.2. X.509証明書と公開鍵暗号基盤

6.2.1. OpenSSL

SSLの実装としてのツールにOpenSSLがある。 SSLはWebサーバとWebブラウザ間でよく使用される暗号化通信を行うための設定で、使用にはサーバ証明書が必要になる。

サーバ証明書にはサーバについての情報と、サーバの公開鍵、証明書を発行した認証局の情報とその署名が含まれる。 署名は、証明書を発行する認証局（CA）が「認証局の秘密鍵」で行う。SSLサーバはこの証明書をクライアントに渡し、クライアントであるブラウザは予め内蔵している認証局の公開鍵を使って、受け取った証明書の署名を復号する。復号できれば証明書が改ざんされていない（接続先サーバが正しい）ことが確認できる。

なお、サーバ証明書の署名はルートCAもしくは中間CAによって署名されますが、現在ではセキュリティレベルの向上などの理由で、ルートCAが直接署名するのではなく、中間CAを1つ以上用いる階層構造を取る認証が主流となっている。

opensslの設定ファイル

openSSLの設定ファイルは以下の通り。

  • Debian系 ... /usr/lib/ssl/openssl.cnf
  • RedHat系 ... /etc/pki/tls/openssl.cnf

opensslコマンド

OpenSSLの操作を行うコマンド。

openssl <サブコマンド> [オプション]
サブコマンド 説明
ca CAの管理
dgst メッセージダイジェストの計算
genrsa RSA暗号方式の秘密鍵を生成
rsa RSA暗号方式の鍵管理
req CSRの管理
x509 X.509証明書の管理
s_client SSL/TLSプロトコルを使用し指定しサーバ接続
s_server SSL/TLSプロトコルを使用しデータを受け取るサーバとして動作
ciphers 使用可能な暗号スイートを一覧表示
verify X.509証明書の検証

OpenSSLのコマンド例

# 設定ファイルの確認
openssl ca

# 秘密鍵の作成
openssl genrsa -des3 2048 > /etc/pki/CA/private/cakey.pem

# 秘密鍵の作成
openssl genrsa -<algorithm> -out <key_filename> <key_size>
openssl genrsa -aes128 -out mykey.key 2048

# 公開鍵の作成
openssl req -utf8 -new -key <key_filename> -x509 -days <cert-lifespan> -out <cert_filename> -set_serial 0

# CSRにCAとして署名する
openssl ca -in <CSR> -out <crt>

# CSRの作成
openssl req -new -key <priv_key.pem> -out <output.csr>

# 証明書情報の確認
openssl x509 -in <cert_filename.crt> -text -nout | less

OpenSSLによる証明書の作成と操作

opensslコマンドにより秘密鍵/証明書などを作成できる。 使用例は以下の通り。

# 秘密鍵の生成
openssl genrsa -<algorithm> -out <key_filename> <key_size>
openssl genrsa -aes128 -out mykey.pem 2048

# 自己証明書(オレオレ認証)の生成
openssl req -utf8 -new -key <key_filename> -x509 -days <cert_lifespan> -out <cert_filename>

#認証の表示
openssl x509 -in mycert.crt -text -noout

#CSR(証明書失効リスト)の作成
openssl req -new -key <priv_key.pem> -out <output.csr>

OpenSSLによるX.509証明書形式の変換

#DERをPEMに変換する
openssl x509 -inform der -in certificate.cer -out certificate.pem

#PEMをDERに変換する
openssl x509 -outform der -in certificate.pem -out certificate.der
#p7b/pkcs#7をPEMに変換する
openssl pkcs7 -print_certs -in certificate.p7b -out certificate.pem.

#PEMをp7b/pkcs#7に変換する
openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

OpenSSLによるトラブルシューティング

## セキュアなコネクションの確立
openssl s_client -connect <host>:<port> 

## トラストチェーンの検証 
openssl verify -verbose <certificate> 

## CAチェーンのすべての証明書を確認する
openssl s_client -connect <host>:<port> -showcerts

## 証明書の詳細を見る
openssl x509 —text <cert_file>

6.2.2. Genkey

genkeyはOpensslの互換ツールでRedHat系OSで使用できるもの。 コマンドはOpenSSLより単純で、TUIが使用できる。

6.2.3. X.509証明書

X.509とはITU-T（国際通信連合（ITU）の電気通信標準化部門）の規格であり、公開鍵暗号方式に基づいて認証局によって発行される公開鍵証明書の標準形式などを定めてたもの。

X.509証明書にはいくつかのエンコードタイプがあるが、代表的なものにPEMとDERがある。

  • PEM
    • DERをBase64でテキスト化したもの
    • サーバー証明書、中間証明書、および秘密キーを1つのファイル内に含めることができる
    • テキスト エディタで開くことができる
    • OpenSSLデフォルトのファイル形式
  • DER
    • JavaベースのWebサーバーに使用される
    • Binary形式
  • PKCS#7
    • 証明書のみを保存する
    • 秘密キーは保存できない
  • PKCS#12
    • Windowsプラットフォームで使用される
    • サーバー証明書、中間証明書、および秘密キーをパスワードで保護された単一の.pfxファイル内に保存できる

また、それぞれの特徴を表にまとめると以下の通り。

フォーマット エンコード ファイルフォーマット
PEM Base64 ASCII .crt、.pem、.cer、.key
DER Binary .der または .cer
PKCS#7 Base64 ASCII
PKCS#12 Binary .pfx、 .p12

X.509証明書のフィールド

フィールド1 フィールド2 説明
tbsCertificate 証明書の基本情報と公開鍵の情報
version X.509証明書のバージョン X509v3では3(0x2)
serialNumber 証明書の識別番号
signature CAが証明書に署名する際のアルゴリズム
issuer CAの名前
validity 証明書の有効期間
subject 証明書の所有者の名前
subjectPublicKeyInfo 証明書所有者の公開鍵に関する情報
extentions 拡張領域。X.503v3にて追加
signatureAlogorithm 証明書の署名アルゴリズム
signatureValue デジタル署名

X.509証明書の拡張フィールド

拡張フィールド 説明
basicConstraints 基本制約。証明書がCAnのものである、証明書のパスの深さなどを指定
authorityKeyIdentifier 認証局鍵識別子
subjectKeyIdentifier サブジェクト識別子
KeyUsaga 鍵の用途
extendedKeyUsage 拡張鍵用途
certificatePolicies 証明書の目的や発行時情報
subjectAltName サブジェクトの代替名
cRLDistributionPoints CRLの配布ポイント
authorityInfoAccess 機関情報アクセス

6.3. 暗号化/署名および認証のX.509証明書

6.3.1. SSL/TLS

SSL(Secure Sockets Layer)/TLS(Transport Layer Security)はトランスポート層の暗号化プロトコルでWebトランザクションを保護するために開発されたが、トランスポート層でTCPを利用するあらゆる種類のネットワークトラフィックの保護にも使用できる。

TLSとしてIETFによってRFC化され、SSL3.0からTLSが派生した。SSL3.1がTLS1.0に該当します。一般的名称として、SSLという言葉が広く普及しているため、SSL/TLSと呼ばれている。

現在、SSLは脆弱性が発見されているため使用は非推奨となっており、TLSの使用が推奨されている。暗号強度等ではTLS1.2、もしくは2018年3月にIETFに承認されたTLS1.3が良い。

項目 SSL TLS
正式名称 Secure Sockets Layer Transport Layer Security
プロトコル Web トラフィックを保護するために使用されていたプロトコル TLS プロトコルは、SSLv3 に代わる TLS 1.0 から始まる SSL の後継プロトコル
状況 最新バージョンは SSLV3 だが、これは非推奨 現在の標準は TLS 1.2 。ただし、TLS 1.3 はインターネット標準として目的とされている

TLS/SSLのハンドシェイクプロセス

TLS は、データを安全に送信する際のパフォーマンスとセキュリティの間で適切な妥協点を提供するため、公開鍵暗号方式と共通鍵暗号方式を組み合わせて使用​​する。 手順は以下の通り。

  1. 各TLS証明書は、公開キーと秘密キーで構成されるキーペアで構成される。これらのキーは、Web サイトのトランザクション中に相互作用する。
  2. Web サイトにアクセスするたびに、クライアント サーバーと Web ブラウザが通信して、安全な TLS/SSL 暗号化接続が確立されていることを確認する。
  3. Web ブラウザ (またはクライアント) がセキュリティで保護された Web サイトにアクセスすると、Web サイト サーバーは TLS/SSL 証明書とその公開キーをクライアントと共有して、安全な接続と一意のセッション キーを確立する。
  4. ブラウザは、SSL 証明書の発行者または認証局を認識し、信頼していることを確認します。また、ブラウザは、TLS/SSL 証明書の有効期限が切れていないこと、取り消されていないこと、および信頼できることを確認します。
  5. ブラウザは対称セッションキーを送り返し、サーバーは秘密キーを使用して対称セッションキーを復号化する。次に、サーバーはセッションキーで暗号化された確認応答を送り返し、暗号化されたセッションを開始する。
  6. サーバーとブラウザは、送信されるすべてのデータをセッションキーで暗号化するようになる。これらは、メッセージのプライバシー、メッセージの整合性、およびサーバーのセキュリティを保護する安全なセッションを開始することを意味する。

トランスポート層のセキュリティ

SSL と TLS はどちらも以下のセキュリティ要件を満たす。

  • 交換されるデータを安全に暗号化する
  • 少なくとも1人の当事者を認証する
  • データの整合性を確保する
  • リプレイ攻撃を防ぐ

トランスポート層のセキュリティは、PKI と一般的な暗号化の使用を通じてこれを実現する。

SSLに対する中間者攻撃

  • POODLE攻撃の脆弱性
    • POODLE攻撃(CVE-2014-3566) はSSLセッション内の選択されたコンテンツを復号化できる中間者(MITM) エクスプロイトのこと。
  • BEAST攻撃の脆弱性
    • BEAST攻撃(CVE-2011-3389)はSSL/TLS 暗号ブロック チェーン (CBC) の弱点を悪用し、中間者攻撃者が Cookie データなどの特定のセッション情報を何からでも回復できるようにする。

ApacheのHTTPSの設定(SSL/TLSを使ったHTTP)

HTTPSと呼ばれるプロトコルはWebのプロトコルであるHTTPをSSL/TLSでセキュアなプロトコルとして通信させるもの。 代表的なWebサーバ（httpd）であるApacheもSSL/TLSに対応しており、パッチまたはモジュール(mod_ssl)での対応が可能となっている。

Apacheの基本的な動作設定は/etc/httpd/conf/httpd.confにて行う。 SSLの設定も同ファイルに記述できるが、デフォルトでは/etc/httpd/conf.d/ssl.confが用意されており、ここに記述するのが一般的となる。

サーバ認証関連のディレクティブ 説明
SSLEngine on/off SSL/TLSプロトコルを使用するかどうかの設定
SSLProtocol SSLv3/TLSv1/TLSv1.2 SSL/TLSのバージョン指定
SSLCipherSuite !AAA/-AAA/+AAA 使用する暗号化スイートの指定
SSLCertificateFile サーバ証明書の指定
SSLCertificateKeyFile サーバの秘密鍵を指定
SSLCertificateChainFile 中間認証局(CA)の証明書を指定
クライアント認証関連のディレクティブ 説明
SSLCACertificateFile クライアント証明書を発行したCAの証明書を指定
SSLVerifyClient クライアントの認証レベルの指定
SSLVerifyDepth 有効なクライアント証明書を確認する深さを指定
OCSP stapling関連のディレクティブ 説明
SSLUseStapling on/off OCSP staplingの有効/無効
SSLStaplingResponderTimeiut OCSP staplingの応答タイムアウト
SSLStaplingReturnResponseErrors on/off OCSP staplingのエラーをクライアントに送信するかどうか
SSLStaplingCache OCSP staplingのキャッシュに使用するストレージタイプ
SNI関連のディレクティブ 説明
SSLStrictSNIVhostCheck on/off 非SNIクライアントの挙動設定

SNI

SNI(Server Name Indication)は1つのWebサーバで複数のドメインのSSL/TLS証明書を利用できる仕組み。 名前ベースのVirtualHostであってもSSLに対応できるようにしたSSL/TLSの拡張仕様ともいえる。

SNIでは、コネクション確立時にクライアントからサーバへアクセスしたいホスト名を渡すことにより、適切なサーバ証明書を返すことができる仕様とした。 これにより、コネクション前にホスト名を確認することが可能となり、名前ベースの仮想ホストを使用可能となった。

HSTS

HSTS(HTTP Strict Transport Security)はWebセキュリティの仕組みの一つでウェブサイトがHTTPSを使用することを強制するための仕組みのこと。 HSTSはウェブブラウザに対して、特定の期間内でHTTPSを使用するように指示する。

HSTSの主な目的はMITM攻撃を防ぐことにある。 通常、攻撃者はHTTP通信を盗聴し、変更することができるが、HTTPSを使用すると通信が暗号化され、改ざんや盗聴が難しくなる。 HSTSは、ウェブサイトがHTTPSを使用するように強制し、ユーザーが暗号化された通信を確実に得ることを支援する。 クライアントが一度HTTPSでアクセスしたサイトがHSTSを強制するようクライアントに指示した場合、以後一定の有効期間内はクライアント側からはHTTPSで通信を行うようになる。

また、初回のHTTPSアクセスまでの脅威に対応するため、予め「このドメインはHSTSに対応している」という情報をブラウザ側に知らせておく「プリロードHSTS（Preload HSTS）」という仕組みも提唱されてきている。

Apacheのクライアントアクセス制御

SSL/TLSを利用したApacheでは、クライアントの証明書を使ってアクセス制御を行うことができる。 「ssl.conf」では設定項目SSLVerifyClientにより、クライアントに対して証明書を提示させるよう指定することができる。

OCSP Stapling

OCSPはクライアントがOCSPサーバ（OCSPレスポンダ）へ問い合わせを行い、証明書の失効確認を行うためのプロトコル。

しかし、レスポンダとの通信次第で問い合わせに遅延が発生し、確認手続きが失敗するなどの弊害もあった。これに対応する方法としてOCSPを拡張したものが、OCSP stapling（OCSPステープリング）となる。 クライアントが行っていたOCSPレスポンダへの問い合わせを証明書提供側のサーバが行うことにより、クライアントが確認手続きで失敗するリスクをなくす。 「ssl.conf」では設定項目SSLUseStaplingにて有効化するか否かを選択できる。

#OCSP Stapling: 
SSLUseStapling On 
SSLStaplingCache "shmcb:logs/ssl_stapling(32 768)"

CipherSuite

CipherSuiteは暗号化の組み合わせのことを指す。 SSL/TLSで使用できる暗号化には様々な種類があり、暗号といっても、目的によって使用できる暗号技術が異なる。

SSL/TLSの動作は複数の暗号技術の組み合わせで成り立っており、通信の開始から終了までの間に数種類の暗号技術を使用する。 この組み合わせは暗号スイートと呼ばれ、OpenSSLではopenssl chipersコマンドで使用できる暗号スイートを確認できる。

6.4. 暗号化ファイルシステム

6.4.1. ディスク暗号化の基礎

ディスク全体の暗号化は盗難や偶発的な紛失の場合にディスクを保護する。 ディスク全体の暗号化では、スワップファイル、システムファイル、休止状態ファイルを含むディスク全体が暗号化される。 暗号化されたディスクが紛失、盗難された場合でも、ドライブの暗号化状態は変更されず、許可されたユーザーのみがその内容にアクセスできる。

ファイルの暗号化では起動中にシステムにログインし、その後コンピュータを放置した場合、権限のないユーザーはディスク上の任意のファイルを開くことができないようにできる。 またファイルシステムの暗号化は以下の方法がある。

  • ブロックデバイス
  • ファイルシステムレベル

ディスク暗号化ツール

ディスクを暗号化するためのツールは以下のようなものがある。

  • dm-encryptとLUKS (通常は連携して使用する)
  • cryptmount (エンドユーザーがデータを暗号化するのに役立ちます)
  • eCryptfs (ファイル システム レベルの暗号化)
  • EncFS (eCryptfs互換)

6.4.2. ブロックデバイスとファイルシステムの暗号化

dm-cryptとLUKS

dm-cryptsはブロックデバイスの暗号化を行う暗号化の方法の1つ。 dm、すなわちdevice-mapper（デバイスマッパー：物理デバイスと論理デバイスをマッピングするLinuxカーネルの標準機能）の暗号化機能を使ってデバイス全体に対する暗号化を行う。

dm-cryptを扱うためのツールには以下の2つがある

  • cryptsetup ... 暗号化デバイスの作成・管理・各種操作
  • cryptmount ... 暗号化ファイルシステムのマウント・アンマウントなど

cryptsetupコマンドでは、暗号化のタイプとしてplain（plain dm-crypt）モードとLUKSモードを選択することができる。

LUKS（Linux Unified Key Setup：ラックス）とはLinuxにおけるディスク暗号化の標準仕様で、dm-cryptを用いて実装されている。 ファイルシステムに依存しておらず、Linuxで一般的なファイルシステムのext3やext4、Brtfs、さらにSWAP領域を暗号化することも可能である。

  • /etc/crypttab
    • cryptsetupで設定した暗号化ボリュームをOS起動時に自動的にマウントするためには、「/etc/crypttab」にエントリを追加する必要がある
    • 「/etc/crypttab」は「/etc/fstab」より先に読み込まれるため、暗号化を解除した上で復号されたファイルシステムをマウントすることが可能になる

eCryptfs

eCryptfsはファイルシステムの暗号化を行う技術の一つで、ファイルやディレクトリを暗号化することができるもの。 dm-cryptと異なり、ブロックデバイスではなくファイルやディレクトリを暗号化する。 カーネルモードで動作し、各ファイルのヘッダに暗号化メタデータを持つことにより、ホスト間で暗号化ファイルをやり取りすることができる。 特にUbuntuにおけるホームディレクトリの暗号化の仕組みとして広く利用されている。

またecryptfsdと呼ばれるデーモンによって制御が行われ、ecryptfs-*コマンドで各種操作を行う。

ENcFS

ファイルの暗号化のシステムとして、eCryptfsのほかにEncFS（Encrypted Filesystem）が知られている。

歴史はeCryptfsよりも古く、暗号化ファイルシステムとしては最も扱いやすいファイルシステムと言われている。FUSE（Filesystem in Userspace：カーネルを弄ることなくユーザ空間でファイルシステムを作成するソフトウェア）を用いているため制約もありますが、GUIや、WindowsやMacなどのOSもサポートされているのが特徴である。

6.4.3. dm-crypt

dm-cryptはブロックデバイスの暗号化を行うコマンド。 dm-cryptを扱うためのツールには以下の2つがある。

  • cryptsetup ... 暗号化デバイスの作成・管理・各種操作
  • cryptmount ... 暗号化ファイルシステムのマウント・アンマウントなど

cryptsetupコマンド

暗号化ファイルシステム利用を行うコマンド。

cryptsetup <アクション> <アクションごとのオプション>
アクション【plainモード】 説明
open --type plain デバイス名 名称 マッピング名とデバイスを指定して暗号化マッピングの作成
close 名前 / remove 名前 暗号化マッピングの削除
resize 名前 暗号化マッピングのサイズ変更
status 名前 暗号化マッピングの状態表示
アクション【LUKSモード】 説明
luksFormat デバイス名 デバイスをLUKSパーティションとして初期化
luksOpen デバイス名 名前 デバイスとLUKSパーティション名を指定しLUKSパーティションを開く
luksClose 名前 Luksパーティションを閉じる
luksAddkey デバイス名 キーファイル名 LUKSパーティションにパスフレーズを追加
luksKillSlot デバイス名 キースロット番号
luksDelKey デバイス名 キースロット番号		 LUKSパーティションから設定したパスフレーズを削除
luksDump デバイス名 LUKSパーティションの状態表示
isLuks デバイス名 デバイスがLUKSパーティションの場合は真をそうでない場合は偽を返す

cryptmountコマンド

cryptmount [オプション] [ターゲット]
オプション 説明
-m ターゲットのマウント
-u ターゲットのアンマウント
-S ターゲットのマウント状況の表示
-l 利用可能なターゲットの基本情報の表示
-s ターゲットのスワップ領域の有効化
-x ターゲットのスワップ領域の無効化
-p ターゲットに対するデバイスの準備
-r ターゲットから全デバイスの開放
-c ターゲットのパスワード変更
-g 復号キーの作成

cryptsetupによる暗号化デバイスの利用方法

cryptsetupを用いて暗号化デバイス（パーティション）を利用する流れは以下の通り

  1. （LUKSモード利用時）luksFormatによるパーティションの初期化
    • cryptsetup luksFormal /dev/sdb2
  2. openまたはluksOpenによる暗号化マッピングの作成
    • cryptsetup open --type plain /devsdb1 dm01
    • cryptsetup luksOpen /dev/sdb2 dm02
  3. mkfsおよびパーティションのマウント
    • mkfs.ext4 /dev/mapper/dm02
    • mount /dev/mapper/dm02 /mnt/luks

なお利用終了時は、アンマウントし暗号化マッピングを削除する。

  1. パーティションのアンマウント
    • unmount /mnt/luks
  2. closeまたはluksCloseによる暗号化マッピングの削除
    • cryptsetup close dm01
    • cryptsetup luksClose dm02

6.4.4. eCryptfs

eCryptfsはファイルシステムの暗号化を行う技術の一つで、ファイルやディレクトリを暗号化することができるもの。 擬似ファイルシステムとも呼ばれ、マウントすることでeCryptfs層を通過させることにより復号を行う。

カーネルモードで動作し、各ファイルのヘッダに暗号化メタデータを持つことにより、ホスト間で暗号化ファイルをやり取りすることができる。 特にUbuntuにおけるホームディレクトリの暗号化の仕組みとして広く利用されている。 またecryptfsdと呼ばれるデーモンによって制御が行われ、ecryptfs-*コマンドで各種操作を行う。

ecryptfsコマンド

ecryptfsコマンドはecryptfsの操作を行うコマンド。 mount.ecryptfs, umount.ecryptfsでも操作をおこ会う。

オプション 説明
ecryptfs-setup-private 暗号化ディレクトリのセットアップ
ecryptfs-migrate-home ユーザディレクトリの暗号化
ecryptfs-mount-private 暗号化ディレクトリのマウント
ecryptfs-umount-private 暗号化ディレクトリのアンマウント
ecryptfs-unwrap-passphrase パスフレーズの複合 
# eCryptfsのセットアップを行う
ecryptfs-setup-private

# 暗号化ディレクトリのマウント、アンマウントを行う
ecryptfs-mount-private
ecryptfs-umount-private

# rootユーザが、一般ユーザのホームディレクトリ全体を暗号化するコマンド
ecryptfs-migrate-home

# 「wrapped-passphrase」を復号する
ecryptfs-unwrap-passphrase

なおファイルのマウントはmount -t encryptfsコマンドでも可能となる。 また、マウントした状態（復号した状態）でバックアップを取ると、暗号化されていないデータもバックアップされることになるので注意する。 暗号化した状態のみにしたい場合はumountしてからバックアップを実施する。

eCryptfsのディレクトリ構造

ecryptfs-migrate-homeコマンドなどにより暗号化ディレクトリを作成すると、以下のようなファイルやディレクトリが作成される。

$HOME
  ├ Private/ ... 復号されたデータを含むマウントポイント
  ├ .ecryptfs/
  │  ├ Private.mnt ... 暗号化ディレクトリのマウントポイントが書かれたファイル
  │  ├ Private.sig ... 暗号化パスフレーズの署名ファイル
  │  ├ wrapped-passphrase ... マウント用の暗号化パスフレーズ
  │  ├ auto-mount ... 自動マウント用の空ファイル
  │  └ auto-umount ... 自動アンマウント用の空ファイル
  └ .Private/ ... 暗号化されたデータを含むディレクトリ

6.4.5. ENcFS

encfsパッケージは ecryptfs と同様の機能を提供するが、スーパーユーザー以外が使用するように設計されている。

6.5. DNSと暗号化

6.5.1. DNSの概要

DNSとは

DNSはIPアドレスやその他のデータを保存し、名前によるクエリを可能にする階層型の仕組みのこと。 DNS サーバーはドメイン名のデータベースを保存し、ネットワーク内のクライアントからの DNS クエリに基づいてドメイン名を処理する。

DNSサーバの種類

DNSサーバには以下の種類がある。

  • マスタDNSサーバ(権威DNSサーバ)
    • ゾーンファイルを所有するDNSサーバ
    • A、AAAA、CNAME などのDNS名レコードを保持する
  • スレーブDNSサーバ(キャッシュDNSサーバ)
    • マスターDNSサーバのゾーン情報をコピーするDNSサーバ
    • ドメインに対する以前のクエリに基づいてキャッシュファイルを構築している

再帰問い合わせと反復問い合わせ

ドメイン名とIPアドレス対応に関する問い合わせは再帰問い合わせ（Recursive query）と反復問い合わせ（Iterative query）の２種類がある。

  • 再帰問い合わせ
    • リゾルバからの問い合わせ要求を受けたDNSサーバが、他のDNSサーバに問い合わせを行い、その最終的な結果をリゾルバに応答する必要のある問い合わせ
  • 反復問い合わせ
    • リゾルバから再帰問い合わせを受けたキャッシュDNSサーバが、再帰問い合わせの結果を返すために、答えを得られるまで繰り返し他のDNSサーバへ行う問い合わせのこと

DNSゾーン

DNS構成はゾーンとリソースレコード で構成される。 ゾーンの種類は以下の通り。

  • パブリックDNSゾーン
    • インターネットから参照できるゾーン
    • パブリックゾーンに DNS レコードを作成して、インターネット上にサービスを公開できる
  • プライベートDNSゾーン
    • パブリックインターネット経由でクエリできないゾーンのこと
  • サブゾーン
    • ゾーンの所有者が NS レコードを使用してサブドメインを別のネーム サーバーに委任できるもの
    • example.comの場合、aaa.example.comやbbb.example.com作成し、親ドメインのゾーンから見つけられるようにする(委任)するもの

スプリットビューDNS(スプリットホライズンDNS)

スプリットホライズンDNSを使用すると、要求に応じて同じ名前に対して異なる回答 (異なるリソースレコードセット) を提供できる。

この機能は、クエリが開発ネットワークから送信された場合はアプリの開発/ステージング バージョンを提供し、クエリがパブリックインターネットから送信された場合はアプリの運用/公開バージョンを提供するといったことに利用できる。

リソースレコード

リソースレコードはドメイン名と IP アドレスに関するデータを保存するために使用されるもの。 DNSゾーンのデータベースは、リソース レコードのコレクションで構成される。 各リソース レコードは、特定のオブジェクトに関する情報を指定する。

リソースレコードタイプ 説明
SOA 管理情報の記述
NS ゾーンを管理するDNSサーバを記述
MX メールサーバを記述(正引きのみ)
A ホスト名に対するIPアドレスを記述(正引きのみ)
AAAA ホスト名に対するIPv6アドレスを記述(正引きのみ)
CNAME ホスト名の別名に対するホスト名を記述(正引きのみ)
PTR IPアドレスに対するホスト名を記述(逆引きのみ)
TLSA デジタル署名されたレコード。サーバ認証に使われる証明書や鍵の情報がドメイン名に対して関連付けられてDANE(DNSを使った認証の仕組み)で用いられる

レコードセット

レコードセットは同じ名前と同じタイプで、データ値が異なるレコードのこと。 以下は同じ名前とタイプを持つ複数のレコードを含むレコードセットの例。

DNS名 タイプ TTL (秒) データ
db-01.dev.gcp.example.com A 50 10.128.1.35
db-01.dev.gcp.example.com A 50 10.128.1.10

6.5.2. ドメインレジストラ

ドメインレジストラはパブリックゾーンのインターネットドメイン名の予約を管理する組織のこと。 レジストラは汎用トップレベル ドメイン (gTLD) レジストリまたは国コード トップレベル ドメイン (ccTLD) レジストリによって認定される必要がある。

6.5.3. SOAレコードのシリアル番号

SOAレコードのシリアル番号はDNSゾーンのバージョン番号のこと。 すべてのネームサーバーがゾーンの最新のバージョンであるためには、それらのネーム サーバーが同じSOAシリアル番号を持っている必要がある。

EDNS

EDNSはDNSの拡張プロトコルEDNS（Extension mechanism for DNS）のこと。 DNSでUDPを用いる場合、パケットサイズが512byteを超えることができないという制約を緩和するためのものともいえる。 EDNS の最も一般的な実装はDNSSECである。

また、EDNSは基本的なDNSプロトコルの枠組みは残したままで512byte以上の通信を可能にする。

DOビット/ADビット

EDNSによって拡張されたDNSパケットでは、DO bitという識別情報がやりとりされる。 DO＝「DNSSEC OK」bitであり、このbitを識別できることがDNSSECを使用できる前提となる。つまりENDSを理解できない場合はDNSSECを利用といえる。

またDNSSECで認証確認が成立した場合は、DNS応答のAD（Authentic Data）ビットに1が格納される。

6.5.4. BINDの保護

TSIG

TSIGはトランザクション署名とも呼ばれるDNS メッセージを保護し、安全なサーバー間通信を提供するための仕組みのこと。BIND v8.2 以降で使用できる。 DNSサーバ同士でなりすましを防ぐために認証を行う仕組みともいえる。

TSIG は2つのDNS サーバー間の次のタイプのトランザクションを保護できる。 TSIG は、共有シークレットと一方向ハッシュ関数を使用して DNS メッセージを認証する。

chroot jailによるBIND実行

chrootは指定したディレクトリを新しいルートディレクトリとしてプロセスを制限できる機能のこと。 この機能によりディレクトリ内のソフトウェアが乗っ取られても、被害をソフトウェア内だけにとどめることができる。

/etc/named.confの主要なディレクティブ

CentOSにおける設定例は以下の通り。

options {
        listen-on port 53 { 127.0.0.1; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        secroots-file   "/var/named/data/named.secroots";
        recursing-file  "/var/named/data/named.recursing";
        allow-query     { localhost; };

        recursion yes;

        dnssec-enable yes;
        dnssec-validation yes;

        managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";

        /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
        include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
ディレクティブ 説明
allow-query ネームサーバーへのクエリを許可するホストを指定する
allow-recursion 再帰クエリに適用できる。デフォルトではすべてのホストがネームサーバー上で再帰的クエリを実行できる。
allow-transfer ゾーンの情報の転送要求を許可するスレーブサーバーを指定する。デフォルトではすべての転送リクエストが許可される。
allow-update ゾーン内の情報を動的に更新できるホストを指定する。デフォルトでは、すべての動的更新リクエストが拒否される。

Rndc

rndc (リモート ネーム デーモン コントロール)は、BIND にてローカルホストまたはリモートホストから指定されたデーモンをコマンドラインで管理できるようにするツール。BIND 9.0以降で使用できる。

rndcは、デジタル署名された名前付きコマンドを TCP 接続経由で送信する。

rndc の設定ファイルは/etc/rndc.confとなる。 この構成ファイルには、接続するネームサーバーやデジタル署名に使用するキーなどの構成情報が保存される。

rndc ユーティリティは、初期化スクリプトを使用してnamedが開始されるときに開始される。 rndc.confファイルはrndc-confgenコマンドユーティリティを使用してランダムキーを使用して生成できる。

6.5.5. DNS関連のコマンド

digコマンド

dig(Domain Information Groper)コマンドはDNSにクエリを実行するためのコマンド。 DNS 問題の検証とトラブルシューティングに使用できる。

dig <ドメイン名>
digコマンド 説明
dig google.com MX ドメインの MX レコードをクエリする
dig google.com SOA ドメインの SOA レコードをクエリする
dig google.com TTL ドメインの TTL レコードをクエリする
dig @8.8.8.8 google.com クエリに別の DNS サーバーを使用する
dig digコマンドのバージョンとルートDNS サーバーを表示します

delvコマンド

delvコマンドはBIND 9.10以降のdigコマンドの後継ツール。

delv <オプション> ドメイン名
オプション 説明
+rtrace クエリされたすべてのレコードリソースをリストするだけ。DNSSEC の詳細は含まれない
+mtrace rtrace と同じだが、すべてのレコードリソースの完全な内容が含まれる
+vtrace 多くの追加メモを含む検証プロセスの追跡

6.5.6. DNSSECによるDNSの保護

DNSSEC

DNSSECはDNSの応答にデジタル署名の機能を使って正当性を付与し、改ざんされていないこと、正当な管理者の管理しているレコードであることを保証する仕組みのこと。

DNSはもともとルートサーバから始まる名前解決の木構造で、順に権限移譲しながら最終的な名前解決に辿り着くという仕組みとなる。 この際、自己の署名に対する公開鍵を上位DNSサーバへ登録することで、信頼される権威サーバであることを担保し、これによりその応答レコードも信頼される...という信頼の連鎖によって一覧のDNSレコードの信頼性を確保する。

DNSサーバは、ドメイン情報を保持・提供する権威DNSサーバと、権威DNSサーバに問い合わせをするキャッシュDNSサーバに分かれているが、DNSSECを使用するにはそれぞれがDNSSECに対応している必要がある。

DNSSECでは2種類の鍵を用いる

  • ゾーンの署名鍵（ZSK：Zone Signing Key）... ゾーンに署名する
  • 鍵の署名鍵（KSK： Key Signing Key）... ゾーンに署名した鍵に署名する

それぞれは公開鍵と秘密鍵のペアになっている。

DNSSECを利用するためにはBINDの場合、設定ファイル/etc/named.confのoptionsセクションへ以下の二つの項目を設定する必要がある。

options {
   dnssec-enable   yes; # DNSSECの有効（yes）/無効（no）を設定する
   dnssec-validation  auto; # DNSSEC検証の有効/無効を設定する (auto または yes)
   ：                       # auto: DNSSEC検証を有効にし、トラストアンカー
   ：                       # yes: DNSSEC検証を有効にする。トラストアンカー（trusted-key）を手動で設定する必要がある
   ：                       # no : DNSSEC検証を無効にする
   ：（以下省略）

これらのパラメータは、BINDのバージョンによってデフォルト値が異なる。 BINDのバージョンを確認するには、BINDサーバ上で直接named -vコマンドを実行するか、クライアントからBINDサーバへ向けて確認するには上述のdigコマンドを使用できる。

named -v

dig

セキュリティのためにバージョンを隠す場合は設定ファイル/etc/named.confのoptionsセクションに以下のように記載する。

options {
    version "表示したい文字列";
    ：（以下省略）

DNSのリソースレコード

DNSはIPアドレスとドメイン名とを紐づけるためのデータベースをリソースレコードと呼ばれる形で保持する。 DNSSECで使用されるリソースレコードは以下の通り。

リソースレコード 説明
DS KSK公開鍵のハッシュ値を含む情報
親ゾーンに登録すると信頼の連鎖を構築する
DNSKEY 公開鍵の情報
キャッシュDNSサーバが署名を検証するために公開鍵を使用する
RRSIG 各リソースレコードへのデジタル署名
キャッシュDNSサーバが権威DNSサーバからの応答に対する正当性を検証するために使用
NSEC 存在しないサーバへ問い合わせがあった際に不在証明のため辞書順で並べた際に次の位置するゾーン情報を示す
NSEC3 NSECを改良したもの。直接のゾーン名ではなくハッシュ化されたゾーン名を示す
NSEC3PARAM 権威DNSサーバがNSEC3を生成する際に必要な情報
TLSA DANEにおいて用いられるレコード(ドメイン名にX.509証明書情報の紐づけ)

TLSAレコードを除き、基本的には署名を行うと署名や公開鍵を含んだレコード（ゾーンファイル）が作成される。 DNSKEYリソースレコードには上述の通りKSK・ZSKの公開鍵が含まれ、これらは各リソースレコードの検証に使用される。

BINDのDNSSEC関連ユーティリティ

DNSサーバソフトウェアであるBINDには、サーバやKSK、ZSKの生成・管理などを行うための以下のようなコマンドユーティリティがある。

コマンド 機能
dnssec-keygen DNSSECのZSK/KSKを生成する
dnssec-signzone ゾーンファイルへの署名を行う(NSEC, NSEC3, RRSIG, DNSKEYなどの生成)
dnssec-settime 鍵ファイルのメタデータである時間の表示/変更
dnssec-dsfromkey 鍵ファイルから上位サーバに登録するDSレコード生成する
openssl TLSAレコードの検証を行う
rndc BIND 9.0以降の制御設定ツール
delv BIND 9.10以降の検証/解析ツール

6.5.7. DNSSECの設定

dnssec-keygenコマンド

dnssec-keygenはDNSSECのキーを生成することができるコマンド。

dnssec-keygen -a RSASHA256 -b 512 -n ZONE -f KSK myzone.
オプション 説明
-a アルゴリズムの指定
-b キーサイズ
-n nametype
-f 指定されたフラグをKEY/DNSKEYレコードのフラグフィールドに設定する

dnssec には、ゾーンに署名するための ZSK キーのペアも必要となる。

dnssec-signzoneコマンド

dnssec-signzone はゾーンに署名しゾーンの署名付きバージョンを生成するコマンド。

dnssec-signzone -o myzone. -S db.myzoneFetching ZSK 63075/RSASHA256 from key repository.

ファイル内部は以下のようになる。

; File written on Mon Apr  9 01:45:42 2018
; dnssec_signzone version 9.10.3-P4-Ubuntu
myzone.            604800    IN SOA    myzone. root.myzone. (
                    51         ; serial
                    604800     ; refresh (1 week)
                    86400      ; retry (1 day)
                    2419200    ; expire (4 weeks)
                    604800     ; minimum (1 week)
                    )
            604800    RRSIG    SOA 8 1 604800 (
                    20180509074542 20180409074542 63075 myzone.
                    eHu3B0s9AcclEMfkaXK+zUcqnhYTRXO2BBoR
                    s4z9DGxbwcTXoy8MbIACkuVOhkM6+tQ8r7pr
                    clIKoUALm4I4mQ== )

dnssec-settimeコマンド

指定されたキーの有効期間を管理するコマンド。

dnssec-dsfromkeyコマンド

特定の KSK の DS RR を生成するために使用されるコマンド。

6.5.8. DANE

DANEはDNSSECの技術を応用した認証の仕組みのこと。 DNSSECの導入により、DNSサーバの応答の正当性が検証できるようになった。

DANEで用いられるリソースレコードをTLSAレコードと呼ぶ。

TLSAレコード

TLSAレコードはTLS サーバー証明書または公開キーを、レコードが見つかったドメイン名に関連付けるために使用される。