公開情報から読むCloud-assisted BLE(caBLE)をつかったWebAuthn

https://lepidum.co.jp/
Copyright © Lepidum Co. Ltd. All rights reserved.
公開情報から読む
Cloud-assisted BLE(caBLE)
をつかったWebAuthn
株式会社レピダム
名古屋謙彦
(@ayokura)

View Slide

自己紹介
◼
株式会社レピダムで技術者をしています。
◼
コード書いたり、社内システム管理をしています
◼
サーバーやネットワークのおせわをするのは癒し
◼
クリスチャンです
◼
@ayokura でtwitterなどやっています
◼
ID関係は、学生時代からの趣味です
今は仕事にも役立っています
◼
簡単に、安全である世の中が来てほしいです
2

View Slide

目的とおことわり
◼
２０１９年4月にGoogleから”Phone as Security key”が発表されて、
それ以降とても興味をもって追いかけてきたので、その内容を共有したい
◼
CTAP２/WebAuthnのcloud-assisted BLE(caBLE) transportの
話についてとりあげたい
◼
上記をGoogleアカウント以外に対しても使えるようにしたもの。
◼
現在CTAP2の仕様に入れるための作業中（と思われる）
◼
CTAP2の仕様策定はFIDOアライアンス内で行われており、Publicではないため想像
◼
WebAuthn側のチケットなどで少しだけ情報がうかがえる
◼
公開されている場所のどこにどのような情報があるのかを紹介したい。
◼
注意点
◼
発表者はFIDOの非公開情報にアクセスすることができません
◼
本発表は公開情報から想像した内容なので、誤りが含まれえます。
◼
発表内容と、最終的に標準化される内容が異なる可能性が充分あります。
3

View Slide

現状のPhone as Security key
◼
Googleアカウントでの”Phone as Security key”利用について
◼
Authenticatorとしては以下の環境に対応
◼
Android 7.0 以上のデバイス
◼
最新のSmart LockアプリがインストールされたiOSデバイス
◼
事前に当該Androidを利用するアカウントに紐づけ、セキュリティキーとして利用可能にしておく
こと
◼
Clientとしては以下を搭載した環境に対応
◼
パソコンの場合
◼
Bluetooth
◼
Google Chromeなど、互換性のあるブラウザの最新バージョン
◼
Chrome OS、macOS、Windows など、互換性のあるオペレーティングシステムの最新バージョン
◼
iOSデバイスの場合
◼
最新のSmart Lockアプリがインストールされている
◼
Google Chromeなど、互換性のあるブラウザの最新バージョン
◼
登録は、スマートフォン上で、Googleアカウントに対してセキュリティキーとしてス
マートフォンを登録することで実施。
◼
利用時はログインしているGoogleアカウントと紐づいたAuthenticatorに通知を
送る
◼
その後デバイス上でログインを許可することでBLE経由でClientと接続する
4

View Slide

Phone as Security keyの動作イメージ
5
◼
https://www.blog.google/technology/safety-security/your-
android-phone-is-a-security-key/ のブログ上にある画像を開く
◼
https://storage.googleapis.com/gweb-uniblog-publish-
prod/original_images/Using_the_built-
in_security_key_in_a_Pixel_3_to_log_into_your_Google_Accou.gif

View Slide

FIDO（Fast IDentity Online）
6
◼
パスワード問題への解決策である、シンプルで堅牢な認証
◼
公開鍵暗号方式による認証
◼
オンラインサービスへの登録時に鍵ペアを生成して登録
Authenticator
gesture
User Verification（検証）
privatekey
signature
FIDO Authentication
（FIDO認証）
challenge
publickey
client RP
ID
User
RPが署名を検証することによって認証している

View Slide

用語説明
◼
RP（Relying Party）
◼
ユーザの登録、認証を行うWebサイト、または事業者
◼
Authenticator（認証器）
◼
ユーザーに関するクレデンシャル (認証情報)
◼
クレデンシャルは指紋情報や生体情報・秘密鍵を指す
◼
内部認証器（組み込みの認証器）の場合（Windows HelloやAndroidなど）
◼
指紋
◼
虹彩
◼
顔
◼
外部認証器（移動可能な認証器）の場合
◼
セキュリティキーのドングル（USB/NFC/BLEなどで接続）
◼
スマートフォン
7

View Slide

クレデンシャル（認証情報）の通信経路
10
リモート認証（パスワードでの認証）
client RP
User Authenticator
FIDO認証モデル
ローカル認証リモート認証（署名）
client RP
User
ユーザーが入力したID (IDentifier、識別子) とパスワードは、
ネットワーク上を流れ、サーバーに送付
リモート認証モデルにおける認証の機能(識別と検証)が分離されて
検証機能がユーザーの保有するデバイス側に存在

View Slide

