Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Financial APIセキュリティの現状について @ OpenID BizDay 10

242 views

Published on

Financial APIセキュリティの現状について @ OpenID BizDay 10

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Financial APIセキュリティの現状について @ OpenID BizDay 10

  1. 1. Nomura Research Institute 崎村 夏彦(@_nat) Financial APIセキュリティの現状について • OpenID® は、 OpenID Foundation の登録商標です。 • *Unless otherwise noted, all the photos and vector images are licensed by GraphicStocks. 2017年8月1日 米国OpenID Foundation 理事長 上席研究員
  2. 2. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 2 崎村夏彦(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://nat.Sakimura.org/ • @_nat_en (English) • @_nat (日本語) • Linked.in/natsakimura • https://www.linkedin.com /in/natsakimura • https://ja.wikipedia.org/w iki/崎村夏彦 2
  3. 3. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 3 2015〜Fintechに対する関心が急速に上がってきている (SOURCE)Google Trends
  4. 4. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 4 APIはその中の主要な要素であると認識されてきている 4 Use cases for Identity Federation API in Financial sector 1. Account Opening (incl. KYC) 2. Personal Asset Managment 3. Payment, Sending Money 4. Loan Application 5. AI assisted portfolio management (Source) 日経BP: 『フィンテック革命』 P.4 (Source)日経BP: FinTech 年鑑
  5. 5. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 5 APIが提供する「LEGOモデル」は、B2Dという新たな顧客セグメントを作り出す。 Laurens Hamerlinck Innovation Manager ABN AMRO Bank @lhamerlinck • Open Banking APIs は、Fintech企業を英国に引き寄せている。 • API はLego モデルを可能にする。全てを自分で作る必要はなくなる。 • OEaS:=Our Expertise as a Service • 金融セクターは従来よりオープンになる。EUだけではなく、米国やそれ以外の地域でも。 • iOSアプリプラットフォームには、当初開発者はいなかった。しかし、その後のエコシ ステムに何が起こったか?オープン化しなかった会社には何が起きたか? • B2D: API は新たな顧客セグメントを作り出す。 『Bank as a Platform: Exploring a new Role in the Age of Technology』 (European Identity Summit 2017 講演よ り)
  6. 6. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 6 API提供により、パスワード保存が必要なくなることは、 口座保有者にとってもFintechにとっても歓迎すべきことである 6 概要 メリット デメリット 現 状 口座保有者のパス スワードを保存し、 し、口座保有者に になりかわって HTMLをスクレー ピング・解析・デー データ化 金融機関側のシステム変更なしに、Fintech側だけ けで対応できる。 口座保有者 • Fintechに全権を委ねることになる。 Fintech • パスワード保管コスト • ページ変更対応コスト 金融機関 • 顧客保護面の課題 • システム負荷 AP I提 供 後 アプリケーションの ンの処理内容ごと とに権限を区切っ 切った「トークン」を ン」を発行し、それ それを使ってクライ ライアントが「構造 「構造化データ」に タ」にアクセス。 口座保有者 • Fintechには、必要最低限の権限付与。 • よりカスタマイズしたサービスがうけられるよう ようになる。 Fintech • パスワード保管コストがかからない。 • ページ変更対応コストがかからない。 金融機関 • 顧客保護面で優れている。 • Fintechと協力してサービス拡充が可能になる。 る。 Fintech • API制約の中で動くことになる。 金融機関 • API開発・メンテナンスコストがかかる。
  7. 7. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 7 一方では、「Future of European Fintech」のように、 パスワード保存によるアクセス(Direct Access)がセキュアであり、 これをつづけるべきと主張するFintech企業群もある。 パスワード保存モデルは原理的にセキュアではあり えない。 パスワード保存モデルは、Access Minimizationの原則に 反する。 ユーザ認識に対する悪影響も要考慮。 金融機関が提供するAPIの数が足りないというのな らば、トークン+スクリーン・スクレーピングを考慮す べき。 Evestment Yodleeなどはこの考え。 金融機関が、自社のAPIを提供するために、Fintechと契約 してScreen Scrapingするのは、この類型でできるはず。 7
  8. 8. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 8 モバイルファーストの時代には, API保護にOAuth 2.0 を使うのは当然. 8
  9. 9. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 9 問題解決?!
  10. 10. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 10 “部品を正しく組み合わせることが重 要だ。#oauth を使えば良いと言うだ けでは解決策になっていない。” 10 -- Mark O’Neill, Gartner (SOURCE) Photo taken by Nat Sakimura @APIDays on 13th Dec. 2016 @APIDays Paris 2016 モバイルファーストの時代には, API保護にOAuth 2.0 を使うのは当然だが、 OAuthを使えというだけでは問題解決になっていない。
  11. 11. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 11 なぜなら、OAuth 2.0 はフレームワーク: 11
  12. 12. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 12 OAuthは「フレームワーク」であることより、様々なサービス環境に 適切に対応できるようになっている。 12 様々なサービス環境に 対応するための 柔軟なオプションを提供 対象の価値 環境制御レベル高 低 高 低
  13. 13. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 13 しかしそれは、個別の状況に応じてプロファイルを用意する必要 があることを意味している。 13 対象の価値 環境制御レベル高 低 高 低 Social sharing Closed circuit Factory application Financial API – Read & Write たとえば: 基本的実装でも OK Bearer token Not OK 基本的実装では ダメ すべてのセキュリティ要件をOAuth 層で満たす必要はない インターネットのように制 御されていない環境下 では、十分注意する必 要がある。 Financial API – Read only
  14. 14. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 14 RFC6749における、発信者(sender)・受信者(receiver)・ メッセージ(message)認証(authentication)の状況 14 送信者認証 受信者認証 メッセージ認証 認可要求 Indirect None None 認可応答 None None None トークン要求 Weak Good Good トークン応答 Good Good Good
  15. 15. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 15 OAuth 2.0 関連のオプション機能とセキュリティレベル セキュリ ティ・レベル 機能セット 適用 JWS Authz Req w/Hybrid Flow 認可要求の保護 Hybrid Flow*1 (confidential client) 認可応答の保護 Code Flow (confidential client) クライアント認証 Implicit Flow クライアント認証無し Plain OAuth Anonymous *1) stateインジェクションの回避のために、‘s_hash’ を含む。 認証要求・応答の種類とセキュリティ・レベル トークンの種類とセキュリティ・レベル セキュリ ティ・レ ベル トークンの種類 適用 記名式トークン (Sender Constrained Token) 発行をうけた者しか トークン利用不能 持参人トークン (Bearer Token) 盗難されたトークンも 利用可能 15
  16. 16. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 16 FAPI RWセキュリティプロファイルでは、送信者・受信者・ メッセージ認証を強化 16 送信者認証 受信者認証 メッセージ認証 認可要求 Request Object Request Object Request object 認可応答 Hybrid Flow Hybrid Flow Hybrid Flow トークン要求 Good Good Good トークン応答 Good Good Good
  17. 17. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 17 金融APIのためのプロファイルを作る上では、 複数の要因を考慮する必要がある。 17 これらの多くはしばしば無視され、結果として非常 に危ないOAuth 2.0実装を産んでいる。
  18. 18. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 18 要因の例: 18 1クライアント1サーバの前提 メッセージ認証(要求・応答) 送信者認証 受信者認証 利用者認証 メッセージ秘匿性 トークンフィッシング/リプレイ 金融機関向けのプロファイルは これら全てを解決する必要がある。
  19. 19. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 19 OAuthの重要なセキュリティ上の前提に、 「1クライアント1サーバ」の前提がある:  Personal Finance Management ソフトの場合, 当該クライアントは必ず複数の認可サーバとやりとりすることになる.  論理的な分離(それぞれの認可サーバ毎に異なるredirection uriを設定)することが、 認可サーバMix-up攻撃などを回避するのには重要。 v.s. C1 O C1R U A A1Z C2R C2 O A2Z 1クライアント1認可サーバモデル C2R C1 O C1R U A A1Z C2 O A2Z 1クライアントN認可サーバモデル
  20. 20. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 20 メッセージ認証の問題 (ブラウザなどの)UAを通じた通信は、UA内で終端されるため、TLSで保護されない。つまり、メッセージ認 証はされず、変更されるおそれがある。にもかかわらず、多くの場合、汚染チェックせずに使われる。 例えば、codeもstateも、額面どおりに受け取ってはならないのにもかかわらず、実際にはそうすることが 多い…。 C1O C1R UA A1Z TLSが終端される。 メッセージ認証されていない。 (response_type, client_id, redirect_uri, scope, state) メッセージ認証されていない。 (code, state)
  21. 21. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 21 メッセージ送信者認証の問題 認可要求・応答はブラウザーを通じて送られるため、受信者は実際の送信者が誰かを確 かめることができない。 C1O C1R UA A1Z TLSが終端される。 A1Z は認可要求が C1Oから来たことを確認できない。 C1R は認可応答が C1Oから来たことを確認できない。
  22. 22. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 22 メッセージ受信者認証問題 モバイルアプリ(パブリッククライアント)上の「code横取り攻撃」などで顕著。 例:カスタム・スキームなどはデバイス上のマルウェアなどによってハイジャック。 ▪ 非常に有名なアプリがこの攻撃にあっていた。 ▪ RFC7636 OAuth PKCE はこの問題への対処のために存在している. 22 Good App Bad App UA A1Z Redirect uri = goodapp:// I am goodapp!
  23. 23. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 23 Identity とユーザ認証問題 23 OAuth にはユーザのIdentityの概念が無い. ユーザ認証は“out of scope”.
  24. 24. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 2424Created by @nishantk
  25. 25. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 25 メッセージ秘匿性問題 認可要求は、アプリケーション層では暗号化されていないので、man-in-the-browserな どによって読まれてしまう可能性がある。 ブラウザ内マルウェアはかなり一般的である。 2014年には、man-in-the-browserによる不正送金が、日本のオンライン・バンキングに対する主要な 攻撃のひとつであった。 C1O C1R UA A1Z TLSが終端される。 マルウェアはメッセージの内容を読むことができる。
  26. 26. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 26 トークン・フィッシング/トークン・リプレイ クライアントがトークン要求とリソース要求を、不正なサーバに送る。不正サーバは今度 はクライアントとして、取得した要求を正規のサーバに送る。 例: ▪ クライアント開発者に、サーバのエンドポイントが変更されたとの偽メールを送る。(20人に1人程度はこのよう なメール・フィッシングにひっかかることが知られている。) ▪ 不正発行されたTLS証明書とDNSスプーフィングの組み合わせ ← 南米の某銀行で実際に行われた。 26 Client XYZ Attack er ABC Bank Hi I am ABC Bank API Hi I am Client XYZ
  27. 27. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 27 BCM Principles P1 Positional tagging. Cryptographic message components should contain information that uniquely identities their origin. In particular, the information should identify the protocol, the protocol variant, the message number, and the particular position within the message, from which the component was sent. P2 Inclusion of identities and their roles. Each cryptographic message component should include information about the identities of all the agents involved in the protocol run and their roles, unless there is a compelling reason to do otherwise. 3 Criteria (a)Unique Source Identifier (b)Protocol + version + msg identifier (c)Full list of actor/roles 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) (a) (b) (c)
  28. 28. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 28 Let’s apply! 28 Let’s Play!
  29. 29. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 29 RFC6749 OAuth – code grant protocol msgs Authorization Request Authorization Response Token Request Token Response Assume:  a network attacker as (e.g. Browser malware) the crypto & TLS are not broken pure RFC6749 – Three parties static OAuth 2.0 29 UA Clien t AS
  30. 30. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 30 So, how is RFC6749 (Naïve implementation) doing? Message Parameters (a) Unique Source Identifier (b) Protocol + version identifier (c) Full list of actor/roles 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 30 Combination of parameters are unique for each message type = (b) Good! Legend Required Parameter Optional Parameter Recommended Parameter But the good ends here.
  31. 31. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 31 So, how is RFC6749 (Naïve implementation) doing? Message Parameters (a) Unique Source Identifier (b) Protocol + version identifier (c) Full list of actor/roles Authorization Request response type client id redirect uri scope state Client ID is not globally unique. Tampering possible List of params as identifier, but it is not integrity protected No. Authorization Response code state other extension parameters No source identifier As above 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. Token Response access token token_type expires_in refresh_token others No source identifier As above No. 31
  32. 32. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 3232 It’s a sad state.
  33. 33. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 33 Could be tightened up Message Parameters (a) Unique Source Identifier (b) Protocol + version identifier (c) Full list of actor/roles Authorization Request response type client id redirect uri scope state Unique redirect URI + Client ID Request signing (a) + state as the UA identifier / TBID as UA identifier Authorization Response code state other extension parameters Unique redirect URI Response signing (a) + client_id + state as the UA identifier / TBID as UA identifier Token Request grant type code redirect uri client credential/client id Unique redirect URI + Client ID OK (as long as there is no OAuth 3.0) (a) + state as the UA identifier / TBID as UA identifier Token Response access token token_type expires_in refresh_token others Unique redirect URI As above (a) + client_id + state as the UA identifier / TBID as UA identifier 33
  34. 34. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 34 Integrity protect the AuthZ Request/Response • draft-ietf-oauth-jwsreq aka OAuth JAR AuthZ Request • Use ID Token as a dethatched signature. • Include new parameter `s_hash` in the ID Token. AuthZ Response 34
  35. 35. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 35 Comparison Message Original Parameters Modified Parameters Original Integrity Protection Modified Integrity Protection Authorization Request response type client id redirect uri scope state response type client id redirect uri (uniqeue) scope state/tbid None JAR Authorization Response code state extension params code state redirect uri (uniqeue) client id state/tbid extension params None ID Token + s_hash Token Request grant type code redirect uri client cred/id grant type code redirect uri (uniqeue) client cred/id state/tbid TLS TLS Token Response access token token_type expires_in refresh_token others access token token_type expires_in refresh_token others TLS TLS 35
  36. 36. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 36 BCM Principles Satisfied! 36
  37. 37. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 3737
  38. 38. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 3838 Science needed!
  39. 39. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 39 Darmstadt University Team 39
  40. 40. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 40 Academics & Standardization 40
  41. 41. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 41 こうした課題を解決するために組成されたのが、OpenID Foundation のFinancial API WGである。 目的 セキュリティ+プライバシー^プロファイル、 JSON data schema, REST APIs, に関する勧告を提供し、 アプリケーションが金融口座に保管されている データを利用すること、 アプリケーションが金融口座とやりとりすること、 利用者がセキュリティとプライバシー設定をするこ と、 を可能にすることである。 銀行・証券口座のみならず、保険およびクレジット カード口座も考慮対象とする。 41 (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/
  42. 42. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 42 なぜOpenID Foundationで行うのか? • OAuth, JWT, JWS, OpenID Connect の 全著者が所属 Right People • 無償、相互不主張提供とする知財ポリシー →だれでも自由に実装可能 Right IPR • WG加盟は無料 (スポンサーは歓迎だが) • WTO TBT 協定準拠のプロセス. Right Structure 42
  43. 43. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 43 In a IPR safe and Completely Open Environment IPR regime 特許相互不行使 規格サポートに関する商標(OpenID®) 不正利用取締 相互接続性強化のための規格準拠性認証 (Certification) 完全にオープンな開発環境 IPR Agreementに署名さえすれば、無料で規格開発に 参加可能。 Bitbucket (git) で変更管理。 ▪ 課題(issue)を作成、プルリクエスト送信! Made possible by these sponsors! 43 Sustaining corporate members (理事企業) Corporate members Non-profit members
  44. 44. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 44 作業は、週1回の電話会議(太平洋会議、大西洋会議を隔週で実施)、 メーリング・リスト、 プロジェクト・レポジトリ (https://bitbucket.org/openid/fapi/ )を通じて実施 44 課題管理 議事録など コミット履歴 プル・リクエスト ドラフト・テキスト
  45. 45. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 45 Working Together 45 OpenID FAPI (Chair) (Co-Chair)(Co-Chair) (UK OBIE Liaison) Liaison Organizations
  46. 46. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 46 現在の仕様構造と今後の見込み Financial Services – Financial API – Part 1: Read Only API Security Profile http://openid.net/specs/openid-financial-api-part-1.html ▪ Implementer’s Draft (I-D) ~実装開始 Part 2: Read and Write API Security Profile http://openid.net/specs/openid-financial-api-part-2.html ▪ Public Review中 〜各種ベンダー実装中 Part X: CIBA Profile https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md?at=master Part 3: Open Data API ▪ UK OBIE からの寄付待ち Part 4: Protected Data API and Schema - Read only ▪ 銀行口座 - US FS-ISAC DDA / OpenBank Project / Figo などを参考に作成 UK OBIEからの寄付待ち ▪ 証券口座 – 現在NRIで試案作成中 Part 5: Protected Data API and Schema - Read and Write ▪ 同上〜Scopeではなく、Claims Requestを使うことで、より詳細・柔軟な認可を取得 46 OpenAPI(Swagger) ファイルを提供。 レジストリ化? ISO 20022?
  47. 47. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 47 Financial Services – Financial API -- Part 1: Read Only API Security Profile 注意) keywords が、IETF的なのと違います。(ISOのKeywords, “shall”, “should”, “may”, “can” を使っているため)。 いっぱい “shall” があります。全部やらないとセキュリティ・レベル、保てません。 47 (出所)Financial Services – Financial API -- Part 1: Read Only API Security Profile Implementer’s Draft
  48. 48. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 48 Adoption among the industry is great! 48
  49. 49. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 49 Japanese Banker’s Association Recommendation (16 March 2017) 49
  50. 50. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 50 Open Banking Implementation Entity Announcement (17 May 2017)
  51. 51. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 51 これらを正しく実装できているか、 どうやったらわかるか? 51
  52. 52. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 52 Certification test will be available online 52
  53. 53. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 53 仕様が正しく実装されているかどうかは、Certification によって 確認できるようにしていく。 オンライン提供されているテスト・スイートを使って、正しく 実装されていることを確認。 結果をSelf Certify して登録・公開 → FTC法5条の配下に入る。これによって信頼性を担保。 また、ログも公開されるので、虚偽の申告は、他者が指摘可能。 現在はOP Certificationが正式提供中。 来週RP Certificationが発表される予定。 FAPIにおいても、同様のスキームでテスト可能にする予 定。 Certificationの詳細については、 http://openid.net/certification/ 参照 53
  54. 54. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 54 おまけ おまけ おまけ おまけ おまけ おまけ おまけ おまけ おまけ おまけ おまけ おまけおまけ おまけ おまけ おまけ おまけ おまけ おまけ スマホ・アプリでOAuthをつかうとき どうしていますか? 54
  55. 55. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 55 モバイルにおける認証時のベスト・プラクティス OAuth 2.0 for Native Apps OpenID FoundationのNative Apps WGの検討結果をIETFに持ち込んだもの。 https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07 Native apps MUST use an external user-agent to perform OAuth authentication requests. ▪ Embedded User-agent (e.g.WebView) は使ってはいけない. Authorization servers MUST support the following three redirect URI options. ▪ App-declared Custom URI Scheme Redirection ▪ App-claimed HTTPS URI Redirection ▪ Loopback URI Redirection Public native app clients MUST protect the authorization request with PKCE [RFC7636]. Authorization servers that still require a shared secret for native app clients MUST treat the client as a public client 55
  56. 56. © 2017 by Nat Sakimura. CC-BY-SA. Copyright © 2016 Nat Sakimura. All Rights Reserved. 56 まとめ 1. APIは「LEGOモデル」によるB2D顧客セグメントを出現させ、Fintechの成長を促進する。 A) 英国はPSD2を超えて、標準APIの整備を法的に要求することにより、Fintech企業を引きつけている。 B) 一方では、「Future of European Fintech」のように、パスワード保存によるアクセス(Direct Access)がセキュアであり、 これをつづけるべきと主 張するFintech企業群もある。 2. APIは、パスワード保存モデルからの脱却を即し、顧客により安全かつ安定した環境を提供する。 3. API保護にはOAuthを利用するのが主流だが、対象となるAPIのリスクに応じて適切にオプションを選ぶ必要がある。 A) 認可要求・応答保護、記名式トークンなど 4. OpenID Foundationには、OAuth, JWT, JWSなどのAPI保護の主要仕様の著者全員があつまっており、ここで金融 API利用に適したプロファイルの策定を進めている。 5. FAPIのセキュリティ・プロファイルは、金融APIのRead Only/Read Writeの2段階のリスクレベルに応じて、適切なオ プションを提示している。 6. FAPIセキュリティ・プロファイルの採用も進んできている(全銀協、英国OBIE)。 7. アクセス許可の要求には、Scopeではなく、Claimsを定義して使うことにより、セキュリティ・プライバシーともに向上。 8. 実装が適切であるかの評価をしやすくするために、OpenID Certification をFAPI用に提供する予定。 9. スマホ・アプリでOAuthを使うためには、draft-ietf-oauth-native-apps の利用を推奨。 56

×