2024年5月4日土曜日

NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む(1)

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

先日紹介した通り、NIST SP800-63-3の追補版という形で同期可能なクレデンシャルの取り扱いに関する文書がリリースされました。

今回から中身を少し見ていこうと思います。

しかし、ちょうど最近iOSやmacOSの共有パスワードグループでAirDrop環境外でもパスワードに加えてパスキーまで共有ができるようになった、というアナウンスが界隈では話題に上りました。なんだか単純な同期の話だけでは済まなくなってきてしまった気もしますが、この機能がこのガイドラインにどのような影響を与えるのかは継続ウォッチということで、まずはガイドライン(追補版)を見ていきましょう。

参考)共有パスワードグループ

とりあえずイントロです。例によってDeeplで機械翻訳です。

Introduction

NIST デジタル ID ガイドラインは、ID 証明、認証、およびフェデレーションを 含む、デジタル ID のプロセスと技術要件を規定している。NIST 特別刊行物(SP)800-63B(SP 800-63-3 に関連する第 B 巻)は、認証およびライフサイクル管理 の要件を特に取り上げている。改訂 3 は、このガイドラインの最新の大幅な改訂であり、2017 年 6 月に発行された。シリーズ全体の更新が進行中であり、改訂 4 で完結する予定であるが、技術のペースは NIST の典型的な文書開発およびレビューのプロセスよりも速いため、この補足的な更新が正当化される。

SP 800-63B で扱われるこのような認証タイプは、多要素暗号認証である。通常、この認証タイプは、ハードウェアまたはソフトウェアで暗号鍵を保護し、第 2 の認証要素(記憶された秘密またはバイオメトリック特性のいずれか)による起動を必要とする。秘密鍵を不正な暴露から保護することは、多要素暗号認証機のセキュリティ・モデルの基本である。これには従来、秘密鍵がエクスポートまたはクローン可能でないことを保証することが含まれる。しかし、このパラダイムは変わり始めている。特に、新しい一連の認証プロトコルと仕様により、同期可能な認証子(一般に「パスキー」と呼ばれる)が急速に採用されるようになり、ユーザが異なるデバイス間で秘密鍵を同期(つまり、 複製)できるようになった。

SP 800-63-3 が 2017 年に発行されたとき、2 つの重要なサポート仕様である Fast Identity Online (FIDO) Client to Authenticator Protocol (CTAP) と W3C の Web Authentication(一緒に使用される場合は FIDO2 として知られる)は存在せず、実装の強固でよく理解されたエコシステムもなかった。当時利用可能であった暗号認証の種類に基づき、2017年のガイドラインは、多要素暗号認証が他のデバイスに鍵を「クローン」する能力を制限した。しかし、この2年間でエコシステムは急速に加速し、現在ではほとんどの主要なプラットフォーム・プロバイダが、スケーラブルで同期可能な認証機能を実装している。これらの認証機能は、耐フィッシング性のサポート、特定の依拠当事者にバインドする機能、パスワー ドを送信する必要性の排除、認証機能のリカバリの簡素化、保存された秘密鍵に付随する第 2 要素とし ての多様なデバイス固有の生体認証および PIN の使用など、多くの利点を提供する。また、ますますマルチデバイス、マルチプラットフォーム化する世界に適合する利便性も提供する。どのような新しい技術もそうであるように、技術革新の約束には、探求し理解しなければならない新たな脅威と課題が伴う。そのため、この補遺では、連邦機関が同期可能な認証機能を実装するかどうか、またどのように実装す るかを決定する際に、現代の脅威を含めて考慮すべき事項の概要を示す。
まぁ、先日のポストにも書いた通り、時代が変わったのでver.4を待たずに追補版で同期可能なパスキーに関してちゃんと分析して考慮をしよう、という話です。

次に文書の目的です。

Purpose

