FAPI Security

Yoko TAMADA @tmd452017/08/18 feedforce Inc.

OpenID BizDay で金融 API に求められるセキュリティの話を聞いてきた話

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

https://www.slideshare.net/secret/t4myNYsddpQX4k

© 2017 by Nat Sakimura. CC-BY-SA

本スライドもこれに従い CC-BY-SA ライセンスとします。

所出、ライセンス

OAuth 2.0 おさらい

※用語は OpenID Connect と混ざってます

OAuth とは

● リソースアクセスのしくみ（認可 , Authorization）

● リソース（≒ 個人情報）へのアクセスを許可する／許可してもらう

【ソーシャルPLUS】各プロバイダの認証プロトコル #補足

https://feedforce.qiita.com/tmd45/items/2c7dc19854746096b330#%E8%A3%9C%E8%B6%B3

例「Taro さん が キャンペーンサイト に Facebook ログイン を使ってログインする」

● IdP（Identity Provider）

○ 認証結果と属性情報を 提供する 側 ＝Facebook

○ 認証（認可）のサーバ側とか呼んだりする

● RP（Relying Party）

○ 認証結果と属性情報を 受け取る 側 ＝キャンペーンサイト

○ 認証（認可）のクライアント側とか呼んだりする

● その他

○ Entity（実体）＝Taro さん（エンドユーザー , 人間）

○ Identity（属性）＝Taro さんの情報（ID, 個人情報 , など）

Role

● 認証とは「ブラウザの前にいる Entity が、サービス側が認識するどの Identiry と紐付いてい

るのか確証を得ること」

● 認可を元に得られた情報（プロバイダ側のユーザ ID）→ お客様システムの会員 ID と紐づくこ

とで、サービス側は「いまブラウザの前にいる人は Taro さんである」という確証を得る

○ ソーシャルログインによる認証

認証と認可

1. 認可要求（Authorization Request）

2. 認可応答（Authorization Response）

3. トークン要求（Access Token Request）

4. トークン応答（Access Token Response）

認可取得のフロー

キャンペーンサイト（RP）

Facebook（IdP）

エンドユーザ

認可開始（ログインボタン押下とか）

認可要求

ログイン／同意画面

認可応答

トークン要求

トークン応答

例: メアドの取得（API 利用）

⑤ じゃあください！… あ、このメアドは過去にご利用いただいたゲ＊ラ様ですね！

マイページ表示

① メアドが欲しいです

② メアドが欲しいって言われてるんだけどいい？

③ よかろう

④ いいってさ

● パスワード保存モデルは原理的※にセキュアではない

● OAuth 2.0 を使わせるのは当然

API のセキュリティ

おさらいおわり

OAuth 2.0 のセキュリティ

● OAuth 2.0 を使わせるのは当然

API のセキュリティ（再）

● OAuth 2.0 を使わせるのは当然

○ OAuth 2.0 を使っていれば安全なのか？

API のセキュリティ（再）

● OAuth 2.0 はフレームワークである

○ RFC6749 - The OAuth 2.0 Authorization Framework

● "部品を正しく組み合わせることが重要。 OAuth を使えば良いというだけでは解決策にはなって

いない。" ― Mark O'Neill, Gertner @APIDays Paris 2016

● さまざまなサービス環境に適切に対応するための、柔軟なオプションを提供している

ただ OAuth を使うというだけではダメ

個別の状況によってプロファイルが必要

Closed Circuit Factory

Application

Social Sharing

Financial API- Read only

Financial API- Read & Write

環境制御レベル高 低

高

低

対象の価値

基本実装でも充分

基本実装ではダメ

インターネットのように制御されていない環境下

基本のプロファイル

送信者(sender), 受信者(receiver), メッセージ(message) の認証

送信者認証 受信者認証 メッセージ認証

認可要求 間接的 なし なし

認可応答 なし なし なし

トークン要求 弱い GOOD GOOD

トークン応答 GOOD GOOD GOOD

オプション機能とセキュリティレベル

認可要求/応答の種類とセキュリティレベル

セキュリティレベル 機能セット 適用

高JWS AuthZ Req.w/ Hybrid Flow

認可要求の保護

Hybrid Flow(confidential client)

認可応答の保護

Code Flow(confidential client)

クライアント認証

低Implicit Flow クライアント認証なし

オプション機能とセキュリティレベル

トークンの種類とセキュリティレベル

