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

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

© 2017 by Nat Sakimura. CC-BY-SA.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
2
JWT
JWS
OAuth PKCE
OpenID Connect

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

Copyright（C） Nomura Research Institute, Ltd. All rights reserved. 4
自己紹介
OpenID Foundationとは
FAPI WGとは？
FAPI Part 1 & 2
FAPI Part 3 and beyond
Certification
もくじ

5
自己紹介
FAPI WGとは？
FAPI Part 1 & 2
Certification
もくじ

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

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

9
OpenID Financial API (FAPI) WGとは？
9

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

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

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
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？

15
自己紹介
FAPI WGとは？
FAPI Part 1 & 2
Certification
もくじ

16
Part 1 , 2 の特徴＝セキュリティ・プロファイル
16

17
え、OAuth使えばそれで
問題解決なんじゃ?!

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を使えというだけでは問題解決になっていない。
なぜならば…

19
OAuth 2.0 はフレームワーク：
19

20
OAuthは「フレームワーク」であることより、様々なサービス環境に
適切に対応できるようになっている。
20
様々なサービス環境に
対応するための
柔軟なオプションを提供
対象の価値
環境制御レベル高低
高
低

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

22
金融APIのためのプロファイルを作る上では、
複数の要因を考慮する必要がある。
22
これらの多くはしばしば無視され、結果として非常
に危ないOAuth 2.0実装を産んでいる。

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

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
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
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
So, how is RFC6749 (Naïve implementation) doing?
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
code
redirect uri
client
Client ID is not
globally unique.
OK (as long as there
is no OAuth 3.0)
No. OK
token_type
expires_in
refresh_token
others
No source identifier As above No. OK
27

28
RFC6749における、発信者(sender)・受信者(receiver)・
メッセージ(message)認証(authentication)の状況
28
送信者認証受信者認証メッセージ認証
認可要求 Indirect None None
認可応答 None None None
トークン要求 Weak Good Good
トークン応答 Good Good Good

2929
泣けてくる

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
Could be tightened up
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
code
redirect uri
client
Unique redirect URI
+ Client ID
OK (Unique
Parameter List)
(a) + state as the
UA identifier / TBID
as UA identifier
TLS Protected
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
FAPI RWセキュリティプロファイルでは、送信者・受信者・
メッセージ認証を強化
32
送信者認証受信者認証メッセージ認証
認可要求 Request Object Request Object Request object
認可応答 Hybrid Flow Hybrid Flow Hybrid Flow
トークン要求 Good Good Good
トークン応答 Good Good Good

33
実際のFAPI Profileは、
チェックリストになっています。
33

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

35
これ以外にも、いっぱい “shall” があります。
全部やらないとセキュリティ・レベル、保てません。
35

36
Part 1, 2の採用状況は良好
36

37
Open Banking Implementation Entity Announcement (17 May 2017)

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

39
自己紹介
FAPI WGとは？
FAPI Part 1 & 2
Certification
もくじ

40
Part 3, 4, 5 and beyond
40

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

42
ちなみに、UK Open Bankingをベースにすると、
Part 3, 4, 5はこんな感じに。
42

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
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
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 … にするのかも。

46
User not-in-presence authorizationは
どうするのか？
46

47
Client Initiated Backchannel Authentication
Profile
47

48
これらを正しく実装できているか、
どうやったらわかるか？
48

49
自己紹介
FAPI WGとは？
FAPI Part 1 & 2
Certification
もくじ

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

51
uestions?
51

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

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

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

More from Nat Sakimura

More from Nat Sakimura (20)

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