第13章
電子署名の仕組みとDNSSECの適用
DNSSECはDNSのセキュリティ拡張
受け取ったDNSレコードの出自や完全性を担保するための仕組み
具体的にはDNS応答に公開鍵暗号技術を用いた電子署名を付加する
電子署名の仕組み
データの利用者に対して、データの出自の認証と完全性の検証を行えるようにする仕組み
署名者が作成したデータであることを証明
利用者が受け取ったデータに改ざんや欠落が見られないことを証明
最近対応した
公開鍵暗号方式
https://gyazo.com/628914bcfa05cd9b9dbe0800f85c7f28
DNSでは委任ごとにゾーンが作られる
DNSSECではソーンの管理者が電子署名の署名者=データの作成者
ゾーンデータのリソースレコードセット(RRset)=署名対象のデータ
署名に使用した鍵ペアの公開鍵をゾーンデータとして権威サーバーで公開する
DNSKEYリソースレコード=公開鍵
PRSIGリソースレコード==各リソースレコードセットに付加される電子署名
code:DNSKEY
$ dig jprs.jp DNSKEY
; <<>> DiG 9.10.6 <<>> jprs.jp DNSKEY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46894
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;jprs.jp. IN DNSKEY
;; ANSWER SECTION:
jprs.jp. 3600 IN DNSKEY 257 3 8 AwEAAbEW7c61WQ+ZWrUivmXoOTqqN4i7yB1MhCtaG2YCTm5UdlBaOHtc JFNaubPYntvmz5Nd9S7NE05r2dUtA/pDR7GD35gku2y6tDas78VXivIG 6Mgj+M5G0J5xFl074PULJj1v4Omxrv7kojcsgrwjdZR46q7iVNPvCmeB lWO7FIAx2J+hGLk38XgCCKFzYtcYOgDxWexL3KvE1MMWz2D2Hs3GRWd0 fYdVv3iaoKyS2wtAtnt+zc/qKmB7hZ645O7JIRRCEhZrzLoOIQUaD+0o RdmCNtecRWcRB7pYYxF9kaRKknWX2dO78ndRUaGos725rOkISqtEP0O6 Cu96/ecggkU=
jprs.jp. 3600 IN DNSKEY 256 3 8 AwEAAbqJTLf0DTwRTzXExy+DifhwVhtFWYEDorFPIcEE9J8CBierd4cv R5kT2qSHru3MViqZTz/40ApLwQArzKtOm4z1KsWLQsNFO63fJw1pOXS6 DtUTEaex2wH2IXeH9fZwVWQpgfbuzqBuGlefRSLEFU9D0+o+QgP5RQ38 /scK69PR
;; Query time: 409 msec
;; SERVER: 240d:1e:103:7000:d6c1:c8ff:fe65:3bd0#53(240d:1e:103:7000:d6c1:c8ff:fe65:3bd0)
;; WHEN: Tue Apr 21 22:15:13 JST 2020
;; MSG SIZE rcvd: 460
https://gyazo.com/7f5e86b3140aba14d7037c3c2d56314f
署名の検証=バリデーターはスタブリゾルバーとフルリゾルバー
信頼の連鎖
DNSSECではそのゾーンの公開鍵を親ゾーンの秘密鍵で署名し親ゾーンで公開する
親ゾーンはその公開鍵の信頼性を担保することになる
この仕組みを信頼の連鎖という
信頼の構築はその公開鍵(DNSKEYリソースレコード)に対応するDSリソースレコードで行う
DSリソースレコード
KSK公開鍵を、SHA-1/SHA-256等のハッシュ関数で変換したリソースレコード
KSK公開鍵と暗号論的に等価の情報
親ゾーンの委任ポイントに、NSと共に子ゾーンのDSを登録
親ゾーンのZSKでDSに署名することにより、信頼の連鎖を構築
code:DS
$ dig jprs.jp DS
; <<>> DiG 9.10.6 <<>> jprs.jp DS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62085
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;jprs.jp. IN DS
;; ANSWER SECTION:
jprs.jp. 3600 IN DS 43519 8 2 F1253DCC0CEE00CFB6518894AD23F135E1801D67D67D9CCDA81AADA9 954109DC
;; Query time: 326 msec
;; SERVER: 240d:1e:103:7000:d6c1:c8ff:fe65:3bd0#53(240d:1e:103:7000:d6c1:c8ff:fe65:3bd0)
;; WHEN: Tue Apr 21 22:15:46 JST 2020
;; MSG SIZE rcvd: 84
https://gyazo.com/c6ac26d9b9a8e7abdfbc86aa636a5ff3
ハッシュ値・・・元データをハッシュ関数と呼ばれる計算手順で処理した結果
元データが1ビットでも異なると大きく異なるハッシュ値が生成される
また計算結果からの復元はほぼ不可能
DSリソースレコードは委任情報ではない
親ゾーンの秘密鍵で署名され公開される、親ゾーンが権威を持つ情報
親ゾーンの権威サーバーはNSリソースレコードとグルーレコードを応答する際にそのゾーンのDSリソースレコードを付加する
code:DSリソースレコード
$ dig +multi +dnssec jprs.jp a @203.119.1.1
; <<>> DiG 9.10.6 <<>> +multi +dnssec jprs.jp a @203.119.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46393
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 9
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;jprs.jp. IN A
;; AUTHORITY SECTION:
jprs.jp. 86400 IN NS ns3.jprs.jp.
jprs.jp. 86400 IN NS ns1.jprs.jp.
jprs.jp. 86400 IN NS ns4.jprs.jp.
jprs.jp. 86400 IN NS ns2.jprs.jp.
## 親の権威サーバーが付加したDSリソースレコード
jprs.jp. 7200 IN DS 43519 8 2 (
F1253DCC0CEE00CFB6518894AD23F135E1801D67D67D
9CCDA81AADA9954109DC )
jprs.jp. 7200 IN RRSIG DS 8 2 7200 (
20200518174503 20200418174503 26115 jp.
hlQqo2rYMty6KdMppJ9VuRWGS+XQrlAHLbWaYVgNnfLJ
sM4K3WstNe5qTKfjwA+gJJKrzptZ5/RGqcyP2fcGuv+6
Ckml7C8YfNc+xXckiVEmcG+j3bzj0X7uGQ4Nd44HpfvW
E5dPdXXWyFe8wwHEWZiP4GEo06xA5pFk7M/MXRA= )
;; ADDITIONAL SECTION:
ns1.jprs.jp. 86400 IN A 202.11.16.49
ns2.jprs.jp. 86400 IN A 202.11.16.59
ns3.jprs.jp. 86400 IN A 203.105.65.178
ns4.jprs.jp. 86400 IN A 203.105.65.181
ns1.jprs.jp. 86400 IN AAAA 2001:df0:8::a153
ns2.jprs.jp. 86400 IN AAAA 2001:df0:8::a253
ns3.jprs.jp. 86400 IN AAAA 2001:218:3001::a153
ns4.jprs.jp. 86400 IN AAAA 2001:218:3001::a253
;; Query time: 21 msec
;; SERVER: 203.119.1.1#53(203.119.1.1)
;; WHEN: Tue Apr 21 22:23:08 JST 2020
;; MSG SIZE rcvd: 494
https://gyazo.com/86b50909af4ea953e480f20540e2dd82
証明の連鎖とは、「ある者が別の者の正しさを証明し、 その者が更に別の者の正しさを証明する」といった構造のことです。 このような認証基盤を使った認証の手続きは、通信相手の電子的な証明、 または電子データに付けられた署名が、あらかじめ設定しておいた基点との間で、 正しく連鎖しているかどうかを確認することで行われます。 この基点がトラストアンカーです。
ルートゾーンがトラストアンカーになる
https://gyazo.com/35e245c21c593d800e52425e1cc33ab6
DNSSECで使われるKSKとZSKという2種類の鍵について
親ゾーンに登録した鍵の更新は面倒なので強力な鍵を使いたい
強力な鍵=長期間使える鍵
強力な鍵は計算量が多くて署名コストがかかるので全部のゾーンで使うにはよろしくない
子ゾーンはもっと簡単な鍵=短期間だが署名コストが低い鍵をを使いたい
ゾーンごとに2種類の鍵を使うことになった!
署名対象が公開鍵(DNSKEYレコード)の鍵はKSK
鍵を署名するための鍵ということから「key-signing key」
比較的暗号強度が強い鍵
署名対象がゾーンに含まれる残りのレコードとなる鍵はZSK
ゾーンのデータを署名する鍵ということから「zone-signing key」
比較的暗号強度が弱い鍵
https://gyazo.com/cc5dc3c71328eb06b13835db7b84c6a9
情報を鍵で秘匿しているわけではない
ちょっと鍵という言葉に惑わされたがあくまで署名として機能する
https://gyazo.com/488466deec02f72a50707762dd45f890
KSK公開鍵をリゾルバーに置いておく(KSK1)
DNS応答で以下の情報を送る
A=ZSK秘密鍵で署名した委任先の情報
B=KSK公開鍵で署名したZSKの公開鍵とKSKの公開鍵(KSK2)
KSK1でBを複号する
KSK1とKSK2を比較して同じならKSK1の鍵の信頼性が確認できる
(ルートへの問い合わせの場合のみKS1を無条件に信用する)
さらにBの内容全体についても信頼性が確認できる
Bに含まれていたZSKの公開鍵を使って、Aを複号する
こうして委任先の情報は信頼できる情報になる
これでループするような感じで委任先に問い合わせを続ける
次の委任先では信頼性が担保されたKSK2を使って復号する
以下同
この資料の中で語られるDNSキャッシュへの毒入れ、はキャッシュポイズニングのこと
DNSSECはキャッシュポイズニング=偽のリソースレコードをキャッシュされる攻撃を防ぐための仕組みとして考案された
DSとNSの違いがごちゃごちゃしてきていたのでこれがありがたかった
https://gyazo.com/25fb36f73e0969606aa56d6ef806fb68
総務省の説明資料も非常に分かりやすい。頭いい。
https://gyazo.com/54c928a64e2d0822122b77a3bfad1dd7
2017年10月に新しいKSKが利用され始めたらしく、その際の対応などが書かれていた(KSKロールオーバー)
DNSSECの不在照明に使われるリソースレコード=NSEC
なぜ不在証明が必要なのか??
存在するデータに対しては署名を負荷して存在を証明できるが存在しないデータに署名ができないので証明できなかった
そのためにNSECリソースレコードが生まれた
DNSSECはめちゃくちゃ頭いい。DNSやってて思うけど本当に良くできた仕組みだ。。。すごい。