技術検証報告書
2020年度新技術ワーキンググループ Dチーム

アジェンダ1. FIDOについて

3. 結果と考察

1.1 FIDOとは

3.1 検証結果報告

1.2 FIDO利用の流れ

3.1.1 検証①

1.3 FIDOの仕様

3.1.2 検証②

1.4 FIDOの登録・認証フロー

3.1.3 検証③

2. 検証について

3.2 所感・まとめ

2.1 検証の目的と概要
2.2 検証の内容
2.2.1 検証①
2.2.2 検証②
2.2.3 検証③

1．FIDOについて
1.1 FIDOとは■Fast IDentity Onlineの略称■FIDOアライアンスが推進しているパスワードレス認証を実現するための仕組み■認証情報がネットワーク上に流れない為、※FIDOアライアンスとはパスワードレス認証を用いた認証技術（FIDO）の標準化を目的として2012年に米国で発足した団体。

情報が漏洩するリスクがほとんどない→現在普及しているパスワード認証に代わる次世代の認証技術

1．FIDOについて
1.2 FIDO利用の流れ
端末：スマートフォン,PCなどのデバイス
認証器：秘密鍵・公開鍵のペアを生成し、FIDOサーバへ送信する署名を生成※FIDO規格に対応している必要がある

FIDOサーバ：ユーザーのIDを登録、認証し管理するサーバ
利用者は端末と認証器を用意

FIDOサーバに利用者情報を登録

FIDO認証の利用を開始

1．FIDOについて
1.3 FIDOの仕様①
UAF：（Universal Authentication Framework）
パスワードレスの認証方式
主にスマートフォンアプリで利用

指紋などでユーザー認証

U2F：（Universal Second Factor）「記憶認証」と「所有認証」を用いた2要素認証
FIDO未対応端末でも、認証器を購入することで利用可能

パスワードと認証器でユーザー認証

1．FIDOについて
1.3 FIDOの仕様②

FIDO2:WebAuthn（Web認証）＆CTAP
WebAuthn:パスワードレス認証をWebブラウザで使用可能にするAPI
CTAP:デバイスと認証器の通信プロトコル
認証器

ブラウザ
CTAP

FIDO2サーバ
WebAuthn

パスワードレスでWebブラウザ上の認証が可能1．FIDOについて
1.4 FIDO2仕組み－登録フロー－

利用者⓪ログイン開始

Webブラウザ①ログインID②鍵ペアの生成要求(JavaScript API経由)

FIDO2サーバ

1．FIDOについて
1.4 FIDO2仕組み－登録フロー－
Webブラウザ
利用者

認証器①ログインID②鍵ペアの生成要求③認証要求(JavaScript API経由)④生体認証⑥公開鍵のみサーバへ送信⑤秘密鍵・公開鍵生成→認証器内に保存

FIDO2サーバ

1．FIDOについて
1.4 FIDO2仕組み－登録フロー－
Webブラウザ
利用者

認証器①ログインID

FIDO2サーバ②鍵ペアの生成要求③認証要求(JavaScript API経由)④生体認証⑥公開鍵のみサーバへ送信⑤秘密鍵・公開鍵生成→認証器内に保存⑦ログインIDに公開鍵を紐づけ

1．FIDOについて
1.4 FIDO2仕組み－認証フロー－
Webブラウザ
利用者

認証器

FIDO2サーバ①ログインID②チャレンジ生成

③認証要求
④認証要求

⑤生体認証
⑦署名されたチャレンジを送信⑥認証完了後、秘密鍵でチャレンジに署名⑧署名を公開鍵で検証1．FIDOについて
1.4 FIDO2仕組み－認証フロー－
Webブラウザ
利用者

認証器

FIDO2サーバ①ログインID②チャレンジ生成

③認証要求
④認証要求

⑤生体認証
⑦署名されたチャレンジを送信⑥認証完了後、秘密鍵でチャレンジに署名

生体情報はローカル内部に留まる⑧署名を公開鍵で検証

検証について2.1 検証の目的と概要
検証目的•

FIDO2の動作に対する知見の獲得•

FIDO2を利用した認証システムの構築に対する知見の獲得

検証概要
検証①： FIDOサーバと認証するアプリを構築し、端末とサーバ間の通信を確認
検証②： オンプレにてFIDO2に対応したSSO用認証サーバを構築し、SSOを実装
検証③： FIDO2に対応したSSOのクラウドサービスでSSOを実装

検証期間
2020年10月7日 ー 2021年3月中旬