この文書の目的は、変化する認証およびクレデンシャルの市場を反映するために、現行の NIST ガイドラインを適合させることである。この補足では、SP 800-63-3 で確立された認証保証レベルと一致する方法で、同期可能な認証機能がどのように脅威を軽減するかを説明し、SP 800-63-3 認証保証レベル 2(AAL2)を達成するために活用できる同期可能な認証機能の理解を連邦機関に提供する。また、SP 800-63B の第 5.1.8 節で説明されているソフトウェア暗号化認証子の使用に関する最新情報、 特に、鍵が別のデバイスに複製(例えば、「クローン」または「同期」)された場合でも、当該認証子が AAL2 認証要件をサポートする能力についても提供する。最後に、本文書は、公衆向けアプリケーション(すなわち、OMB Memorandum M-19-17 に記 載されているように、公衆 ID と相互作用する連邦情報システム)と連邦エンタープライズ・ アプリケーション(すなわち、OMB Memorandum M19-17 に記載されているように、主に連邦エ ンタープライズ ID と相互作用する連邦情報システム)という 2 つのユースケースに基づ いて、実装に関するいくつかの考慮事項を示す。この文書は、SP 800-63-3 にある既存のガイダンスを補足するものであり、SP 800-63B-4 の最終版に取って代わられる。
記載の通りですが、同期可能であってもAAL2を達成できることを説明するための資料になっているってことですね。また、当然ですが最終的にはver.4へ統合されていく文書というわけです。

ということで、ちょっと長めのシリーズになりそうですが徐々に見ていきたいと思いますので、今回はここまでです。



2024年5月3日金曜日

Entra External IDがGAされています

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

長らくPreviewだったEntra External ID(旧Azure AD B2B、およびCIAM)がGAされました。(といっても特にCIAMはまだまだPreviewの機能だらけなんですけどね・・・)

https://techcommunity.microsoft.com/t5/microsoft-entra-blog/announcing-general-availability-of-microsoft-entra-external-id/ba-p/3974961


個人的にポイントだと思っているのは、いわゆるワークフォースIDであるEntra ID(Azure AD)との機能面での統合が進んだこと、そしてEntra Verified IDとの連携ですね。

しかし、もうここまでくると単なるID基盤という枠には収まらず、他のAzureリソースとの組み合わせを意識した統合的なアイデンティティ・プラットフォームになってきていますね。いよいよインフラとしての設計も難しくなってきてますので、ちゃんとプロ(国井さんとか)の教育を受けて使うことをお勧めします。



個人的にも気になってきたAzure AD B2Cからのトランジションについてはまだまだ情報が不足していますが、現状のCIAMの機能ではとてもじゃないけどAzure AD B2Cの自由度のカバーはできないので、まだしばらくは並行してサポートされていくことになると思います。本社の開発チームの話ではマイグレーションパスなどもゆくゆくは用意していくということなので、こちらも継続ウォッチですね。

2024年5月2日木曜日

日EUデジタルパートナーシップの目玉の一つはデジタル・アイデンティティとトラスト

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

4/30にベルギーで開催された2回目となる日EUデジタルパートナーシップ閣僚級会合が開かれて、共同声明が発行されましたね。

(デジタル庁のポストより)

https://www.digital.go.jp/news/955484d4-1ba4-4680-b0d8-a0e78946508c

共同声明の1番目(1番目っていうのが大事!)に「デジタル・アイデンティティに関する協力推進」が記載されています。(赤字、アンダーラインはブログ著者による)

OECDでのDFFT専門家コミュニティの設立を含むパートナーシップのための制度的アレンジメント(the Institutional Arrangement for Partnership:IAP)の始動を歓迎する。OECD閣僚理事会(2024年5月2日、3日)での連携を含め、IAPの更なる強化に関して引き続き協力する。本パートナーシップの機会を捉え、河野デジタル大臣とブルトン欧州委員との間でデジタル・アイデンティティの協力推進に関する協力覚書に署名した。日本に対するEUの十分性認定の範囲を学術研究分野及び公的部門に拡大する議論を歓迎する。

対象分野として学術研究分野についても触れられており、毎日新聞の記事を見ると「具体的には、転職や留学で用いる学歴などのデータを互いに流通させる仕組みを2024年中に先行開始できないか検討する。(以下の記事より引用)」とありますので、EUDIWのLSP(ラージスケールパイロット)の中のテーマの一つである学位・学修歴クレデンシャルを日EUで相互運用できるようになったりすることが期待されます。

