Hlavní navigace

Bezpečné DNS

22. 5. 2003
Doba čtení: 4 minuty

Sdílet

V uplynulém týdnu se konal 45. RIPE meeting. Jedním z témat, která se nedala přehlédnout, bylo bezpečné DNS, čili DNSSEC. Vracelo se k němu několik příspěvků v různých sekcích. Důvodem nepochybně je, že do konce roku by mělo být nasazeno v praxi. Jelikož Lupa se tomuto tématu dosud nevěnovala, je na čase dohnat dluh.

Stejně jako ostatní internetové protokoly i DNS vychází z koncepce, že Internet je křišťálová studánka, kde nejhlubší je les a jeho uživatelé jsou milí, hodní, pozitivní lidé. Bohužel se ukázalo, že v lese žijí i vlci a kapradí je plné slimáků. Stávající DNS neposkytuje žádnou ochranu proti falšování a podobným nepravostem.

Cílem Domain Name System Security Extensions (DNSSEC) je definovat mechanismy, které by klientovi umožnily ověřit si, zda informace, které z DNS dostal, jsou pravé. Druhý úkol je ještě o něco těžší: ověřit, že daná informace v DNS skutečně chybí.

Důležitým východiskem je, že DNSSEC chrání jen data v DNS obsažená. Nestará se o přenosový kanál. Nenabízí tedy žádné prostředky pro omezování přístupu, autentizaci klientů, šifrování odpovědí a podobně. Jen ověření pravosti získaných údajů.

K ověření pravosti se standardně používá elektronický podpis a nejinak je tomu i v DNSSEC. Využívají se postupy šifrování s veřejným klíčem. Jen stručně připomenu jejich základ: Primární DNS server domény si vygeneruje dvojici klíčů – soukromý a veřejný. Co se podepíše soukromým klíčem, dá se ověřit jen jemu odpovídajícím veřejným. Z veřejného klíče pochopitelně nejde odvodit soukromý.

Server jednotlivé informace ve své doméně podepíše soukromým klíčem, který drží v tajnosti (doporučuje se dokonce jej pokud možno mít zcela mimo dosah sítě). Vedle původní informace pak vyvěsí ještě její podpis. Veřejný klíč je k dispozici komukoli a ten si jeho prostřednictvím může ověřit, zda podpis odpovídá poskytnuté informaci. Pokud ano, dokazuje to, že informace zůstala nezměněna a že jejím původcem je ten, kdo zná soukromý klíč (čili původní server).

Záznam SIG


Pro podpis byl vytvořen nový typ záznamu (Resource Record, RR) nazvaný SIG. Podepisuje se jím vždy celá sada záznamů, které mají stejné jméno, třídu a typ. Pokud tedy pro dané jméno existují řekněme tři A záznamy, tvoří jednu sadu a budou podepsány dohromady. Tento přístup je racionální, protože v odpovědi se posílá vždy celá sada a je efektivnější opatřit ji jedním společným podpisem než podepisovat každý záznam samostatně.

Záznam SIG obsahuje:

  • typ záznamu, který podepisuje
  • použitý algoritmus; na výběr je několik algoritmů, implementace je povinna podporovat RSA/SHA1, který je označen číslem 5
  • počet domén ve jméně, které se podepisuje (např. www.kit.vslib.cz obsahuje čtyři domény, kořenová se nepočítá), tento údaj je určen především pro použití v kombinaci s žolíkovými znaky
  • dobu životnosti podepisovaného záznamu
  • dobu ukončení platnosti podpisu, v zónovém souboru je ve tvaru YYYYMMDDhhmmss
  • dobu zahájení platnosti podpisu
  • značku pro rychlejší nalezení klíče
  • doménové jméno podepisujícího
  • a konečně vlastní podpis, který se do zónového souboru zapisuje v kódování Base64 známém ze světa MIME

Sada dvou A záznamů s podpisem může vypadat následovně:

pc.kdesi.cz. 999 IN A 10.1.2.3
             999 IN A 10.1.8.9
             999 SIG A 5 3 999 20030610114923 20030510114923 (
                     2539 kdesi.cz Tjpdt...H6D )

Poněkud zvláštní je značka klíče, která je uvedena před jménem podepisujícího. Jejím cílem je urychlit výběr správného klíče pro ověření podpisu. K dané doméně se totiž může vázat klíčů několik a zkoušet všechny by mohlo být časově náročné. Proto se ke každému klíči vypočítá jeho značka (používá se algoritmus podobný výpočtu kontrolních součtů v řadě internetových protokolů). Kombinace jména podepisujícího, šifrovacího algoritmu a značky klíče pak podstatně omezí výběr kandidátů (zpravidla na jediný klíč, který mu vyhovuje). Přestože pravděpodobnost shodné značky pro více klíčů je malá, není značka jednoznačným identifikátorem. Jen zužuje výběr.

Záznam KEY


Tím jsme se zvolna propracovali k otázce, kde vzít klíče pro ověřování podpisů. Řešení je prosté – v DNS. K jejich ukládání slouží záznam KEY obsahující:
  • příznaky (zatím byl definován jediný a ten bude typicky nastaven, takže hodnota této položky bude zpravidla 256)
  • protokol, který má pevně danou hodnotu 3, stejně jako předchozí položka je určen především pro budoucí využití
  • algoritmus, pro který se klíč používá
  • hodnotu klíče, také v kódování Base64

DNSSEC by byl pro švandu králíkům, kdyby na obsah KEY záznamů nebylo spolehnutí. Proto tyto záznamy pochopitelně musí být podepsány klíčem, kterému klient důvěřuje. Tím se objevují dvě možná využití klíčů: pro podepisování informací v doméně (zone signing key, ZSK) a pro podepisování jiných klíčů (key signing key, KSK).

Idea je taková, že klíče pro podepisování zóny mohou být poměrně často měněny, proto mohou být „jednodušší“, aby ověřování netrvalo příliš dlouho. Naopak klíče pro podepisování jiných klíčů musí být stvrzeny z vyšších míst (viz dále). Proto by měly mít dlouhou životnost a měly by také být patřičně „složité“, aby odolaly případným útokům. Rozdělení na KSK a ZSK není povinné, je pouze praktické. Teoreticky můžete v celé zóně použít jen jediný klíč, který podepíše i sám sebe a funguje tak jako KSK i ZSK zároveň.

Doména kdesi.cz by mohla ve své definici obsahovat následující dvojici klíčů:

BRAND24

kdesi.cz. 999 IN KEY 256 3 1 AQDv...GiDx
          999 IN KEY 256 3 5 CLgC...Yb6n
          999 SIG KEY 1 2 999 20030610113107 20030510113107 (
                  2539 kdesi.cz BH1x...7Wq3 )

První z nich je KSK a je použit pro podpis pod dvojicí klíčů. Druhý se pak používá jako ZSK k podepisování dat v zóně.

(Dokončení příště)

Byl pro vás článek přínosný?

Autor článku

Autor dělá nepořádek v příslovích, protože sítě nejen dělá, ale i učí a dokonce také řídí. Působí na Ústavu nových technologií a aplikované informatiky na Technické univerzitě v Liberci. Píše knihy.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).