クレデンシャル情報（認証情報）の安全性
◼
RPごとに鍵ペアを作成して異なる公開鍵を登録
◼
ユーザ・認証器・RP間にトラスト（信頼）を構築することにより、リスト型
攻撃・フィッシングに対する耐性を実現
11
User
Authenticator
privatekey1
（クレデンシャル1）
Privatekey2
（クレデンシャル2）
RP1
RP2
publickey1
publickey2
ID
ID

View Slide

FIDO2
◼
FIDO２はWebAuthnとCTAP2の二つの仕様を合わせたもの
◼
W3C Web Authentication（WebAuthn）
◼
user agent（ブラウザ）に実装されたFIDO2のClient機能を呼び出す
JavaScript API
◼
FIDOアライアンスで素案を作ったものをW3Cで標準化した
◼
CTAP2（Client to Authenticator Protocol の version 2）
◼
クライアント（user agentやアプリ）と外部認証器の間の通信プロトコル
◼
FIDOアライアンスが仕様策定
12

View Slide

Web Authentication
◼
ブラウザがJavascriptを用いてクレデンシャルにアクセスするAPI
◼
登録と認証の２つの基本的な機能がある
◼
登録：navigator.credentials.create()
◼
認証器で鍵を生成・登録するAPIを使用して処理を行う
◼
新しいアカウント、または既存のアカウントへ新しい非対称鍵ペアの関連付ける認証情報を作成
する
◼
認証：navigator.credentials.get()
◼
登録済みの鍵を使って認証用の署名を生成するAPIを使用して処理を行う
13

View Slide

CTAP2
◼
クライアントと外部認証器との間の通信プロトコル
◼
USB・NFC・Bluetoothのtransport（伝送経路）が定義されている。
14
参考：https://fidoalliance.org/fido2/ に一部加筆
赤丸部分がCTAP
青枠部分がWeb Authentication API

View Slide

ログインイメージ（1/2）
15
WebAuthn でセキュリティキーの
使用を確認する画面が出てくる
利用するtransportを選択する
登録に必要な情報の入力

View Slide

ログインイメージ（2/2）
16
最後にRP側で署名を検証
参考：https://www.soudegesu.com/post/javascript/web-authentication-api/
端末についている
指紋センサーに指を当てる

View Slide

WebAuthnで使う認証器について
◼
WebAuthnを大雑把にいうと
◼
認証器（Authenticator）の結果を使って認証をする
◼
認証器（Authenticator）
◼
登録された認証器と同一であることを電子署名で証明できる（所有物認証）。
◼
「所有物認証+α」が可能。
◼
＋αの部分の最低限としては、人間が存在しているかを確認することが必須
◼
＋αは他にたとえば、正しい人間が捜査しているかの検証がある
◼
PINやパターンで本人かを検証する（所有物認証＋知識認証）
◼
指紋認証などの生体認証を行う（所有物認証+生体認証）
◼
認証器の結果を信頼するので、認証器側に問題があった場合は影響を受
ける
◼
電子署名に使う秘密鍵を複製された場合は、完全ななりすましが可能
◼
認証器がだめな実装をすれば、認証器が本来保証するべきものが保証されない
◼
⇒現状のFIDOでは認証器の秘密鍵を取り出せないことが認定時に保証
されている認識
17

View Slide

再掲：用語説明
◼
RP（Relying Party）
◼
ユーザの登録、認証を行うWebサイト、または事業者
◼
Authenticator（認証器）
◼
ユーザーに関するクレデンシャル (認証情報)
◼
クレデンシャルは指紋情報や生体情報・秘密鍵を指す
◼
内部認証器（組み込みの認証器）の場合（Windows HelloやAndroidなど）
◼
指紋
◼
虹彩
◼
顔
◼
外部認証器（移動可能な認証器）の場合
◼
セキュリティキーのドングル（USB/NFC/BLEなどで接続）
◼
スマートフォン
18

View Slide

WebAuthnでは
◼
スペック上では、外部認証器と内部認証器を以下のように併用する姿が
紹介されている
◼
初回やリカバリとしては外部認証器を利用
◼
外部認証器を用いたログイン後に、そのデバイスの内部認証器を登録して二度目
以降は内部認証器を利用。
19

View Slide

◼
caBLE
◼
Googleが提案中のCTAP2/WebAuthnの新しいtransport。
◼
cloud-assisted BLE
◼
従来のBLEがペアリング必須だったものをペアリングレスにし、モバイルデバイスを
外部認証器としてもちいる。
◼
phone as security keyの一般化と思われる。
◼
特にphone as security keyで問題にならなかった、Authenticatorをどうやって探すか
（discovery）についてがきっちり考えられている
◼
いまあるスマートフォンを外部認証器として使うことができるようになれば、
外部認証器と内部認証器の組み合わせがより多くの人にできる！！
◼
以下のような欠点もあると感じているので、そこがどのように解決されるか
は今後を注視していきたい
◼
スマートフォンは（YubiKeyのような）ドングルよりは壊れやすい
◼
スマートフォンは寿命がドングルより短く端末移行が発生しうる
◼
端末移行時は、現状だと全サイトに対して新しいセキュリティキーを再登録しないといけない
20
caBLEについて