https://mainichi.jp/articles/20240430/k00/00m/300/189000c

なお、この閣僚級会合に先立ち、4/17にステークホルダーを集めたワークショップがあり、私も急遽日本における学修歴クレデンシャルの状況についてお話しさせていただきました。この際もEU側からも相互運用に向けて取り組みを進めたい、というコメントもありましたので、今後に期待ですね。

こちらがワークショップのページです。ちょうどIIWで西海岸にいた日なので時差がきつかったですが・・・

https://eprd.pl/en/dpa/japan/public-private-stakeholder-workshop/agenda/



実は、このようなデジタルパートナーシップ協定はいろいろな国と締結しており、その中でもデジタル・アイデンティティはしばしばテーマの一つとして取り上げられています。ざっくりデジタル庁のホームページから探した範囲では以下の国々と取り組みについて触れられています。

広く相互運用ができるといいと思いますので、今後もウォッチしていこうと思います。






2024年5月1日水曜日

Trusted Signing(元Azure Code Signing)がPublic Preview

こんにちは、富士榮です。
ちょっといつもと話題を変えてコード署名の話です。

昔から(少なくともプロダクションの)コードに署名しましょう、という話はありましたが署名するための環境を用意するのは面倒くさいという難点がありました。

ということでこの辺りをas a ServiceとしてMicrosoftが提供しようとしているのがAzure Code Signingなのですが、これが「Trusted Signing」としてPublic Previewになりました。

アナウンス

サービス内容はこちらのようです。基本的にマネージドな基盤として提供され、GithubやVisual StudioなどのCI/CDに組み込んでいくこともできるものです。
  • We manage the full certificate lifecycle – generation, renewal, issuance – and key storage that is FIPS 140-2 Level 3 HSMs. The certificates are short lived certificates, which helps reduce the impact on your customers in abuse or misuse scenarios. 
  • We have integrated into popular developer toolsets such as SignTool.exe and GitHub and Visual Studio experiences for CI/CD pipelines enabling signing to easily integrate into application build workflows. For Private Trust, there is also PowerShell cmdlets for IT Pros to sign WDAC policy and future integrations with IT endpoint management solutions. 
  • Signing is digest signing, meaning it is fast and confidential – your files never leave your endpoint. 
  • We have support for different certificate profile types including Public Trust, Private Trust, and Test with more coming soon! 
  • Trusted Signing enables easy resource management and access control for all signing resources with Azure role-based access control as an Azure native resource. 
  • To learn more about the service go to: https://learn.microsoft.com/azure/trusted-signing

まぁ、当然お金はかかるわけですが、自前でCAを立てて運用するよりは楽ですね。

  • BASICプラン
    • 基本料金:$9.99/月
    • 月間署名数上限:5,000
    • 上限超過分:$0.005/署名
    • プライベート署名、パブリック署名それぞれについて1つの証明書プロファイルポリシーの定義が可能
  • Premiumプラン
    • 基本料金:$99.99/月
    • 月間署名数上限:100,000
    • 上限超過分:$0.005/署名
    • プライベート署名、パブリック署名それぞれについて10個の証明書プロファイルポリシーの定義が可能

ちなみに使おうとするとサブスクリプションのResource ProviderにMicrosoft.CodeSigningを登録してあげる必要があります。
くわしくはこちらから。




まぁぼちぼち使ってみますかね。。。

2024年4月30日火曜日

VC-JOSE-COSEがCRに

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

VC-JOSE-COSEがW3CのCR(勧告候補)になっていますね。

https://www.w3.org/TR/2024/CRD-vc-jose-cose-20240425/



Mike Jonesも書いているように先日同じく勧告候補になったVCDM(Verifiable Credentials Data Model)v2.0では前のバージョンと異なりクレデンシャルフォーマットにJSON-LDだけをサポートするようになっています。

一方でこのVC-JOSE-COSEはJOSE、SD-JWT、COSEをスコープとしているのでなんだかチグハグな感じになりつつあります。

まぁ、そもそもクレデンシャルフォーマットがISOのmDoc、IETFのSD-JWTやJWP、W3CのVCDMと割れてしまっているが今後どうなっていくんだろうか・・・という話ではあるんですが。

