ケンタロウのメモ

内容薄めです。

秘密の質問について

前回パスワードの定期変更についてという記事を書いた

 

kentarou55.hatenablog.com

 

もう一つ気になっているのが秘密の質問である。

事前登録した質問にいくつか正解すると、パスワード初期化画面に遷移できるといったものだ。僕の構築した認証基盤にも実装されている。

 

パスワードについては何文字以上だの変更頻度だの強度について議論がされるのに秘密の質問の強度はあまり議論されない(気がする)。

しかしこれを突破するとパスワードが漏洩したのと当然同じことになる。

 

しかも秘密の質問はソーシャルハッキングが可能だ。

大体「母親の旧姓」や「ペットの名前」などがよくある質問項目だがSNSなどの公開情報から推測できるものもあるだろう。

 

ただ、秘密の質問も数年前はお勧めのオプションだったのだ。

僕は「セルフヘルプ」の目的でこの機能を実装した。

認証基盤の運用をしていると、驚くほどパスワードがわからなくなる人は多い。そういう時は管理者が本人確認した上で初期化したりするが、その負荷を軽減するために、自分自身でパスワード初期化できるのがこの秘密の質問方式なのだ。

 

なぜ秘密の質問もやめるべきか、整理したい。

 

 

  • NIST Special Publication 800-63B

 

openid-foundation-japan.github.io

 

前回同様、まずNISTガイドラインの記述を見る。

ガイドラインの概略や記法(SHALLとか)は前回記事を参照いただきたい。

 

ここに以下記述がある。

記憶シークレットを選択する際、検証主体は加入者に対して特別なタイプの情報(例えば、あなたの最初のペットの名前はなんですか?といったもの)の入力を求めないものとする(SHALL)。

 SHALLなので「厳密に従うことを要求しており、内容と異なってはならない。」だ。

もう絶対やめろと言っているのだ。(しないものとするだからSHALL NOTのような気もするが)

 

 

  •  いつから絶対やめろになった?

 

SHALL NOTになったのは今回の改訂からである。

NIST SP 800-63は初版は2006年4月に発行され、以降NIST SP 800-63-1、NIST SP 800-63-2 とバージョンアップされ今回NIST SP 800-63-3として3回目のバージョンアップがされた。

 

各バージョンの簡単な変更履歴は 2.2. 変更履歴 にある

openid-foundation-japan.github.io
この 2.2.3. SP 800-63-3 に以下記述がある。

  • Pre-registered Knowledge Token (Authenticator) は (往々にして弱い) パスワードの特別な形態であるという認識のもと, Pre-registered Knowledge Token を関する記述の削除.

 このガイドライン上では

pre-registered knowledge tokens = 事前登録された知識トークン = 秘密の質問 である。よって秘密の質問は今回から禁止となっている。

 

 

なおSP 800-63-1 の変更履歴には

従来の Token タイプに対する専門用語の変更や, Pre-registered Knowledge Token や Look-up Secret Token, Out-of-band Token 等のより多種多様な Token タイプへの言及.

 とあるので、おそらくSP 800-63-1からTokenとしてpre-registered knowledge tokensが定義されたのだろう。

しかし NIST 800‐63‐1 Overview によれば

Knowledge Based Authentication is not
recognized, due to risk of targeted research
attacks
– Pre‐registered knowledge tokens (e.g., “Name of
first pet?”) permitted at Levels 1 and 2 only

とあるため、禁止ではないもののリスクがあるとこの時既に警告はされていたようだ。

ちなみに「Level1または2での利用にとどめよ」とあるが

このLevelはAuthenticator Assurance Level(AAL)のこと・・と思われる。

AALとはざっくりいうと認証の強度のレベルで、

Level1が単一要素認証OK

Level2が2要素認証だがソフトウェアトークンを含めてOK

Level3は2要素認証かつハードウェアトークン必須

という感じだ。(かなり簡素な説明なので注意。)

 

 

  • 秘密の質問が危険である理由

 

SP 800-63Bのリファレンスの情報をちらちらとみてはみたものの秘密の質問廃止に関わるエビデンスは見つけられなかった。

 

かわりに以下の記事を見つけた。

