金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG

1. Nomura Research Institute 崎村夏彦(@_nat) 金融 API 時代のセキュリティ: OpenID Financial API (FAPI) WG • OpenID® は、 OpenID Foundation の登録商標です。 • *Unless otherwise noted, all the photos and vector images are licensed by GraphicStocks. 2017年9月11日米国OpenID Foundation 理事長上席研究員 #apijp API Meetup #21

3. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 3 崎村夏彦（Nat Sakimura） 著作: OpenID Connect Core 1.0 JSON Web Token [RFC7519] JSON Web Signature [7515] OAuth PKCE [RFC7636] OAuth JAR [IETF Last Call] Etc. Editor of: ISO/IEC 29184 Guidelines for online notice and consent ISO/IEC 29100 AMD: Privacy Framework – Amendment 1 ISO/IEC 27551 Requirements for attribute based unlinkable entity authentication Etc. • OpenID Foundation 理事長 • Financial API WG議長 • ISO/IEC JTC 1/SC 27/WG5国内小委員会主査 • WG5〜OECD/SPDEリエゾン • 野村総合研究所上席研究員 • https://www.sakimura.org • https://nat.sakimura.org • @_nat_en (English) • @_nat (日本語) • https://www.linkedin.com/ in/natsakimura • https://ja.wikipedia.org/wi ki/崎村夏彦 3

6. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 6 OpenID Foundationとは？ 米国オレゴン州非営利法人 Digital Identityに特化した国際標準化団体 (international standardization organization) 国際(international) = 参加に対する地域制限なし 標準化団体(standardization organization) = WTO TBT協定のプロセスに従って、コンセンサスベースで標準規格を作成する団体。 IPR regimeに特徴 特許相互不行使 規格サポートに関する商標(OpenID®) 不正利用取締 相互接続性強化のための規格準拠性認証（Certification） メンバー（スポンサー企業）と参加者 現在のスポンサー企業 ▪ 有料。Member Agreementが必要。理事の選任、WGの生成、規格承認が可能。 参加者（汗をかく人） ▪ 無料。IPR Agreementのみ必要。規格開発作業参加が可能。 6 Sustaining corporate members (理事企業) Corporate members Non-profit members NEC Yubico

7. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 7 「国際標準規格開発」と「普及・啓蒙・知財管理」がメインタスク国際標準規格開発 WGで実施  WG一覧は次ページ参照 完全にオープンな開発環境 IPR Agreementに署名さえすれば、無料で規格開発に参加可能。 Bitbucket (git) で変更管理。 課題(issue)を作成、プルリクエスト送信！普及・啓蒙・知財管理 OpenID Workshops 各種カンファレンスでのスピーチ Certification OpenID標準の提供サイト運営（安定的なURL） OpenID®の商標管理 各種団体とのリエゾン関係の管理 7

8. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 8 OpenID Foundation のワーキング・グループ(WG) WGは３社以上のメンバーの共同提案と Specs Council及び理事会のレビュー（２週間）によって形成される。 Specs Council は、現在のエディタから選任され、他のWGや規格作成団体との重複が無いかなどをチェック。 理事会は、知財的に財団にとってリスクをもたらさないかチェックを行う。 8

10. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 10 OpenID Foundation のFinancial API WG (2016/6組成） 目的 セキュリティ＋プライバシープロファイル、 JSON data schema, REST APIs, に関する勧告を提供し、 アプリケーションが金融口座に保管されているデータを利用すること、 アプリケーションが金融口座とやりとりすること、 利用者がセキュリティとプライバシー設定をすること、を可能にすることである。 銀行・証券口座のみならず、保険およびクレジットカード口座も考慮対象とする。 10 (Source) OpenID Foundation Financial API WG draft charterを元に、崎村試訳 JSON REST OAuth OpenID Connect (SOURCE) ODI OBWG: The Open Banking Standard (2016) FAPI WGの詳細情報 ↓ https://openid.net/wg/fapi/

11. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 11 なぜOpenID Foundationで行うのか？ • OAuth, JWT, JWS, OpenID Connect の全著者が所属 Right People • 無償、相互不主張提供とする知財ポリシー→だれでも自由に実装可能 Right IPR • WG加盟は無料 (スポンサーは歓迎だが) • WTO TBT 協定準拠のプロセス. Right Structure 11

12. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 12 作業は、週１回の電話会議（太平洋会議、大西洋会議を隔週で実施）、メーリング・リスト、プロジェクト・レポジトリ (https://bitbucket.org/openid/fapi/ )を通じて実施 12 課題管理議事録などコミット履歴プル・リクエストドラフト・テキスト

13. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 13 Working Together 13 OpenID FAPI (Chair) (Co-Chair)(Co-Chair) (UK OBIE Liaison) Liaison Organizations TC 68 JTC 1/SC 27/WG 5 Nat Sakimura Tony NadalinAnoop Saxena fido 2.0 WG Chair W3C Web Authn WG Chair

14. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 14 FAPI仕様群：Financial Services – Financial API – Part 1: Read Only API Security Profile (implementer’s draft) http://openid.net/specs/openid-financial-api-part-1.html Part 2: Read and Write API Security Profile (implementer’s draft) http://openid.net/specs/openid-financial-api-part-2.html Part X: Client Initiated Backchannel Authentication Profile (WD) Part 3: Open Data API (WD) UK OBIE からの寄付待ち Part 4: Protected Data API and Schema - Read only (WD) 銀行口座 - US FS-ISAC DDA / OpenBank Project / Figo などを参考に作成 UK OBIEからの寄付待ち 証券口座 – 現在NRIで試案作成中 Part 5: Protected Data API and Schema - Read and Write (WD) 同上〜Scopeではなく、Claims Requestを使うことで、より詳細・柔軟な認可を取得 14 OpenAPI(Swagger) ファイルを提供。レジストリ化？ ISO 20022？

18. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 18 “部品を正しく組み合わせることが重要だ。#oauth を使えば良いと言うだけでは解決策になっていない。” 18 -- Mark O’Neill, Gartner (SOURCE) Photo taken by Nat Sakimura @APIDays on 13th Dec. 2016 @APIDays Paris 2016 モバイルファーストの時代には, API保護にOAuth 2.0 を使うのは当然だが、 OAuthを使えというだけでは問題解決になっていない。なぜならば…

21. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 21 しかしそれは、個別の状況に応じてプロファイルを用意する必要があることを意味している。 21 対象の価値環境制御レベル高低高低 Social sharing Closed circuit Factory application Financial API – Read & Write たとえば: 基本的実装でも OK Bearer token Not OK 基本的実装ではダメすべてのセキュリティ要件をOAuth 層で満たす必要はないインターネットのように制御されていない環境下では、十分注意する必要がある。 Financial API – Read only

23. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 23 要因の例： 23 １クライアント１サーバの前提 メッセージ認証（要求・応答） 送信者認証 受信者認証 利用者認証 メッセージ秘匿性 トークンフィッシング／リプレイ金融機関向けのプロファイルはこれら全てを解決する必要がある。

24. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 24 Paraphrased BCM*1 Principles 24 4 Criteria (a)Unique Source Identifier (b)Protocol + version + msg identifier (c)Full list of actor/roles (d)Messages are not tampered Basin, D., Cremers, C., Meier, S.: Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication. Journal of Computer Security - Security and Trust Principles archive Volume 21 Issue 6, 817-846 (2013) *1

25. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 25 RFC6749 OAuth – code grant protocol メッセージs Authorization Request Authorization Response Token Request Token Response Assume:  a network attacker (e.g. Browser malware) the crypto & TLS are not broken pure RFC6749 – Three parties static OAuth 2.0 25 UA Client AS

26. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 26 So, how is RFC6749 (Naïve implementation) doing? Message Parameters (a) Unique Source Identifier (b) Protocol + version identifier (c) Full list of actor/roles (d) Message Authentication Authorization Request response type client id redirect uri scope state Authorization Response code state other extension parameters Token Request grant type code redirect uri client credential/client id . Token Response access token token_type expires_in refresh_token others 26 メッセージ種別毎にパラメータの組み合わせは異なるので、 (b)= Good! Legend Required Parameter Optional Parameter Recommended Parameter でも、喜ぶのはそこまでだ！

27. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 27 So, how is RFC6749 (Naïve implementation) doing? Message Parameters (a) Unique Source Identifier (b) Protocol + version identifier (c) Full list of actor/roles (d) Message Authentication Authorization Request response type client id redirect uri scope state Client ID is not globally unique. Tampering possible OK, but it is not integrity protected No. No. Authorization Response code state other extension parameters No source identifier OK, but it is not integrity protected No No Token Request grant type code redirect uri client credential/client id Client ID is not globally unique. OK (as long as there is no OAuth 3.0) No. OK Token Response access token token_type expires_in refresh_token others No source identifier As above No. OK 27

28. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 28 RFC6749における、発信者(sender)・受信者(receiver)・メッセージ(message)認証(authentication)の状況 28 送信者認証受信者認証メッセージ認証認可要求 Indirect None None 認可応答 None None None トークン要求 Weak Good Good トークン応答 Good Good Good

30. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 30 OAuth 2.0 関連のオプション機能とセキュリティレベルセキュリティ・レベル機能セット適用 JWS Authz Req w/Hybrid Flow 認可要求の保護 Hybrid Flow*1 (confidential client) 認可応答の保護 Code Flow (confidential client) + PKCE + MTLS code injectionへの対応長期Bearer Tokenの排除 Code Flow (confidential client) クライアント認証 Implicit Flow クライアント認証無し Plain OAuth Anonymous *1) stateインジェクションの回避のために、‘s_hash’ を含む。認証要求・応答の種類とセキュリティ・レベルトークンの種類とセキュリティ・レベルセキュリティ・レベルトークンの種類適用記名式トークン (Sender Constrained Token) 発行をうけた者しかトークン利用不能持参人トークン (Bearer Token) 盗難されたトークンも利用可能 30 Part 1 Part 2

31. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 31 Could be tightened up Message Parameters (a) Unique Source Identifier (b) Protocol + version identifier (c) Full list of actor/roles (d) Message Authentication Authorization Request response type client id redirect uri scope state Unique redirect URI + Client ID OK (Unique Parameter List) (a) + state as the UA identifier / TBID as UA identifier Request signing by JAR Authorization Response code state other extension parameters Unique redirect URI OK (Unique Parameter List) (a) + client_id + state as the UA identifier / TBID as UA identifier Response signing by ID Token + s_hash Token Request grant type code redirect uri client credential/client id Unique redirect URI + Client ID OK (Unique Parameter List) (a) + state as the UA identifier / TBID as UA identifier TLS Protected Token Response access token token_type expires_in refresh_token others Unique redirect URI OK (Unique Parameter List) (a) + client_id + state as the UA identifier / TBID as UA identifier TLS Protected 31

32. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 32 FAPI RWセキュリティプロファイルでは、送信者・受信者・メッセージ認証を強化 32 送信者認証受信者認証メッセージ認証認可要求 Request Object Request Object Request object 認可応答 Hybrid Flow Hybrid Flow Hybrid Flow トークン要求 Good Good Good トークン応答 Good Good Good

34. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 34 たとえば、ほんの一部を Part 1: Read Only API Security Profile から抜き出してみると、 注意） keywords が、IETF的なのと違います。（ISOのKeywords, “shall”, “should”, “may”, “can” を使っているため）。 34 （出所）Financial Services – Financial API -- Part 1: Read Only API Security Profile Implementer’s Draft

38. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 38 欧州 • UK Open Banking は Part 2 （＝Part 1を含む）を採用。現在、CMA9が実装中、来年1月13日にカットオーバー予定。 • ちなみに、Open Banking Profile は、FAPI WG下で現在リファクタリング中。 (https://bitbucket.org/openid/obuk/) • デンマークは、UK Open Bankingを横展開すると見られている。 • ドイツのBerlin Group も採用の方向？米国 • FS-ISACは、Part 1を採用の見込み。日本 • 全銀協の「オープンAPIのあり方に関する検討会」における検討結果で言及。 • 金融ISACが設置した「FinTechセキュリティWG」ではどうなるか？？？ 38

41. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 41 Part 3～はWorking Draft == work in progress 1. US FS-ISAC DDAのcontributionを受けてスタート(Part 4)。ただし、UK OBに合わせるかも。 2. Part 3, 5には、UK OBのOpen Data APIs と Read Write APIs の寄付を受けてアップデートする予定。UK OBのAPIと日本の現状のFit&GapはNRI内部で検討中。ある程度まとまり次第、WGにSubmit予定。 3. 証券APIは弱いので、現在まずはNRI内部で、どのようなデータモデルなら行けそうか検討中。ある程度まとまり次第、WGにSubmit予定。 41

43. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 43 Part 3: Open Data API ATM API Specification – v2.0.0 (location, service, and accessibility information about ATMs) Branch API Specification – v2.0.0 (location, service, accessibility, and opening time information about branches) PCA API Specification – v2.0.0 (product information about retail personal current accounts) BCA API Specification – v2.0.0 (product information about retail business current accounts) SME API Specification – v2.0.0 (product information about business unsecured loans) CCC API Specification – v2.0.0 (product information about commercial credit cards) 43

44. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 44 Part 4 - Account and Transaction API Resource Endpoint Mandatory? Parameters 1 account-requests POST /account-requests Mandatory Pagination 2 account-requests GET /account-requests/{AccountRequestId} Optional Pagination 3 account-requests DELETE /account-requests/{AccountRequestId} Mandatory Pagination 4 accounts GET /accounts Mandatory Pagination 5 accounts GET /accounts/{AccountId} Mandatory Pagination 6 balances GET /accounts/{AccountId}/balances Mandatory Pagination 7 beneficiaries GET /accounts/{AccountId}/beneficiaries Mandatory Pagination 8 direct-debits GET /accounts/{AccountId}/direct-debits Mandatory Pagination 9 products GET /accounts/{AccountId}/product Mandatory Pagination 10 standing-orders GET /accounts/{AccountId}/standing-orders Mandatory Pagination 11 transactions GET /accounts/{AccountId}/transactions Mandatory PaginationFiltering 12 balances GET /balances Optional Pagination 13 beneficiaries GET /beneficiaries Optional Pagination 14 direct-debits GET /direct-debits Optional Pagination 15 products GET /products Optional Pagination 16 standing-orders GET /standing-orders Optional Pagination 17 transactions GET /transactions Optional PaginationFiltering 44

45. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 45 Part 5 - Resource HTTP Operation End-point Mandatory? Scope Idempotent Request Object Response Object payments POST POST /payments Mandatory payments Yes OBPaymentSetu p1 OBPaymentSetu pResponse1 payments GET GET /payments/{Pay mentId} Optional payments NA NA OBPaymentSetu pResponse1 payment- submissions POST POST /payment- submissions Mandatory payments Yes OBPaymentSub mission1 OBPaymentSub missionResponse 1 payment- submissions GET GET /payment- submissions/{Pay mentSubmissionI d} Optional payments NA NA OBPaymentSub missionResponse 1 45 Payment Initiation API この他にも、Account Creationやら、証券取引やら…。ひょっとしたら、Part 5ではなく、Part 6 … にするのかも。

50. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 50 仕様が正しく実装されているかどうかは、Certification によって確認できるようにしていく。 オンライン提供されているテスト・スイートを使って、正しく実装されていることを確認。 結果をSelf Certify して登録・公開 → FTC法５条の配下に入る。これによって信頼性を担保。 また、ログも公開されるので、虚偽の申告は、他者が指摘可能。 現在はOP Certification, RP Certificationが正式提供中。 FAPIにおいても、同様のスキームでテスト可能にする予定。 Certificationの詳細については、 http://openid.net/certification/ 参照 50