追記)崎村さんからOpen Wallet Foundationが見ているクレデンシャルフォーマットの一覧を頂いたので貼っておきます。16種類もある・・・(2024年4月末時点)

https://github.com/openwallet-foundation/credential-format-comparison-sig/tree/main/data/Credential-Format






2024年4月29日月曜日

SIDI Hubの活動が本格的に開始されています

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

これまでも何度か本ブログで取り上げてきたSIDI Hubですが、いよいよ活動が本格的に開始されています。


おさらいですが、現在、SIDI Hubのワークストリームは以下の通り定義されています。

1. Champion Use Cases for cross-border interoperability, develop a process for selecting and fleshing out 1-3 cross-border use cases.

2. Minimum Requirements for Digital Identity Interoperability for Champion Use Cases.

3. Trust Framework Mapping for Champion Use Cases, by analysing and amplifying existing trust mapping efforts, identifying gaps (including duplication), and aligning on mitigation tactics.

4. Metrics of success Define what SIDI Hub metrics of success are, and monitoring delivery.

5. SIDI Hub Governance, such as SIDI Hub internal processes & grant management, SIDI decision tracking, SIDI partner issue resolution monitoring, SIDI roadmap alignment, global ecosystem governance gap analysis & options to remediate.

このうち、2番目のチャンピオンユースケースの実現に向けたデジタルIDに関する最低限の相互運用性要件の定義、3番目のトラストフレームワークのマッピングに関する定例会議が始まりました。

それぞれ、以下の曜日・時間帯でスタートします。

  • 最低限の相互運用性要件の定義
    • 毎週月曜日の16:00-17:00(CET)
    • 4/29(UTC)から開始
    • 日本時間で言うと4/29(月)23:00-24:00(つまり今晩)※現在CESTだったので修正
  • トラストフレームワークのマッピング
    • 毎週木曜日の14:30〜15:30(UTC)
    • 5/2(UTC)から開始
    • 日本時間で言うと5/2(木)22:30-23:30※同じく現在CESTだったので修正

※時差計算は苦手なので間違っていたらすみません。


こちらのページで興味のあるワークストリームに登録をすると案内メールが流れてくるので、その中に参加用のTeams会議のリンクがあります。ぜひ参加しましょう。


2024年4月28日日曜日

CACTIの次世代クレデンシャルに関するレポート(3)

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

このレポートを見ていくのも最後です。最後はユースケースの話です。

パイロットとユースケースについてこのように分類しています。
広くユースケースの募集をしていました。
パイロットは、研究および教育部門ではやや独特な問題に焦点を当てる必要があります。学生、教職員、およびスタッフは、多くの場合、機関間および機関内の承認に使用する必要がある非常に多くのグループと役割を担っています。 これらのグループ メンバーシップは、セキュリティ上の理由からリアルタイムの失効に大きく依存しており、グループの数が膨大であるため、大規模な承認に対して課題、別名「Kerberos PAC フィールド問題」が発生することがよくあります。 この分野におけるもう 1 つの特有のニーズは、eduperson、voperson、SCHAC などのカスタマイズされたスキーマのサポートです。 コミュニティは、検証可能な資格情報スペースの既存のオープンスタンダード内でこれらのスキーマをどのように適応させて使用できるかを調査する必要があります。
ワーキンググループは 31 のユースケースを収集しました。 ユースケースの違いを示す最も顕著な側面の 1 つは、各ケースで R&E 機関が果たす役割です。 多くの場合、教育機関は卒業証書や学生証などの資格情報の発行者です。 他の場合には、その機関が、おそらく別の学術機関からの資格の検証者です。 また、場合によっては、機関自体が資格情報を保持していることもあります。 これらのカテゴリのうち最初の 2 つ、つまり発行者および検証者としての機関が、最もすぐに対応できると思われます。 そこで、グループは、これらのカテゴリを最もよく表すユースケースを選択しようとしました。
31!結構な数です。あまり私たちはコントリビュートできませんでしたが、いろいろなケースが存在します。