セキュリティレベル トークンの種類 適用

高記名式トークンSender Constrained Token

発行を受けた者しか利用できない

低持参人トークンBearer Token

盗難されたトークンでも利用可能

飛行機のチケット

電車の切符

※Hybrid Flow は OpenID Connect Core のなかで策定されている

http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#HybridFlowAuth

金融 API 向けに策定中のプロファイル

送信者(sender), 受信者(receiver), メッセージ(message) の認証

送信者認証 受信者認証 メッセージ認証

認可要求 Request Object Request Object Request Object

認可応答 Hybrid Flow Hybrid Flow Hybrid Flow

トークン要求 GOOD GOOD GOOD

トークン応答 GOOD GOOD GOOD

● １クライアント１サーバの前提

● メッセージ認証（要求・応答）

● 送信者認証

● 受信者認証

● 利用者認証

● メッセージ秘匿性

● トークンフィッシング、リプレイ

金融 API で解決必須の要因

"これらの多くはしばしば無視され、結果として非常に危ない OAuth 2.0 実装を産んでいる。"― Nat Sakimura @OpenID BizDay

C1R

● OAuth の重要な「セキュリティ上の前提」

○ 論理的な分離（認可サーバ毎に異なる redirection uri を設定）することが、認可サーバ

Mix-up 攻撃などを回避するのに重要

１クライアント１サーバの前提

UA

C1O

C1R

C2O

C2R

A1Z

A2Z

１クライアント１認可サーバ

UA

C1O

C1R

C2O

A1Z

A2Z

１クライアント N 認可サーバ

違う認可サーバからの応答を１つのredirection uri で受け取る、とか

● UA（ブラウザなど）を介した通信は、 UA 内で TLS が終端するため保護されない。メッセージは

認証されず、変更される恐れがある

● 例えば code や state も汚染チェックせずに使われることが多い

メッセージ認証の問題

UA

C1O

C1R

A1Z

メッセージ認証されていない(response_type, client_id, redirect_uri, scope, state)

メッセージ認証されていない(code, state)

TLS 終端

● 認可要求・応答はブラウザを介するため、受信者は実際の送信者がだれかを確かめることが

できない

メッセージ 送信者 認証の問題

UA

C1O

C1R

A1Z

AZ は認可要求が CO から来たことを確認できない

CR は認可応答が AZ から来たことを確認できない

TLS 終端

● ネイティブアプリ（パブリッククライアント）上の「 code 横取り攻撃」などで顕著

○ 例: カスタムスキームをデバイス上のマルウェアなどによってハイジャック

○ OAuth PKCE (RFC7636) はこの問題のために存在している

メッセージ 受信者 認証の問題

UA

GOOD APP

BADAPP

A1Z

I am GOOD APP!!!

redirect uri = goodapp://

● OAuth には利用者（ユーザ）の Identity の概念が無い

● 利用者（ユーザ）認証については "Out of scope"

利用者認証 問題

● 認可要求はアプリケーション層では暗号化されていないので、 man-in-the-browser などによっ

て読み取られる可能性がある

● ブラウザ内マルウェアはかなり一般的

メッセージ秘匿性 問題

UA

C1O

C1R

A1Z

マルウェアはメッセージの内容を読むことができる

TLS 終端

● クライアントがトークン要求とリソース要求を「不正なサーバ」に送る。不正なサーバは今度は

「クライアント」として取得した要求を正規のサーバに送る

○ クライアント開発者に、サーバのエンドポイントが変更されたとの偽メールを送る

（２０人に１人程度はこのようなメール・フィッシングにひっかかることが知られている）

○ 不正発行された TLS 証明書と DNS スプーフィングの組み合わせ

トークン・フィッシング、トークン・リプレイ

AttackerClientABC Provider

Hi! I am Provider API ♥

Hi! I am Client ABC ♪

どうする？FAPI セキュリティ

1. Unique Source Identifier

2. Protocol + Version + Message Identifier

3. Full list of Actors/Roles

３つの要

OAuth 2.0 (RFC6749) の単純な実装の場合

Message Parameters ① Unique Source Identifier

② Protocol + Version Identifier ③ Fill list of Actors/Roles

認可要求

response type*client id*redirect uriscopestate

Client ID はグローバルに unique ではないため改ざんが可能

識別子として params のリストがありますが、これは完全な保証にはなりません

存在しない

