デジタルアイデンティティの技術を学ぼう!～認証認可にまつわる標準仕様文書を読んでみよう～ / OpenID Summit Tokyo 2024

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 2 自己紹介 ■基本属性姓名名古屋謙彦（なごやよしひこ）所属 GMOサイバーセキュリティ byイエラエ株式会社サイバーセキュリティ事業本部高度解析部調査分析課 ■その他の属性 Twitter（X）あよくら @ayokura BlueSky @ayokura.net 属性タグ CISSP/CC/クリスチャンエンジニアではない人でも簡単・安全にインターネットを利用できるように、デジタルアイデンティティや認証連携などの技術の適切な利用を広めていきたいです。デジタルアイデンティティの技術は、インターネット上で（実世界でも）、僕が僕であることを、あなたがあなたであることを証明できる大切なパーツであり、学生自体から今に至るまで大好きな領域です。

Slide 3

Slide 3 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 3 背景 • デジタルアイデンティティを形作る技術を学んでいくとき、概要を学んだあと、さらに深めていくときに、ほぼ必ずRFCやNIST文章、OpenID Specificationsなどの仕様文書がでてきます。 ‒ 日本語資料がある場合もあるが、最新仕様を読む場合や、正確な記載を確認する場合など、英語原文に当たらなければならないときもある • 近くに聴ける人がいるのも、強いことだけど、ある程度自分で頑張っていく上では、この仕様を読み解けるようになる必要があるし、それができるのは強みになる！ ‒ 誤った理解による実装は、相互運用の支障になったり、セキュリティ上の脆弱性に繋がることも……！

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 5 目標 RFCやNISTなどの標準仕様の文章を、忌避感なく読めるそのために、読み方のかなめにもなると僕の思う、以下の二つを見ていきます。 • デジタルアイデンティティ関連の仕様でよく参照されている二つの書き方（RFC・ ISO）における、「要請の程度に使われるキーワード」について把握する • RFCの書き方においては、加えてセキュリティ面の記載や、プライバシー面の記載がどこにあるか、を把握する（僕がはじめてRFCの文書を読んだときに知りたかったなーと思う内容です）

Slide 6

Slide 6 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 6 標準（化された）仕様の文書 • OAuthやOpenID Connectも、HTTPやDHCPも、はたまた物理的なネジにいたるまで、相互に使えるようにするためには、共通の取り決めが必要です。 • そんな共通の取り決めが作られることは標準化とよばれます。 • 標準化の作業で作られる仕様の文章は、読む人によって違った意味にとられないよう、書き方や使う用語についてもある程度ルールが定められています。 • 標準化をする組織によって、ルールには違いがありますが、例えば、守らなければならないものの強さを表す表現は似通ったルールを使っていたりします。 • ここからは、そんな強さを表す表現について、よく見かける以下の二つの表記法での使われ方を紹介します。 ‒ IETF（Internet Engineering Task Force）が定めるRFCで用いられる表記法 ‒ ISO（International Organization for Standardization）が定める国際標準で用いられる表記法

Slide 7