2. 検証内容
2.2.1 検証①
検証内容：
FIDOサーバとFIDO2に対応したアプリケーションを構築し、認証を実施

検証目標：
・ FIDOサーバとアプリケーションを構築すること
・ FIDO2における認証フローを確認すること
KELLAB環境

検証構成：
通信内容を確認認証器

アプリ+FIDOサーバ

2.2 検証内容
2.2.2 検証②
検証内容：
FIDO2に対応したオンプレミス型のSSOサービスを構築し、VPN装置にSSOでログイン

検証目標：
・ SSOサービスにFIDO2でログイン可能であること
・ SSOを利用してVPN接続が可能であること

検証構成：

KELLAB環境
FIDOを確認
SSOサービス

認証器

SSOを確認VPN装置

2.2 検証内容
2.2.3 検証③
検証内容：
FIDO2に対応したクラウド型SSOサービスを利用し、VPN装置にSSOでログイン

検証目標：
・ SSOサービスにFIDO2でログイン可能であること
・ SSOを利用してVPN接続が可能であること

検証構成：

認証器

SSOサービス

SSOを確認KELLAB環境

VPN装置

結果と考察3. 結果と考察
3.1.1 検証結果報告①
検証目標①：FIDO2サーバとサンプルアプリケーションを構築すること➡OK

検証目標②：FIDO2における登録/認証フローを確認すること➡OK

通信内容を確認

KELLAB環境

検証作業
・Linuxマシン上にFIDO2サーバを構築する
・Linuxマシン上にサンプルアプリケーションをインストールする・クライアント端末と認証器を使用してユーザを登録する

認証器

クライアント端末

FIDO2+アプリサーバ

・登録したユーザアカウントを使ってログインする3. 結果と考察
3.1.1 検証結果報告①●FIDO2サーバ・サンプルアプリケーションのインストールソース
GitHubにてStrongkeyが公開しているFIDO2サーバ・サンプルアプリケーションのサンプルコード及びインストール手順

https://github.com/StrongKey/fido2●検証環境(FIDO2+アプリサーバ)の条件
・サポートOS
RedHat 7, CentOS 7, Oracle 7, Ubuntu 18.04, Debian 9, Amazon Linux 2・メモリ4GB以上、ディスク空き容量10GB以上のVM
・完全修飾ドメイン名(FQDN)を持ち、名前解決できる状態

3. 結果と考察
3.1.1 検証結果報告①
本検証の検証環境●FIDO2+アプリサーバKELLAB環境

・Linux RedHat 7
・メモリ32GB、ディスク容量100GB
・FQDN：fidoap.kensho1.local

DNSサーバ●DNSサーバ（FIDO2+APサーバの名前解決用）(172.17.4.226)
有線接続・Windows Server 2016
●クライアント端末
・Windows 10
・サンプルアプリ利用ブラウザ：Google Chrome●認証器
・BioPassFIDO2 K27（Feitian Technologies社）

認証器

クライアント端末(10.11.206.1)

FIDO2+アプリサーバ(172.17.4.225)

3. 結果と考察
3.1.1 検証結果報告①
FIDO2サーバ構築手順① FIDO2サーバのFQDN名を設定$ sudo hostnamectl set-hostname fidoap.kensho1.local② rootユーザでwgetをインストール$ sudo yum install wget
③ バイナリ配布ファイルをダウンロード$ wget https://github.com/StrongKey/fido2/raw/master/fido2server-v4.3.0-dist.tgz④ スクリプトを実行し、FIDO2サーバとアプリサーバPayaraをインストール、StrongKeyユーザアカウントを自動作成$ sudo ./install-skfs.sh3. 結果と考察
3.1.1 検証結果報告①
FIDO2サーバ構築手順⑤ FIDO2サーバの動作確認。以下のようにWADLファイルが表示されれば動作に問題なし。
$ curl –k https://localhost:8181/skfs/rest/application.wadl

3. 結果と考察
3.1.1 検証結果報告①
サンプルアプリケーション(Java)構築手順① StrongKeyユーザでログイン後、アプリケーションの構成ファイルを作成し、FIDO2サーバの場所を記載$ echo “ webauthntutorial.cfg.property.apiuri = https://fidoap.kensho1.local:8181 " >/usr/local/strongkey/webauthntutorial/etc /webauthntutorial-configuration.properties② Webアプリケーションファイル「basicserver.war」をダウンロード$ wget https://github.com/StrongKey/fido2/raw/master/sampleapps/java/basic /basicserver.war③ ②をpayaraに追加$ payara41 / glassfish / bin / asadmin deploy basicserver.war

