Создание пары открытый / закрытый ключи (DNSSEC-ОР1)
DNSSEC определяет создание и проверку цифровых подписей с использованием асимметричных ключей. Это требует создания пары открытый / закрытый ключи. Для облегчения операций администрирования, которые должны выполняться периодически, таких как обновление ключа и переподписывание зоны, необходимо иметь два различных типа ключей. Один тип ключа называется Key Signing Key (KSK Ключ данного типа (а именно, закрытый ключ, называемый KSK-private) будет использоваться только для подписывания ключа, содержащегося в зонном файле в ресурсной записи с типом DNSKEY. Другой тип ключа называется Zone Signing Key (ZSK) (соответствующий закрытый ключ называется ZSK-private). Этот ключ используется для подписывания всех множеств ресурсных записей в зоне (включая множество ресурсных записей DNSKEY). Административное разграничение между KSK- и ZSK-ключами осуществляется с помощью флага Secure Entry Point (SEP) в ресурсной записи DNSKEY, который присутствует в открытых ключах, называемых KSK-public и ZSK-public, соответственно.
Причина, лежащая в основе создания двух типов пар ключей, состоит в определении отдельного набора функций для каждого типа ключа для того, чтобы уменьшить сложность задач, связанных с обновлением ключей и переподписыванием зоны. KSK (KSK-private) используется для подписывания множества ключей (т.е. множества ресурсных записей DNSKEY) и является тем ключом, который передается родительской зоне для использования его при аутентифицированном делегировании. Аутентифицированное делегирование выполняется посредством создания ресурсной записи DS, содержащей хэш дочернего KSK-public ключа, и затем создания соответствующей подписи (ресурсной записи RRSIG), используя свой собственный ZSK-private. Ключ KSK (KSK-public) также может использоваться в качестве доверенного anchor для установления доверенных цепочек при проверки подписей.
Ключ ZSK (ZSK-private) применяется для подписывания зонного файла (всех множеств ресурсных записей). Открытый ключ (ZSK-public) не посылается родителю, он всегда хранится в зоне.
При создании пар ключей KSK и ZSK необходимо выбрать следующие параметры:
- алгоритм цифровой подписи;
- длину ключа;
- период, в течение которого ключ будет использоваться.
Выбор алгоритма цифровой подписи основывается на принятых стандартах. Обычно рассматриваются следующие алгоритмы:
- DSA;
- RSA;
- Elliptic Curve DSA (ECDSA).
Из этих трех алгоритмов наиболее широко распространены RSA и DSA. С точки зрения производительности RSA и DSA имеют сопоставимую скорость создания подписи, но DSA является более медленным при проверке, а RSA — более быстрым. Единственным обязательным для реализации в DNSSEC алгоритмом является RSA с MD5. Считается, что как минимум name-серверы и клиенты должны иметь возможность использовать RSA. Предполагается, что по крайней мере один ZSK для зоны использует алгоритм RSA.
Выбор длины ключа определяется соотношением между риском компрометации ключа и производительностью. Производительность определяется временем создания подписи и временем проверки подписи. Длина пакета DNS-ответа также должна учитываться, потому что ресурсные записи DNSKEY посылаются в дополнительном разделе DNS-ответа. Так как ключ KSK используется только для подписывания множества ключей (множества ресурсных записей DNSKEY), в этом случае производительность не является решающим фактором. Однако компрометация ключа KSK может иметь большее негативное воздействие, так как этот ключ является фактически мастер-ключом для зоны. Компрометация ключа KSK в зоне, расположенной высоко в DNS-иерархии, может подвергнуть большую часть DNS-поддерева (следовательно, большое число зон) spoofing атакам. Кроме того, обновление ключа KSK в случае компрометации означает изменение доверенных anchor’ов во многих name-серверах и resolver’ах. Тем самым для KSK рекомендуется большая длина ключа: он имеет небольшое воздействие на производительность, но чувствителен к компрометации.
При выборе длины ключа для ZSK производительность является основным фактором, потому что этот ключ используется для подписывания всех множеств ресурсных записей в зоне.
При создании пар ключей KSK и ZSK необходимо выбрать следующие параметры:
- алгоритм цифровой подписи;
- длину ключа;
- период, в течение которого ключ будет использоваться.
Выбор алгоритма цифровой подписи основывается на принятых стандартах. Обычно рассматриваются следующие алгоритмы:
- DSA;
- RSA;
- Elliptic Curve DSA (ECDSA).
Из этих трех алгоритмов наиболее широко распространены RSA и DSA. С точки зрения производительности RSA и DSA имеют сопоставимую скорость создания подписи, но DSA является более медленным при проверке, а RSA — более быстрым. Единственным обязательным для реализации в DNSSEC алгоритмом является RSA с MD5. Считается, что как минимум name-серверы и клиенты должны иметь возможность использовать RSA. Предполагается, что по крайней мере один ZSK для зоны использует алгоритм RSA.
Выбор длины ключа определяется соотношением между риском компрометации ключа и производительностью. Производительность определяется временем создания подписи и временем проверки подписи. Длина пакета DNS-ответа также должна учитываться, потому что ресурсные записи DNSKEY посылаются в дополнительном разделе DNS-ответа. Так как ключ KSK используется только для подписывания множества ключей (множества ресурсных записей DNSKEY), в этом случае производительность не является решающим фактором. Однако компрометация ключа KSK может иметь большее негативное воздействие, так как этот ключ является фактически мастер-ключом для зоны. Компрометация ключа KSK в зоне, расположенной высоко в DNS-иерархии, может подвергнуть большую часть DNS-поддерева (следовательно, большое число зон) spoofing атакам. Кроме того, обновление ключа KSK в случае компрометации означает изменение доверенных anchor’ов во многих name-серверах и resolver’ах. Тем самым для KSK рекомендуется большая длина ключа: он имеет небольшое воздействие на производительность, но чувствителен к компрометации.
При выборе длины ключа для ZSK производительность является основным фактором, потому что этот ключ используется для подписывания всех множеств ресурсных записей в зоне.