Slide 7 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 7 参考：いろいろな標準化団体デジタルアイデンティティ周りでも、いろんな団体が標準化をしています。 • IETFで定めたRFC(Internet Standard Track） ‒ RFC 6749 “The OAuth 2.0 Authorization Framework” • OpenID Foundationで定めたOpenID Specification ‒ OpenID Connect Core 1.0 ‒ Financial-grade API Security Profile 1.0 - Part 1: Baseline • NIST(アメリカ国立標準技術研究所)が作ったSpecial Publication ‒ NIST SP 800-63-3 / NIST SP800-63-4 draft • W3Cが定めたRecommendation（勧告） ‒ W3C Web Authentication（WebAuthn） • 他にもFIDO Allianceや、ISO、JISなどが定めた標準なども

Slide 8

Slide 8 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 8 RFCのKeywordsの話 RFCの表現方法で、どれくらい従うべき仕様を表すもの： BCP14 • BCP：Best Current Practices、現時点でベストと思われる推奨 BCP14は以下の2つのRFCで構成される ‒ RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels • (RFCにおいて要請の程度を示すために用いるキーワード） ‒ RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words • （RFC 2119の大文字と小文字のあいまいさ） [BCP14] https://www.rfc-editor.org/info/bcp14 [RFC2119] Key words for use in RFCs to Indicate Requirement Levels https://www.ietf.org/rfc/rfc2119.txt [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words https://www.ietf.org/rfc/rfc8174.txt

Slide 9

Slide 9 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 9 大文字キーワード（RFC） • "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL” • これらのキーワードは記載内容の要求レベルを表し、RFC 2119でその意味が厳密に定義されている ‒ 例）MUST / REQUIRED / SHALL : 絶対要件 SHOULD / RECOMMENDED : 推奨要件、特定の条件下では採用されない場合もあり得るが、その際は十分検討する必要がある • RFC 8174で、キーワードは大文字で表記されたときのみ RFC 2119 の定義に従うことが明確化（小文字のmustやshouldはキーワードではない） [RFC2119] Key words for use in RFCs to Indicate Requirement Levels https://www.ietf.org/rfc/rfc2119.txt [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words https://www.ietf.org/rfc/rfc8174.txt

Slide 10

Slide 10 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 10 RFC/ISOのキーワードの違い RFC ISO 意味・備考 MUST / REQUIRED / SHALL shall 実施しなければならない（必須） MUST NOT / SHALL NOT shall not 実施してはいけない（必須） SHOULD / RECOMMENDED should 実施するべきである（推奨） SHOULD NOT / NOT RECOMMENDED should not 実施するべきでない（推奨） MAY / OPTIONAL may 実施してもよい、実施しなくてもよい（任意）

Slide 11

Slide 11 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 11 いろんな仕様でのキーワード表記 • 先ほど紹介した仕様たちでもこれらの表現が使われます。 • OpenID Foundationで定めたOpenID Specification ‒ OpenID Connect Core 1.0 （RFC表記） ‒ Financial-grade API Security Profile 1.0 - Part 1: Baseline （ISO 表記） • NIST(アメリカ国立標準技術研究所)が作ったSpecial Publication ‒ NIST SP 800-63-3 / NIST SP800-63-4 draft （いずれもRFC表記） • W3Cが定めたRecommendation（勧告） ‒ W3C Web Authentication（WebAuthn）（RFC表記） ⇒多くの場合、仕様の最初の方にどこの表現を借りてきているかの記載があります

Slide 12

Slide 12 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 12 例 • OpenID Foundationでの仕様では文章により、キーワードの表記が異なる Financial-grade API Security Profile 1.0 - Part 1: Baseline https://openid.net/specs/openid-financial-api-part-1-1_0.html OpenID Connect Core 1.0 incorporating errata set 2 https://openid.net/specs/openid-connect-core-1_0.html

Slide 13

Slide 13 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 13 はじめて仕様を読んでいくにあたってここまで主に英語での仕様本文を読む場合の話をしてきました（でも英語資料読むのって難しいですよね）実際に仕様を読んでいくのであれば例えば以下のような順序も考えられます 1. 仕様について解説しているような日本語記事を探して概要をつかむ 2. 仕様自体の日本語翻訳を読む（できたら機械翻訳でないもので） ⇒機械翻訳の場合は今日紹介したキーワードの部分も訳されてるので注意。あとたまに意味が真逆になってることも 3. 元々の英語仕様書で、2までの理解が正しいか、キーワードの部分などに気を付けて検証していく 4．もちろん詳しい人に聞いてみるのも大事（直接とかTwitter（X）とか）

Slide 14

Slide 14 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 14 Security Considerations • RFCには基本的にSecurity Considerationsが含まれる ‒ 他にもOpenID Foundationが出しているSpecにも含まれる • RFCの本文を参照すれば実装することは可能だが、仕様の意図や目的（どのような思想でセキュリティを確保しているか）を知るためにはSecurity Considerationsを読むのが近道 • Security Considerationsだけで独立したRFCが出てる場合もある ‒ RFC 6819 “OAuth 2.0 Threat Model and Security Considerations” • OAuth 2.0の脅威モデルとセキュリティの考察(OAuth 2.0発行後に発生した問題に対する対処) • ちなみに、OpenID FoundationのSpecではPrivacyに関するPrivacy Considerationsも章立てされてるのでそちらも忘れず読もう ‒ RFCの場合はPrivacy Considerationsは必要に応じて独立したRFCとなっていそう

Slide 15

Slide 15 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 15 おすすめの技術文書 • 自分が好きなものや自分で使っているものが一番ではあるのですが…！いくつか個人的なおすすめの例を書いてみます ‒ 良質な日本語訳があるもの(OIDF-Jの翻訳WG訳がおすすめ) • OpenID Connect Core 1.0 • RFC 6749 “The OAuth 2.0 Authorization Framework” • NIST SP 800-63-4 draft (身元確認・認証・認証連携の保証レベルが学べる) ‒ 英語での一本目として読みやすいと思うもの（図が多かったり） • RFC2131 Dynamic Host Configuration Protocol（いわゆるDHCP） • RFC8628 OAuth 2.0 Device Authorization Grant（いわゆるデバイスフロー） ‒ 最新仕様なもの • draft-ietf-httpbis-message-signatures-19 ‒ HTTPでのやり取りに署名を付ける仕様、もうすぐ正式なRFCになるはず

Slide 16

Slide 16 text

Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved. 16 最後に • 標準仕様や、いろんな技術文書を英語でも読めるようになると、気になったことをどんどん深く調べていくことができると考えます。 • まだ読んだことがない方がもしいましたら、トライしてもらえればうれしいです。 • また、もし皆様が教えるときの選択肢の一つとして利用いただければ嬉しいです。 • そして、いろんな技術文書を読んで、もっと仕様を知って、一緒にデジタルアイデンティティの技術を広げ、守っていき、信頼されて当たり前のものであり続けられる技術だったらいいな、と思います。 • （私自身ももっと成長しつづけて、その一端を担い続けられるよう頑張ります）