2024年5月7日火曜日

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

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

前回に引き続きNIST SP800-63-3の追補版を見ていきます。

だいぶ中身に入ってきました。
早速読んでいきます。

Updates on the Allowance of Cloning Authentication Keys

SP 800-63B のセクション 5.1.8.1「多要素暗号化ソフトウェア認証機能」は、認証器があるデバイスから別のデバイスへ暗号化認証鍵を「クローン」することを制限している。具体的には、以下のとおりである:

多要素暗号化ソフトウェア認証器は、複数のデバイスへの秘密鍵のクローニングを抑制すべきであり、促進してはならない(SHALL NOT)。

同期可能な認証器は、デバイスや異なるプラットフォーム・プロバイダにまたがって、以前に 登録した認証器へのアクセスをユーザに提供するため、明示的に鍵の複製を促進する。NISTがSP 800-63B-4の初期公開草案(ipd)からこの制限を削除したことで、この現実が認識された。本文書の発行時点で、5.1.8.1 項の上記の記述は、本補足により置き換えられ、本補足に規定される要件に基 づいて導入される同期可能な認証器は、AAL2 で想定される脅威から保護するのに十分であるとみなされるものとする。


そうです、元々のSP 800-63Bでは秘密鍵のクローニングを制限していたわけです。今回の更新でこの点について緩和が行われたわけです。

ただ、そのために満たすべき要件を以下の通り定義しています。

同期可能な認証器のすべての使用に関する一般要件:

  • すべての鍵は、承認された暗号技術を用いて生成されなければならない。
  • デバイスからクローンまたはエクスポートされた秘密鍵は、暗号化された形式でのみ保存されるものとする。
  • すべての認証トランザクションは、デバイス上で生成された、または同期ファブリック(クラウドストレージ など)から復元された暗号鍵を使用して、ローカル・デバイス上で秘密鍵操作を実行しなければならな い。
  • クラウドベースのアカウントに保存された秘密鍵は、認証されたユーザのみがシンクファブリック内の秘密鍵にアクセスできるよう、アクセス制御メカニズムによって保護されなければならない。
  • 同期ファブリック内の秘密鍵へのユーザ・アクセスは、同期された鍵を使用する認証プロトコルの完全性を保持するために、AAL2相当のMFAによって保護されなければならない。
  • これらの一般的要件および同期可能な認証器の使用に関するその他の機関固有の要件は、文書化し、公開ウェブサイトおよびデジタル・サービス・ポリシー(該当する場合)を含め、周知されるも のとする。

ちゃんと認定された暗号技術を使うこと、同期された鍵を使って認証に必要な操作を行う場合はローカルで操作を行うこと(要するにリモート署名なんかはNGってことですね)、秘密鍵へのアクセス制御を行うこと、具体的にはAAL2相当の認証強度で保護されていること、同期可能な認証器を使っていることをポリシーとして公開・周知すること、が記載されています。要は、同期してもいいけどちゃんと認められた方法で管理し、その旨を周知せよ、ということですね。

また、追加要件として以下のについても定義されています。 

連邦企業が同期可能な認証器を使用するための追加要件: 

  • 連邦企業の秘密鍵(すなわち、連邦鍵)は、FISMA Moderateの保護または同等の保護を達成した同期ファブリックに保管しなければならない。
  • 連邦企業の秘密鍵を含む認証器を生成、保管、同期するデバイス(携帯電話、ノート型パソコン、タブレットなど)は、モバイル・デバイス管理ソフトウェアまたはその他のデバイス・コンフィギュレーショ ン・コントロールによって保護され、権限のないデバイスまたは同期ファブリックへの鍵の同期または共有を防止しなければならない。
  • 同期ファブリックへのアクセスは、省庁が管理するアカウント(例えば、中央アイデンティティ・アクセス管理ソリューションまたはプラットフォーム・ベースの管理アカウント)によって制御され、 秘密鍵のライフ・サイクルに対する企業管理を維持するものとする。
  • 秘密鍵を生成する認証器は、認証器の能力およびソースを検証するために使用できる認証機能(例えば、エンタープライズ認証)をサポートすべきである(SHOULD)。

これらの管理は、特に同期をサポートし、FIPS 140 の検証を含む、既存の多要素ソフトウ ェア暗号認証の要件および AAL2 の要件に追加するものとみなされるものとする。

秘密鍵の同期に使うファブリック(要するにクラウドストレージやiCloudやGoogle Platformなど)の保護レベルはFISMA(米国連邦政府のセキュリティ基準)のModerate(平均レベル)もしくは同等が求められています。