security.googleblog.com

 2015年5月と古いが、Googleのセキュリティブログ記事である。

Googleで秘密の質問を解析し、利用すべきでないと結論づけた論文のサマリだ。

そのサマリのブログを要約すると以下。

 

調査者 Google
調査対象 Googleで数百万回のアカウント復旧の申し立てに使用されていた何百万もの秘密の質問と回答
発表 www2015(http://www.www2015.it)にて発表

 

調査結果

英語を話すユーザの「あなたの好きな食べ物は何ですか?」の答えは1回の試行で19.7%当たった。(ちなみにピザ)
アラビア語を話すユーザの「最初の先生の名前は何ですか?」の答えは10回の試行で24%当たった。
スペイン語を話すユーザの「あなたの父親のミドルネームは何ですか?」の答えは10回の試行で21%当たった。
韓国語を話すユーザの「あなたの出身都市は何ですか?」の答えは10回の試行で39%当たった。
韓国語を話すユーザの「好きな食べ物は?」の答えは10回の試行で43%当たった。
37%のユーザはあえて質問内容を無視し、共通の間違った回答を登録していた。
英語を話すユーザの40%は秘密の質問に回答できなかった。ただしそれらのユーザはSMSやe-mailによるリセットコードを75~80%返すことができた。
「あなたの図書館カード番号は何ですか?」は22%しか回答できなかった。
「あなたのマイレージ番号は何ですか?」は9%しか回答できなかった。
英語を話すユーザの「あなたの父親のミドルネームは何ですか?」は76%回答できるが、「あなたの最初の電話番号は何ですか?」は55%しか回答できない。

 

①「あなたはどの都市に生まれましたか」は79%回答できる。攻撃者が10回試行しても6.9%しか当たらない。
②「あなたの父親のミドルネームは何ですか?」は74%回答できる。攻撃者が10回試行しても14.6%しか当たらない。
③①②の両方に答えないといけないとき、攻撃者は10回試行して1%しか当たらないが、ユーザも59%しか回答できない。

 

https://1.bp.blogspot.com/-TSF7k8eyZhQ/VV5HGx89JHI/AAAAAAAAAF4/mHmH5K8vgzw/s1600/Beutler_Google_passwords-v6.png

 

と、いうことが上のカフェメニューのような資料にかかれている。

 

  • まとめ

 

上記の結果から

 ✔ ユーザが答えやすい質問では少ない試行で攻撃者に当てられてしまう可能性がある。

 ✔ ユーザが秘密の質問に回答できる確率はそもそもあまり高くなく、全ての質問に同じ回答をいれておくなど脆弱な設定にしているユーザもいる。

 ✔ ユーザが答えやすい質問を複数文答えさせる場合、ユーザが回答できる確率も下がる。

ということが言えるだろう。

 

なので、難しい質問を複数文答えさせるなどの運用だとそもそもユーザは回答できず、ユーザが回答できるレベルまで落とした運用にすると容易に推測できるリスクが高まってしまう。

なのでもうやめましょうということだろう。

 

まぁそもそも、パスワードを忘れたから秘密の質問で代替するというのもいずれもSometing you know(あなたが知っていること)であり認証的には単一要素だ。

Googleが言うようにSMSやe-mailでリセットコードを受け取る方式や、ワンタイムパスワードなどパスワードとは違う要素で認証できるのが良いのは間違いない。

 

ただ、秘密の質問方式は非常に導入が簡単なのである。

秘密の質問に代わるパスワード初期化方式はこれからじっくり考えたい。

(そもそもパスワードもなくせると・・・)

 

パスワードの定期変更について

パスワードの定期変更をやめるべき理由を整理したい。

 

 

僕は数年前にとある企業ネットワーク内の認証基盤を構築した。

その時僕が設計したIDのパスワード運用は、定期変更を促す機能が実装されている。

その時は推奨される対策だったのだ。

いまやそのIDは様々なシステムに連携され非常に重要なものになっている。

 

そして認証情報を狙うサイバー攻撃は日々変化しており、パスワードの運用も時代にあわせ見直していくことが必要なのだ。

定期変更はもうするべきではない。

 

最近たまたまステークホルダーと雑談していてその話題となり、定期変更はやめるべきと進言した。人は定期変更を促すと安易なパスワードや他と同じパスワードをつける傾向があり、辞書攻撃やリスト型攻撃には逆に脆弱になるというのが僕の理解だ。

 

しかしそのステークホルダーは説得できなかった。

僕の説明も悪かっただろう。しかし、たぶん一番この話が理解されない原因は、定期変更自体は決して悪いことではないからだ。意識高く、毎回複雑なパスワードを設定していればそれはとても良いことだ。

 

なぜ定期変更をやめるべきか。

 

  • NIST Special Publication 800-63B

openid-foundation-japan.github.io

 

去年から定期変更の議論が活発になったのはこの文書が出たからだろう。

NIST(アメリカ国立標準技術研究所)という、アメリカ合衆国商務省配下の技術部門が公開したDigital Authenticationに関するガイドラインだ。

リンクは、それを日本のOpenIDFoundationが翻訳したものだ。

 

この

5. 認証器及び検証主体の要求事項

5.1. 認証器タイプ毎の要求事項

5.1.1. 記憶シークレット

「検証主体は、認証器が侵害されている、または加入者が変更要求を行った証拠がない限りは、記憶シークレットを任意で(例えば、定期的に)変更するよう要求すべきではない(SHOULD NOT)。」

という記述が入っている。

 

この末尾にSHOULD NOTとかSHALLとかついてるのはこのガイドライン独特の記法で以下のような意味だ。

 

SHALL(するものとする)/SHALL NOT(しないものとする) 刊行物に厳密に従うことを要求しており、内容と異なってはならない。
SHOULD(すべきである)/SHOULD NOT(すべきではない) いくつかある選択肢の中で特定の推奨があることを示しており、他の選択肢については言及も除外もしない。ある行動指針を推奨するが、必須であることまでは要求しない。(否定の意味では)ある選択肢または行動指針を非推奨するが、禁止はしない。
MAY(してもよい)/NEED NOT(しなくてよい) 刊行物の範囲において、行動指針が許容できることを示す。
CAN(できる)/CANNOT(できない) 可能性や、能力があることを示す。その対象が物理的か一時的かにはかかわらない。

定期変更の要求はSHOULD NOTなので、禁止ではないが非推奨だ。

その根拠はなにか。

 

https://www.cs.unc.edu/~reiter/papers/2010/CCS.pdf

これ・・が根拠になった論文のようだがちょっとこのまま読むのはつらいので要約したブログがこれだ。

www.ftc.gov

 まとめると以下のとおり。 

 

f:id:kentarou55:20180325162808p:plain

 

確かに本気で標的にされたら、パスワードを定期的に変更しても追随してパスワードクラックができる可能性が高いのはわかった。

でも定期変更を積極的にやめる理由にはなっていない気がする。

定期変更の効果はさほどないというだけだ。

 

ただ、記事の下のほうに以下記述があった。

パスワードを変更する必要があることを知っているユーザーは、強力なパスワードを選択しないで、パスワードを書き留める可能性が高いことを示す証拠があります。研究私はカーネギーメロン大学の同僚や学生との働いていた(リンクは外部にあります)、CMUの学生、教職員、およびCMUのパスワードポリシーに煩わしさを感じたスタッフが、煩わしさを報告しなかった人よりも弱いパスワードの選択に終わったことがわかりました。私はこれに関連することができます:ログインしようとしているときに突然パスワードを変更するように求められたときに、強力なパスワードを思いつくために多くの努力を払うつもりはありません。パスワード期限切れポリシーがユーザーの行動に与える影響を実証した管理調査はまだありませんが、これらのポリシーは逆効果である可能性があります。

 

・・・実証されてないんかい!

と突っ込みつつ、、調査報告はpdfがついていた

USERS ARE NOT THE ENEMY

 

ちなみに昨年10月頃MicrosoftのOfficce365管理センターでもパスワードは無期限の設定を推奨する旨の文言がでており、その根拠としてマイクロソフト

Microsoft Password Guidance

というガイドラインをあげているのだが、エビデンスはこのブログと、上述の調査報告pdfだった。

マイクロソフトもこれを根拠にしているのではしょうがない。

 

調査報告pdfの一部を読み取った要旨が以下。

f:id:kentarou55:20180325162914p:plain

正直全然読み取れなかったので、とりあえず研究-複数のパスワード という章をまとめた。誰か要約してほしい・・!

 

 

調べてはみたものの積極的に定期変更をやめる明確な理由はよくわからなかった。

 

定期変更によりユーザは安易なパスワードをつけがちという明確な実証結果がまだないので、NISTとしても「推奨しない(SHOULD NOT)」にとどめているのだろうか。

 

冒頭のステークホルダーを説得できる気はまだしないので引き続き調査したい。

 

 

SAML脆弱性のまとめ

SAMLライブラリに脆弱性が見つかり、シングルサインオンの過程で異なるユーザになりすますことが可能なことがわかった。なかなか衝撃的だったので整理してみたい。

なお、自分の整理なのでテンポよく簡潔な言葉でまとめることを心掛ける。それゆえ正確ではないかもしれない。間違いもあるだろう。

このブログをこれから読もうという奇特な方は注意いただきたい。

 

  • まずSAMLとはなにか

f:id:kentarou55:20171217112652p:plain


以前も載せたアイデンティティ管理におけるレイヤー図だが

SAMLはこの「フェデレーション」と「SSO」の実装である。


フェデレーションとはネットワークドメインをまたいだアイデンティティの連携である。SSOはシングルサインオンで、1度誰かに認証してもらったという情報を引き回して何度もユーザがサインオン行為をしなくてよくすることだ。なんか似てるがちょっと違う。


SAMLはもともと企業のM&Aにより異なるシステム間で認証を統一するためにできたのが始まりと聞いたことがある。よって最初は企業ネットワーク内のアイデンティティ連携のための規格だったが、パブリッククラウドが台頭し、その認証連携にも活用できるため利用拡大し次第にネットワークドメインをまたいだアイデンティティ連携での利用が主流となった。


なお現在フェデレーションプロトコルの主流といえばOpenIDConnectだ。こちらはコンシューマ向けサービスでもともと利用されていたOpenIDという認証機能にOAuthの認可機能を取り入れエンタープライズで活用できるようになったものだ。


発展の経緯は違うものの機能的にはSAMLと似たような感じだ。だがOpenIDConnectは軽い。SAMLが一回のパケットに認証情報も属性情報もいろいろどっさり持ち込むのに対し、OpenIDConnectは最初のやりとりは最小限の認証情報だけ。属性情報が欲しければ再度要求するというフローになっている。トラフィックの問題でSAMLからOpenIDConnectに乗り換えた事例を聞いたことがある。


SAMLの話に戻る。SAMLのフローはこんな感じ。


https://www.secureauth.com/sites/default/files/saml_sp_in_sso_flow.pngwww.secureauth.com


IdentityProviderは例えば社内イントラ内にあるADやLDAPサーバだ。ユーザが例えばSalesForceみたいなクラウドサービス(SP)を使いたいとき、わざわざ社員情報を登録するのは面倒だし管理が一元化できない。自社FWの外に社員情報を置くことにまだ抵抗もあるかもしれない。当然社内にすでにあるADやLDAPの情報を使いたい。

 

そこで利用したいクラウドサービスがSAMLフェデレーションに対応していれば、上記のフローで実際の認証はIdPが実施し、SPは「認証OKだったよ」という情報とそのユーザの属性情報だけもらい、以降の処理をする。

 

大元はDuo SecurityのKelby Ludwigさんが報告したらしい。
duo.com


英語のサイトなのでなんとなくわかるようでわからない。
こちらの富士榮さんのブログがめちゃくちゃわかりやすい。
idmlab.eidentity.jp


簡単に言うと、SAMLの応答(上のフローでいくと⑤の時)のNameIDというメルアドとか社員番号とかのユーザIDが入ってくる項目にコメントが埋め込まれると、コメントの後ろが無視されてしまうというのが今回の問題です。


これを悪用すると

(a) user@user.com<!-- コメント -->.evil.jp というユーザIDでIdPの認証を受ける(フロー図の④)

(b) IdPからSPにNameIDにuser@user.com<!-- コメント -->.evil.jpが入ったパケットがSAMLレスポンスとしていく(フロー図の⑤)

(c) SPはuser@user.com.evil.jpで正規化~署名検証までした後でuser@user.comとしてログインしてしまう

=NameIDを詐称し他人で入れてしまうということです。


つまりSAMLのSP側の実装の不具合ということになります。

SAML自体のプロトコルに問題があるわけではないです。

 

  • 影響があったサービス


SAMLを使っていると全部影響があるということではなく、上記不具合が包含されたライブラリを使ってSAML SPを実装しているサービスに影響があります。

 

ここが情報豊富だった
www.kb.cert.org


以下のライブラリに不具合のある実装が包含されているようです。

 

ライブラリ   脆弱性番号 GitHub/製品ページ
OneLogin python-saml CVE-2017-11427 https://github.com/onelogin/python-saml
 〃 ruby​​-saml CVE-2017-11428 https://github.com/onelogin/ruby-saml
Clever saml2-js CVE-2017-11429 https://github.com/Clever/saml2
OmniAuth SAML CVE-2017-11430 https://github.com/omniauth/omniauth-saml
Shibboleth

openSAML C ++

CVE-2018-0489 https://shibboleth.net/downloads/c++-opensaml/2.6.1/
Duo Network Gateway   CVE-2018-7340 ?

 

 

SAML製品またはベンダで影響なしと確認できているものは以下。

AssureBridge 影響なし
Box 影響なし
CA Technologies 影響なし
Cisco 影響なし
ComponentSpace Pty Ltd 影響なし
Entr'ouvert 影響なし
ForgeRock 影響なし
GitHub 影響なし
Google 影響なし
Microsoft(AAD、ADFS) 影響なし
Okta Inc. 影響なし
Ping Identity 影響なし
Pivotal Software,Inc. 影響なし
VMware 影響なし
OpenAM 影響なし

 

https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=475445&SearchOrder=4


SAMLライブラリ の脆弱性(JVNVU#98536678)について [AM20180306-1] - Open Source Solution Technology Corporation

 

  • 所感

思ったより簡単な操作でできてしまうんだな、、と恐怖を感じました。

対象製品を利用している方は対策済みバージョンへアップデートをちゃんとしたほうがいいですね。

ちなみに本当に成功するのか試してみたい気持ちに少しだけなりましたが実際のサービスで意図的に詐称するとおそらく不正アクセス禁止法違反の「他人の識別符号(パスワード、生体認証)他を使ってアクセス制限を突破してはならない。」に該当しますよね(-_-;)

 

更新履歴:

2018/3/9  新規作成

2018/3/9 表がスマホでは見えなかったため、違う作り方にしました 

 

 

 

仮想通貨取引所の取締役が誘拐された件

このニュースが気になった

www.hackread.com

 

jp.cointelegraph.com

 

 

仮想通貨取引所EXMOは法人登録はイギリスだが、ウクライナを拠点とする取引所。

取り扱う仮想通貨は以下

Bitcoin
Litecoin
Dogecoin
Dash
Ethereum
Waves
Zcash
Tether
Monero
Ripple
KickCoin
Ethereum Classic
Bitcoin Cash

 

Wavesやkickcoinを取り扱うのが特徴らしい

 

その取締役であるパベル・レナーさんが12/27にキエフの勤務先を出たところで誘拐され、少なくとも12/30には身代金を支払って解放されている

支払ったのは、ビットコインで1億1000万円相当だ

 

ウクライナの情勢はよくわからないが仮に日本でこんな事件がおきたら大変なことだ

しかも身代金の入手に成功しているので、同じような事件が続くかもしれない

 

誘拐事件というと、身代金は足のつかない現金の受け渡し、それを引き渡すタイミングが犯人確保のチャンスというのが映画やドラマではお約束だが

 

ビットコインは足がつかないので

ランサムウェアやランサム(D)DoSなどのサイバー犯罪の支払いに使われるだけでなく

リアルの犯罪にもとうとう使われるのかと思うと恐ろしくなる

 

でも完全匿名なサイバー犯罪とは違い、誘拐なのだからなにかしら痕跡はあるだろう、、

犯人逮捕を願っています

 

あとひとつ解せないのが

 誘拐の翌日にEXMOは(D)DoS攻撃を受け、サイトダウンに至っている

 

犯人が身代金支払いを促すためのさらなる脅しとして(D)DoS攻撃も併用したのだろうか

それとも全く別の攻撃なのか

 

 なんにせよ真相が解明されるのを願います

 

ブロックチェーン技術で個人情報を管理するとはどういうことか

この記事が気になったので調べてみた。

 

www.nikkei.com

 

そもそもブロックチェーンとは、

分散型台帳技術で、要は分散ネットワーク型のデータベースである。

ブロックチェーン英語Blockchain)とは、分散型台帳技術[1]、または、分散型ネットワークである[2]ブロックチェインとも[3][4]ビットコインの中核技術(Satoshi Nakamotoが開発)を原型とするデータベースである。ブロックと呼ばれる順序付けられたレコードの連続的に増加するリストを持つ。各ブロックには、タイムスタンプと前のブロックへのリンクが含まれている。理論上、一度記録すると、ブロック内のデータを遡及的に変更することはできない。ブロックチェーンデータベースは、Peer to Peerネットワークと分散型タイムスタンプサーバーの使用により、自律的に管理される。フィンテックに応用されるケースでは独占資金洗浄の危険が指摘されることもある。

ブロックチェーン - Wikipedia

 

ちなみに開発者とされるSatoshi Nakamotoは正体を明かしていない。

少し前にSBIホールディングス代表取締役である北尾氏が

サトシ・ナカモト氏と議論を行ったとし少しざわっとしたが

apptimes.net

今見たらなんか全然違う内容に訂正されていた。大丈夫か。

【訂正内容】

「これの対策として北尾氏はビットコインの考案者であるサトシ・ナカモト氏と議論を行っている。」→「ウォレットのセキュリティ対策が弱すぎるとし、北尾氏は以下のように話した。」。北尾氏の発言をYouTubeから引用し追記。訂正日10月29日

 

 

ブロックチェーンの技術的な解説はとても僕では無理なので

ひとまずこのあたりでざっと概要をつかんでいただいて

www.slideshare.net

 

ブロックチェーンのメリットは

  • 分散管理なので各所で同じデータを共有できる、しかも低コスト(peer to peer)
  • 改ざんに強い(proof of work)
  • そのユーザが記録したことを証明できる

 

 

 

ビットコインなどの仮想通貨はこの特性を生かして、

国に依存しない(非中央集権的)な通貨を発行し運用してるわけです

 

で、この技術を使って個人情報を管理するとどういうメリットがあるのか?

以下は最初のニュース記事からの抜粋

 

月間17万件に及ぶ家賃の決済履歴と物件の情報を、ブロックチェーンの仕組みを使って金融機関と共有する。

 金融機関は融資条件を決める際の与信情報として、家賃の決済履歴を支払い余力の算定などに使えるようになる。これまでは借り手の給与明細や銀行口座を確認するなどの手間がかかっていた。

機微で大量の更新情報を低コストで管理でき、

分散ネットワーク内で共有ができるから ということか

 

個人情報などのデータは通常、一つのサーバーやクラウドで管理するが、情報が書き換えられるなどの危険性がある。一方、ブロックチェーンは複数のパソコンがデータを管理し、相互に監視しながら正しい記録を蓄積していくため、情報が改ざんされにくい。

 

確かに一か所で管理するより改ざんされにくいのはわかる

 

こんな記事をみつけた

https://infcurion.jp/wp-content/uploads/2016/04/cc92fdea1e37958c5dbb304366e8602f.png

infcurion.jp

 

今の時点では真ん中の活用までだが

将来的には一番右のスマートコントラクトにも展開していけるかも、、

 

という意思があるかどうかわかりませんが

 

ひとまず今後もウォッチしたいです。

 

FIDOアライアンスに行ってきた

12/8(金)に虎ノ門ヒルズで開催されたFIDOアライアンスに行ってきたので

心に残ったことをメモ

 

会場の様子

セッションによっては立ち見もいた模様

セキュリティの一分野であるID管理、かつ「認証」だけに特化したFIDOの話、正直そんなに人いないんじゃないかと思ってたけど

意外と(失礼)注目されていて会場内も熱気を感じました

 

ちなみに僕はこういうのセミナー、早めに会場入りして前のほうでかつ一番はじっこを

キープする派です。この写真には残念ながら映ってないけど(-_-;)

そして隣に自分が一方的にTwitterフォローしているID界の有名人が座るという・・

ちょっとドキドキしてました(笑

 

そもそもFIDOとは

アイデンティティ管理のレイヤーはこんな感じに分類されるのですが

f:id:kentarou55:20171217112652p:plain

この「認証」のレイヤーだけに特化したプロトコルがFIDOです。

OAuthやOpenIDConnectはSSOやフェデレーションのレイヤです。

流れはこの、LINE関水さんの説明がとてもわかりやすかった

f:id:kentarou55:20171217111103j:plain

FIDOのキモは、ユーザの「認証」はローカルで行うので、ユーザの識別情報がネットワーク上に流れないということです。

そして、「認証」の方式は特に定めていないことです。

FIDOというと生体認証のイメージがありますが、生体だけに限定するものではないです。

f:id:kentarou55:20171217123010p:plain

FIDO認証と公開鍵暗号

ヤフー株式会社 Yahoo!Japan研究所 上席研究員 五味秀仁 さんの公開資料より

http://www.jnsa.org/seminar/pki-day/2017/data/170419_gomi.pdf

 生体認証自体は昔からあるものだけど、ベンダー独自仕様だったりして相互運用性がなかった。そこを解決するのがFIDOで、FIDO標準メッセージに対応していれば、FIDO認証器として動作でき、認証を部品として切り離すことができる。

 

そしてそのFIDO認証器の認定プログラムがこれからできるそうです。

逆にいままではどういう基準で認定されてたのがよくわかりませんでしたが・・

 

FIDOに対応している認証器だと

Windows10のWindowsHelloが有名だと思うんですが

FIDOアライアンスJAPAN座長森山さんがいらっしゃるNTTドコモが着々と対応機種を増やしていたり

今年ソフトバンクがFIDOアライアンスに加入したそうで

今後スマホのコンシューマ向けアプリでFIDOの活用が進んでいきそうですね。

 

そして、FIDOが今注目されている背景に

銀行のオープンAPI化があるというお話がありました。

欧州ではこんな3つの規制があって

ざっくりいうとFintech進めるにあたり各銀行は強固なユーザ認証やプライバシーに配慮したAPIを公開する義務が発生します、と(理解間違ってたらすいません(-_-;)

で、認証する際に単にリダイレクトするだけではユーザは

たくさんトークンもつことになってしまうので

 認証の標準化がいるよね→FIDOが理想的だよね ということのよう

 

そして、日本のOpenIDファウンデーションにて

金融APIの標準仕様を検討しているWG(FAPI WG)があり

データはJSONAPIはREST

セキュリティはOAuth、OpenIDConnect を使っていきましょう、

その全体フレームワーク(OAuthプロファイル)の中で、認証部分はFIDOが最適

ですね、ということです。 

 この絵の中で、青い色の部分「Login(UserAuthentication)」とある部分がFIDOで実装する部分です。

 

ということで、とても内容の濃いセミナーでした。

来年も行かせてもらえるといいなー('ω')

 

このブログについて

ケンタロウです。

 

インフラエンジニアをずっとやってます。

日々セミナーに行ったり本を読んだり

情報収集は絶やさないよう心掛けているのですが

アウトプットしてないなと思い、このブログを立ち上げてみました。

 

基本的に自分が学んだことのメモなので

人様から見て有益なものにはならないと思います。

 

本当は技術情報を見やすくかっこよく整理したいですが

そういうことを考えていると全然記事が書けないので

 

まずは気軽に、ジャンルもあまりこだわらず、書き残していきたいと思います。

セキュリティ、アイデンティティ関係の話が多いと思います。

 

よろしくお願いします。