滅びてほしい認証系の実装の話

こんにちは、富士榮です。

ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。

考えていると結局のところ、サービス提供側が意図していることとは全然違うことが起きている気がするので、この辺はしっかり考えて実装したいところですね。（実装ミスは問題外として）

カテゴリ	滅びてほしいもの	実装側がやりたいこと	利用者が感じること	実際に起きていること	代替手法
認証	CAPTCHA	bot避け	ぐにゃぐにゃ文字が読めない バイクと自転車の違いとは？	ユーザの離脱、カゴ落ち	パスキーの利用 新しいタイプのCAPTCHA（通常は画面に出ない） リスクベース認証との組み合わせによる抑制
認証	パスワード	誰でも使える認証手段の用意	忘れる。複雑なパスワードをそれぞれのサービス毎に管理するのは無理	パスワードの使い回し。パスワード漏洩が他サービスへ迷惑をかける（逆もしかり）	パスキーの利用
認証	パスワードマネージャが対応できないパスワードポリシー、input type要素の設定ミス。コピペができない、自分の設定したパスワードの確認ができない	何も考えていない（単なる考慮不足）	パスワードマネージャが使えないので自分でパスワード入力が必要で面倒くさい	簡単なパスワードの指定	パスワードマネージャを考慮した実装
認証	（届かない）OTP	認証強化（所持認証）	SMS受信できないSIMなんだけど なかなか届かない。すぐにログインしたいのに。	ユーザの離脱、カゴ落ち	パスキーの利用
認証	（音声通知のみの）OTP	認証強化（所持認証）	データSIMやiPadじゃ使えない 面倒臭い	ユーザの離脱、カゴ落ち	パスキーの利用
認証	input typeがpasswordになっているOTP（毎回記憶を促される）	何も考えていない（単なる考慮不足）	面倒臭い	パスワードマネージャが毎回更新の確認をしてくる	適切な実装
認証	キャリア回線認証	認証強化（所持認証）	wifi切り替えが面倒（別デバイスで使えない）	ユーザの離脱、カゴ落ち	パスキーの利用
認証	ソフトウェアキーボード	キーロガー対策	面倒臭い	ユーザの離脱、カゴ落ち	パスキーなど知識認証を使わせない仕組み （そもそもキー入力不要にする）
認証	定期的なパスワード更新	パスワードが漏洩していても安心	面倒。仕方ないので簡単なパスワードの末尾を1,2,3とインクリメントして使い回そう	簡単なパスワードの指定	複雑なパスワード要件の定義によるパスワードマネージャ利用の促進と併せて定期変更の無効化 パスキーの利用
認証	乱数表	認証強化（所持認証）	どこいった？	ユーザの離脱、カゴ落ち	ソフトウェア認証器、パスキーの利用
認証	第２パスワード	認証強化（多段階）	忘れる。意味は？	問い合わせの増加、ユーザ離脱	ソフトウェア認証器、パスキーの利用
証明書	オレオレ認証局のRoot CA入れろってやつ...w	第三者に頼らずに信頼できる環境を作り上げたい（JPKI・・・）	面倒くさい、やり方が複雑すぎる	ユーザの離脱、カゴ落ち	ブラウザベンダとの調整 上位レイヤーでのトラスト確保
リカバリ	秘密の質問	パスワード忘れへのヘルプデスク対応を減らしたい	どの質問にどう回答したか忘れる 出身地とかって他の人でも答えられるんじゃない？（全然秘密じゃない）	アカウント乗っ取り	同期可能パスキーの利用
リカバリ	パスワードリマインドで平文パスワードが送られてくる	パスワード忘れへのヘルプデスク対応を減らしたい	不安。。	ユーザの離脱、カゴ落ち	同期可能パスキーの利用
識別	独自ID（メールアドレスじゃない）	好きなIDの利用によるロイヤリティ	忘れる 好きなものが取れない 変えられない？	ユーザの離脱、カゴ落ち	オートフィル 変更可能なIDの利用
本人確認	eKYC（セルフィー＋免許証の顔写真比較）	本人確認	うまくいかない	券面偽造による不正登録	ICチップの利用
登録	偽ソーシャルログイン（メアドのverifyやパスワード登録を求めてくるやつ）	属性入力の簡素化による離脱防止 認証手段は自前で用意することによるサポートの簡素化	ソーシャルログインなのになぜパスワード登録が必要なのかわからない	ユーザの離脱、カゴ落ち	属性登録と認証手段登録の分離（UX） 認証手段としてパスキーをデフォルトにする
決済	カードのCVVを入力させる	決済を確実に、素早く実行できるのでカゴ落ちが減る	不安。。	ユーザの離脱、カゴ落ち PCIDSSの取得が必須になりコストアップ	3Dセキュアなどに任せてしまう