また、同期ファブリックへのアクセス制御についてはIAMなどによりしっかり管理されている必要がある、ということなので共有パスワードグループはこの辺りに引っかかるんじゃないかな、、と思います。多分、企業などでiOSやmacOSを使う場合はMDMなどで共有パスワードグループを制御する(できるかどうかは知りませんが)ことが必要になりそうです。



2024年5月6日月曜日

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

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

引き続きNIST SP800-63-3の追補版を見ていきます。


前回はイントロ、文書の目的について読みましたが今回はAAL2の要件と同期可能な認証器の関係性について見ていきます。

では早速。

Syncable Authenticators Achieve AAL2

NIST の認証機関保証レベルは、主に、認証プロセスに対する特定の脅威から保護する認証機 関の能力を中心に構成されている。AAL2 では、ユーザが 2 つの 1 要素認証子、またはユーザ・アカウントにバインドされた多要素 認証子を所持しているという高い信頼性を提供することが意図されている。表 1 は、SP800-63-3 から要求される脅威の緩和と、適切に構成された同期可能な認証子がこれらの 脅威からどのように保護されるかを示している。

SP 800-63-3 による必要な脅威の緩和(表 4-1) 

要求事項AAL2同期可能な認証器(パスキーなど)
Man in the Middleに対する耐性必須達成
適切に構成された同期可能な認証器は、認証され保護されたチャネルによって、すべての認証デー タを交換する。
Verifierに関するなりすまし耐性必須ではない達成
適切に設定された同期可能な認証器は、一意の公開鍵または秘密鍵のペアを作成し、そのペアの使用は、作成されたドメインに限定される(つまり、鍵は特定のウェブサイトまたはRelying Partyでのみ使用できる)。これにより、改ざんされたウェブ・ページが認証子の出力をキャプチャして再利用することを防ぐことができる。
Verifierに関する侵害耐性必須ではない達成
適切に設定された同期可能な認証器は、検証者側にのみ公開鍵を保存する。これらの鍵は、ユーザ認証には使用できない。同期ファブリックによって保存される秘密鍵は、承認された暗号化技術を使用して暗号化された形でのみ保存される。アクセス制御により、認証されたユーザー以外が保存された鍵にアクセスすることはできない。
リプレイ耐性必須達成
同期可能な認証器は、各認証トランザクションに組み込まれたランダムなノンスを使用する ことで、リプレイ耐性(すなわち、将来のトランザクションでの再利用防止)を防ぐ。
認証の意図推奨達成
同期可能な認証器は、暗号化認証プロトコルを開始するために、ユーザがアクティ ベーション・シークレットを入力することを要求する。これは、ユーザの積極的な参加なしにはイベントが進行しないため、認証の意図として機能する。

セクション5では、同期可能な認証器の設定に関する追加的な考慮事項について論じる。

AAL2 要件を満たすために、同期可能な認証器は、ローカルに保存された鍵をアンロックするた めにローカル認証イベントを利用しなければならない[SHALL]。あるいは、ローカル認証の仕組みが 利用できない場合は、別の認証手段(たとえば、ユーザが選択したパスワード)と併用しなければ ならない[SHALL]。FIDO2 Web認証(WebAuthn)コンテキストでは、W3C Web認証仕様の認証子データで利用可能な User Verificationフラグの値によって示される。FIDO2 WebAuthn 認証データフラグの詳細については、セクション5を参照のこと。

ポイントは最後の一文で、やはり同期クレデンシャル「だけ」ではダメで、ちゃんとローカル認証イベント(たとえば端末アンロックの利用など)を使う必要がある、ということに触れたところでしょうか。

次回も引き続き読んでいきたいと思います。


2024年5月5日日曜日

DIFのClaims & Credentials WGの新しいワーキングアイテムに関するWebinarがあります

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

またまた日本時間だと辛い時間帯ではありますが、DIF(Decentralized Identity Foundation)のClaims and Credentialsワーキンググループの新しいワーキングアイテムである、
  • Reusable KYC credentials
  • Age Verification
  • Proof of Humanity
の互換性に関する取り組みのWebinarが日本時間5/15 1am-2amで開催されます。
(申込ページより)

申込ページ


KYCクレデンシャルの応用や年齢確認、(AgentやIoTデバイスなどではなく)人間が操作していることの証明など、あちこちで議論はされていますので、どこの動きを集中的にウォッチすべきか迷う部分はあると思いますし、ともすると車輪の再発明になるので注意は必要ですが、動向は追いかけておいても良いと思います。いずれ日本においても議論しなければならない話ばかりだと思いますので。


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を登録してあげる必要があります。
くわしくはこちらから。




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