2024年4月24日水曜日

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 が完成すると、この補足は廃止されます。


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

2024年4月23日火曜日

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

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

Digital Credential Consortiumが公開しているOSSのVerifiable CredentialsのIssuer/Walletを試してみました。
Adminダッシュボード
Learner Wallet

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

導入方法は非常に簡単で、
に書かれている通り、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

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

これでdockerイメージから起動すると、http://localhost:3000で管理画面へアクセスできます。初回は管理ユーザを作成するところから始まります。
最初の画面です。
まだ何もありません。
使い方としては、まず最初にCredential Templatesから発行するVCの定義を行います。
タイトルやテンプレートとなるJSONを記載してきます。
ちなみに
にサンプルの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で出てくるのは非常にいいですね。うまくコントリビューションしていければと思います。




2024年4月22日月曜日

自民党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


2024年4月21日日曜日

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

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

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


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

  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



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

2024年4月20日土曜日

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年4月19日金曜日

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を使って動きを見ながらこれまでの研究成果を発表してくれています。
参考)

今回はこれまで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年後に参加して進捗を見ていきたいと思います。

2024年4月18日木曜日

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

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

昨日に引き続きIIW(Internet Identity Workshop)の記録です。

今日も主要なセッションについてメモしていきたいと思います。
印象に残ったのが以下のセッションです。
  • Cross Platform Demo of Digital Credential API - Eric@Apple, etc.
  • OpenID for VP + OpenID for VP over Browser API - Kristina, Joseph, Torsten
  • Demo hour(ブータン、台湾の展示)

早速みていきます。
まずはApple/Googleからの発表です。

Cross Platform Demo of Digital Credential API - Eric@Apple, etc.

要するに、Credential APIを使ってWalletとの間のインタラクションを簡素化しましょう、という話です。
従来だとIssuance requestやPresentation requestをCross deviceだとQRコード、Same deviceだとカスタムURLスキームで、という形でブラウザとWalletとの間でやり取りをしていましたが、これまでにも触れたカスタムURLスキームの後勝ち問題など、OSの仕組み上どうしようもない課題が存在していていました。
しかし、よく考えてみると同一デバイスならブラウザから直接呼び出し、別デバイスならQRコードを表示する、というUXは他でもみたことがありますよね?そう、パスキーです。パスキーでは以前解説したとおりcredential.get()などのブラウザAPIを使って認証機能を呼び出していました。
このアイデアはOpenID for Verifiable Credentials関連の仕様においても同じ仕組みを使えるようにブラウザAPIの拡張を行うことはできないか?という話で、今回AppleとGoogleがそれぞれのデバイスで実装したデモを披露してくれました。

こんな感じでidentityDocumentのrequest/responseをブラウザAPIを使って実現します。


実際に動くデモがiOS/Androidの両方で披露されました。

OpenID for VP + OpenID for VP over Browser API - Kristina, Joseph, Torsten

前のセッションに引き続きプロトコルの面からの詳細解説です。

先に記載した通り、VerifierでPresentation requestを行うところでブラウザAPIを使うことで、現在VerifierがQRコードを自前で生成しているがこれをより安全に生成することはできないか?そして、Crossデバイスの際にパスキーでQRコードを出す仕組みをそのまま使うことでカスタムURLスキームを使わずに済むようにできないか?またフィッシングレジスタントという意味でもこの辺りはパスキーと同様の仕組みにするのがリーズナブルではないか?などモチベーションが紹介されました。



呼び出し方については
navigator.identity.get({
  digital: {
    prividers: [{
      protocol: "urn:openid.net:oid4vp"
      request: JSON.stringfy({
       ※ここにOID4VPリクエストを入れる
   ※ただし、Client_id_scheme : "web-origin"を追加する
というイメージでAPIを実行するようです。

Demo Hour①(ブータンの国民ID)

少しセッションとは毛色が異なりますが、ブータンの国民ID、Walletの展示がありました。


オンボーディング時は軍の方が各家庭を回って本人確認〜登録を勧めたそうです。スマートフォンの配布もこの際に行ったそうです。


なお、インドと同様に各国民の生体情報(実際は特徴点情報)が国側に登録されているのでアクティベーションにいは生体情報を使います。

ざっくりメモです。
  • インドの会社が作っている
  • Hyperledger Ariesベース
  • anonCredを使っている
  • オンボーディングの際は軍が一人一人を訪ねて立ち上げをサポート
  • スマホも配った
  • ブートストラップする際は生体認証(そもそも国側に顔の情報が登録済み)
  • 顔認証が通るとFundamental Credentialが落ちてくる
  • それをベースに自己発行のクレデンシャの作成などもできる
  • 民間で使う場合、例えば銀行口座を解説する場合などはサインアップ時にVCを提示してアカウントを作る
  • アカウントが作られるとVCとしてWalletに取り込まれる
  • そのVCを使ってオンラインバンクへのログインができる
  • モチベーションとしては高地に住んでいる人が対面銀行に来るとなると標高差年全mの移動が必要となるのでデジタル化は必須だった
  • ちなみにインドでも同じスタックを使っているので、インドでもこのWalletは使える
  • 実際にオフィスの扉の開錠に使っている

Demo Hour②(台湾のデジタルIDウォレット)

ちょうどオードリー・タン大臣の退任が伝えられたばかりですが、台湾のデジタルIDウォレットの展示がありました。

2027年の向けてオープンソースで開発を進めているそうです。
また、トラストリストを持つことで安心して使えるようにしているのも特徴ですね。

キャラクターグッズ?をもらいました。

以下メモです。
  • 細かいプロトコルやクレデンシャルフォーマットは動くので抽象化した実装となっている
  • OSSで公開してブラッシュアップをしていくモデルだが、政府が7ミリオンドルくらいを毎年予算計上している
  • モチベーションとしては地政学リスクを考えて、分権型としている(中央集権だと中国に乗っ取られたら終わる)
  • トラストリストを作り、利用できる事業者やサービスを絞ることで利用者に安心を与えている
  • オンボード時はtwFIDOとの連携している

こう言う形で実装を早い段階で展示して多くの人の意見をもらえるようにしていけるといいですね。
明日は最終日です。また記録していきたいと思います。