他にもあればぜひご意見ください。

NIST SP800-63Bへの同期可能な認証器に関する補足文書がリリースされています

こんにちは、富士榮です。

パスキーを使う際に、AppleやGoogle、Microsoftなどのクラウドプラットフォームを通じたデバイス間で鍵の同期を行うSyned Passkeysをどう扱うか？、つまりそもそもFIDO認証の良いところはデバイスとの紐付けが強固であることだったはず、一方で鍵のリカバリが認証強度の弱点となりクレデンシャルの盗難や不正利用のきっかけになってしまう、その意味で鍵の同期は必要なのである、といった論争もひと段落してきたわけですが、その意味でパスキーを念頭においた各種ガイドラインについても更新される時期が来ているのかもしれません。

今回、NISTからSP800-63Bに関する同期可能な認証器に関する補足文書が公開されています。

アナウンス原文はこちら）

https://www.nist.gov/blogs/cybersecurity-insights/giving-nist-digital-identity-guidelines-boost-supplement-incorporating

 公開された文書はこちら）

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63Bsup1.pdf

 

アナウンスに概要が記載されているので紹介しておきます。（Google Webページ翻訳）

補足文書とは何か？

補足は、既存の NIST Special Publication (SP) を強化、拡張、または詳しく説明することを目的とした特定の文書タイプです。これにより、SP 全体を更新するプロセスを経ることなく、対象を絞った更新や変更が可能になります。これらは、NIST がテクノロジーとリスク環境の変化により迅速に適応するためのメカニズムを提供します (たとえば、同期可能な認証システムのような新しい認証システム タイプの要件を提供します)。 

同期可能な認証器とはなにか？

同期可能な認証システムは、秘密キーを複製して認証システムとは別に保存して、異なるデバイス間でのその鍵の使用 (同期など) をサポートできる暗号化認証システムです。実際には、これらは通常、FIDO Allianceによって「パスキー」と呼ばれるもので、Client-to-Authenticator Protocol や World Wide Web Consortium (W3C) の Web Authentication (WebAuthn) などの複数の標準およびプロトコルを利用します。 

正しく実装されると、シンプルなリカバリ、クロスデバイスのサポート、消費者に優しいプラットフォーム認証サポート (ネイティブ生体認証など) など、多くの利点を備えたフィッシング耐性のある認証システムが提供されます。このような認証システムは、デジタル ID ガイドラインのコンテキストでは非準拠とみなされ、補足では、認証保証レベル 2 (AAL2) での使用を許可するための追加の要件と考慮事項が規定されています。 

ガイドライン（SP800-63-3）が発行されてからの世の中の変化は？

多くのことが変わりました。ガイドラインが最初に開発および発行された時点では、同期可能な認証システムをサポートするための標準と仕様は開発されていませんでした。それ以来、標準は成熟し、ほとんどの主要な消費者プラットフォームが同期可能な認証システムのサポートを導入しました。  FIDO Alliance はこれまでのところ、80 億を超えるユーザー アカウントが認証にパスキーを使用するオプションを備えていると推定しています。まだどこにでも普及しているわけではありませんが、日に日に一般的になってきています。 

鍵の複製に関するリスクは？

