# Keeperの暗号化とセキュリティのモデル
## ゼロ知識・ゼロトラストのアーキテクチャ Keeperはゼロ知識セキュリティプロバイダです。ゼロ知識とは、最高レベルのセキュリティとプライバシーを保証するシステムアーキテクチャであり、データの暗号化および復号は常にユーザーのデバイス上でローカルに実行されます。 {% embed url="" %} Keeperの暗号化モデルは、次の構造に準拠しています。 1. 各ボルトレコードは、クライアント側で生成された専用の256ビットAES鍵 (GCMモード) で暗号化されます。 2. レコードが共有フォルダに含まれている場合、そのレコード専用の鍵は、共有フォルダ鍵 (256ビットAES鍵) でラップされます。 3. ボルトユーザーの場合、レコード鍵とフォルダ鍵は、データ鍵 (256ビットAES) で暗号化されます。 4. シークレットマネージャーユーザーの場合、レコード鍵とフォルダ鍵は、アプリケーション鍵 (256ビットAES) で暗号化されます。 5. マスターパスワードでログインするユーザーの場合、データの暗号化・復号に必要な鍵は、マスターパスワードから導出されます。 6. SSOやパスワードレス技術でログインするユーザーの場合、楕円曲線暗号 (ECC) を用いて、デバイスレベルでデータの暗号化・復号が行われます。 7. Keeperサーバーに送信されるすべての暗号化済みペイロードは、TLSに加え、256ビットAESの伝送鍵でラップされており、中間者攻撃 (MITM) に対する防御が強化されています。伝送鍵はクライアントデバイス上で生成され、サーバーの公開EC鍵を使用したECIES暗号でサーバーに転送されます。 8. 2026年第1四半期より、Keeperでは送信キーに対する追加の暗号化レイヤーとして、量子耐性暗号 (QRC) の段階的な展開を開始しています。 9. ユーザー間のシークレット共有には、鍵の安全な配布のために楕円曲線暗号(ECC)が使用されます。 10. 多層の暗号化により、ユーザー、グループ、管理者レベルでの厳格なアクセス制御が実現しています。 データは、Keeperのクラウドセキュリティボルトに送信・保存される前に、ユーザーのデバイス上でローカルに暗号化されます。別のデバイスと同期される際も、データは常に暗号化されたままで、復号は受信側のデバイスでのみ行われます。 Keeperは、世界で最も安全で、認証・検証・監査が徹底されたパスワードセキュリティプラットフォームです。業界で最も長期間にわたってSOC 2およびISO認証を維持しており、ISO 27001、27017、27018を取得済みです。また、KeeperはGDPR、CCPA、HIPAAへの準拠に加え、FedRAMP HighおよびStateRAMPの認可を受けており、PCI DSSおよびTrustArcによるプライバシー認証も取得しています。 Keeperは、米国商務省が定めたEU-U.S.データプライバシーフレームワーク (EU-U.S. DPF)、EU-U.S. DPFに対する英国拡張、ならびにスイス-U.S.データプライバシーフレームワーク (Swiss-U.S. DPF) に準拠しています。Keeperは業界最高レベルの暗号化技術を実装するだけでなく、厳格な内部運用基準も遵守しており、これらは継続的に第三者による監査を受けています。これにより、セキュアなソフトウェアの開発と、世界で最も安全なサイバーセキュリティプラットフォームの提供を継続的に実現しています。 ## データプライバシー KeeperはGDPR（一般データ保護規則）に準拠しており、欧州連合（EU）のお客様に対して継続的にコンプライアンスを維持できるよう、業務プロセスおよび製品の改善に取り組んでいます。 Keeperのプライバシーポリシーは、[こちらのウェブページ](https://www.keepersecurity.com/privacypolicy.html)でご確認いただけます。 また、Keeperのデスクトップアプリケーション、ウェブアプリケーション、モバイルアプリケーションには、トラッカーや第三者による追跡を行うライブラリは一切含まれていません。KeeperのAndroidアプリにトラッカーがインストールされていないことは、[こちらのリンク](https://reports.exodus-privacy.eu.org/en/reports/com.callpod.android_apps.keeper/latest/)から確認できます。 ## データ分離 Keeperは完全な SaaS 型プラットフォームであり、現在以下の Amazon AWS データセンターでデータをホスティングしています。お客様は希望するリージョンを選択して Keeper テナントをホスティングすることができます。お客様のデータ (暗号化されたデータ) およびプラットフォームへのアクセスは、指定されたリージョンに限定され、分離されています。 #### 使用可能なリージョン (地域) * 米国 (US) * 米国政府クラウド (US\_GOV) * 欧州 (EU) * 豪州 (AU) * 日本 (JP) * カナダ (CA) ## **FIPS 140-3の検証** Keeper Securityの暗号化モジュールは、FIPS 140-3認証 (証明書番号#4976) を取得しており (2029年7月29日まで有効)、米国連邦政府および国防総省 (DoD) の暗号要件を満たしています。FIPS 140-3は、ISO 19790で定義されたセキュリティ標準とも整合しており、国際的な暗号規格との一貫性を確保しています。 以下のリンクから、NIST CMVP証明書#4976をご覧ください。 {% embed url="" %} ## **FedRAMP Highの認定取得** Keeper SecurityのGovernment Cloudパスワードマネージャーおよび特権アクセス管理は、AWS GovCloud (US) 上にホストされ、FedRAMPのHighインパクトレベルで認可されたプロバイダです。Keeper Securityは[FedRAMPマーケットプレイス](https://marketplace.fedramp.gov/products/FR2116544598A?cache=true)に掲載されています。 FedRAMP (連邦リスクおよび認可管理プログラム) は、クラウド製品およびサービスに対するセキュリティ評価、認可、および継続的な監視に関して、標準化されたアプローチを提供する米国連邦政府のプログラムです。FedRAMPは政府機関がセキュリティと連邦情報の保護に重点を置きながら、最新のクラウド技術を活用できるよう支援し、安全なクラウドソリューションの導入を加速します。 FedRAMPの詳細については、[こちらのウェブサイト](https://www.gsa.gov/technology/government-it-initiatives/fedramp)をご覧ください。 ### ITAR準拠 KSGCは、米国の国際武器取引規則 (ITAR) への準拠をサポートしています。ITARの輸出規制の対象となる企業は、保護対象データへのアクセスを米国市民のみに制限し、データの物理的な保存場所も米国内に限定することで、意図しない輸出を防ぐ必要があります。 KSGCのFedRAMP High環境は、以下の点でITAR要件をサポートしています。 * 米国国内に限定されたAWS GovCloud上での完全準拠なデータ保存 * 転送中および保存中のデータの安全な暗号化 * ゼロ知識およびゼロトラストのセキュリティ設計と細かな権限設定により、承認された人員のみが機密データへアクセス可能 * すべての操作と入力されたデータの追跡可能な電子監査証跡を提供する高度なコンプライアンスレポート機能 * 輸出管理対象およびITAR管理データの安全な取り扱いに特化して訓練された、米国籍の専任カスタマーサクセスチーム * 米国外からのサポートなし KeeperのFedRAMP環境は、独立した第三者評価機関 (3PAO) による監査を受けており、顧客の輸出コンプライアンスプログラムをサポートするために適切な管理体制が整っていることが検証されています。 ITARの詳細については、[こちらのウェブサイト](https://app.gitbook.com/o/-LO5CAzoigGmCWBUbw9z/s/Z7s6LQJaKa1G17O787JG/)をご覧ください。 ## エンドツーエンド暗号化 (E2EE) Keeperのプラットフォームは、すべてのデバイスおよびエンドポイントにわたってエンドツーエンド暗号化 (E2EE) で構築されています。この技術アーキテクチャドキュメントに記載されている通り： * プラットフォームに保存されるデータはローカルで暗号化され、ユーザーのデバイス間で転送中に暗号化されます。 * Keeperユーザー間で交換される情報は、ボルト間で暗号化されます。 * 静止データは、レコードレベルでAES-256暗号化を使用して複数のレイヤーで暗号化されます。 * 転送中のデータはTLSと追加の転送暗号化レイヤーで暗号化され、MITM攻撃、サービスプロバイダー、不信なネットワークからのアクセスを防ぎます。 ## レコードレベルの暗号化
Keeperは、クライアント側で生成される鍵に基づく多層暗号化システムを採用しています。レコードレベルキーとフォルダレベルキーはローカルデバイス上で生成され、各ボルトレコード(例: パスワード)を暗号化します。たとえば、ボルト内に1万件のレコードがある場合、同時に1万個のAESレコードキーによってデータが保護されます。 鍵はゼロ知識を維持するため、またレコードやフォルダの共有といった高度な機能を実現するために、デバイス上でローカルに生成されます。レコードキーおよびフォルダキーは、データキーやクライアントキーなど、他の鍵によってラップ(暗号化)されます。 {% hint style="success" %} ボルト内のすべてのフィールドとすべてのデータは、添付ファイルを含めて暗号化されています。 {% endhint %} **マスターパスワードでログインするユーザーの場合** マスターパスワードキーは、マスターパスワードからPBKDF2 (100万回の反復) によって導出されます。\ このキーでAES-256データキーのラップを解除し、そのデータキーでAES-256レコードキーおよびフォルダキーのラップを解除します。その後、レコードキーを使用して、ボルト内に保存されているレコード情報を復号します。 **KeeperクラウドSSOコネクトでログインするユーザーの場合** ローカルに保存された楕円曲線 (EC) 鍵ペアが生成され、ユーザーのデータキーの暗号化と復号に使用されます。このデータキーによって、レコードおよびフォルダキーが復号されます。 鍵のラッピングについては、以下の[保存データの暗号化](#dtano)セクションで説明しています。 **KeeperオンプレミスSSOコネクトでログインするユーザーの場合** マスターパスワードハッシュと256ビットAESマスターパスワードキーは、オンプレミスのSSOクラウドアプリケーションによって生成されます。 ## エンタープライズ暗号鍵 ビジネスプランおよびエンタープライズプランの利用者は、ロールベースの適用ポリシー、プロビジョニング、認証、チーム管理など、Keeperプラットフォームのさまざまな機能を管理できます。\ 管理機能は、認可に加えて暗号化によっても保護されています。認可によって管理者がプラットフォーム上の特定の機能にアクセスできる一方、暗号化は指定されたユーザーのみが実際に機能を実行したり、機密情報を閲覧したりできるようにするために多層的に使用されています。 管理機能の多くは、ゼロ知識およびゼロトラストを維持しながら動作するために、鍵の復号を必要とします。たとえば、次のようなケースがあります。 * チームには公開鍵と秘密鍵のペアが存在します。 * ボルト移譲やデバイス承認のロールポリシーでは、公開鍵と秘密鍵のペアが使用されます。 * エンタープライズレベルの鍵ペアは、個々のユーザーから管理者への利用データの共有に使用されます。 * パスワード強度の監査などの機密性の高い利用データは、エンタープライズ公開鍵で暗号化され、管理者のみが復号できます。 Keeperプラットフォーム全体は、ユーザーおよびKeeper管理者が完全に鍵を管理できる「鍵管理プラットフォーム」として位置づけられます。鍵管理の複雑な仕組みは、使いやすいフロントエンドインターフェースによってユーザーから意識せずに利用できるよう設計されています。 ## クラウド認証 Keeperは、最高水準のプライバシー、セキュリティ、信頼性を実現するために設計された高度なクラウド認証およびネットワーク通信モデルを構築しています。認証モデルの主な特徴は次のとおりです。 **・マスターパスワードはネットワーク層を通過しない** 多くのSaaSサービスとは異なり、ログイン認証情報はデバイス外へ送信されません。PBKDF2がローカルデバイス上で実行され、復号に使用される256ビットAESキーが生成されます。さらに、別のPBKDF2キーがローカルで生成され、HMAC\_SHA256でハッシュ化されて認証トークンが導出されます。Keeperのクラウドセキュリティボルトは、ユーザーの復号キーを一切保持していません。 **・クライアントデバイスとKeeperクラウド間の通信は傍受も復号も不可能**\ Keeperは、MITM攻撃 (中間者攻撃) を防ぐため、デバイスとKeeperサーバー間でキー・ピニングおよび転送キーによる追加のネットワークレベル暗号化を実装しています。 **・新しいデバイスはデバイス検証を完了しない限りログイン不可**\ このステップを通過しない限り、アカウントへのログイン試行は行えません。Keeperは、利用されている認証方式に応じて複数のデバイス検証方法をサポートしています。 **・2要素認証 (2FA) はデバイス検証後、マスターパスワード入力前に実施**\ ユーザーが2FAを有効または必須設定にしている場合、このステップを通過しない限りマスターパスワードの入力には進めません。 **・デバイス検証と2FA認証の完了後にのみマスターパスワードを入力可能**\ ユーザーは、デバイス検証および2FA認証を完了しない限り、マスターパスワード入力ステップに進むことはできません。この高度な認証フローによって、総当たり攻撃、パスワードスプレー攻撃、列挙攻撃、中間者攻撃など、さまざまな攻撃手法に対して強力な防御が実現されています。 ## 認証方式 Keeperでは、プラットフォームの認証に複数の方法を用意しています。 * マスターパスワード * SAML 2.0を使用したSSO (オンプレミス) * SAML 2.0を使用したSSO (クラウド) * SSO代替マスターパスワード * 生体認証 ### デバイスの承認 ユーザーは、デバイスの承認と確認の手順を踏まないと、アカウントへのログインを試行できません。 マスターパスワードでログインする利用者の場合、デバイス検証は次のいずれかの方法で実行できます。 * メールで送信される確認コードの入力 * TOTPまたはSMSによる2要素認証 (2FA) コードの入力 * 登録済みデバイスへのKeeper Push™メッセージ送信 KeeperクラウドSSOコネクトを利用して認証を行う利用者の場合、デバイス承認ではキー転送が実施されます。この処理では、ユーザーの暗号化されたデータキーがデバイスに送信され、楕円曲線 (EC) 秘密鍵を使用してローカルで復号されます。デバイス承認の方法には次のものがあります。 * 既存のユーザーデバイスへのKeeper Push (プッシュ通知を使用) * Keeper管理コンソールからの管理者承認 * [Keeperオートメーターサービス](https://app.gitbook.com/s/-Mfd2v-YT48Ljtykb8qm/device-approvals/automator)による自動承認 * [コマンダーCLI](https://app.gitbook.com/s/-Mfd2v-YT48Ljtykb8qm/device-approvals/commander-cli)による自動管理者承認 * Azure Functionによる自動管理者承認 デバイス承認の詳細については、[こちらのリンク](#debaisu)をご参照ください。 ### 2要素認証 2要素認証 (2FA) は、個人アカウントおよび法人アカウントのどちらにも追加できます。法人のお客様の場合、さまざまな制御レベルやセキュリティオプションを使用して、2FAの利用を強制できます。 KeeperバックエンドAPIのバージョン3 (Keeperクライアントアプリケーションのバージョン15以降に対応) からは、2FAステップがマスターパスワード入力の前に実行されるようになりました。マスターパスワード入力の前にデバイス検証および2FAを実行することで、総当たり攻撃、パスワードテスト、アカウント列挙など、複数の攻撃ベクトルを軽減できます。 ### マスターパスワード ユーザーのボルトレコードは、デバイス上でランダムに生成される256ビットAES-GCMの「レコードキー」によってローカルで暗号化されます。このレコードキーは、同じくユーザーのデバイス上でランダムに生成され、各ユーザーに固有の256ビットAES-GCMの「データキー」で暗号化されます。マスターパスワードでログインするユーザーの場合、データキーはユーザーのマスターパスワードから導出された鍵で暗号化されます。この導出には、128ビットのランダムソルトと100万回の反復を使用したPBKDF2-HMAC-SHA256が用いられます。暗号化されたボルトの暗号文はKeeperクラウドに保存されます。 認証の際には、別のPBKDF2鍵がユーザーのデバイス上でローカルに生成されます。これも128ビットのランダムソルトと100万回の反復を使用し、生成された鍵はSHA256でハッシュ化され、認証トークンが導出されます。Keeperクラウド上では、この認証トークンが「ユーザー認証キー」でさらに暗号化(スーパー暗号化)されます。ユーザー認証キーはサーバーによってランダムに生成され、保存前にハードウェアセキュリティモジュール (HSM) 内で非エクスポート可能な鍵を使用して暗号化されます。このユーザー認証キーは、ソルト、認証トークン、ユーザーの暗号化されたデータキー、その他の生体認証などの代替認証方式に関連するフィールドを暗号化するために使用されます。 ### クラウドSSO (SAML 2.0) KeeperのクラウドSSO機能は、SAML 2.0に準拠したアイデンティティプロバイダによる認証を行いながら、ユーザーのボルトに対するゼロ知識暗号化を完全に維持します。デバイス上で楕円曲線 (secp256r1) の秘密鍵ペアが生成されます。ユーザーのデータキーはデバイスの秘密鍵で復号され、指定されたアイデンティティプロバイダーによる認証が成功すると、暗号化されたデータキーがユーザーに渡されます。 ### オンプレミスSSO (SAML 2.0) SAML 2.0アイデンティティプロバイダを使用してKeeperに認証するユーザーの場合、Keeper SSO Connectソフトウェアは顧客の環境内にホストされます。SSOコネクトソフトウェアはユーザーのマスターパスワードを生成および管理します。生成されたマスターパスワードはPBKDF2で処理され、データキーなど、ユーザーの他の鍵を復号するための鍵が導出されます。 ### SSO代替マスターパスワード 通常、エンタープライズSSOログイン (SAML 2.0) を使用してKeeperボルトにログインしているユーザーは、「代替マスターパスワード」を使用してKeeperウェブボルト、ブラウザ拡張機能、Keeperコマンダーにもログインできます。この機能を利用するには、Keeper管理者がロールポリシーで有効化し、ユーザーが自身で設定する必要があります。この機能が有効化されている場合、SSOを利用しているユーザーでもマスターパスワードを使用してオフラインアクセスを行うことができます。 この機能は次のような理由で有用です。 * オフラインモードでボルトにログインする必要がある場合 * SSOアイデンティティプロバイダーが利用できない場合の代替ログイン手段 * Keeper Commander CLI (コマンドラインインターフェイス) 経由での認証 代替マスターパスワードから鍵を導出する際にはPBKDF2が使用されます。鍵のハッシュ値が認証に使用され、導出された鍵はユーザーのデバイス上でローカルにデータキーを復号します。SSOマスターパスワードの詳細については、[こちらのページ](https://docs.keeper.io/jp/enterprise-guide/roles/enforcement-policies)をご参照ください。 ### 生体認証 Keeperは、Windows Hello、Touch ID、Face ID、Androidの生体認証に対応しています。通常、マスターパスワードまたはエンタープライズSSOログイン (SAML 2.0) を使用してKeeperボルトにログインしているユーザーも、生体認証でデバイスにログインできます。生体認証は、Keeper管理者がロールポリシーで有効化する必要があります。この機能を有効化すると、マスターパスワードユーザーおよびSSOユーザーの両方が、生体認証によるオフラインアクセスを利用できます。 デバイスで生体認証ログインを有効にすると、ランダムに生成された鍵がローカルで作成され、デバイスのセキュアエンクレーブ (例: KeychainやKeystore) に保存されます。\ ユーザーのデータキーはこの生体認証キーで暗号化されます。\ 生体認証が成功すると、鍵が取得され、ボルトを復号できるようになります。 Keeperはユーザーの生体認証データを保存したり処理したりしません。OSの生体認証機能と連携し、ユーザーの認証とセキュアエンクレーブで保護された暗号鍵の取得を行います。 ### パスキーによる生体認証ログイン Keeperのパスキー認証は、FIDO2 WebAuthn標準とデバイスに紐づく認証情報を利用し、フィッシング耐性のある暗号的に安全なログインを実現します。パスキーを作成すると、固有の鍵ペアが生成され、デバイス上に安全に保存されます。この鍵は、デバイスの生体認証またはPINによるローカル認証で保護されます。 ログイン時には、Keeperがチャレンジレスポンス方式の認証を使用し、秘密情報をネットワーク上に送信することなくユーザーを検証します。秘密鍵はデバイス外に出ることがなく、認証にはデバイスの所持と生体認証の両方が必要となるため、パスキーによるログインは第一要素認証と第二要素認証の両方の要件を満たします。 この仕組みにより、パスワードやワンタイムコードへの依存を排除し、認証情報を狙った攻撃のリスクを大幅に低減しながら、Keeperのゼロ知識暗号化アーキテクチャを維持します。 ## 保存データの暗号化 #### ユーザーの新規作成 * パスワードを使用した認証では、ユーザーがアカウントプロファイルを作成する際に「マスターパスワード」を設定する必要があります。また、FIDO2 WebAuthn、TOTP、Duo Security、RSA SecurID、SMS、またはスマートウォッチを使用して、第二要素認証を構成することもできます。
* ユーザーがKeeperクラウドSSOコネクト経由で認証される場合、256ビット楕円曲線 (EC secp256r1) の秘密鍵が各デバイス上で生成され、ローカルに保存されます。このECデバイス秘密鍵はAES-256データキーの復号に使用され、データキーがユーザーのボルト内のレコードキーおよびフォルダキーを復号します。この暗号化モデルでは、マスターパスワードは使用されません。
* ユーザーがKeeperオンプレミスSSOコネクト (SAML 2.0 IDプロバイダとの統合) 経由で認証される場合、マスターパスワードとAES-256キーはSSOコネクトソフトウェア (オンプレミスでエンタープライズ顧客によってホストされ、運営されている) によって自動生成されます。
* ECデバイス秘密鍵は、ボルトデータの暗号化や復号に直接使用されることはありません。アイデンティティプロバイダでの認証が成功すると、保存されない別の一時キーが使用されてボルトデータの復号が行われます。そのため、ローカルのデバイス秘密鍵をオフラインで抽出しても、ユーザーのボルトを復号することはできません。
* マスターパスワードは、クライアントデバイス上で100万回の反復を行うPBKDF2 (Password Based Key Derivation Function) によって暗号鍵を導出するために使用されます。
* クライアントデバイス上では、256ビットAESの「データキー」と「クライアントキー」、ユーザー間・チーム間でレコードを共有するためのEC公開鍵/秘密鍵ペアが生成されます (互換性維持のため、従来の共有レコード向けに2048ビットRSA公開鍵/秘密鍵ペアも生成されます。) ![新規ユーザー登録暗号化モデル](https://3468650114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeJwa6ByNJ2qindnPknCW%2Fuploads%2Fkpb1TS9vbl61Hbqkl9hr%2FNew%20user%20creation%20encryption%20model.png?alt=media\&token=b803c67e-8384-4452-9d29-8b6f712e9fc9) #### データストレージ * 「データキー」は、ボルトに同期されるデータの暗号化に使用されます。マスターパスワード使用の認証の場合、「データキー」はマスターパスワードからPBKDF2 (100万回の反復) によって導出される「マスターパスワードキー」で暗号化されます。この暗号文はさらに多重暗号化 (スーパー暗号化) され、クラウドセキュリティボルトに保存されます。クラウドSSO使用の認証の場合、ローカルデバイス上のEC (secp256r1) 秘密鍵によってデータキーが復号されます。データキーは、ユーザーのボルト内にある暗号化済みレコードキーを復号します。
* 「クライアントキー」は、ユーザーのデバイス上にローカル保存されるデータの暗号化に使用されます。「クライアントキー」は「データキー」で暗号化され、その暗号文がクラウドセキュリティボルトに保存されます。マスターパスワード使用の認証では、「クライアントキー」は「マスターパスワードキー」でも暗号化され、この暗号文がオフライン利用のためにデバイス上に保存されます。オフラインモードの利用可否は、エンタープライズ管理者が[強制適用ポリシー](https://docs.keeper.io/jp/enterprise-guide/roles/enforcement-policies)を通して管理できます。
* オフラインで保存されるボルトデータは、256ビットの「クライアントキー」でAES-GCM暗号化されています。このクライアントキーはランダムに生成され、128ビットのランダムソルトと100万回の反復を使用したPBKDF2-HMAC-SHA512によって保護されます。ソルトと反復回数はローカルに保存されます。ユーザーがマスターパスワードを入力すると、そのソルトと反復回数を用いて鍵が導出され、クライアントキーの復号が試みられます。復号されたクライアントキーによって、保存されたレコードキャッシュが復号されます。
* 「デバイスEC公開鍵」はボルトに直接格納されます。
* 「デバイスEC秘密鍵」はデバイス上にローカルに保存され、デバイスの外に出ることはありません。これはクラウドSSO認証モデルに使用されます。
* 「ユーザーEC公開鍵」は、ボルトに直接保存されます。
* 「ユーザーEC秘密鍵」は「データキー」で暗号化され、暗号文はボルトに保存されます。
* 各レコード (例: ウェブサイトのパスワードやファイル) が作成されるたびに、256ビットAESの「レコードキー」がクライアントデバイス上で生成されます。「レコードキー」は、レコードの内容を暗号化および復号するために使用されます。この「レコードキー」はユーザーの「データキー」で暗号化され、その暗号文がボルトに保存されます。また、「レコードキー」とレコードデータは「クライアントキー」でも暗号化され、その暗号文がデバイス上にローカル保存されます。 #### マスターパスワードでログイン * ユーザーが (マスターパスワードで) デバイスにログインすると、最初にマスターパスワードから導出された鍵クライアント鍵を復号します。
* クライアント鍵は、デバイス上にローカル保存されているすべてのデータの復号に使用されます。
* 認証が成功すると、ローカルでラップ解除された、またはクラウドセキュリティボルトから取得されたデータキーが、ユーザーのマスターパスワードから導出された鍵で復号されます。
* レコードキーの暗号文はボルトから同期され、ユーザーのデータキーでローカル復号されます。\ 共有フォルダキーは、それぞれのフォルダに対応する共有フォルダキーで復号されます。レコードの内容は、それぞれのレコードに対応するレコードキーで復号されます。その後、レコードキーおよびレコード内容はクライアントキーで暗号化され、ローカルに保存されます。

マスターパスワードと生体認証暗号化モデル

## 共有 * Keeperレコードを他のユーザーと共有する際、Keeperはまず、共有先ユーザーの楕円曲線公開鍵をクラウドセキュリティボルトから取得します。 * 各レコードのレコードキーは、共有先ユーザーの楕円曲線公開鍵で暗号化され、クラウドセキュリティボルトを介してそのユーザーのKeeperボルトに同期されます。 * 暗号化された共有レコードを受け取ったユーザーは、自身の楕円曲線秘密鍵を使用してレコードキーを復号します。最適化のため、このレコードキーはユーザーのデータキーで再暗号化され、その暗号文が共有先ユーザーのクラウドセキュリティボルトに保存されます。 * 以降のレコード取得時には、共有先ユーザーがデータキーを使用してレコードキーを復号し、その後、レコードキーを用いてレコードの内容を復号します。 * なお、Keeperの従来の「一般」レコードタイプとの互換性を維持するため、2048ビットのRSA公開鍵および秘密鍵のキーペアも併用されています。

レコード共有暗号化モデル

## 乱数生成器 Keeperクライアントデバイスにおけるすべての暗号処理では、安全な乱数生成器を使用します。例えば、Keeperウェブボルトやブラウザ拡張機能のようなウェブベースのアプリケーションでは、Web Crypto APIの[getRandomValues](https://developer.mozilla.org/ja/docs/Web/API/Crypto/getRandomValues)メソッドが使用されます。iOSでは[SecRandomCopyBytes](https://developer.apple.com/documentation/security/1399291-secrandomcopybytes)メソッドが、Androidでは[SecureRandom](https://developer.android.com/reference/java/security/SecureRandom)が使用されます。 ## 通信時の暗号化 Keeperのクラウドセキュリティボルトは、クライアントデバイスによる認可を通じて検証されるAPIによって保護されています。クライアントはログイン時にセッショントークンを取得し、各API呼び出し時にそのトークンを送信します。セッショントークンはサーバー側で管理されます。ログインは、マスターパスワード、セッションの再開、またはSAML 2.0 SSO認証によって行われます。 マスターパスワードを使用する場合、クライアントデバイスは、128ビットのランダムソルトと1,000,000回の反復を用いたPBKDF2-HMAC-SHA256により、256ビットの「認証キー」を導出します。次に、この認証キーをSHA-256でハッシュ化して「認証ハッシュ」を生成します。ログイン時には、この認証ハッシュがクラウドセキュリティボルトに保存されている認証ハッシュと照合されます。ログイン後、サーバー側でセッショントークンが生成され、以降のAPIリクエストでクライアントデバイスが使用できるよう、クライアントに送信されます。クライアントとサーバー間の通信を継続するには、セッションが有効である必要があります。 KSIは、クライアントアプリケーションとKSIのクラウドベースストレージ間で送受信されるすべてのデータを暗号化するため、256ビットおよび128ビットのTLS (1.3および1.2) をサポートしています。 KSIでは、商用認証局が現在提供している中で最も安全な署名アルゴリズムであるSHA2アルゴリズムを使用し、DigiCertによって署名されたTLS証明書を展開しています。SHA2は、アルゴリズム上の数学的な弱点が指摘されているSHA1と比較して大幅に安全性が高く、攻撃者がウェブサイトになりすますために使用する可能性のある偽造証明書の発行を防ぐのに役立ちます。 またKSIは、認証局によって署名された証明書の公開監査可能な記録を作成する、Googleによる新しい取り組みである証明書透過性 (Certificate Transparency、CT) もサポートしています。CTは、権限のない主体による証明書の発行を防止するのに役立ちます。CTは現在、Chromeウェブブラウザーの最新バージョンでサポートされています。証明書透過性の詳細については、[こちらのページ](http://www.certificate-transparency.org/)をご参照ください。 Keeperは、以下のTLS暗号スイートをサポートしています (2023年10月時点、AWSのセキュリティポリシー `ELBSecurityPolicy-TLS13-1-2-2021-06` を使用)。 * TLS\_AES\_128\_GCM\_SHA256 * TLS\_AES\_256\_GCM\_SHA384 * TLS\_CHACHA20\_POLY1305\_SHA256 * ECDHE-ECDSA-AES128-GCM-SHA256 * ECDHE-RSA-AES128-GCM-SHA256 * ECDHE-ECDSA-AES128-SHA256 * ECDHE-RSA-AES128-SHA256 * ECDHE-ECDSA-AES256-GCM-SHA384 * ECDHE-RSA-AES256-GCM-SHA384 * ECDHE-ECDSA-AES256-SHA384 * ECDHE-RSA-AES256-SHA384 Keeperクライアントデバイスでは、偽造されたデジタル証明書を用いた攻撃者によるなりすましを防止するためのセキュリティ機構であるキー・ピンニングも実装されています。 ### **2要素認証** ![](https://3468650114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeJwa6ByNJ2qindnPknCW%2Fuploads%2FyncuwncF0p1wJ1aXRBHC%2Fassets_-Mg7WhSIocH_4bp1BfeA_-Mk39EFEjJCuEyuf2u_D_-Mk3Ca73L0LDRz5QL3gR_4_Authenticatiors.webp?alt=media\&token=ba0ca8a0-3b14-4039-816c-fd9c2390830b) ユーザーのアカウントへの不正アクセスを防止するため、Keeperでは2要素認証も利用できます。2要素認証とは、知識要素、所持要素、生体要素という3つの認証要素のうち、2つ以上を組み合わせて本人確認を行う認証方式です。知識要素は「知っているもの」、所持要素は「持っているもの」、生体要素は「本人そのもの」を指します。2要素認証について、詳しくはこちらの[リンク](https://ja.wikipedia.org/wiki/%E5%A4%9A%E8%A6%81%E7%B4%A0%E8%AA%8D%E8%A8%BC)をご参照ください。\ \ Keeperでは、「知っているもの」(パスワード) と「持っているもの」(手元の電話) を組み合わせることで、マスターパスワードやデバイスが侵害された場合でも、セキュリティを強化します。この仕組みとして、[TOTP](http://tools.ietf.org/html/rfc6238) (時間ベースのワンタイムパスワード) を生成します。\ \ Keeperは、暗号学的に安全な乱数生成器を使用して10バイトのシークレットキーを生成します。このコードは約1分間有効で、SMS、Duo Security、RSA SecurID、TOTPアプリケーション、Google Authenticator、またはKeeper DNA対応のウェアラブルデバイスを通じてユーザーに通知されます。\ \ モバイルデバイスでGoogle認証システムやTOTPアプリケーションを使用する場合、Keeperサーバーは内部的にシークレットキーを含むQRコードを生成します。このシークレットキーが第三者に共有されることはありません。2要素認証を無効化して再度有効化するたびに、新しいシークレットキーが生成されます。 2要素認証を有効にするには、[Keeperウェブアプリ](https://keepersecurity.com/vault/)、デスクトップアプリ、モバイルアプリのいずれかの設定画面にアクセスしてください。ビジネスのお客様は、Keeper管理コンソールのロールポリシーを使用して、2要素認証および対応する2要素認証方式の使用を必須に設定することも可能です。 ### パスキーとFIDO2 WebAuthnセキュリティキー ![](https://3468650114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeJwa6ByNJ2qindnPknCW%2Fuploads%2FTaok364y8Vs8NNRdqcYe%2Fassets_-Mg7WhSIocH_4bp1BfeA_-Mk39EFEjJCuEyuf2u_D_-Mk3Clg_cXo53y6YBIzE_5_Keys.webp?alt=media\&token=e330ecca-3f98-4b72-bf52-4e0f0fe0be37) Keeperは、2要素認証の第2要素として、**パスキー**およびFIDO2互換のWebAuthnセキュリティキー (YubiKeyやGoogle Titanキーなど) をサポートしています。セキュリティキーを使用すると、6桁のコードを手入力することなく、簡単かつ安全に2要素認証を行えます。 ユーザーのボルトには、複数のセキュリティキーを設定できます。セキュリティキーに対応していないプラットフォームでは、あらかじめ設定されている他の2要素認証方式を利用できます。 セキュリティキーやその他の2要素認証方式を構成するには、Keeperアプリケーションの **\[設定]** 画面にアクセスしてください。 ## BreachWatch Keeperでは、Amazon AWS上で稼働するBreachWatch (ブリーチウォッチ) という自己完結型のマネージドサービスアーキテクチャを運用しています。BreachWatchは、KeeperのバックエンドAPIおよびユーザーの保存データとは物理的に分離された環境で構成されています。 BreachWatchサーバーでは、物理的なハードウェアセキュリティモジュール (HSM) を用いて、ダークウェブ上のデータ侵害から収集された数十億件規模の一意なパスワードを処理、ハッシュ化、保存しています。これらのパスワードは、HMAC\_SHA512 ハッシュ方式を使用し、エクスポート不可能なキーによってHSM内でハッシュ化されます。 エンドユーザーのクライアントデバイスでは、BreachWatchを有効にすると、保存されている各パスワードから HMAC\_SHA512 ハッシュが生成され、サーバーに送信されます。サーバー側では、HSMを使用して、エクスポート不可能なキーによる HMAC\_SHA512 ハッシュがさらに生成されます。これらのハッシュ同士を比較することで、パスワードが侵害されているかどうかを判定します。 BreachWatchのバックエンドアーキテクチャは、データ侵害の規模にかかわらず、侵害されたパスワードをユーザーのボルト内に保存されている実際のパスワードと関連付けられないよう設計されています。侵害パスワードの検出に用いられるハッシュ処理では、物理的なHSMを使用することで、ハッシュ化をオンラインでのみ実行可能とし、BreachWatchデータに対する総当たり攻撃のリスクを低減しています。 以下のシステム図は、データフロー、暗号化処理、およびBreachWatchにおけるハッシュ処理のワークフロー全体を示しています。

BreachWatch暗号化モデル

まとめ * パスワードはHMAC\_SHA512を使用して2回ハッシュ化されます。1回目はクライアントデバイス上で「ペッパー」を用いて行われ、2回目はAmazon AWSのCloudHSM上で、エクスポート不可能なキーを使用するハードウェアセキュリティモジュールにより行われます。 * HMAC\_SHA512は、強力なハッシュ関数に加えて秘密鍵 (エクスポート不可) を使用するため、ハッシュ値に対するオフライン攻撃は現実的ではありません。 * メッセージ認証コード (MAC) は、暗号学的ハッシュ関数の結果を用いる方式で、ハッシュ関数の利用範囲を拡張する仕組みです。その結果はメッセージの内容だけでなく、秘密鍵となる第2の入力にも依存します。 ## クラウドSSOコネクトによるSAML 2.0認証 KeeperクラウドSSOコネクトは、完全にクラウド環境で、標準のSAML 2.0プロトコルを使用するサードパーティのアイデンティティプロバイダ (IdP) による認証を通じて、ゼロ知識で暗号化されたボルト内のデータを復号するための仕組みです。 この構成では、ユーザーは自身のSSOアイデンティティプロバイダで認証を行った後、デバイス上でボルトの暗号文をローカルに復号します。各デバイスには、それぞれ固有の楕円曲線 (EC) 公開鍵および秘密鍵のペアと、暗号化されたデータキーが割り当てられます。また、各ユーザーは個別のデータキーを保持します。新しいデバイスでサインインする場合、既存のデバイスによる承認、または権限を持つ管理者による承認が必要となります。 この仕組みでは、Keeperクラウドに保存されている暗号化キーを用いてユーザー自身がボルトを復号しますが、Keeperクラウド側でユーザーのデータキーを復号することはできません。このため、ゼロ知識の原則は維持されます。ユーザーのデータキー (DK) はデバイスの秘密鍵 (DPRIV) によって復号され、デバイスで暗号化されたデータキー (DEDK) は、指定されたアイデンティティプロバイダ (例: Okta、Azure、AD FS、Google Workspace、Duo、Ping、JumpCloud など) による認証が成功した後にユーザーへ渡されます。 ### クラウドSSOコネクトのデータフロー ![クラウドSSOコネクトの暗号化モデル](https://3468650114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeJwa6ByNJ2qindnPknCW%2Fuploads%2FvP3dXOEV1w5OR3sO1MEP%2Fsso-connect-cloud-encryption-model-v2.jpeg?alt=media\&token=1eb09ec2-3f2f-46fe-aa1b-f75423a26da6) #### 初回デバイスフロー (新規ユーザーのオンボーディング) 1. データキー、共有用キーペア、およびデバイス用の楕円曲線 (EC) 秘密鍵／公開鍵ペアが生成されます。 2. データキーはデバイスのEC公開鍵で暗号化され、クラウドに保存されます (DEDK)。 3. ユーザーは、自身のアイデンティティプロバイダ (IdP) を使用してログインします。 4. IdPでのログイン後、署名付きSAMLアサーションがKeeperによって検証されます。\ その後、ボルトが作成され、ユーザーのオンボーディングが完了します。 #### 既存デバイスフロー 1. ユーザーは、自身のアイデンティティプロバイダ (IdP) を使用してログインします。 2. IdPでのログイン後、署名付きSAMLアサーションがKeeperによって検証されます。 3. Keeperから、デバイスで暗号化されたデータキー (DEDK) がユーザーに送信されます。 4. データキーは、デバイスのEC秘密鍵を使用して復号されます。 5. 復号されたデータキーによって、フォルダキーおよびレコードキーが復号されます。 6. レコードキーを使用して、レコードの内容が復号されます。 #### 新規または未認識デバイスのフロー 1. 新しいデバイスごとに、EC秘密鍵／公開鍵ペアが生成されます。 2. ユーザーは、自身のアイデンティティプロバイダ (IdP) を使用してログインします。 3. IdPでのログイン後、署名付きSAMLアサーションがKeeperによって検証されます。 4. デバイスは、Keeper Push、管理者承認、またはオートメーターサービスによって「承認」されます (詳細は「デバイス承認」を参照)。 5. 承認プロセスでは、データキーが新しいデバイスの公開鍵で暗号化されます。 6. デバイスで暗号化されたデータキー (DEDK) がユーザーに送信されます。新しいデバイスごとに、EC秘密鍵と公開鍵のペアが生成されます。 #### デバイス承認 1. デバイス承認は、ゼロ知識を維持したまま、ユーザーのデータキーを新しいデバイスに安全に配布するための仕組みです。 2. ユーザー自身が、新しいデバイスの公開鍵を使用してデータキーを暗号化することで、デバイスを承認できます。 3. 管理者は、管理コンソール、Keeperコマンダー、または自動承認システムからデバイスを承認できます。 4. 管理者承認の場合、ユーザーのデータキーは一度復号された後、新しいデバイスの公開鍵で再暗号化されます。 5. オートメーターサービスを使用すると、顧客のインフラストラクチャ上でデバイス承認を自動化できます。 6. オートメーターサービスでは、SAML署名の検証、データキーの復号、および新しいデバイスの公開鍵を使用したデータキーの暗号化が行われます。 オートメーターサービスの詳細については、[こちらのページ](https://app.gitbook.com/s/-Mfd2v-YT48Ljtykb8qm/device-approvals/automator)をご覧ください。 {% file src="" %} SSO暗号化モデルの大型.svg版 {% endfile %} ### クラウドSSOコネクトのデバイスレベルのセキュリティ クラウドSSOコネクトのユーザーの場合、各デバイスに楕円曲線の秘密鍵が生成され、ローカルに保存されます。Chromiumベースのウェブブラウザの場合、Keeperボルトは、ローカルデバイスの楕円曲線秘密鍵 (DPRIV) をエクスポートできない[CryptoKey](https://developer.mozilla.org/ja/docs/Web/API/CryptoKey)として保管します。 iOSおよびMacデバイスでは、鍵はデバイスの[キーチェーン](https://developer.apple.com/documentation/security/keychain_services/)に保存されます。 Androidデバイスでは、鍵は[Android Keystore](https://developer.android.com/training/articles/keystore?hl=ja)で暗号化され、[EncryptedSharedPreferences](https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences)で使用します。利用できる場合、Keeperは安全なストレージメカニズムを使用します。 デバイスの秘密鍵は、直接的にボルトデータの暗号化や復号化には使用されません。 IDプロバイダによる認証が成功すると、ボルトデータの復号に (保管されていない) 別の鍵が使用されます。 ローカルデバイスの秘密鍵をオフラインで抽出しても、ユーザーのボルトは復号化**できません**。 ### エンドユーザーのデバイス承認 新しいデバイスにサインインするには、ユーザーは既存のデバイスを利用して承認を行うか、特権を持つ管理者が新しいデバイスを承認する必要があります。 新しいデバイスは、新規の公開鍵/秘密鍵のセットを生成し、承認するデバイスは、ユーザーのデータキーを新しいデバイスの公開鍵で暗号化します。 新しいデバイスの暗号化されたデータキー (EDK) が要求元のユーザーやデバイスに提供されると、ユーザーはデータキーを復号化できるようになるので、そのデータキーはユーザーのボルトデータを復号化します。 ユーザーは復号されたボルトデータ内で、ユーザーはレコード鍵、フォルダ鍵、チーム鍵などの他の秘密暗号鍵を復号することができます。 この機能の重要性は、ユーザーがKeeperクラウドに保存されている暗号鍵を使用してボルトを復号化できるという点と、暗号鍵を管理するためのオンプレミスまたはユーザーがホストするアプリケーションサービスを必要としないという点にあります。 Keeperクラウドはユーザーのデバイス上でデータキーを復号することができないため、ゼロ知識が維持されます。ユーザーのデータキーは、デバイスの秘密鍵 (DPRIV) で復号化され、指定されたIDプロバイダ (例 Okta、Azure、AD FS) による認証が成功した場合のみ、ユーザーにEDKが提供されます。 管理者の観点から見ると、Keeperの現行SSOコネクト暗号化モデルで説明されているように、簡単に設定でき、暗号鍵の管理にホスト型のソフトウェアは必要がないという利点があります。 Keeper SSOコネクトのオンプレミス実装と比較すると、このモデルにおける唯一のワークフローに関する変更点は、ユーザーがアクティブなデバイスで新しいデバイスの承認を実行するか、Keeper管理者にデバイス承認の責任を委譲して承認する必要があるということになります。 ### 管理者のデバイス承認 管理者は、「デバイス承認」権限を持つロールが付与されている場合、Keeper管理コンソールまたはKeeperコマンダーCLIを使用してエンドユーザーデバイスの承認を行うことができます。 Keeper管理コンソールでユーザーが管理者権限に昇格されると、エンタープライズ秘密鍵は新しい管理者の公開鍵で暗号化されます。 エンドユーザーのデバイスでは、各ユーザーのデータ鍵がエンタープライズ公開鍵で暗号化され、エンタープライズ暗号化データ鍵としてKeeperクラウドに保存されます。 ユーザーが管理者の承認をリクエストすると、管理者は以下の手順で承認を実行できます。 1. 管理コンソールまたはコマンダーCLIにログインします。 2. エンタープライズ秘密鍵を復号化し、そのユーザーのエンタープライズ暗号化データ鍵を取得します。 3. ユーザーのデータ鍵を復号化します。 4. 新しいデバイスの公開鍵を使用してデータ鍵を再暗号化します。 デバイス承認を実行すると、新しいデバイス暗号化データ鍵が安全にユーザーの新しいデバイスに送信されます。ローカルデバイスでは、エンドユーザーが新しいデバイス秘密鍵を使用してデータ鍵を復号化し、デバイス承認プロセスが完了します。 ### 自動のデバイス承認 エンタープライズ展開のために、エンドユーザーデバイスの承認を自動的かつオンデマンドで実行する完全なセルフホストサービスをご利用になれます。ゼロ知識を維持するため、このサービスは顧客のクラウド環境またはオンプレミス環境で運用される必要があります。 Keeperでは、Azure、AWS、Google Cloud、その他の専用環境でKeeperオートメーターサービスをホスティングするためのさまざまな方法がご利用になれます。 Keeperオートメーターサービスの詳細については、[こちらのページ](https://app.gitbook.com/s/-Mfd2v-YT48Ljtykb8qm/device-approvals/automator)をご参照ください。 ### デバイスの承認方法 KeeperクラウドSSOコネクトでは、複数のデバイス承認方法に対応しています。 1. Keeperプッシュ 2. Keeper管理コンソールからの管理者承認 3. コマンダー自動化ツールによる管理者承認 4. Azure機能による自動管理者承認 5. Keeperオートメーターを使用した自動承認 (推奨) SSOクラウドデバイスの承認の詳細については[こちらのページ](https://app.gitbook.com/s/-Mfd2v-YT48Ljtykb8qm/device-approvals)をご覧ください。 ### SSOアーキテクチャ 以下は、Keeper SSOコネクトのシステムアーキテクチャ図です。 ![SSOコネクトのセキュリティアーキテクチャ](https://3468650114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeJwa6ByNJ2qindnPknCW%2Fuploads%2F6ay3UVZaqHXDX2wQuUBN%2FSecurity%20Architecture-%20Japanese%20\(1\).jpg?alt=media\&token=5f8bf57c-d24f-4d8b-b4e6-a0f8efcfa813) ## アカウント復元 Keeperは、ランダムに生成された24単語のリカバリーフレーズを使用してアカウントを復元します。 マスターパスワードを忘れた場合に、リカバリーフレーズを使用してKeeperボルトへのアクセスを取り戻すことができます。 Keeperは、業界標準のBIP39ワードリストを使用してリカバリーフレーズを実装します。BIP39ワード リストは、256ビットのエントロピーを持つ暗号化キーを生成するために使用される 2048語のセットです。 BIP39リストの各単語は、読みやすさを向上させ、復元プロセスでエラーが発生しにくくするために慎重に選択されています。 リカバリーフレーズでのアカウントの復元は、256ビットAES-GCMキーで暗号化されたユーザーのデータ鍵の2番目のコピーを保存することによって機能します。 この鍵は、基礎となるハッシュアルゴリズムとして HMAC\_SHA512 を使用したHKDFを使用し、BIP39リストでランダムに選択された24個の単語から導出されます。 ボルトの復元を完了するには、ユーザーは次のことを行う必要があります。 * メール認証コードを入力してください。 * 二要素認証を行います (アカウントで有効になっている場合) * リカバリーフレーズをデバイス上でローカルに入力します

24語のリカバリーフレーズ

## Keeperフォースフィールドによるメモリ保護 Keeperフォースフィールドは、Windowsエンドポイント上の機密アプリケーションに対してリアルタイムのメモリ保護を実現することで、Keeperのゼロ知識セキュリティモデルを強化します。Keeperの暗号化により、保存時および通信時のデータは保護されますが、フォースフィールドは実行時にメモリ上で復号されたデータへの不正アクセスを防止し、認証情報を窃取するマルウェアに悪用されてきた重大なギャップを解消します。 従来の暗号化は、保存された暗号文やネットワーク通信を保護しますが、実行時のメモリは依然として攻撃対象となります。Windowsでは、同一のユーザーコンテキストで実行されているプロセス同士が互いのメモリを読み取ることが可能であり、これによりマルウェアがアプリケーションメモリから認証情報、セッショントークン、その他の機密情報を直接取得できてしまいます。Keeperフォースフィールドは、オペレーティングシステムのカーネルレベルで厳格なメモリアクセス制御を適用することで、情報窃取型マルウェアを含む不正なメモリアクセスの試行をブロックします。 [Keeperフォースフィールド](https://docs.keeper.io/jp/enterprise-guide/keeperforcefield)の詳細については、こちらのページをご参照ください。 ## シークレットマネージャー暗号化モデル Keeperシークレットマネージャーは、DevOps、ITセキュリティ、ソフトウェア開発チーム向けのゼロ知識プラットフォームであり、ソフトウェア開発と展開のライフサイクル全体を通じて機密情報を管理します。
シークレットマネージャーは、次の暗号化モデルに準拠しています。 1. 秘密はデバイス上で暗号化および復号化されます (サーバー上ではありません）。 2. デバイスはプレーンテキスト (人間が読める) データを保存することはありません。 3. サーバーがプレーンテキストのデータを受信することはありません。 4. Keeperの従業員、サードパーティや仲介者が秘密を復号化することはできません。 5. 秘密の暗号化や復号化をするための鍵は、クライアントデバイス上でユーザーが管理します。 6. 各秘密は、GCMモードでクライアント側で一意に生成された256ビットAES暗号化鍵によって暗号化されます。 7. 各レコードレベルの鍵は、共有フォルダ内に含まれている場合、共有フォルダ鍵によってラップされます。 8. クライアント側で生成された256ビットAESアプリケーションキーを使用して、共有フォルダおよびレコード鍵が復号化されます。レコード鍵は、個々の秘密を復号化します。 9. Keeperサーバーに送信されるすべての暗号化ペイロードは、中間者攻撃から保護するために、TLSに加えて256ビットAES送信キーでさらにラップされます。送信キーはクライアントデバイスで生成され、サーバーのEC公開鍵を介してECIES暗号化を使用してサーバーに転送されます。 10. ユーザー間の秘密の共有では、楕円曲線暗号を使用して安全な鍵配布が行われます。 11. マルチレイヤー暗号化は、ユーザー、グループ、および管理者レベルでのアクセスコントロールを提供します。 12. ユーザーボルト内で管理される秘密はセグメント化され、個々のレコードとフォルダへのアクセス権が付与されている定義済みのシークレットマネージャーデバイスに分離されます。 Keeperシークレットマネージャーに関するセキュリティの詳細については、[こちらのページ](https://app.gitbook.com/s/PL6k1aGsLiFiiJ3Y7zCl/secrets-manager/about/security-encryption-model)をご参照ください。 シークレットマネージャーの詳細については、[こちらのページ](https://docs.keeper.io/jp/enterprise-guide/broken-reference)をご参照ください。 ## ワンタイム共有暗号化モデル ![ワンタイム共有](https://3468650114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeJwa6ByNJ2qindnPknCW%2Fuploads%2FtusvnzSrMxSZjQEAMNXG%2Fspaces_eJwa6ByNJ2qindnPknCW_uploads_suVT1EW3jMudY9AWbgLj_JP_Onetimeshare.webp?alt=media\&token=b3159781-052f-4921-969a-788ac45384ff) Keeperの「ワンタイム共有」を使用すると、Keeperアカウントを作成しなくても、期限付きで安全にレコード (パスワード、秘密、文書、その他の機密情報など) を受信者に共有できます。ワンタイム共有に実装された暗号化モデルは、クラウドインフラストラクチャを保護するためのゼロ知識およびゼロトラストプラットフォームである、[Keeperシークレットマネージャー](https://docs.keeper.io/jp/enterprise-guide/broken-reference)と同じ技術を採用しています。 1. ボルトで、共有者はレコードオプション画面で「ワンタイム共有」をクリックして、ワンタイムアクセストークンを生成します。共有されるレコードの256ビットAESレコード鍵は、ワンタイムアクセストークンで暗号化され、この暗号化された値はKeeper Cloudに保存されます。 2. 共有者は、単純なURLまたはQRコードを使用して、優先チャネルからワンタイムアクセストークンを受信者に送信します。アクセストークンを含むURL部分はURLの「フラグメント識別子」セクション内に保持され、Keeperのサーバーにネットワーク経由で送信されることはありません。そのため、ゼロ知識は保持され、Keeperはその情報にアクセスしたり、復号化したりすることはできません。 3. 受信者はデバイスのブラウザでURLを開き、単一ページのボルトアプリケーションがデバイスにロードされます。ワンタイムアクセストークンは、ローカルのボルトアプリケーションに直接受け渡されます (サーバーには送信されません）。 4. URLを読み込むと、受信者のデバイスはクライアント側の楕円曲線公開鍵/秘密鍵のペアを生成し、秘密鍵はクライアントデバイスにローカルでブラウザのCryptoKeyストレージに保存されます。 5. 初めて使用する際に、SDKライブラリはワンタイムアクセストークンのハッシュを使用して認証し、認証が成功すると、サーバーは暗号化されたレコード暗号文と暗号化されたレコード鍵で応答します。 6. クライアントはワンタイムアクセストークンを使用してレコード鍵を復号化し、レコードの内容はレコード鍵を使用して復号化されます。その後、レコード鍵は、クライアントデバイスのブラウザのCryptoKeyストレージ、またはその他の指定されているストレージの場所にローカルで保存されます。 7. サーバーでは、そのデバイス用に暗号化されたレコード鍵が削除されるため、ワンタイムアクセストークンは再使用できなくなります。それ以降は、クライアントのリクエストはクライアント秘密鍵で署名される必要があります。 8. 同じデバイスでサーバーに後続のコールを送る際は、デバイスを一意に定義する識別子 (ワンタイムアクセストークンのハッシュ) とクライアント秘密鍵で署名されたリクエスト本文と一緒に送信されます。サーバーは、デバイスのクライアント公開鍵を使用して、特定のデバイス識別子に対するリクエストのECDSA署名をチェックします。Keeper Cloudはレコードのリクエストを処理し、認証が成功すると、サーバーは暗号化されたレコード暗号文をクライアントに返します。 9. レコードレベルの暗号化に加えて、クライアントデバイスはランダムに生成されたAES-256ビットの送信鍵を生成します。この鍵はKeeperクラウドAPIの公開鍵で暗号化されます。クライアントデバイスは、送信鍵を使用してサーバーからの応答を復号化し、レコード鍵を使用して暗号文応答ペイロードを復号化します。これにより、レコードの内容が復号化されます。 ## Keeperゲートウェイのセキュリティ Keeperゲートウェイは、ローテーション、検出、接続、視界内デバイスへのトンネリングを実行するためにオンプレミスにインストールされるサービスです。Keeperゲートウェイは、WebSocketsおよび[Keeperシークレットマネージャーのゼロ知識プロトコル](#secrets-manager-encryption-model)を使用して、Keeper Routerにアウトバウンド通信を行います。 Keeperゲートウェイは、ターゲットマシンにゲートウェイサービスをインストールする際に提供されるワンタイムアクセス トークンを使用して、最初にKeeperルータに認証を行います。初回認証後は、後続のRouterへのAPI呼び出しは、ワンタイムアクセス トークンのHMAC\_SHA512ハッシュであるクライアントデバイス識別子を使用して認証されます。 保管庫（Vault）のレコードへのアクセスおよび復号化には、Keeperゲートウェイは標準のKeeperシークレットマネージャーAPIを使用します。このAPIはデータのクライアント側暗号化および復号化を実行します。Keeperシークレットマネージャーのセキュリティモデルは、サービスによって復号化可能な特定のフォルダやレコードのみを割り当てることで、最小特権とゼロ知識を保証します。KeeperクラウドへのAPIリクエストは、クライアントデバイス識別子と、クライアントデバイス秘密鍵で署名されたリクエストボディを伴って送信されます。サーバーは、指定されたクライアントデバイス識別子のリクエストに対して、デバイスのクライアント公開鍵を使用してECDSA署名を検証します。 他のシークレットマネージャーデバイスと同様に、暗号化および署名プロセスに加えて、IPアドレスに基づいてアクセスを制限することも可能です。 ## Keeperルータのセキュリティ Keeperゲートウェイは、顧客の環境にインストールされ、Keeperルータへのアウトバウンドセキュア接続を確立することで、ネットワーク構成を変更することなくKeeperクラウドとの双方向通信を可能にします。Keeperルータは、インバウンドリクエストにWebSocketsを活用することで、クラウドからオンプレミスインフラへのアクセスを簡単かつ安全にします。 Keeperでは、ウェブボルトなどのエンドユーザーデバイスとKeeperルータの間にWebSocketが確立され、ユーザーの現在のセッショントークンを使用して認証が行われます。セッショントークンはKeeperルータによって検証され、セッションを認証します。Keeperルータに送信されるすべての暗号化ペイロードは、MITM攻撃から保護するためにTLSに加えて256ビットAES送信鍵でラップされています。この送信鍵はエンドユーザーデバイス上で生成され、ルータの公開EC鍵を使用したECIES暗号化を通じてサーバーに転送されます。 ユーザーがウェブボルトまたはデスクトップアプリでパスワードローテーション、検出ジョブ、リモート接続を発動すると、メッセージフローは以下のようになります。 * ゲートウェイのインストール時に、Keeperクラウドと一度だけハッシュ化されたワンタイムアクセス トークンを使用して認証します。この際、クライアントはペイロードに署名し、最初の認証時にサーバーにクライアントデバイス公開鍵を登録します。 * 初回認証後、後続のリクエストはKeeperルータに送信され、クライアントデバイス秘密鍵で署名されます。 * ゲートウェイは、クライアントデバイス秘密鍵とECDSA署名を使用して認証済みのWebSocket接続を確立します。 * ボルトは、実行すべきコマンド（ローテーション、検出、接続）を伴うメッセージをKeeperルータに送信し、ユーザーのアクティブセッショントークンを使用してコマンドを認証します。ボルトは`Rotate UID XXX`など、コマンドおよび制御メッセージのみを送信し、ボルトとルータ間で秘密情報は一切通信されません。 * ルータは、レコードのローテーション設定に基づくセッショントークンを使用してコマンドを認証し、ユーザーのリクエストを検証します。その後、既存のWebSocket接続を介して目的のゲートウェイにコマンドを中継します。 * ゲートウェイは、KeeperシークレットマネージャーAPIを使用してシークレット、管理者資格情報、レコード詳細、およびその他のプライベートデータを取得します。KeeperクラウドへのAPIリクエストにはクライアントデバイス識別子と、クライアントデバイス秘密鍵で署名されたリクエストボディが含まれます。サーバーは指定されたクライアントデバイス識別子のリクエストに対して、デバイスのクライアント公開鍵を使用してECDSA署名を検証します。 * クライアントデバイスは、サーバーからの暗号化応答をアプリケーション秘密鍵で復号化し、レコード鍵や共有フォルダ鍵を復号化します。共有フォルダ鍵はレコード鍵を復号化し、レコード鍵が個別のレコードシークレットを復号化します。 * ゲートウェイは、Keeperシークレットマネージャーの「update」コマンドを使用して、パスワードまたはディスカバリージョブの更新内容をユーザーのボルトに反映します。 * ローテーションまたはディスカバリージョブが完了すると、ゲートウェイはルータにジョブ完了を通知します。この際、ARAMイベントログがルータによってトリガーされます。 Keeperルータアーキテクチャはゼロ知識で設計されており、Keeperのインフラは顧客のボルトデータにアクセスしたり、復号化したりすることは一切できません。 ## ゼロトラスト接続とトンネル接続のセキュリティ ゼロトラストKeeperPAMは、クラウドおよびオンプレミスの特権セッションを確立し、トンネルを作成し、インフラストラクチャへの直接アクセスを確立し、VPNなしでリモートデータベースアクセスを安全に提供する機能を提供します。 **接続**は、ウェブブラウザーを使用した視覚的なリモートセッションです。ユーザーとターゲットデバイス間のインタラクションは、ウェブブラウザウィンドウまたはKeeperデスクトップアプリケーション内で行われます。 **トンネル接続**は、ローカルボルトクライアントとターゲットエンドポイント間で、Keeperゲートウェイを通じて確立されるTCP/IP接続です。ユーザーは、コマンドライン端末、GUIアプリケーション、MySQL Workbenchなどのデータベース管理アプリケーションなど、ターゲットエンドポイントと通信するために任意のネイティブアプリケーションを利用できます。 ユーザーが接続またはトンネルを確立する際の手順は以下の通りです： 1. ボルトクライアントアプリケーションは、Keeperルータインフラに通信し、関連するKeeperレコード内に保存されたECDH対称鍵で保護されたWebRTC接続を開始します。 2. Keeperゲートウェイは、アウトバウンド専用のWebSocketsを通じてKeeperルータと通信します。この詳細は、このリンクで説明されています。 3. Keeperゲートウェイは、KeeperシークレットマネージャーAPIを利用して、ボルトから必要なシークレット (ECDH対称鍵を含む) を取得します。 4. 接続の場合、ボルトクライアント (Keeperコネクションマネージャーguacdプロトコルを使用) は、WebRTC接続を通じてデータをKeeperゲートウェイに送信し、KeeperゲートウェイはGuacdを使用して、Keeperレコードで定義されたターゲットに接続します。 5. トンネル機能 (ポート転送) の場合、ローカルデバイス上でKeeperデスクトップソフトウェアを実行しているローカルポートが開かれます。ローカルポートに送信されたデータは、WebRTC接続を通じてKeeperゲートウェイに転送され、その後、Keeperレコードで定義されたターゲットエンドポイントに転送されます。 6. 接続のセッション録画は、AES-256暗号化鍵 (録画鍵) によって保護され、セッションごとにKeeperゲートウェイで生成されます。録画鍵は、さらにHKDF-derived AES-256リソース鍵でラップされます。 ## リモートブラウザ分離のセキュリティ Keeperリモートブラウザー分離技術は、KeeperコネクションマネージャーのDockerコンテナまたはKeeperゲートウェイを通じて、内部ウェブアプリケーションやその他のウェブベースの資産へのアクセスを保護します。 #### コネクションマネージャーDockerコンテナメソッドを使用する場合 1. ユーザーは、Dockerコンテナ内でホストされたKeeperコネクションマネージャーウェブサービスに認証します。 2. ユーザーは、ターゲットウェブアプリケーションにリモートブラウザー分離セッションを開始します。ユーザーのブラウザーとホストされたKeeperコネクションマネージャーウェブサービス間の通信は、Let's Encryptまたは顧客が指定した証明書によってHTTPSで保護されます。 3. KeeperコネクションマネージャーDockerコンテナ内では、Chromiumの仮想化バージョンがサンドボックス内で実行され、コンテナからターゲットウェブサイトへのHTTPトラフィックはローカルディスプレイドライバーを経由して転送され、最終的にユーザーのウェブブラウザーにApache Guacamole (guacd) プロトコルを使用して転送されます。 #### Keeperゲートウェイを使用し、Keeperウェブボルトまたはデスクトップアプリを通じて接続する場合： 1. ボルトクライアントアプリケーションは、Keeperルータインフラに通信し、関連するKeeperレコード内に保存されたECDH対称鍵で保護されたWebRTC接続を開始します。 2. Keeperゲートウェイは、アウトバウンド専用のWebSocketsを通じてKeeperルータと通信します。この詳細は、このリンクで説明されています。 3. Keeperゲートウェイは、KeeperシークレットマネージャーAPIを利用して、ボルトから必要なシークレット (ECDH対称鍵を含む) を取得します。 4. ボルトクライアント (Keeperコネクションマネージャーguacdプロトコルを使用) は、WebRTC接続を通じてデータをKeeperゲートウェイに送信し、KeeperゲートウェイはApache Guacamole (guacd) プロトコルを使用して、Keeperレコードで定義されたターゲットに接続します。 5. セッション録画は、AES-256暗号化鍵 (録画鍵) によって保護され、セッションごとにKeeperゲートウェイで生成されます。録画鍵は、さらにHKDF-derived AES-256リソース鍵でラップされます。 #### ブラウザー分離保護 リモートブラウザー分離プロトコルを使用することで、いくつかのセキュリティ対策が有効になります。 1. 保護されているウェブアプリケーションエンドポイントは、KeeperコネクションマネージャーゲートウェイからユーザーのローカルデバイスへのTLS暗号化層でラップされ、ゲートウェイとエンドポイント間でTLSが使用されていない場合でも、MITM攻撃やローカルネットワークでのパケット検査から保護されます。 2. リモートブラウジングセッションは、キャンバスとグラフィックレンダリングを使用してユーザーのローカルデバイスにインタラクションを視覚的に投影します。ターゲットのウェブサイトのJavaScriptコードやHTMLは、ユーザーのローカルマシンではレンダリングされません。 3. ターゲットウェブサイトのコードがローカルで実行されず、ローカルブラウザーがアプリケーションコードに直接アクセスできないため、リフレクション型クロスサイトスクリプティング (XSS) 脆弱性、クロスサイトリクエストフォージェリ (CSRF)、APIの悪用などの攻撃ベクターから保護されます。 4. ユーザーは、URLおよびリソースリクエストのフィルタリングを通じて、ターゲットエンドポイントからのデータ漏洩を行わないよう制限できます。ファイルのアップロードおよびダウンロードも制限され、ウェブアプリケーションがそのアクションを試みても実行されません。 5. ブラウジングセッションおよびキーストロークは、監査およびコンプライアンス目的で録画され、ウェブベースのセッションの分析を行うことができます。 6. ゲートウェイからターゲットウェブアプリケーションに自動入力された認証情報は、ユーザーのデバイスには一切送信されず、ローカルデバイス上でアクセスできないため、秘密情報の漏洩を防ぎます。 7. ファイアウォールポリシーにより、ユーザーはリモートブラウザ分離セッションを通じてのみターゲットウェブアプリケーションにアクセスする必要があり、コンプロマイズされたブラウザーやローカルデバイスのマルウェアからの脅威を減らします。 8. ターゲットウェブアプリケーションは、シングルサインオン (SSO) および/またはMFA認証で保護され、アプリケーションがネイティブにこれらをサポートしていなくても、Keeperはボルトおよびリモートブラウザ分離セッションへのアクセスをこの高度な認証方法で保護します。 ## アカウント移管ポリシーの暗号化 ![](https://3468650114-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeJwa6ByNJ2qindnPknCW%2Fuploads%2FIlaxXC6NkXTi5PyySmIN%2F%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-05-17%20%E5%8D%88%E5%BE%8C9.01.57.png?alt=media\&token=b88053d0-3908-41bd-9570-1b514e86bd8d) アカウント移管ポリシーをロールに対して有効にすると、ロール強制適用ポリシーの公開鍵と秘密鍵のペアが管理コンソール上でローカルに生成されます。エンドユーザーのデータキー (強制が適用されるロールのユーザーの場合) は、ユーザーがボルトにサインインする際に、ロール強制適用ポリシーの公開鍵で暗号化されます。ロール強制の秘密鍵は、管理者の公開鍵で暗号化されます。 従って、ボルトを移管する必要がある場合に、管理者はロール強制の秘密鍵を復号化することができます。 ボルトの移管を実行するには、Keeper管理者はまずユーザーのアカウントをロックする必要があります。それから、ボルトが移管できるようになり、移管直後にユーザーのアカウントが削除されます。これにより、秘密裏に操作が行われないようにします。移管を実行する際には、まずロール強制の秘密鍵をアンラップしてから、ユーザーのデータキーをアンラップすることで、ユーザーのデータキーを取得します。データキーは、レコード鍵、チーム鍵、フォルダ鍵のアンラップに使用されます。 すべての暗号化はクライアント側の管理コンソール内で実行されるため、共有または移管される情報をKeeperが復号できるということは一切ありません。また、ユーザーのクライアントデータキーが共有されることもありません。従って、ユーザーのデバイスにキャッシュされたデータは、ユーザーのマスターパスワードがなければ復号できません。チーム、共有フォルダ、直接共有から削除されたユーザーは、そのチーム、共有フォルダ、レコードから新しいデータを受け取ることはありません。レコード、フォルダ、チームの鍵は、トランザクション中に管理者に洩れますが、それらの鍵を基となるレコードやフォルダのデータにアクセスするために使用することはできません。 いくつかの異なる管理者特権が階層ツリーの一部に割り当てられている場合があり、その特権ロールのメンバーは、KSI側のKeeper管理コンソールで操作を実行することができます。 アカウント移管ポリシーの詳細については、[こちらのページ](https://docs.keeper.io/jp/enterprise-guide/account-transfer-policy)をご参照ください。　 ## 緊急アクセス (デジタル遺産)
Keeperの個人向け製品は、緊急時や死亡時にボルトへのアクセスを許可するために、最大5件の緊急連絡先を追加する機能に対応しています。指定された待機時間が経過すると、緊急連絡先に指定されている人はユーザーのボルトにアクセスできるようになります。ボルトの共有プロセスはゼロ知識であり、ユーザーのマスターパスワードは直接共有されることはありせん。元のユーザーによって設定された待機時間が経過した時点で、緊急連絡先と256ビットAES鍵を共有するために、2048ビットRSA暗号化が使用されます。そのため、緊急連絡先には、招待を受け入れるためのKeeperアカウント (および公開鍵と秘密鍵のペア) が必要です。 {% hint style="info" %} デジタル遺産のサポートは、個人レベルのアカウントのみを対象にしています。 {% endhint %} ## モバイル用アプリ Keeperのモバイルアプリにはトラッカーは含まれていません。 すべてのモバイルアプリは、KeeperのサードパーティテスターとBugcrowdバグ報奨金プログラムによる脆弱性テストを受けています。 Exodus Privacyは、ユーザー追跡を実行するアプリケーションを監視する組織です。 KeeperのAndroidアプリケーションは以下のとおりです。 ## ブラウザ拡張機能のアーキテクチャ

ブラウザ拡張機能のアーキテクチャ

## ブラウザ拡張機能のセキュリティ Keeperブラウザ拡張機能 (KeeperFill) では、Chrome、Firefox、Edge、Safari、その他のchromiumベースのブラウザなどのすべてのウェブブラウザで自動入力機能を提供します。 **ユーザーがマスターパスワードを使用してKeeperにログインする場合** PBKDF2をストレッチング回数を最低10万回に設定して使用し、マスターパスワードから鍵を取得します。この鍵は「マスターパスワード鍵」と呼ばれ、どこにも格納されません。これは、AES-256クライアント鍵とAES-256データキーを復号化するために使用されます。 データキーは、Keeper Cloudから送信されるデータを復号化するために使用され、クライアント鍵は、ローカルに保存されている暗号文の暗号化や復号化のために使用されます。 ユーザーの暗号文がKeeper Cloudからローカルデバイスに同期された後、暗号文はデータキーを使用してローカルで復号化され、クライアント鍵を使用してデバイスのローカルIndexedDBデータベースに暗号化されます。ブラウザのIndexedDBデータベースは、Keeperブラウザ拡張機能でのみ使用できます。 Keeperは、ローカルの暗号文を復号化するために使用される暗号鍵を保存することはありません。この情報は、ユーザーがログインしている間はメモリーに保持され、自動入力やKeeperブラウザのツールバー機能へのアクセスに使用されます。Service Workerが再起動されると、Keeperはクライアント鍵を使用してIndexedDBからデータを復号化するプロセスを繰り返します。Service Workerが再起動する間、クライアント鍵はメモリーで保持されます。 ユーザーがKeeperからログアウトした後、またはログアウトタイマーの期限が切れた場合、ボルトはロックされ、ユーザーはマスターパスワードを使用して再度ログインする必要があります。 **ユーザーがシングルサインオンを使用してKeeperにログインする場合** 署名付きSAML応答がSSO IDプロバイダによって返された後、Keeperはユーザーにデバイス暗号化データキー (DEDK) を送信します。 データキーは、楕円曲線デバイス機密鍵 (DPRIV) で復号化されます。次に、データキーを使用して、Keeperクラウドが送信した暗号文が復号化されます。データキーは保存されないため、デバイス暗号化データキーを取得して、データを復号化するために、ユーザーはログインするたびにSSOプロバイダで認証する必要があります。 ### データストレージ * レコード鍵の暗号文はCloud Security Vaultから同期され、ユーザーのデータキーを使用してローカルで復号化されます。 共有フォルダーキーは、各フォルダーのそれぞれの共有フォルダーキーを使用して復号化されます。レコードの内容は、各レコードのそれぞれのレコード鍵を使用して復号化されます。 * レコード鍵とコンテンツはクライアントキーで暗号化され、IndexedDBにローカルに保存されます。楕円曲線秘密キーは、Chromium CryptoKeyストレージに保存されます。 * ドメインからレコードへのマッピングは、クライアントキーを使用してHMAC\_SHA256でハッシュされたURL経由で保存されます。 ### サードパーティの脆弱性テスト Keeperは[NCC Group](https://www.nccgroup.com/)および[Cybertest](https://www.cybertest.com/)と協力して、ソースコードレベルの分析を含む、ブラウザ拡張プラットフォームの脆弱性テストを継続的に実施しています。 ### プライバシーと権限 KeeperFillは、ユーザーが必要とする基本的な機能を提供するために、ブラウザー拡張フレームワークで特定の権限を必要とします。これらの権限は、期待される機能を提供するためにのみ使用されます。具体的には、次のような機能があります： * 保存されたボルトの資格情報を現在のウェブページに一致させる * ボルトとページ内のフォーム入力機能の間での相互作用 * ログインフィールド、支払いカードフィールド、その他のフィールドタイプの検出 * ウェブサイトのログインページへの資格情報の自動入力 * ログイン後の資格情報の保存 * FIDO2 WebAuthnとの相互作用によるパスキーの保存と入力 * HTTP Basic Authのウェブサイトログインスキームとの連携 Keeperセキュリティブラウザー拡張は、これらの権限を使用して、前述のサービス以外の目的でユーザーのブラウジング履歴を追跡したり記録したりすることはありません。ゼロ・ナレッジ・セキュリティモデルに基づいて構築されており、データの暗号化と復号化はすべてユーザーのデバイスでローカルに行われます。Keeperのサーバーは、暗号化されていないデータにアクセスすることはなく、ユーザーのブラウジング履歴も保存しません。 ### 権限の詳細 以下の権限は、KeeperFill拡張機能のマニフェストで宣言されています。これらの説明は、プラットフォームアプリストア (Google、Apple、Microsoft) における権限の正当化要件にも提供されています。 #### contextMenus この権限により、ユーザーは右クリック/コントロールクリックで「コンテキストメニュー」にアクセスし、自動入力に使用する資格情報を選択できます。また、新しいレコードの作成、ログアウト、Keeperウェブボルトアプリケーションの起動など、他のアクションも実行できます。 #### tabs この権限により、Keeperの拡張機能は現在のタブで開いているウェブサイトを検出し、右クリック/コントロールクリックの「コンテキストメニュー」に最も関連性の高い資格情報を提供できます。また、ユーザーは「起動」ボタンをクリックしてKeeperウェブボルトアプリケーションから新しいタブを開き、選択したウェブサイトを自動入力できます。最後に、Keeperユーザーガイド、ヘルプコンテンツ、その他のサポート資料にアクセスできるようにもなります。 #### alarms Keeper拡張機能は、アイドル状態でのログアウトタイマーにアラームを使用しています。ログイン中、ユーザーにはログアウトタイマーの時間（設定されている場合）と同じ時間のアラームが設定されます。ユーザーがブラウザやKeeperアプリケーションとやり取りするたびに、そのアラームは同じログアウト時間にリセットされます。 #### idle Keeper拡張機能は、コンピュータがスリープ状態になり、復帰した際にログアウトタイマー用にアイドル権限を使用します。この権限は、ユーザーがコンピュータを再起動したことをKeeper拡張機能に通知し、アイドル状態のログアウトタイマー時間と現在の時刻を照らし合わせて、ユーザーがボルトにログインしているかどうかを確認します。 #### storage ストレージAPIは、拡張機能のローカル設定を保存するために使用されます。また、ユーザーが拡張機能に保存されたローカル情報をクリアできるように「クリア」機能も使用されます。 #### browsingData この権限は、拡張機能がKeeperウェブボルトアプリケーションを最新バージョンに自動的に更新し、拡張機能とウェブボルトの互換性を確保するために使用されます。 #### webNavigation この権限は、HTTP Basic Authの自動入力にのみ使用され、サポートされているウェブサイトでログイン/パスワードを自動入力します。 #### scripting この権限は、ウェブページに静的なコンテンツスクリプトを注入し、フィールドを検出して自動入力機能を実行するために使用されます。コンテンツスクリプトのセキュリティの詳細については、以下で説明します。 #### offscreen この権限は、ウェブワーカーを作成し、1つのスレッドではなく複数のスレッドで処理を実行するために使用されます。 #### webRequest この権限は、HTTP Basic Authの自動入力にのみ使用され、サポートされているウェブサイトでログイン/パスワードを自動入力します。 #### webRequestAuthProvider この権限は、HTTP Basic Authの自動入力にのみ使用され、サポートされているウェブサイトでログイン/パスワードを自動入力します。 #### webRequestBlocking この権限は、MV2バージョンのKeeperでのみ使用され、サポートされているサイトでHTTP Basic Authのログイン/パスワードの自動入力に使用されます。MV3では非推奨となっています。 ## クロスサイトスクリプティング (XSS) 攻撃対策 Keeperウェブボルトには、発信要求元を制限し、Keeperから明示的に発信されたスクリプトを除くすべてのスクリプト (インラインスクリプトおよびイベント処理HTML属性を含む) の実行を禁止する厳格なコンテンツセキュリティポリシーが実装されており、クロスサイトスクリプティング攻撃のほとんどのベクトルを低減または取り除きます。 Keeperドメイン名へのアクセスは、TLS v1.2を使用するHTTPSに制限され、HTTP Strict Transport Securityによって強制されます。これにより、さまざまなパケットスニフィング、データの改ざんや中間者攻撃が防止されます。 Keeperのブラウザ拡張内では、ページフレーム領域内からボルトにログインするようにKeeperがユーザーに求めることはありません。拡張機能へのログインは、ブラウザのブラウザ拡張機能ツールバー領域で行います。ウェブブラウザからボルトにログインするには、keepersecurity.com、keepersecurity.eu、keepersecurity.com.au、keepersecurity.jp、keepersecurity.caやgovcloud.keepersecurity.usのドメインを使用するか、コンテンツページの外部にあるKeeperブラウザ拡張ツールバーを使用します。 Chrome、Firefox、EdgeやSafariのKeeperブラウザ拡張はウェブページのログインフォームにiFrameを配置し、悪意のあるウェブサイトが挿入されたコンテンツにアクセスできないようにします。また、iFrameに挿入されるレコードの内容は、ユーザーのレコードに保存されていて、対象ウェブサイトのドメインに一致するボルトレコードに制限されます。ウェブサイトドメインがKeeperボルトレコードのウェブサイトドメインフィールドと一致しない限り、ログインまたはパスワードデータの自動入力は提供されません。 Internet Explorerの拡張機能では、レコードへのログインとアクセスを行うために、別のネイティブアプリケーションウィンドウが使用されます。このような個別のウィンドウはブラウザからアクセスできないため、XSS攻撃の対象にはなりません。これにより、Internet Explorerの拡張機能は、ページ内からログインウィンドウを提供することができます。レコードがウェブサイトアドレスのルートドメインと一致しない限り、拡張機能はレコードを表示しません。 サードパーティ製のブラウザ拡張は、ウェブブラウザ内で昇格された権限を取得する場合があり、ページ内の情報にアクセスできる可能性があります。そのため、Keeper管理者は、ユーザーがブラウザの各アプリストアからサードパーティ製のブラウザ拡張をインストールできないようにすることをお勧めします。 ## スクリプトの実行とメッセージング バックグラウンドスクリプトは、ローカルストレージおよび CryptoKeyストレージと連携するブラウザ拡張フレームワークによって実行されます。 * ウェブページスクリプトはページに追加され、フィールドの検出を実行します。 * iFrameによって挿入されたドキュメントは、Keeperユーザーインターフェイスとユーザーが開始した入力アクションを処理します。 * コンテキストメニュー (右クリック) スクリプトは、Chrome拡張機能のバックグラウンドスクリプトから構築されます。 * ブラウザアクション (ツールバー) の塗りつぶしは、バックグラウンドスクリプトと通信し、UIツールバーメニューを管理します。 * コンテンツスクリプトは、ChromeメッセージングAPI (chrome.tabs.sendMessage) を介してバックグラウンドスクリプトと通信します。 * ブラウザ拡張機能とウェブボルトは、Chromium系ブラウザではネイティブポートメッセージング、Firefoxではwindow\.postMessageを介して相互に通信します。メッセージは楕円曲線送信キーで暗号化されます。 * バックグラウンドスクリプトは、Keeperのゼロ知識バックエンドAPIと通信します。 ## 自動入力のセキュリティ
Keeperブラウザ拡張 (KeeperFill) を使用すると、ボルトから資格情報を対象のウェブサイトのログインページに入力して保存することができます。 自動入力機能により、以下を含む多数の技術と高度な機能を活用して、XSS攻撃から保護します。 * ウェブページのログインフォームにiFrameが追加され、悪意のあるウェブサイトが挿入されたコンテンツにアクセスできないようにします。 * ドメインマッチングが実行され、一致するレコードのみが自動入力で使用できるようにします。Keeperでは、ルートドメインが一致しない限り、パスワード入力を提供することはありません。 * ユーザーはロール強制適用ポリシーで厳密なサブドメインマッチングを強制し、正確なサブドメインの一致に応じて使用可能なログインを制限することもできます。 * Keeperでは、ユーザーまたはKeeper管理者が明示的に強制に関する同意をしていない限り、安全ではないウェブサイト (http\://) でパスワードを自動入力することはありません。 Keeperは、[NCC Group](https://nccgroup.com)や[Cybertest](https://cybertest.com)などのサイバーセキュリティ企業と協力して、サードパーティの自動入力に特化した侵入テストを定期的に実施しています。 *** ## KeeperAIによる自動入力 KeeperAIのHTMLフィールド分類モデルは、プライバシーを保護しながら自動入力を行う技術であり、Multilingual BERTをもとに蒸留されたカスタム双方向バイエンコーダーアーキテクチャを採用しています。このモデルは100以上の言語で2,000万件を超えるデータポイントを用いて学習されています。 すべての処理は、ブラウザー拡張機能に組み込まれたONNX最適化モデルを通じてユーザーのデバイス上でローカルに実行されます。これにより、機密データがデバイス外に送信されることがなく、ゼロ知識の動作が保証されます。このローカルアーキテクチャにより、ユーザーデータがKeeper Securityや第三者に保存・送信・アクセスされることはなく、オフライン環境でもプライバシーを保護しつつ安定した動作を実現します。 このモデルは、51言語におけるフィールドタイプ認識で95%以上の精度を達成しており、45種類の異なるフィールドタイプを分類できます。また、16MBというコンパクトなサイズと低い推論レイテンシで効率的に動作するよう最適化されています。 *** ## 量子耐性暗号化技術 (Quantum-Resistant Cryptography) Keeperは、量子コンピューティングによる新たな脅威、特に「ストア・アンド・クラック (store-and-crack)」攻撃への対策として、量子耐性暗号化 (QRC: Quantum-Resistant Cryptography) を導入します。\ 具体的には、**Kyberハイブリッド鍵カプセル化メカニズム (Hybrid Key Encapsulation Mechanism, KEM)** を採用し、ボルトのセキュリティを強化します。 このハイブリッド方式は、従来の暗号技術と量子耐性アルゴリズムを組み合わせることで、ユーザー認証およびTLS内での暗号化通信を保護します。実装には確立されたKyberライブラリを活用し、ブラウザ依存を避けつつ、クライアント単位で段階的な展開を可能にすることで、量子時代におけるデータ保護の将来性を確保します。 * **量子耐性セキュリティ**\ KyberハイブリッドKEMを統合し、将来の量子攻撃から機密データを保護します。 * **ハイブリッド方式**\ 従来の暗号方式と量子耐性アルゴリズムを組み合わせ、多層防御と後方互換性を両立します。 * **実装対象**\ Keeperの認証プロトコルおよびTLS内の暗号化トンネルを保護します。 * **柔軟な展開**\ 確立されたKyberライブラリを使用し、クライアント単位で段階的な導入を実現します。 * **ストア・アンド・クラック攻撃への対策**\ 現在傍受されたデータが、将来の量子解読技術によっても安全に保たれるようにします。 量子耐性暗号化の導入は、2025年11月に開始される予定です。 *** ## コンプライアンスレポート
Keeperコンプライアンスレポートは、Keeperのゼロ知識暗号化モデルに準拠しています。ここでは、暗号化の観点からその仕組みを説明します。エンタープライズエンドユーザーがボルトにログインすると、タイプ (Type）、タイトル (Title）、およびURLフィールドがエンタープライズ楕円曲線公開鍵で暗号化されます。「監査データ」と呼ばれるこのデータは、ユーザーのデバイス上にローカルで暗号化され、Keeperクラウドに保存されます。監査データは、時間の経過とともにエンドユーザーデバイスによって継続的に更新されます。 Keeper管理者は、マスターパスワードまたはシングルサインオンを使用して管理コンソールにログインします。ログインに成功すると、管理者はAES 256 Enterprise Tree Keyと呼ばれる鍵を復号化し、エンタープライズ楕円曲線秘密鍵を復号化します。管理者は、コンプライアンスレポートを実行する権限を持っている場合、権限が付与されているノード内の任意のユーザーに対してレポートを実行できます。 暗号化された監査データは管理コンソールに送信されるので、管理者はエンタープライズ楕円曲線秘密鍵を使用して監査データをローカルでデバイス上に復号化できます。レポートの内容はローカルでユーザーインタフェースに表示され、CSV、JSONまたはPDF形式にエクスポートできます。 指定されたKeeper管理者だけが、管理者権限を付与されたノードのコンプライアンスレポートデータを取得して復号化できます。 コンプライアンスレポートの詳細については、[こちらのページ](https://docs.keeper.io/jp/enterprise-guide/compliance-reports)をご参照ください。 ## 取得済みの米国特許
特許番号要約
11,363,009安全なクラウドベースのシングルサインオン接続を提供するシステムおよび方法であり、ゼロ知識アーキテクチャを持つセキュリティサービスプロバイダを使用します。
10,356,079ゼロ知識ボルトアーキテクチャでシングルサインオン接続を提供するためのシステムおよび方法です。
11,218,304パスワードに関する識別可能な情報をサービスプロバイダや外部の第三者に開示せずに、ゼロ知識ボルト内の漏洩したパスワードの存在の有無を検出する方法です。
10,708,237ゼロ知識ボルトアーキテクチャでチャットメッセージを提供するためのシステムおよび方法です。
8,656,504 , 8,738,934アカウント番号およびパスワードを保護するための方法および装置です。
8,868,932現在の地理的位置に関連するファイルを選択して表示するための装置です。
9,465,786ウェブサイトおよびアプリケーションにログイン資格証明を自動入力することで、モバイルコンピューティングデバイスからの迅速なログインを円滑にする方法です。
9,294,476ユーザー定義のID検証システム。
## 脆弱性レポートおよびバグ報奨金プログラム Keeper Securityは、潜在的なセキュリティ課題に関して責任ある開示を行うという業界のベストプラクティスに取り組んでいます。お客様のセキュリティとプライバシーを真剣に受け止め、KSIのお客様のプライバシーと個人情報の保護に努めます。KSIの使命は、世界で最も安全で革新的なセキュリティアプリを構築することであり、セキュリティ研究者で構成される世界的規模のコミュニティによるバグレポートは、KSIの製品とサービスのセキュリティを確保するうえでの貴重な要素であると考えています。 ユーザーを安全に保つことは、組織としての価値の中核です。KSIは誠実な研究者の情報を尊重し、サイバーセキュリティコミュニティとの継続的な関係がセキュリティとプライバシーを確保し、インターネットをより安全な場所にすることに役立つと信じています。これには、責任あるセキュリティテストとセキュリティ脆弱性の開示を奨励することが含まれます。 #### ガイドライン Keeperの脆弱性開示ポリシーには、誠実な研究者と連携する際に期待されることとKSIに期待できることが提示されています。 セキュリティテストやレポートがこのポリシーのガイドライン内で行われる場合、KSIは以下を行います。 * コンピュータ不正行為防止法に基づいて、認定されたものと見なします。 * デジタルミレニアム著作権法 (DMCA) の適用除外であると見なします。また、セキュリティやテクノロジーの規制を回避したことを理由に訴訟を起こすことはありません。 * 合法的なものと見なし、このプログラムに関連するいかなる法的措置も遂行または支持することはありません。 * 問題を迅速に把握し、解決するために連携します。 * 最初に問題を報告し、KSIがその問題に基づいてコードまたは設定を変更した場合は、その貢献を公式に認めます。 このポリシーのガイドラインおよび対象範囲に一致した方法でテストが実施されているかどうか懸念が生じた場合や確信が持てない場合は、続行する前にに連絡してください。 誠実なセキュリティテストと発見された脆弱性の開示を推奨するために、次のことをお願いします。 * プライバシーの侵害、ユーザーの操作性の低下、本番システムや企業システムの停止、データの破壊を回避します。 * 以下に示された範囲内においてのみ調査を実施し、範囲外となる制度や活動に配慮します。 * テスト中にユーザーデータが検出された場合は、直ちにに連絡してください。 * 脆弱性の発見を公表する前に、報告された問題を分析、確認、解決する十分な期間をKSIに与えます。 #### レポートの送信 KeeperはKSIの脆弱性開示プログラムを管理するために、Bugcrowdと提携しています。 ![bugcrowd](https://www.keepersecurity.com/assets/images/pages/security/bugcrowd@2x.png) \[[https: //bugcrowd.com/keepersecurity](https://bugcrowd.com/keepersecurity)]からレポートを送信してください。 ## ペネトレーションテスト Keeperは、[NCC Group](https://www.nccgroup.com/)、[Cybertest](https://www.cybertest.com/)や独立したセキュリティ研究者などの専門家と協力して、KSIのすべての製品とシステムに対してサードパーティの侵入テストと脆弱性テストを実施します。 レポートの概要は、要望に応じてエンタープライズユーザーに提供されます。 ## セキュリティに関するFAQ ### Q. Keeperの従業員がユーザーが保存しているデータを見ることができますか？ A. いいえ。KSIはゼロ知識であるため、ユーザーのデータを復号することはできません。 ### Q. マスターパスワードや暗号鍵はどこに保存されますか？ A. マスターパスワードは**保存されません**。また、マスターパスワードから取得する暗号鍵も**保存されません**。 ユーザーがマスターパスワードを入力すると、10万回の反復回数を持つPBKDF2と呼ばれるパスワード導出関数を使用して、リアルタイムで鍵が取得されます。この鍵で暗号文をアンラップしてデータキーを抽出してから、データキーでフォルダ鍵、レコード鍵、レコードデータをアンラップします。 ### Q. PBKDF2 の反復は何回使用されますか? A. KeeperはPBKDF2を100万回の繰り返しで使用しています。 ### Q. 生体認証によるログインはどのように行われますか？ A. 管理者が生体認証を有効にして許可した場合、AES-256の「生体認証鍵」がデバイス上でローカルに生成され、iOSキーチェーンに保存されます。ユーザーがFace IDまたはTouch ID認証を使用してオペレーティングシステムとの認証に成功すると、鍵はKeeperアプリケーションに提供され、保存されている暗号文をアンラップしてデータキーを取得するために使用されます。 KeeperはWindows Hello、Touch ID、Face ID、Android生体認証をネイティブでサポートしています。通常、マスターパスワードまたはエンタープライズSSOログイン (SAML 2.0) を使用してKeeperボルトにログインしているユーザーは、生体認証を使用してデバイスにログインすることもできます。生体認証はKeeper管理者がロールポリシーで有効にする必要があります。この機能を有効にすると、マスターパスワードのユーザーとSSOが有効にされているユーザーの両方が、生体認証でオフラインアクセスすることも可能になります。 ### Q. ブルートフォースパスワード攻撃からはどのように保護するのですか？ A. Keeperはパスワードスタッフィングとパスワードブルートフォース攻撃に対して、複数の保護レイヤーを実装しています。承認されていないデバイスのログインは許可していません。承認されると、最初のステップは二要素認証です。二要素認証を通過した場合のみ、ユーザーはパスワードテストを試みることができます。パスワードの試行に10回失敗すると、アカウントは試行ごとに指数関数的にロックされます。Keeperの自己破壊メカニズムをローカルデバイスで有効にして、5回失敗した場合にローカルで保存されたデータを削除することもできます。ログインAPIの詳細は、[こちら](https://docs.keeper.io/jp/enterprise-guide/login-api)をご参照ください。 ### Q. 二要素認証攻撃からはどのように保護するのですか？ A. Keeperでは承認されていないデバイスのログインを許可していません。(メール認証、Keeper Push、または二要素認証コードの入力のいずれかから) デバイスが承認されると、ユーザーに二要素認証のプロンプトが表示されます。二要素認証に10回失敗すると、失敗するたびにアカウントが指数関数的にロックされます。 ### Q. 列挙攻撃からはどのように保護するのですか？ A. [ログインAPI V3](https://docs.keeper.io/jp/enterprise-guide/login-api)により、Keeperクラウドインフラストラクチャに対するユーザー列挙の防止において大きな進歩を遂げています。つまり、サーバーはユーザーのアカウントの存在の有無を開示しないということを意味します。信頼しているデバイスや既知のデバイス、またはIPからユーザーがログインしていない限り、列挙は拒否されます。 Keeperは複数の分離されたデータセンターを運営しており、データセンター間の列挙は拒否されているため、ユーザーが間違ったデータセンターからログインしようとすると、ラウンドトリップとメール認証を行わなければならない場合があります。 ウェブインターフェースから開示することはできないため、ログインとリダイレクトを伝えるためにメールが利用されます。 ### Q. データにアクセスしない状態で、どのようにポリシーを強制するのですか？ A. ユーザーがデバイスにログインすると、すべてのエンタープライズポリシーはKeeperクラウドからダウンロードされ、レコードレベルのフィルタリング、URLフィルタリング、パスワード固有ルールと処理を必要とするポリシーについては、デバイス上でローカルに処理されます。 ### Q. なぜKeeperにはアカウント復元手段としてリカバリーフレーズが利用できるのですか？ A. アカウントの回復は、ユーザーが管理コンソールのロールポリシーセクションで無効にすることができます。これは、サードパーティのIDプロバイダを利用するSSOクラウドを使用している場合に必要になることがあります。\ \ アカウント回復の仕組み (リカバリーフレーズ方式) は、ユーザーの24単語の回復フレーズから生成された256ビットAESキーで暗号化された、ユーザーのデータキーの2番目のコピーを保存することによって行われます。ボルトの回復を完了するには、データキーを復号化するために、ユーザーは1. メール認証コードを入力し、2. 二要素認証手順 (アカウントで有効になっている場合) を通過し、3. デバイス上でローカルにリカバリーフレーズを正確に入力する必要があり、次に、マスターパスワードのリセットをユーザーに許可します。お使いのアカウントの設定メニューで、アカウントリカバリーを有効にし、Keeperの二要素認証機能をオンにすることをお勧めします。\ \ アカウントリカバリーを無効にし、「アカウント移管」管理機能に依存したいエンタープライズのお客様は、このポリシーを設定することが可能です。アカウント回復を無効にした場合、マスターパスワードを忘れたり、SSO IdPにアクセスできなくなった場合にユーザーを回復できる唯一の方法は、アカウント移管となることに注意してください。 ### Q. 従業員をオフボーディングさせて、そのボルトにアクセスするにはどうすればよいですか？ A. ビジネスユーザーやエンタープライズユーザーには、Keeperのアカウント移管ポリシーを使用する、アカウントの回復のためのゼロ知識方式が提供されています。 アカウント移管ポリシーについては、[こちらのページ](https://docs.keeper.io/jp/enterprise-guide/account-transfer-policy)をご参照ください。 ### Q. Keeperがゼロナレッジであるなら、どのようにして新しいデバイスでボルトにアクセスできますか？ A. 最初のデバイスでは、各ユーザーに固有の256ビットAES「データキー」が生成されます。消費者およびマスターパスワードでログインするユーザーの場合、選択したマスターパスワードを使用して、1,000,000回のPBKDF2を経てキーが導出され、このキーがローカルでデータキーを暗号化および復号化するために使用されます。 Keeperクラウドでは、このデータキーの暗号化されたバージョンを保存します。新しいデバイスでログインし、マスターパスワードを入力すると、ローカルでキーが導出され、ハッシュ化され、クラウドとの認証に使用されます。認証が成功し (デバイス検証と2FAのステップを通過した後)、暗号化された暗号文がデバイスに送信され、その後、マスターパスワードから導出されたキーを使用してデバイスで暗号文を復号化します。これによりデータキーが生成され、ローカルでボルトの復号化に使用されます。 マスターパスワードを変更した場合、新しいマスターパスワードから導出されたキーがAES-256データキーを暗号化します。その結果得られた暗号化されたキーは再びクラウドに保存されます。マスターパスワードは決してデバイスから外部に送信されることはありません。 SSO (シングルサインオン) でログインするユーザーは、上記の[クラウドSSO](#kuraudossokonekutodtafur)の項目に記載された異なるプロセスに従います。 ## 暗号鍵の大きさの比較 このセクションでは、KeeperのAES-256暗号化方式 (マスターパスワード認証を使用) とECC-256の強度 (Keeper SSO ConnectによるSSO認証を使用する場合) について詳しく説明します。 ### AES 128bまたは256bの鍵をブルートフォースするのに必要な時間は？ 対称暗号化には、KeeperはAES-256を使用しています。Advanced Encryption Standard (AES) は、擬似ランダム順列であると仮定されます。[PRP/PRF切り替えのレンマ](https://web.cs.ucdavis.edu/~rogaway/classes/227/spring05/book/main.pdf)により、これは鍵の回復がブルートフォース鍵の列挙を必要とすると仮定します。 仮定 * 1ns/候補鍵 (これは3サイクル/鍵と3GhZ CPUを想定) * 攻撃側は100万CPUを並列動作させる **AES-128** = 2^128鍵 / (1 ns/鍵 \* 10^6) = 2^108 ns >= 10^16年 **AES-256** = 2^256鍵 / (1 ns/鍵 \* 10^6) = 2^108 ns >= 10^54年 AES-256はAES-128よりかなり長く、どちらも現存する以上の計算資源と10億年以上の計算時間を必要とします。いずれのアルゴリズムも、AESに対する最もよく知られた攻撃を考えると、鍵の列挙はあり得ない攻撃手段であると考えられています。 #### ECC-256とAES-256の組み合わせ ECC-256は、これらの楕円曲線に対する最もよく知られた攻撃を考えると、128bの鍵の列挙しかできません。これはAES-128の半分の強度です。確かに、ECC-256に対する鍵の列挙攻撃は、AES-256に対する攻撃よりも容易であると思われます。しかし、AES-256とAES-128の性能差は無視できますが、ECC-256とECC-512の性能差は顕著で、一部のライブラリは残念ながら512b版の楕円曲線をサポートしていません。 #### ECC-512の使用状況 前述の通り、AES-128とAES-256に対する鍵列挙攻撃は非現実的であり、AES-256の鍵列挙攻撃は、AES-128とAES-256に対する鍵列挙攻撃は非現実的です。しかし、性能が低下することはほとんどなく、AES-256はすべての開発ライブラリでサポートされているため、実装は簡単で標準的です。ECC-512の使用は、普遍的にサポートされておらず、性能上のペナルティが顕著であるため、困難です。 注目すべきは、ビットコインのブロックチェーンがECC-256を使用していることです。これにより、256b楕円曲線の強度に事実上3000億ドルの懸賞金がかけられています。 #### マスターパスワードに適用されるPBKDF2によるAES鍵の強度 AES鍵のサイズ (128b、192b、256b) にかかわらず、AES鍵がパスワードと鍵導出関数から導出される場合、鍵の強度はパスワードの強度と鍵導出関数の複雑さを組み合わせたものに制限される可能性が非常に高い。 KeeperはPBKDF2 ([NIST SP 800-132](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf)) を100万回の繰り返しで使用しています。(注 Keeperは2023年1月3日から100万回の反復にユーザーを移行し始めました）。 派生鍵は、(パスワードのエントロピー) にlog2 (反復回数) を加えた強度を持ち、AES-256の場合は最大256までとなります。 * 100,000回繰り返した場合: log2(10^5) = 16.6 * 1,000,000回繰り返した場合: log2(10^6) = 19.9 [経験的な調査](https://www.ra.ethz.ch/CDStore/www2007/www2007.org/papers/paper620.pdf)によると、人間が使用する平均的なパスワードは40.5bのエントロピーを持つことが分かっています。これは、平均的な強度のパスワードから導かれるAES鍵が、次のようになることを意味します。 * 100,000回繰り返した場合: 40.5+16.6=57.1bのエントロピー。 * 1,000,000回繰り返した場合: 40.5+19.6=60.1bのエントロピーとなります。 これに対して、ランダムに生成されたECC-256の鍵は128bのエントロピーを持ちます。 ## その他の参考資料 GDPRコンプライアンス\ [https: //keepersecurity.com/GDPR.html](https://keepersecurity.com/GDPR.html) ホワイトペーパー、データシート、ケーススタディ\ [https: //keepersecurity.com/resources.html](https://keepersecurity.com/resources.html) クラウドSSOコネクトのセキュリティモデル\ [https: //docs.keeper.io/sso-connect-cloud/security-and-user-flow](https://docs.keeper.io/sso-connect-cloud/security-and-user-flow)\ \ さらにご質問や資料のご要望がございましたら、**** まで電子メールでお問い合わせください。 ## 脆弱性情報開示プログラム Keeper Securityは、潜在的なセキュリティ課題に関して責任ある開示を行うという業界のベストプラクティスに取り組んでいます。お客様のセキュリティとプライバシーを真剣に受け止め、KSIのお客様のプライバシーと個人情報の保護に努めます。KSIの使命は、世界で最も安全で革新的なセキュリティアプリを構築することであり、セキュリティ研究者で構成される世界的規模のコミュニティによるバグレポートは、KSIの製品とサービスのセキュリティを確保するうえでの貴重な要素であると考えています。\ \ ユーザーを安全に保つことは、組織としての価値の中核です。KSIは誠実な研究者の情報を尊重し、研究者のコミュニティとの継続的な関係がセキュリティとプライバシーを確保し、インターネットをより安全な場所にすることに役立つと信じています。これには、責任あるセキュリティテストとセキュリティ脆弱性の開示を奨励することが含まれます。 ### **ガイドライン** Keeperの脆弱性開示ポリシーには、研究者と連携する際に期待されることと、KSIに期待できることが提示されています。 セキュリティテストやレポートがこのポリシーのガイドライン内で行われる場合、KSIは以下を行います。 * コンピュータ不正行為防止法に基づいて、認定されたものと見なします。 * デジタルミレニアム著作権法 (DMCA) の適用除外であると見なします。また、セキュリティやテクノロジーの規制を回避したことを理由に訴訟を起こすことはありません。 * 合法的なものと見なし、このプログラムに関連するいかなる法的措置も遂行または支持することはありません。 * 問題を迅速に把握し、解決するために連携します。 * 最初に問題を報告し、KSIがその問題に基づいてコードまたは設定を変更した場合は、その貢献を公式に認めます。 このポリシーのガイドラインおよび対象範囲に一致した方法でテストが実施されているかどうか懸念が生じた場合や確信が持てない場合は、続行する前にに連絡してください。 誠実なセキュリティテストと発見された脆弱性の開示を推奨するために、次のことをお願いします。 * プライバシーの侵害、ユーザーの操作性の低下、本番システムや企業システムの停止、データの破壊を回避します。 * 以下に示された範囲内においてのみ調査を実施し、範囲外となる制度や活動に配慮します。 * テスト中にユーザーデータが検出された場合は、直ちにに連絡してください。 * 脆弱性の発見を公表する前に、報告された問題を分析、確認、解決する十分な期間をKSIに与えます。 ### **レポートの送信** KeeperはKSIの脆弱性開示プログラムを管理するために、Bugcrowdと提携しています。\[[https: //bugcrowd.com/keepersecurity](https://bugcrowd.com/keepersecurity)]からレポートを送信してください。