認可応答code*state*other ext params

Source Identifier にあたるものは存在しない

同上 存在しない

トークン要求

grant type*code*redirect uri*client*credential / client id*

Client ID はグローバルに unique ではない

OK (OAuth 3.0 が存在しないかぎり)

存在しない

トークン応答

access token*token_type*expires_inrefresh_tokenothers

Source Identifier にあたるものは存在しない

同上 存在しない

FAPI WG で考案中の実装

Message Parameters ① Unique Source Identifier

② Protocol + Version Identifier ③ Fill list of Actors/Roles

認可要求

response type*client id*redirect uriscopestate

Unique redirect URI& Client ID

要求署名 ① + UA 識別子としての state あるいは TBID

認可応答

code*state*other ext params

Unique redirect URI 応答署名 ① + Client ID + UA 識別子としての state あるいは TBID

トークン要求

grant type*code*redirect uri*client*credential / client id*

Unique redirect URI& Client ID

OK (OAuth 3.0 が存在しないかぎり)

① + UA 識別子としての state あるいは TBID

トークン応答

access token*token_type*expires_inrefresh_tokenothers

Unique redirect URI 同上 ① + Client ID + UA 識別子としての state あるいは TBID

認可要求/応答の整合性を保護する

● AuthZ※ Request/Response Integrity Protection

○ Authorization の略記

● OAuth JAR (JWT Authorization Request) - IETF draft

● ID Token (JWT による署名が施されている ) の利用

● ID Token に新しいパラメータ `s_hash` を含める

Message OriginalParameters

ModifiedParameters

OriginalIntegrity Protection

ModifiedIntegrity Protection

認可要求

response type*client id*redirect uriscopestate

response type*client id*redirect uri* (unique)scope*state* / tbid*

なし JWT Authorization Request(JAR)

認可応答

code*state*other ext params

code*state*redirect uri* (unique)client id*state* / tbid*other ext params

なし ID Token + s_hash

トークン要求

grant type*code*redirect uri*client*credential / client id*

grant type*code*redirect uri* (unique)client*credential / client id*state* / tbid*

TLS TLS

トークン応答

access token*token_type*expires_inrefresh_tokenothers

+ 上記access token*token_type*expires_inrefresh_tokenothers

TLS TLS

これらはまだ "Art" であり "Science" が必要

● ドイツのダルムシュタット工科大学のチームが学術的に標準化を試みている

これらの課題解決のための組織

● OpenID Foundation の Financial API WG https://openid.net/wg/fapi/

● なぜ OpenID Foundation でやるのか

○ OAuth, JWT, JWS, OpenID Connect の全著者が所属している

○ 無償、相互不主張提供とする知財ポリシーにより、だれでも自由に実装可能となる

○ WG 加盟は無料（スポンサーは募集中とのこと）

○ WTO TBT 協定※ 準拠プロセス

■ 貿易の技術的障害に関する協定 云々

所感: 金融って大変だな…

おまけ

正しく実装できているかチェック

● Self Certify 出来る（Docker Image の配布もある）

● Self Certify を公開すると FTC法5条 が適用される

● 公開せずにチェックツールとして使うのも良い

スマホアプリにおける認証時のベストプラクティス

● OAuth 2.0 for Native Apps

○ https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07

○ ネイティブアプリは OAuth認証リクエストを実行するために外部ユーザエージェントを使用しなければならない (MUST)

■ 組み込み UA (WebView など) は使ってはいけない （！！！）

○ 認証サーバは、以下の３つの redirect uri オプションをサポートしなければならない (MUST)■ App-declared Custom URI Scheme Redirection■ App-claimed HTTPS URI Redirection■ Loopback URI Redirection

○ パブリックネイティブアプリクライアントは、 Proof Key for Code Exchange (PKCE, RFC7636) で認可リクエストを

保護しなければならない (MUST)○ ネイティブアプリクライアントのために shared secret が依然として必要な認証サーバーは、クライアントをパブ

リッククライアントとして扱わなければならない (MUST)

これから想定される OAuth

● ネットに繋いでいない（ブラウザを開くなどしていない）ユーザの認可

○ サーバからユーザのスマフォに push 通知で認可を求める

Closed Circuit Factory

Application

Social Sharing

Financial API- Read only

Financial API- Read & Write

環境制御レベル高 低

高

低

対象の価値

終──────ⓣⓜⓓ