そう、リスクは常に存在するのです。補足の要件は、キーの保存、送信、保護の方法を含め、これらの要件にできるだけ多く対処することを目的としています。同期可能なオーセンティケーターには特有のリスクが伴います。特に、一部の技術実装におけるユーザーが自分の認証キーを他の個人と共有する機能です。認証子を共有する機能は同期可能なキーに固有のものではなく、ほぼすべての AAL2 認証子を共有できます。しかし、長年のセキュリティ ポリシーに反して、一部の実装では、多くの消費者シナリオでパスワード共有の安全な代替手段として同期可能な認証子の共有を推進しています。 

すべてのインスタンスと同様に、組織は、提供するあらゆるタイプの認証システムを評価し、実装する前にそれに伴うメリットとリスクを比較検討する必要があります。同期可能なオーセンティケータは、すべてのアプリケーションやサービスに適しているわけではありませんが、エンドユーザーと信頼当事者の両方に多くのメリットをもたらす、新たな AAL2認証器オプションとなります。

パブリックコメント期間は設けられるのか？

この更新文書には適していません 。 SP 800-63-4 に関する最初のパブリック コメント期間からのフィードバックがこの補足資料に組み込まれました。同期可能な認証システムと補足の全体的な内容に関する追加のコメントは、リビジョン 4 の今後の第 2 回パブリック コメント期間を通じて提出できます。これは今年後半に行われる予定です。 

SP800-63-4を待たないのか？

上で述べたように、デジタル ID ガイドラインの規範文に厳密に従っている政府機関は、同期可能な認証システムを使用することを許可されません。この補足では、連邦ゼロトラスト戦略をサポートする強力で使いやすく、フィッシング耐性のある認証を提供する新しいセキュリティ技術の使用方法についての指示を提供することで、多くの政府機関の当面のニーズに対応しています。リビジョン 4 が完成すると、この補足は廃止されます。

技術や状況は日々変わってきているので柔軟にガイドラインも対応していく必要がありますね。

Digital Credential Consortiumが公開しているVerifiable Credentials関連サービスを試す

こんにちは、富士榮です。

Digital Credential Consortiumが公開しているOSSのVerifiable CredentialsのIssuer/Walletを試してみました。

Adminダッシュボード

https://github.com/digitalcredentials/dcc-admin-dashboard

Learner Wallet

https://lcw.app/

何をするツールなのか、というと学修歴（に限りませんが）をVerifiable Credentialとして発行する管理ツール（ダッシュボード）とそれを受け取るための学習者向けのWalletの組み合わせになっており、管理者が定義したVCを学習者に対して発行することができます。

導入方法は非常に簡単で、

https://github.com/digitalcredentials/dcc-admin-dashboard/blob/main/docs/GETTING_STARTED.md

に書かれている通り、dockerイメージを落としてきて実行するだけです。

ただ、本ツールは基本的にメールでクレデンシャル発行要求を飛ばすところから始まる前提となっているので（要所要所にOpenBadge系の匂いがします）、メールサーバの設定をしてあげる必要があります。

そのためには、手順にある

curl https://raw.githubusercontent.com/digitalcredentials/docs/jc-compose-files/deployment-guide/docker-compose-files/admin-dashboard-compose.yaml | docker compose -f - up

ではなく、 

https://raw.githubusercontent.com/digitalcredentials/docs/jc-compose-files/deployment-guide/docker-compose-files/admin-dashboard-compose.yaml

をダウンロードしてきてメールサーバに関する記述を変更した上で、docker-compose.ymlにリネーム、docker-compose -up -dをする方がベターです。

変更対象は

      - SMTP_HOST=sandbox.smtp.mailtrap.io

      - SMTP_USER=myusername

      - SMTP_PASS=mypassword

の３行です。私はテスト用にmailtrapを使ったので必要なSMTPホストやユーザID、パスワードはmailtrapのサンドボックスの値を使いました。

これでdockerイメージから起動すると、http://localhost:3000で管理画面へアクセスできます。初回は管理ユーザを作成するところから始まります。

最初の画面です。

まだ何もありません。

使い方としては、まず最初にCredential Templatesから発行するVCの定義を行います。

タイトルやテンプレートとなるJSONを記載してきます。

ちなみに