作業グループは、次の 3 つの使用例を検討することに同意しました。
学生は、現在の学業状況以外のことを明らかにすることなく、在学生にのみ提供されるサービス割引を受けるために、サービスプロバイダーに検証可能な資格情報を提示します。
大学は入学希望者の高校卒業資格および/または成績証明書を確認する必要があります。
雇用主は、将来の従業員の大学の卒業証書および/または成績証明書を確認する必要があります。
 
やはりアカデミックと言うことでアクターとして学生と雇用を考えるわけです。
ユースケース 1 は、次世代認証情報の魅力的なユースケースと考えられていました。 これは理解しやすく、次世代認証情報のプライバシー強化の可能性を明確に示しています。 まず、ユーザーは現在の学歴をプロバイダーに提示するだけでよく、他の情報はすべて隠します。 第 2 に、資格情報の発行者 (おそらく教育機関) は、ユーザーがサービス割引を有効にしたことに気づいていません。
ユースケース 2 と 3 は似ていますが、各ケースで機関はエコシステム内で異なる役割を引き受けます。 ケース 2 では、教育機関が検証者として機能し、ケース 3 では、教育機関が学歴証明書の発行者として機能します。 どちらの場合も、従来の境界を超えた相互運用性と信頼が基本的な要件です。
ユースケース 3 では、次世代認証情報の性質から得られるセキュリティ上の利点も強調しています。 教育機関が資格情報を発行すると、所有者はその資格情報を直接提示できます。 卒業証書や成績証明書を保持する仲介者がいないため、侵害の可能性がさらに高まります。 組織にとって、攻撃対象領域が小さくなり、侵害範囲がより限定されることによるリスクの潜在的な削減は、説得力のあるものとなるはずです。

WGでは1つ目のユースケースにフォーカスを置いて議論を進めています。
ワーキンググループは、ユースケース 1 が次世代の認証情報エコシステムの期待と利点を最もよく表しており、かつ理解しやすいものであることに同意しました。 個人の学業上の地位を主張することは、学術機関が実行する基本的な機能であり、割引の引き換えだけに限定されるものではありません。 ほとんどのユーザーは、学歴を証明するために既存の資格認証テクノロジーを使用することに慣れています。 機関とユーザーの両方が慣れ親しんだ既存のプロセスとして、次世代認証情報のプライバシー強化機能を強調しながら、テクノロジーを直接比較する機会を提供します。
これらの最初の非常に単純な使用例をサポートできるパイロット アーキテクチャを構築するには、多くの領域でさらなる作業が明らかに必要です。 ワーキング グループは、InCommon のコミュニティ ガバナンス領域の全領域に及ぶ可能性のある後続の活動を推奨しており、大規模なアーキテクチャ、信頼モデル、標準、運用要件と展開要件、グローバルな相互運用性、内部での反復実装を調査するために必然的に新しいワーキング グループを作成します。

なかなか難しい問題ですが、結局のところ、トラストフレームワークの中で管理されている学生とその外にある人たちをどうやってコラボレーションさせるか、というなところがやはり次世代のクレデンシャルで解決すべき問題になるんじゃないかな、と思ったりもしました。
これをコミュニティとガバナンスの問題に閉じこめたらダメなんじゃないかと思いました。

ということでこのレポートは以下の結論で締めくくっていますす。
CACTI と InCommon Technical Advisory Committee (TAC) は、2024 年の第 1 四半期に開始し、2024 年 9 月末の終了日を目標として、共同作業グループの取り組みを開始し、実証のためのユースケースをさらに絞り込む必要があります。 これらのユース ケースを使用して、InCommon 信頼環境内で検証可能な資格情報テクノロジを使用する概念実証の展開のための高レベルのアーキテクチャと技術要件を定義します。 可能であれば、コミュニティのニーズとその要件に合わせて、既存の機能、機能、およびビジネス プロセスの使用を検討する必要があります。 この作業グループは、概念実証のためのソフトウェアおよびシステム要件に関する規範文書だけでなく、高レベルのアーキテクチャを説明する規範文書を作成する任務を負う必要があります。
まぁ、結論というかなんと言うかの締めくくりですが、今後も検討をしていかないといけないテーマなんだと思います。