View Slide

caBLEの情報源
◼
現状、CTAPの仕様策定はPublicではないDesign Phaseなので、情報
は他の場所から得る必要がある。
◼
WebAuthnのGitHubライブラリにpull reqがきている
◼
https://github.com/w3c/webauthn/pull/909
◼
差分プレビュー https://pr-
preview.s3.amazonaws.com/w3c/webauthn/909/5d11e62...kpaulh:63be77d.ht
ml#sctn-cable-registration-extension
◼
RP側実装はGitHubのgoogle/webauthndemoにある
◼
https://github.com/google/webauthndemo/commit/8c588e670f31807b6bd06
9b8cf71798baa9a673b
◼
ブラウザ側実装は、 Chromeのソースコードにある
◼
https://chromium.googlesource.com/chromium/src/+/lkgr/device/fido/cable
◼
Flagsで有効化可能
chrome://flags/#enable-web-authentication-cable-v2-support
◼
認証器側実装は発見できなかった
21

View Slide

現状集められる情報
caBLE v1 ? caBLE v2 ?
CTAP仕様 ×（非公開） ×（非公開）
WebAuthn仕様〇（Pull Req） ×
Authenticator実装 ×（実装発見できず） ×（実装発見できず）
RP実装〇（GitHub上の
google/webauthndemo）
×？
ブラウザ実装〇（Chromium）〇（Chromium）
22

View Slide

参考：当初やりたかったこと
◼
AndroidとChromeで、Googleアカウントでは、Android phone‘s
built-in security keyが利用できる
◼
これは、FIDO2のcloud-assisted Bluetooth Low Energy (caBLE)
transportとしてGoogleが提案中、の模様。
◼
提案先は少なくともCTAPには入る。おそらくWebAuthnにも入る
◼
2020年1月現在でのこの状況をまとめたい。
◼
このころにはpublicになっているのでは？
◼
caBLE自体の仕組みと必要性
◼
実装が可能な状態であればデモサイトでの実装を行う
◼
実装が無理であればChromiumの実装や、
github.com/google/webauthndemo上にあるサーバー実装について説明する。
◼
見つけられたらAndroid側の実装も調査したい。（ただGoogle側のみが持つク
ローズドな部分の可能性あり）
◼
わかっている範囲及び推測をこめて、今後の展望など
23

View Slide

いろいろ想像
◼
ブラウザ実装より推測
◼
Authenticatorを探すDiscoveryという操作が肝心と思われる。
◼
Discoveryして、通信経路を確保して、そのうえでmakeCredentialやgetAssertionする。
◼
Discoveryの方法はv1とv2があり、それぞれhandshake時に用いるパラメータや
方式が異なる。
◼
v1は client_eid, authenticator_eid, session_pre_keyのパラメーターを用いる。
◼
ClientがBLEでclient_eidをadvertiseして、その情報をもとにAuthenticatorがhandshakeを行
うように見受けられる。
◼
https://chromium.googlesource.com/chromium/src/+/lkgr/device/fido/cable/fid
o_cable_discovery.cc#39
◼
v2は eidとPSKと、peer_identityまたはpeer_nameを用いる
◼
eidとPSKはQRコードからハッシュ関数（HKDF）を用いて生成する。
◼
WebAuthnのドラフトとRP実装より推測
◼
これらは現在v1の方式しか対応していなさそう？
◼
caBLEに必要な追加情報はAPIに対しては拡張として渡す。
◼
Registration時はECDHを用いることで、サーバーと認証器の間で直接やり取りできるように
していそう（実際にどのようなコミュニケーションをとっているかは不明）
◼
Authentication時は、 client_eid, authenticator_eid, session_pre_keyをAPIに渡して
いる。
24

View Slide

公開情報から読む
Cloud-assisted BLE(caBLE)
をつかったWebAuthn
名古屋謙彦
(@ayokura)

View Slide

セキュリティやネットワーク技術の研究開発を強みとし、
課題解決やビジネス実現を通じて顧客の事業成長の加速に貢献する
26
開発力
専門性 HUB力
事業ニーズ
・事業会社
・自治体
・新規ビジネス
エッジの効いた技術で顧客のビジネスを加速
技術シーズ
・企業研究所
・標準化団体
・大学
事業ニーズを次世代の技術開発へ

View Slide

公開情報から読むCloud-assisted BLE(caBLE)をつかったWebAuthn

公開情報から読むCloud-assisted BLE(caBLE)をつかったWebAuthn

Ayokura

More Decks by Ayokura

Other Decks in Technology

Featured

Transcript