https://github.com/digitalcredentials/dcc-admin-dashboard/blob/main/docs/GETTING_STARTED.md

にサンプルのJSONテンプレートがあるのでそのまま使いました。

定義ができました。

次がEmail Templatesです。先ほど書いた通り、メールでVC発行をユーザへ通知する仕組みなのでそのメールの本文を定義します。

これも先ほどのドキュメントにテンプレートのサンプルがあるので、そのまま設定します。

これで設定はおしまいです。

非常に簡単です。

あとは、実際にVCを発行することになりますが、最初のIssuance OverviewのページからUpload and Prepare BatchをクリックしてVCの発行を行います。

基本は先ほどのCredential Templatesの定義とEmail Templatesの定義を指定し、CSVファイルに記載した宛先に対してメールを飛ばす仕組みになっています。

必要なフィールドを入れたCSVファイルを用意してアップロードします。

準備ができるとこんな感じで送信確認を行います。

実際に送信するとメールが届くのでメールのリンクをクリックします。

先述の通りmailtrapを使っているのでサンドボックスからメールの確認ができます。

このリンクを実行するとVC発行のQRコードが出てきます。

これを先ほどのLearner Walletで読み込みます。

すると、、、、エラーがでます。

作者のDmitriに聞いてみましたが、どうやらバグっぽいので治るのを待ちましょう。
しばらくしたらまた試してみたいと思います。

しかし、こう言うツールがOSSで出てくるのは非常にいいですね。うまくコントリビューションしていければと思います。

自民党web3PTの2024年版ホワイトペーパーのテーマの一つはDID/VC

こんにちは、富士榮です。

先日リリースされた自民党のweb3PT（プロジェクトチーム）のホワイトペーパーのテーマの一つとしてDID/VCが取り上げられていますね。ブロックチェーン、DAO一筋だったころに比べると社会実装に向けて現実的な路線も取り入れられてきていて成熟してきた感があります。

新たなテクノロジーが社会基盤となる時代へweb3PTが「ホワイトペーパー2024」を策定

https://www.jimin.jp/news/information/208018.html

発行されたホワイトペーパーの要旨にはこんな感じで「VC及びDIDの利活用促進、DIWに関する検討」がテーマとして記載されています。実はこのDID→VCではなく「VC及びDID」となっているところが個人的には注目です。これまでのweb3ではDIDが全面に出てきていましたが、ようやく本質はVCだということが理解されてきたようです。事務局のみなさん本当にお疲れ様です。

ちなみに、平井卓也さんのInstagramに会合の様子が掲載されています。この会は私もお邪魔してVCとブロックチェーンの関係性の話を少しお話してきました。（あんなに細かい話をして良かったのかどうかは置いておいて）

ちなみにホワイトペーパーは平将明さんのページにダウンロードリンクが紹介されています。

https://www.taira-m.jp/2024/04/web3-3.html

Interopカンファレンスは今年もトラストで！

こんにちは、富士榮です。

昨年はパネリストでおよびいただいておりましたが、今年はプログラム委員を拝命いたしましたInteropカンファレンスがいよいよ6月に迫ってきています。申し込みも開始されたようなのでぜひお越しください。

https://f2ff.jp/conf/2024/06

さて、私の担当プログラムは例によってトラストが中心です。

1. Trusted Web(1)　デジタル空間におけるトラストをいかにして実現するか？
• こちらはクロサカさん、鈴木先生と一緒にTrusted Webの進捗を語りたいと思います。ちょうどホワイトペーパーもv3.0が昨年度発行され、いろいろな取り組みが表に出てき始めていますが、まだEUのように社会実装にまでは至ってはいません。この辺りについての観測と今後の展望についてお話しできるといいのではないかと思います。
• https://f2ff.jp/introduction/8830?event_id=conf-2024-06
2. Trusted Web(2) 実社会での本格利用に向けて動き始めた分散型IDとデジタルIDウォレット
• こちらはDataSignの太田さん、DNPの岡本さん、高市さんをお招きして実際に開発をされている方々のご意見を伺ってみたいと思います。両社ともTrusted Webの実証事業者としてウォレットや分散型IDに関する基盤開発に関わってきていらっしゃる事業者の方なので、開発の実際や今後の展開における課題などを聞いていきたいと思います。
• https://f2ff.jp/introduction/8831?event_id=conf-2024-06