3. 結果と考察
3.1.1 検証結果報告①
登録フローの確認
https://fidoap.kensho1.local:8181/basicserver/①任意のユーザ名を入力②任意の鍵名を入力③Register New Keyを押下④新しいユーザ・鍵登録要求を受信

クライアント端末(10.11.206.1)

FIDO2サーバ(172.17.4.225)

3. 結果と考察
3.1.1 検証結果報告①
登録フローの確認
https://fidoap.kensho1.local:8181/basicserver/⑤秘密鍵と公開鍵の生成（鍵の認証）要求をクライアント端末へ向けて送信⑦認証を実施⑥要求受信後、認証器を使用して鍵を登録するポップアップウインドウが表示される認証器⑧秘密鍵と公開鍵を生成し公開鍵のみFIDO2サーバへ送信
クライアント端末(10.11.206.1)

FIDO2サーバ(172.17.4.225)

3. 結果と考察
3.1.1 検証結果報告①
登録フローの確認
https://fidoap.kensho1.local:8181/basicserver/⑧秘密鍵と公開鍵を生成し公開鍵のみFIDO2サーバへ送信

ログイン完了画面を配信➈公開鍵を受信し登録完了、同時にログインも完了となる

ユーザ名が表示される
登録したユーザ・認証器の情報を見ることもできる

認証器

クライアント端末(10.11.206.1)

FIDO2サーバ(172.17.4.225)

3. 結果と考察
3.1.1 検証結果報告①
認証フローの確認
https://fidoap.kensho1.local:8181/basicserver/①ログインするユーザ名を入力②Sign Inを押下③ログイン要求を受信

クライアント端末(10.11.206.1)

FIDO2サーバ(172.17.4.225)

3. 結果と考察
3.1.1 検証結果報告①
認証フローの確認
https://fidoap.kensho1.local:8181/basicserver/④ユーザの認証のためのチャレンジを送信⑥認証を実施⑤受信後、認証器を使用してユーザを認証するポップアップウインドウが表示される認証器⑦秘密鍵から生成した署名を記載したチャレンジをFIDO2サーバへ送信
クライアント端末(10.11.206.1)

FIDO2サーバ(172.17.4.225)

3. 結果と考察
3.1.1 検証結果報告①
認証フローの確認
https://fidoap.kensho1.local:8181/basicserver/⑦秘密鍵から生成した署名を記載したチャレンジをFIDO2サーバへ送信
ログイン完了画面を配信⑧既に登録してある公開鍵でチャレンジを検証し、合致すればログイン完了となる

ユーザ名が表示される
登録したユーザ・認証器の情報を見ることもできる

認証器クライアント端末(10.11.206.1)

FIDO2サーバ(172.17.4.225)

3. 結果と考察
3.1.1 検証結果報告①
FIDO2サーバでの登録ログ

ユーザ情報登録された公開鍵(チャレンジ)の情報

ユーザのパスワードや生体情報はFIDO2サーバに存在しない

3. 結果と考察
3.1.1 検証結果報告①
躓きポイント・注意事項
 秘密鍵と公開鍵の再生成
keymanagerのjarファイルにバグがあり新しいユーザーの登録が正しく行えなかったため、鍵を再生成した。
 地域の変更
Webアプリケーションとサーバー間で通信リクエストの構成が異なっており、新しいユーザーの登録が正しく行えなかった。構成を揃えるため、地域設定を日本から米国に変更した。
 FQDNの設定
ドメインの名前解決ができずWebアプリケーションにアクセスできなかったため、DNSサーバを追加で構築し名前解決を実現した。

3. 結果と考察
3.1.2 検証結果報告②
検証目標①：SSOサービスにFIDO2でログイン可能であること

KELLAB環境➡OK

検証作業
・ FIDO2に対応したオンプレミス型SSOサービスである
Open AMを構築する

FIDOを確認
SSOサービス

検証完了条件
・認証器を利用してOpen AMにログインができること
認証器

3. 結果と考察
3.1.2 検証結果報告②
OpenAMインストール手順：① 必要ファイルをインストールする(JDK8以降、tomcat7以降、SSL証明書とApache-HTTP)$ yum –y install tomcat mod_ssl② Open AMコンソーシアムのgithubに公開されてる、OpenAM14のwarファイルをダウンロードする※FIDO2はOpen AM 14.0.0以上のバージョンにしか対応していないので注意する③ FQDN、ホスト名を登録する (fidotest.kensho4.local に設定)
＄ vi /etc /hosts＄ vi /etc /hostname

