DNSSEC

Key Management　Part1

http://www.isc.org/files/DNSSEC_Ke

y_Management.pdf

を訳してみた

訳：qt.takada

このセッションの参加者

• Alan Clegg

– ISC Training and Support Engineer

• Larissa Shapiro

– ISC Product Manager

Part1の内容

• part2、3では以下の話題を扱う

– 鍵のロールオーバ方針

– ロールオーバのツールとその使用方法

• Part1では、鍵の配置について解説

そもそも鍵とは何か？

• ZSK(Zone Signing Key)

– ゾーン内のリソースレコードに署名する鍵

• KSK(Key Signing Key)

– DNSKEYリソースレコードに署名する鍵

– 上位ゾーンから提供される当該ゾーンへの「安全な入り口」

鍵の作り方

• BINDでは、dnssec-keygenコマンドが提供

• ZSK、KSKの両方を作ることが可能

– flagオプションで生成する鍵を指定可能

　-f ksk

• いずれの鍵を生成するときも、dnssec-keygenは2つのファイルを出力する

dnssec-keygenによる出力される

２つのファイル• DNSSECは公開鍵暗号方式を使う

– 公開鍵／秘密鍵のセットが使われる

– 秘密鍵は漏洩しないように管理する

– 公開鍵はゾーンデータ内に記載され、公開される

ゾーン内でのKSK/ZSK

• ゾーンデータを検証（Validation）されるようにするには、署名前にKSKとZSK双方の

公開鍵がゾーンファイルに含まれている必要がある。– $INCLUDE を使うか、単純にコピペのどっち

か

• BIND9.7では自動化機能が実装された

署名はどのように行われるか

• BIND9.7以前

– “dnssec-signzone”コマンド使った手動署名

• BIND9.7以降

– 手動署名の機能が強化

– 自動再署名機能がつかえるようになった

手動署名

• 署名作業の全工程はコマンドラインから実行

– 作業者は公開鍵（ゾーンファイルに含まれる）と秘密鍵（署名用）の両方にアクセスできないといけない

– 非署名のゾーンは署名される

– 署名済みゾーンは再署名される（必要があれば）

自動署名

• BINDはオンラインでの自動署名機能を提

供

– 対話型の操作は必要ない

– BINDのプロセスは鍵へのアクセス権が必要

鍵はどこに保存できるか？

• 現時点では2つの選択が可能

– ファイルシステム

– HSM(Hardware Security Module)

ファイルシステム

• BIND9.7以前は、ゾーンファイルともに鍵を保存しておくのが適当な方法だった。。。

メリット：

各ゾーンファイルでどの鍵が有効化を把握するのが簡単

デメリット:

秘密鍵と公開鍵の区別がつきにくい

BIND9.7で改善された点　１

• 9.7では、DNSSECの各種コマンドに“-k”オ

プションが追加されている

– 鍵の配置ディレクトリの場所を指定可能に

• 署名処理では、この場所から鍵を読み込む

• 鍵の生成処理では、この場所に鍵の出力を行う

BIND9.7で改善された点　２

• 加えて、namdプロセスには、鍵の配置ディ

レクトリを指定するオプションが追加された– key-directory

• このオプションは、ゾーン単位もしくはグロバール設定として指定可能

理想と現実

http://www.http://www.http://www.http://www.xkcdxkcdxkcdxkcd.com/538/.com/538/.com/538/.com/538/

暗号化おたくの想像「そいつのノートPCは暗号化されている。クラックするために、最高級のツールを使おう」「いや、こいつは4096bitRSA方式だから不可能だ」「ちくしょー。俺らの企みは失敗だ」

実際はどうなるか

「そいつのノートPCは暗号化されている。」

「そいつにクスリを嗅がせて、パスワードを吐くまで、5$のレンチでぶん殴ろう」

「よし、やっちまおう」

殴られないために・・・。

• KSK秘密鍵は、必要となるまでオフライン

化しておくべき– KSKはDNSKEYレコードに署名するだけに使

用され、かつリソースレコードの変更時にしか必要とされないため

– KSKもしくはZSKのロールオーバ時

リソースレコードシグネチャの期限切れへの注意

• DNSKEYレコードの署名は、自動的に期限延長されており、30日ごとに再生成され

ていない

– これは、（署名の期限切れを原因とする）リプレイアタック攻撃への脆弱性を高める

よりセキュアでありたければ

• ファイルシステムは、常に権限をもったユーザによるローカル攻撃への脆弱性を持っている– ”高価値”なゾーンは、より保護される必要が

ある

– お上の通達は、時に保護への取り組みの動機づけにもなる(FIPS 140-2)

• セキュリティ要件を規定した米国連邦標準規格

HSM(Hardware Security Module)

• HSMは、抽出不可能な秘密鍵を提供する

• 公開鍵はファイルシステム上に配置– ゾーンファイル中に“include”される必要があ

るので

HSMはどのように動作するか

• 署名アプリはハードウェアデバイスにアクセスできる必要がある– namedプロセスやdnssec-signzoneなど

– アクセスは改良版のOPENSSLライブラリを通

して行われる

HSMによる署名

• ゾーンデータの署名はHSM内で行われる

– KSK秘密鍵は決して攻撃者に漏えいすること

はない

– 署名処理の性能は、HSMに依存する

改良版のOPENSSLライブラリ

• BINDでは、標準でパッチを提供

– “key by reference”とPIN管理を追加

– システムのOPENSSLを置き換えるものではな

い

まともに動くのか？

• HSM上での鍵生成は、"dnssec-key"コマンドの変わりに、"pkcs11-keygen"コマンドを

使う

• namedプロセスによる自動再署名が実装さ

れてる– PINはファイルシステム上に配置されている必

要がある

どこで入手可能か？

• 鍵生成装置は個別に入手可能、またISC

のインストール・コンサルサービスとセットでの提供も可能

• ISC営業担当者に問い合わせ