もちろん、これ以外にも数多くの興味深いセッションがありますので、ぜひ参加登録をしてください。

OpenID Technight #21を開催します。今回はShared SignalとIIWの振り返りです

こんにちは、富士榮です。

半年ぶりくらいになるでしょうか？OpenID Technight #21を開催します。

今回は対面＋オンラインのハイブリッド開催です。

気になるテーマはマニアックに「Shared Signal Framework」です。まさにID基盤を裏から支える縁の下の力持ちのフレームワークで、主にリスクイベントやアイデンティティ・ライフサイクル上で発生する様々なイベントを裏側でIdP同士やIdPからクライアントへ伝達するためのシグナリングのための仕組みです。

また、時期的にもInternet Identity Workshop（IIW）の前後でありましたOpenID Foundation Workshopを含むIIWでの最新情報などについても、OpenIDファウンデーションジャパンの最新動向と合わせてお話できると思います。

ということでぜひ重し込みください。

• 日時：2024年5月16日（木）18:30〜（開場18:00）
• 場所：大手町KDDIホール＋オンライン（Youtube Live）
• 申し込みサイト：
• https://openid.connpass.com/event/316748/

お会いできるのを楽しみにしています。

IIW #38 Day3クイックレビュー

こんにちは、富士榮です。

いよいよ最終日でした。

一昨日、昨日に引き続きIIW（Internet Identity Workshop）のクイックレビューです。

本日は、

• OID4VP Suggestions for query syntax(P.E.) simplification - Tobias, Kristina, Oliver
• OID4VC as Framework vs Profiles - Kristina
• Verifiable Credentials with BBS+ and zk-SNARKs for Predicate Proofs - Dan Yamamoto
• Learning Record - Mehesh Balan

あたりを記録しておきたいと思います。

OID4VP Suggestions for query syntax(P.E.) simplification - Tobias, Kristina, Oliver

現在OpenID for Verifiable Presentations（OID4VP）はPresentation Exchange 2.0.0（PE）を使っているがシンプルにできないか？という話です。現在、要件をDCPWGで洗い出しているそうです。

例えば、

• JWTでCBORでも使えるようにしたい
• SDにも対応できるようにしたい
• ネスト構造にも対応できるようにしたい

などがテーマのようです。

うまく、OID4VPをプロトコル、PEをクエリ言語としてモジュラー型にできるか、という議論もあります。方向性としてはPEをシンプル化してBreaking changeを極小化する形に落ち着いてくると思われます。

具体的にはinput_descriptorsの下にformat要素を作り、例えばmDocならdoctypeとしてmDL、claimsにnamespaceやdata_element_idを指定する、という形で考えているようです。

OID4VC as Framework vs Profiles - Kristina

引き続きKristinaさんのセッションです。

相互運用性を担保するために必要なこととしてあげられる、

• Definition of "mandatory to implement" element of the protocols
• Wallet invocation mechanism. Custom url scheme, etc
• Verifierにおける認証メカニズム
• Walletのクレデンシャルフォーマット
• issuerの識別とキー解決
• Holder key binding
• 暗号アルゴリズム

をプロファイルとして定義していこう、という話ですね。

これはOAuthでも行われていることでRFC6749はFrameworkでFAPIなどはプロファイル、という言い方をします。

しかし、FAPIではブラジルやオーストラリアのオープンバンキング向け、など各国向けのプロファイルが存在している状態になっています。今回のOpenID for Verifiable Credentialsはどうしていくのか？は考えないといけないところだと思います。

現在、HAIP（High Assurance Interoperable Profile）が定義され、EUではこのプロファイルを使うことになっていますが、これが全世界的に受け入れられるプロファイルとなるのか、もう少しコアプロファイルを削り出して個別の事情を含め柔軟に受け入れられるようになるか、は今後のデザイン次第だと思います。