3. 結果と考察
3.1.2 検証結果報告②
WebAuthn認証設定方法：① Open AMの管理ページに「amadmin」でログインする。（http://fidotest.kensho4.local:8080/openam/）② WebAuthn AuthenticatorサービスをOpen AMに追加する。

3. 結果と考察
3.1.2 検証結果報告②
パスワードレス認証連鎖の設定：
認証連鎖：認証モジュールを組み合わせて、それぞれの認証結果をもとに、次の認証モジュールの要不要を判定する機能➡ 複数の認証モジュールを組み合わせることで、よりセキュアな認証を可能にする「多要素認証」機能を実装可能

WebAuthn(認証)
ID/PW認証

ログイン成功失敗：認証失敗：認証・ログイン成功

WebAuthn(登録)ログイン成功失敗

3. 結果と考察
3.1.2 検証結果報告②
検証目標②： SSOを利用してVPN接続が可能であること

KELLAB環境
FIDOを確認

検証作業
・ OpenAM側とVPN装置側でSSOの設定を行う

SSOサービス
認証器➡NG

検証完了条件・ SSOを利用してVPN接続ができること

SSOを確認VPN装置

3. 結果と考察
3.1.2 検証結果報告②
SAML：異なるドメイン間でユーザー認証を行うための認証情報の規格
IdP

SP

ユーザー（認証情報を提供する側）（認証情報を利用する側）①アクセス

SSO装置（OpenAM）③SAML認証を解析

VPN装置②SAML認証要求を作成しIdPにリダイレクト④ユーザー認証後応答を作成⑤認証応答とともにSPへリダイレクト⑥応答を検証してログイン許可3. 結果と考察
3.1.2 検証結果報告②
検証②のユーザーからVPN装置への認証フロー
IdP
ユーザーSP（認証情報を提供する側）（認証情報を利用する側）
①アクセス
VPN装置

SSO装置（OpenAM）②SAML認証要求を作成しIdPにリダイレクト③SAML認証を解析④ユーザー認証後応答を作成⑤認証応答とともにSPへリダイレクト
エラー発生

エラー発生
⑥応答を検証してログイン許可3. 結果と考察
3.1.2 検証結果報告②
OpenAMにおけるログ
access.csv：すべてのアクセスに対して、誰が、いつ、何をしたのかを出力するファイル

3. 結果と考察
3.1.2 検証結果報告②
エラー対処➡ 「秘密鍵がない」というエラーが発生しているため、証明書が原因であると推測
OpenAMの設定画面VPN装置（SP）の証明書エイリアスが空白となっており何も登録されていない

3. 結果と考察
3.1.2 検証結果報告②
考えられる対策
KELLAB環境

OpenAM(SAML IdP)

OpenAMにVPN装置の証明書を登録出来れば、解決する可能性がある

認証器

VPN装置
(SAML SP)

3. 結果と考察
3.1.3 検証結果報告③
検証目標： SSOを利用してVPN接続が可能であること

KELLAB環境
SSOサービス➡NG

検証作業
・ クラウド型SSOサービスであるSoliton社OneGate側とVPN装置側でSSOの設定を行う

検証完了条件認証器

SSOを確認VPN装置

・ SSOを利用してVPN接続が利用可能であること

3. 結果と考察
3.1.3 検証結果報告③
 SAML連携を利用したオンプレミスのサービスへのSSOは未対応※ロードマップとしては将来的に実装予定→ VPN装置との連携は現時点では不可能
 OneGateにおけるSSO(SAML)対応サービス一覧
・O365 ・G Suite ・box ・cybouzu.com ・Salesforce
・AgileWorks ・Akamai ・ASANA ・AWS ・SAP ・Slack・Cisco Webex ・X-point etc.

3. 結果と考察
3.2 所感・まとめ アプリケーションやSSOサービスへのFIDO2導入が実現すれば、ユーザの利便性向上とセキュリティ強化が同時に見込める FIDO2はセキュリティが厳重且つ認証が簡単であるが、最先端の技術であるため情報が少ない→今後も継続的な検証を行う価値あり エラーの未解決など検証に不十分な点があったため、引き続きFIDO2に関する調査・検証を行い、KELの事業領域拡大の一助となる可能性を模索する
 FIDO2に対応しているクラウド型SSOサービスにおいて、SSO連携が可能なサービスには制限があるため、選定には注意が必要である

ご清聴誠にありがとうございました