暗認本読書会8
•
0 likes•438 views
https://anninbon.connpass.com/ 否認防止, タイムスタンプ, ブロックチェーン, PKI, CA, CT タイムスタンプについては補足資料も参照。 https://github.com/herumi/anninbon/blob/gh-pages/readme.md#sec31-%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%B9%E3%82%BF%E3%83%B3%E3%83%97
暗認本読書会8
- 2. • 正しい署名は署名鍵を持つ本人(アリス)しか作れない • 署名は否認防止機能を持つ • アリスが意図的に署名鍵を漏洩させて署名を無効化 時間軸 • 署名に時刻を関連づけさせる必要 否認防止と署名の失効 2 / 26
- 3. • タイムスタンプ Haber, Stornetta, 1990 • あるとき確かにあるデータが存在したことを示す • ハッシュ関数𝐻 • 信頼できる機関 • ハッシュ値を管理するタイムスタンプ局 • 時刻認証局TSA (Time Stamping Authorith) • ハッシュ値の連鎖を公開 : 誰でも検証可能 ハッシュ値の連鎖によるタイムスタンプ 3 / 26
- 4. • アリスは署名を失効させても否認できない • リンクトークン生成型タイムスタンプISO/IEC 18014-3 • 署名情報は新聞などで広く周知 タイムスタンプを用いた否認防止 4 / 26
- 5. • ハッシュ値を一本の鎖ではなく2分木で管理したもの • ハッシュ値ℎ8の正しさを確認 • ℎ1−4, ℎ5−6, ℎ7, ℎ1−8を使う, 必要なデータ量がO(log 𝑛 ) Merkle木 5 / 26
- 6. • リンクトークンとは別方式 • 信頼できるTSAが署名の検証鍵を公開 • RFC 3161, ISO/IEC18014-2などで標準化 署名を用いたタイムスタンプ 6 / 26
- 7. • 時刻の扱い • 国家時刻標準機関NTA (National Time Authority) • 情報通信研究機構NICTが日本標準時を生成、供給 • 時刻配信局TAA (Time Assessment Authority)がサービス提供 • 通常の署名は最大5年 • 住宅ローンなどには対応できない • EU : 2016年eIDAS規則, 国家間でタイムスタンプを利用可能 • 日本は公的なタイムスタンプ制度の不在 (2021年現在) • 長期の利用に不安 : e.g. NTTデータSecureSealは2020年終了 日本のタイムスタンプ 7 / 26
- 8. • (パブリック)ブロックチェーン • リンクトークン生成型タイムスタンプ : データの改竄耐性 • ハッシュ値の列(鎖)をP2Pネットワークで管理 • 不特定多数の主体が所有するコンピュータが互いに通信 • データが十分分散されると可用性と改竄耐性に優れる • データ更新性能は低い : シャーディングなどの技術 ブロックチェーンとビットコイン 8 / 26
- 9. • 初めてブロックチェーンを暗号資産に応用 • ハッシュ関数と署名の応用(「暗号化」機能は使ってない!) • トランザクション • 「ある人からある人に資産が移動した」という取引履歴 • トランザクションをいくつかまとめてブロックにする • ブロックをハッシュ値の連鎖で管理する • 資産の移動履歴だけが記録される • ある人の現在の資産残高は記載されていない • ビットコインアドレス • ECDSAの検証鍵のSHA-256とRIPEMD160によるハッシュ値 • 銀行口座番号に相当 ビットコイン 9 / 26
- 10. 1.コインの存在 : 「コイン10BTCが、あるビットコインアドレス からビットコインアドレス𝑎𝐴に移動した」という トランザクションTがブロックチェーンに含まれている 2.所有者 : アリスがビットコインアドレス𝑎𝐴に対応する 署名鍵𝑠𝐴を持っている 3.未使用 : 「a_Aから別のビットコインアドレスに移動した」 というトランザクションが存在しない アリスが10BTC持っているとは 10 / 26
- 11. • アリスがボブに2BTを送金するとは • アリスは新しいビットコインアドレス(𝑠𝐴 ′ , 𝑆𝐴 ′ , 𝑎𝐴 ′ )を作る • ボブも(𝑠𝐵, 𝑆𝐵, 𝑎𝐵)を作る • アリスが𝑎𝐵に向けてのトランザクション𝑇′を作成する • 𝑇′がブロックチェーンに取り込まれると送金完了 トランザクション 11 / 26
- 12. • 正しいチェーン • チェーンを延ばすとビットコインを得られる(マイニング) • チェーンを延ばすインセンティブ • 二重送金を含むブロックは無視される • 最も長いチェーンが正しいチェーン • 経験的に6ブロック伸びると取り込まれたと判断する • 一時的にチェーンが分岐しても短い方は無視される • ブロックのハッシュ値がターゲットtよりも小さいのが正しい • ブロックを延ばすのに時間(計算資源)が掛かる 二重送金の防止とマイニング 12 / 26
- 13. • ハッシュ値の先頭Nビットが0であるようにsaltを調整 • N=8なら1/2^8の確率で先頭8bitが0になる • 2020年でN=80ぐらい(10分に1個ブロックが伸びる) • 1秒間に1.6x1020(160𝑚 𝑇𝑒𝑟𝑎 𝐻𝑎𝑠ℎ/𝑠𝑒𝑐) • 電力消費の無駄・取引性能の低さ→オルトコインが有象無象 • 計算資源を50%独占すると思いのまま→信頼が無くなる マイニング 13 / 26
- 15. • 公開鍵暗号の公開鍵や署名の検証鍵が 本人のものと分かればOK • 二人であって直接手渡しするのが確実(キーサインパーティ) • 信用の輪 • 自分が信用している人が持っている別の人の公開鍵はOK? 信用の輪 15 / 26
- 16. • 人や組織とそれに紐付く公開鍵(検証鍵)の対応を保証 • 認証局CA : 公開鍵を保証する機関, 信頼できるものとする • 公開鍵証明書 : アリス本人と公開鍵の結びつきにCAが署名 • X.509というフォーマットの規格, CAの検証鍵で検証可能 • サーバ運用に利用することが多いのでサーバ証明書とも 公開鍵基盤PKI 16 / 26
- 17. • CAが一つだけだと権限や責任が一極集中 • 複数のCAが互いに認証し合う • ルート認証局 • 最終的に自分で認証したもの • トラストアンカー • 認証局の階層 認証局の相互認証 17 / 26
- 18. • 公開鍵証明書を破棄したい • 登録情報が古くなった・秘密鍵が漏洩したとき • すみやかに認証局CAに失効依頼をする • 証明書失効リストCRL(Certificate Revocation List) • PKIで失効した公開鍵証明書の一覧 公開鍵証明書の失効 18 / 26
- 19. • CRLの問題点 • 世界中の失効リスト一覧なのでサイズが大きい • 更新負荷が高くなる • OCSP • OCSPレスポンス : レスポンダの署名付き • 利点 : 全てを取ってくる必要がない • 欠点 : アクセスの度に問い合わせが必要 プライバシーの問題 OCSP(Online Certificate Status Protocol) 19 / 26
- 20. • サーバがOCSPレスポンスを持っておく • クライアントは自分で問い合わせる必要がない • どのサイトにアクセスしたかの情報が漏洩するリスクが減る ブラウザごとに類似の手法 e.g. Chrome : CRLSets (2014) Firefox : OneCRL (2015), CRLite (2020) OCSPステープリング(stapling) 20 / 26
- 21. • ドメイン認証DV (Domain Validation) • メール認証 • サーバ運営者がadmin@, root@などのメールでCAに依頼 • そういうメールアドレスはそのドメイン所有者だろう • サーバやDNSレコードの特定の箇所にCAが指定したトークン を置いてもらって確認 • ACME : 公開鍵証明書の確認を自動化 : Let's Encryptで利用 証明書の発行方法 21 / 26
- 23. • 組織認証OV (Organization Validation) • 書類審査や電話などを用いてドメインの管理者が法人である ことを確認 • 拡張認証EV (Extended Validation) • OVよりもより厳格 : CA/ブラウザフォーラムが規定 • アドレスバーが緑色 : 2019年Chrome/Firefoxが止めた • 注意 • これらの認証はサーバとクライアント間が暗号的に安全であ ることのみを保証 • 悪意ある業者でもEVは取得可能 その他の認証 23 / 26
- 24. • 認証局CA自体の信頼性 • 2011年頃からCAに関する大きな事件が続いた • CAへの攻撃, 弱い証明書・間違った証明書の発行 • CT (Certificate Transparency) • 認証局CAを監視する仕組み • CTのログサーバに発行した証明書を登録することを義務づけ • SCT (Signed Certificate Timestamp) : ログサーバによる署名 • Chrome, Safari (2018), FirefoxはCTの使用を義務づけていない 証明書の透明性CT 24 / 26
- 25. • 一般ユーザ • アクセスした証明書にSCTが無いと怪しい • SCTがあったもそれがログサーバに無いと怪しい • サービス事業者 • 自分のサイトで不正な証明書が発行されていないか監視可能 • Symantecが不正な証明書を発行したことを検知 (2015) CTの利点 25 / 26
- 26. • 一般ユーザ • SCTの妥当性確認のためにログサーバにアクセス • 自分がどのサイトを見ようとしているかログサーバに伝わる • OCSPと同様の問題点 • サービス事業者 • CAに証明書を発行してもらう前にログサーバに知らせる必要 • ドメイン名を隠しておきたいなどがログサーバに公開される • 解決案を検討中 • その他 • ログサーバは世界中の証明書を収集できる • 特定の業者に権力が集中 • 運営者が不正をしないか? CTの問題点 26 / 26