参考までに、HAIPでは

• Protocol profile
• SIOP,OID4VP,OID4VCI
• Credential profile: SD-JWT VC
• SD-JWT VC
• JWT/CWT Statuslist
• Wallet Attestation Scheme
• Attestation based client authentication
• Basic choices
• Custom scheme
• Issuer key resolution
• Crypto suite

あたりが決められています。

Verifiable Credentials with BBS+ and zk-SNARKs for Predicate Proofs - Dan Yamamoto

次はIIJの山本さんのセッションです。

これまでも毎年Updateされてきているzkp playgroundを使って動きを見ながらこれまでの研究成果を発表してくれています。

参考）

https://playground.zkp-ld.org

今回はこれまでBBS+で実装してきたSelective Disclosureに加えてzk-SNARKを使ったPredicateへの対応です。

具体的に言うと、単純に名前や生年月日を開示する・しないを選択できる選択的開示に加えて、21歳以上かどうか？などと言った判定結果のみを開示する、ということにも対応した、という話です。

具体的には、RDFのブランクを示す、”_;"から始まる文字列で対象となる値を置き換えます。

例）birthDate: "_:HIDDEN_DATETIME"

この状態でpredicateタイプとしてprivate<publicといった演算子を選択し、

• privateに先ほど指定した_:HIDDEN_DATETIMEを、
• publicに比較対象となる日付、例えば"2003-04-018T23:59:59Z"を

設定します。

こうすると実際の値が隠されたプロパティがpublicに指定した値よりも大きいのか小さいのか、ということがクレデンシャル内にセットされるためVerifierは判別ができる、という仕掛けです。

また、この結果のVerifiable Presentationを検証できるChrome Extensionを用意しており、例えばデモで見せてくれたのはBlueSkyに当該のVPを配置したストレージ（デモではgithub）のURLを投稿、このリンクの値を検証することで本当にこのアカウントの持ち主は21歳以上なのかどうかを検証ができる、というシナリオでした。

こう言う形で動いているものを見ながら議論ができると盛り上がっていいですね。

Learning Record - Mehesh Balan

最後はMeheshさんの学修歴クレデンシャルです。アリゾナ州立大学の学位などをVCとして発行する、というシナリオで実装をしているそうですが、実際の社会実装として適用していくためにはどうしていくのがいいのか？というどこかで聞いたような話でお悩み相談でした。

（スピーカーと私を含めて全部で3人のセッションだったので本当にお悩み相談っぽかったです）

ちょうどアリゾナ州にはTSMCの工場ができていたり、と半導体が盛り上がっているので学生を送り込みたいところなのですが、効率的にスキル証明をすることができれば、という話です。これもどこかで聞いた話だなぁ、と。

具体的なお悩みポイントは、

• Issuerのトラストをどのようにして検証するのか
• どうやってVerifier（例えばTSMC）に受け入れてもらうか

です。

まず、トラストの話はX.509のルートを辿っていく、という話も出てきましたが、技術以外にトラストフレームワークをどう捉えるのかも総合して考えないとダメだよね、という話をしました。米国の大学ではinCommonがあるのでそのSPとしてTSMCを構成すればそもそもVCじゃなくてもいいのでは？という話もありますが、卒業生や他の大学の学生などトラストフレームワークの外のエンティティをどうやって担保するのか？という話なども議論の種でした。

Verifierとの調整の話は典型的な卵・鶏の話なので、まずはアカデミアの世界でちゃんとグローバル標準を作って、より多くの大学が同じタイプのクレデンシャルを発行できる状態を作って数で勝負していなかないとダメ、という話をしました。この辺りは某QRコード決済を普及された事業者がやっていたような力技もどこかで必要になるでしょうし、政府のサポートも重要なファクターとなると思われます。

また半年後、もしくは1年後に彼とは情報交換をして進捗を確認し合っていけると良いと思いました。

ということで3日間のIIWはおしまいです。

ここに書いた話以外にもサイドで個別に議論をできたことも多く、結果的に実りのある3日間でした。また次回の秋もしくは1年後に参加して進捗を見ていきたいと思います。