Keeperの暗号化モデル

Keeperの暗号化とセキュリティモデルの詳細については、ブロック図、実装の詳細、その他のリソースと併せて以下に概説します。

ゼロ知識とゼロトラストのアーキテクチャ

Keeperはゼロ知識セキュリティプロバイダです。ゼロ知識は、最高レベルのセキュリティとプライバシーを保証するシステムアーキテクチャです。データの暗号化と復号化は、必ずユーザーのデバイス上でローカルに実行されます。

Keeperの暗号化モデルは、次の構造に準拠しています。

  1. 各ボルトのレコードは、GCMモードでクライアント側で一意に生成された256ビットAES暗号化鍵によって暗号化されます。

  2. 各レコードレベルの鍵は、共有フォルダ内に含まれている場合、256ビットAES共有フォルダ鍵でラップされます。

  3. ボルトユーザーの場合、レコード鍵とフォルダ鍵はデータキーと呼ばれる別のAES-256鍵で暗号化されます。

  4. Secrets Managerユーザーの場合、レコード鍵とフォルダ鍵は256ビットAESアプリケーションキーで暗号化されます。

  5. マスターパスワードでログインするユーザーの場合、データを復号化と暗号化するためのキーは、ユーザーのマスターパスワードから得られます。

  6. SSOまたはパスワードレス技術でログインするユーザーは、デバイスレベルでデータの暗号化と復号化を行うために楕円曲線暗号方式が使用されます。

  7. Keeperサーバーに送信されるすべての暗号化ペイロードは、中間者攻撃から保護するために、TLSに加えて256ビットAES送信キーによってさらにラップされます。送信キーはクライアントデバイスで生成され、サーバーのEC公開鍵を介してECIES暗号化を使用してサーバーに転送されます。

  8. ユーザー間の秘密の共有では、楕円曲線暗号を使用して安全な鍵配布が行われます。

  9. マルチレイヤー暗号化は、ユーザー、グループ、および管理者レベルでのアクセス管理を提供します。

データは、Keeperのクラウドセキュリティボルトに送信されて保存される前に、ユーザーのデバイス上でローカルに暗号化されます。データが別のデバイスに同期されると、データは他のデバイスで復号化されるまで暗号化されたままとなります。

Keeperは、世界で最も安全で、認証され、テストされ、監査されたパスワードセキュリティプラットフォームです。Keeperは業界で最も長い歴史を誇るSOC 2およびISO認証を保持しています。KeeperはISO 27001、27017、27018の認証を受けています。KeeperはGDPR、CCPA、HIPAAに準拠しており、FedRAMPおよびStateRAMPの認可を受け、PCI DSS認証を取得し、TrustArcによるプライバシー認証を受けています。

Keeperは、米国商務省が定めたEU-U.S.データプライバシーフレームワーク(「EU-U.S. DPF」)、EU-U.S. DPFへの英国の拡張、およびスイス-U.S.データプライバシーフレームワーク(「Swiss-U.S. DPF」)に準拠しています。私たちは最も安全なレベルの暗号化を実装するだけでなく、非常に厳格な内部の実践を守り、これらは第三者によって継続的に監査されており、セキュアなソフトウェアの開発を進め、世界で最も安全なサイバーセキュリティプラットフォームを提供し続けるために役立っています。

データプライバシー

KeeperはEU一般データ保護規則 (GDPR) を遵守し、欧州連合のお客様のために、当社のビジネスプロセスと製品がコンプライアンスを維持し続けるように全力を尽くしています。

プライバシーポリシーは、こちらをご覧ください。

https://www.keepersecurity.com/privacypolicy.html

Keeperのデスクトップアプリケーション、ウェブアプリケーション、およびモバイルアプリケーションには、トラッキングを実行するトラッカーやサードパーティライブラリーは含まれていません。例えば、KeeperのAndroidアプリにトラッカーがインストールされていないという情報を確認するには、こちらのリンクをご確認ください

データ分離

Keeperは完全なSaaSプラットフォームであり、現在以下のAmazon AWSデータセンターでデータをホストしています。お客様は、希望した第一地域でKeeperテナントをホストできます。顧客データ (保存された暗号文)、およびプラットフォームへのアクセスは、特定の地域に限定されます。

使用可能な地域

  • 米国 (US)

  • 米国政府クラウド (US_GOV)

  • 欧州 (EU)

  • オーストラリア (AU)

  • 日本 (JP)

  • カナダ (CA)

FIPS 140-3の検証

Keeperは、FIPS 140-3で検証されている暗号化モジュールを使用して、政府および公共部門の厳しいセキュリティ要件に対応しています。Keeperの暗号化は、NIST CMVPによって認定され、認定サードパーティの研究所によってFIPS 140標準に対しても認証されています。

Keeperは、NIST CMVPで証明書#4743を取得しています https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3976

FedRAMPの認定取得

Keeper Security Government Cloud (KSGC) は、公共機関向けのKSIのパスワード管理およびサイバーセキュリティプラットフォームです。KSGCは、AWS GovCloud (米国) でホストされるModerate Impact LevelのFedRAMP Authorizedプロバイダです。KSGCについては、FedRAMP Marketplaceでご確認ください。

米国連邦リスク認証管理プログラム (FedRAMP: Federal Risk and Authorization Management Program) は、クラウド製品およびサービスのセキュリティ評価、認可、継続的なモニタリングに対する標準化されたアプローチを提供する米国連邦政府のプログラムです。FedRAMPは、政府機関が連邦政府の情報のセキュリティと保護に重点を置いた最新のクラウドテクノロジーを使用できるようにして、安全なクラウドソリューションの採用を促進しています。FedRAMPの詳細は、https: //www.gsa.gov/technology/government-it-initiatives/fedrampをご参照ください。

ITAR準拠

KSGCは、米国国際武器取引規則 (ITAR: International Traffic in Arms Regulations) の遵守をサポートしています。ITARの輸出規制の対象となる企業は、保護されたデータへのアクセスを米国国民に限定し、保護されたデータの物理的な場所を米国に制限することで、意図しない輸出を制御する必要があります。

KSGCのFedRAMP Moderate環境では、以下を行うことでITAR要件をサポートしています。

  • AWS GovCloudでホストされ、米国に限定された完全準拠のデータストレージ。

  • 送信時よび保存中のセキュリティが確保されたデータ暗号化。

  • ゼロ知識とゼロトラストセキュリティでは、詳細なアクセス許可を併用して、承認された担当者のみが機密データにアクセスできるようにします。

  • 堅牢なコンプライアンスレポート機能により、実行されたすべての操作や入力されたデータの追跡可能な電子監査証跡を提供します。

  • 隔離されたCustomer Successチームは、輸出規制対象データおよびITAR準拠データの安全な取り扱いで特別な訓練を受けた米国国民で構成されています。

  • 米国以外を拠点とするサポートはありません。

Keeper FedRAMP環境は、独立した第三者評価機関 (3PAO) の監査を受け、お客様の輸出コンプライアンスプログラムをサポートする適切な管理が行われていることが検証されています。

ITARの詳細については、https: //www.pmddtc.state.gov/をご覧ください。

エンドツーエンド暗号化 (E2EE)

Keeperのプラットフォームは、すべてのデバイスおよびエンドポイントにわたってエンドツーエンド暗号化 (E2EE) で構築されています。この技術アーキテクチャドキュメントに記載されている通り:

  • プラットフォームに保存されるデータはローカルで暗号化され、ユーザーのデバイス間で転送中に暗号化されます。

  • Keeperユーザー間で交換される情報は、ボルト間で暗号化されます。

  • 静止データは、レコードレベルでAES-256暗号化を使用して複数のレイヤーで暗号化されます。

  • 転送中のデータはTLSと追加の転送暗号化レイヤーで暗号化され、MITM攻撃、サービスプロバイダー、不信なネットワークからのアクセスを防ぎます。

レコードレベルの暗号化

Keeperは、クライアント側で生成された鍵による多層暗号化方式を実装します。レコードレベルのキーとフォルダレベルのキーは、ローカルデバイスで生成され、保存されている個々のボルトレコード (例 パスワード) を暗号化します。 例えば、ボルトに1万件のレコードがある場合は、データを保護するAESレコード鍵も1万個あります。

鍵はデバイス上でローカルに生成されて、ゼロ知識を保持し、記録やフォルダの共有などの高度な機能をサポートします。 レコード鍵とフォルダ鍵は、データキーやクライアント鍵などの他の鍵によってラップされます。

ボルト内のすべてのフィールドとすべてのデータは、添付ファイルを含めて暗号化されています。

マスターパスワードでログインするユーザーの場合

マスターパスワード鍵は、PBKDF2を使用してマスターパスワードから派生し、データキーの展開に使用されます。データキーは、レコード鍵とフォルダ鍵の展開に使用されます。 次に、レコード鍵を使用して、ボルトに保存されているレコードの情報を復号化します。 各レコードのすべてのデータフィールドは、添付ファイルも含めてすべて暗号化されます。

KeeperクラウドSSOコネクトでログインするユーザーの場合

ローカルに保存された楕円曲線 (EC: Elliptic Curve) 鍵のペアがローカルに生成され、ユーザーのデータキーが暗号化および復号化されて、レコード鍵とフォルダ鍵が展開されます。

鍵のラッピングの詳細については、以下の保存データの暗号化セクションで説明します。

KeeperオンプレミスSSOコネクトでログインするユーザーの場合

マスターパスワードハッシュと256ビットAESマスターパスワード鍵は、オンプレミスSSOクラウドアプリケーションによって生成されます。

エンタープライズ暗号鍵

ビジネスおよびエンタープライズのユーザーは、ロールベースの強制ポリシー、プロビジョニング、認証、チーム管理など、Keeperプラットフォームの多岐にわたる機能を管理できます。

管理機能は、認証に加えて、暗号化することによりKeeperプラットフォームで保護されます。 認証により、管理者はプラットフォームの特定の機能にアクセスできますが、指定されたユーザーのみが物理的に機能を実行したり、機密情報を表示したりするなど、暗号化は多くの点で活用されます。

管理機能内の様々な機能は、ゼロ知識とゼロトラストを維持しながら機能するうえで鍵の復号化が必要です。以下に例を示します。

  • チームには公開鍵と秘密鍵のペアがあります。

  • ボルト転送およびデバイス承認のロールポリシーでは、公開鍵と秘密鍵のペアを使用します。

  • エンタープライズレベルの鍵ペアは、個々のユーザーから管理者に使用状況データを共有するために使用されます。

  • パスワード強度およびその他の機密性の高い使用データの監査は、管理者のみが復号化できるエンタープライズ公開鍵を使用して暗号化されます。

Keeperのプラットフォームは、総じて、鍵がユーザーとKeeper管理者を完全に制御する鍵管理プラットフォームと考えることができます。 鍵管理に内在する複雑さは、使いやすいフロントエンドインターフェースによってユーザーには概念化されてています。

クラウド認証

Keeperは、最高レベルのプライバシー、セキュリティ、信頼性を実現する高度なクラウド認証とネットワーク通信モデルを構築しています。 認証モデルの主な機能は、次のとおりです。

  • マスターパスワードの送信はネットワーク層を経由しません 多くのSaaSサービスとは異なり、ログイン認証情報がデバイスから離れることはありません。PBKDF2は、復号化に使用される256ビットAESキーを取得するためにローカルデバイスで使用されます。2つ目のPBKDF2キーがローカルで生成されると、HMAC_SHA 256でハッシュ化されて認証トークンを取得します。Keeper's Cloud Security Vaultは、ユーザーの復号キーについてゼロ知識です。

  • クライアントデバイスとKeeper Cloud間のトラフィックの傍受や復号化はできません Keeperは、デバイスとKeeperサーバー間でKey Pinningとネットワークレベルの暗号化 (トランスミッションキー) の追加レイヤーを利用して、中間者 (MITM) 攻撃を防止します。

  • デバイス検証手順を実行しない限り、新しいデバイスはアカウントにログインできません この手順を踏まないと、アカウントにログインしようとすることはできません。 Keeperでは、使用されている認証スキームに応じて、複数のタイプのデバイス検証方式に対応しています。

  • 二要素認証は、デバイスの検証後、マスターパスワードの入力前に実行されます ユーザーが二要素認証を設定または強制している場合、マスターパスワードを入力する前にこの手順を踏む必要があります。

  • デバイスの確認と二要素認証の手順が成功するまでは、マスターパスワードを入力できません ユーザーは、最初にデバイスの検証と二要素認証を実行しないと、マスターパスワードの入力手順に進むことができません。 このような高度な認証フローにより、ブルートフォース攻撃、パスワードスプレー、列挙攻撃や中間者攻撃などのさまざまな攻撃ベクトルから保護します。

認証方式

Keeperでは、プラットフォームの認証に複数の方法を用意しています。

  • マスターパスワード

  • SAML 2.0を使用したSSO (オンプレミス)

  • SAML 2.0を使用したSSO (クラウド)

  • SSO代替マスターパスワード

  • 生体認証

デバイスの確認

ユーザーは、デバイスの承認と確認の手順を踏まないと、アカウントにログインを試みることはできません。

マスターパスワードを使用してログインするユーザーは、複数の新しい方法を使用してデバイス確認を実行できます。これには次の方法が含まれます。

  • メール認証コード

  • タイムベースワンタイムパスワード (TOTP) またはSMS通知の二要素認証コードを入力します

  • 認識されたデバイスにKeeper Push™メッセージを送信します

KeeperクラウドSSOコネクトで認証するユーザーの場合、デバイス承認は鍵転送で構成されます。鍵転送では、ユーザーの暗号化されたデータキーがデバイスに送信され、そのデータキーは楕円曲線の秘密鍵を使用してローカルで復号化されます。デバイスの承認方法には、次のものがあります。

  • 既存のユーザーデバイスへのKeeper Push (プッシュ通知を使用)

  • Keeper管理コンソールからの管理者承認

  • Keeper Automatorサービスによる自動承認

  • コマンダーCLIによる自動管理者承認

  • Azure機能による自動管理者承認

デバイス承認の詳細については、こちらのリンクをご参照ください。

二要素認証の検証

二要素認証は、任意の個人アカウントまたは法人アカウントに追加できます。 法人ユーザーは、さまざまなレベルの制御およびセキュリティオプションと二要素認証の使用を強制できます。

KeeperバックエンドAPIのバージョン3 (Keeperクライアントアプリケーションのバージョン15以降に対応) 以降では、マスターパスワードを入力する前に二要素認証の手順があります。 マスターパスワードの入力段階の前にデバイス検証と二要素認証手順を実行すると、ブルートフォース攻撃、パスワードテストやアカウント列挙攻撃など、さまざまな攻撃ベクトルを低減できます。

マスターパスワード

ユーザーのボルトのレコードは、デバイス上でランダムに生成される 256ビットAES-GCM「レコード鍵」を使用してローカルで暗号化されます。レコード鍵は、256ビットAES-GCM「データ鍵」で暗号化されます。このデータ鍵もユーザーのデバイス上でランダムに生成され、各ユーザーに固有です。マスターパスワードでログインするユーザーの場合、データ鍵は、128ビットのランダムに生成されたソルトと 1,000,000回の反復を含むPBKDF2-HMAC-SHA256を使用して、ユーザーのマスターパスワードから派生した鍵で暗号化されます。暗号化されたボルトの暗号文は Keeperクラウドに保存されます。

認証のために、1,000,000回の反復と128ビットのランダムに生成されたソルトを使用して、2番目の PBKDF2鍵がユーザーのデバイス上でローカルに生成されます。この鍵はSHA256 でハッシュ化され、認証トークンが導出されます。Keeperクラウドでは、認証トークンは「ユーザー認証」キーで超暗号化されます。ユーザー認証キーはサーバーによってランダムに生成され、保存する前にハードウェアセキュリティモジュール (エクスポート不可能なキー) で暗号化されます。ユーザー認証キーは、ソルト、認証トークン、ユーザーの暗号化データ・キー、およびバイオメトリクスなどの代替認証方法のためのその他の認証関連フィールドを暗号化するために使用されます。

SAML 2.0を使用したSSO (クラウド)

KeeperのSSOクラウド機能は、SAML 2.0 IDプロバイダに対する認証を提供しながら、ユーザーのボルトで完全なゼロ知識暗号化を維持します。 楕円曲線(secp256r1)秘密鍵ペアがデバイス上で生成されます。 ユーザーのデータキーはデバイスの秘密鍵で復号化され、指定されたIDプロバイダによる認証が成功すると、暗号化されたデータキーがユーザーに提供されます。

SAML 2.0を使用したSSO (オンプレミス)

SAML 2.0 IDプロバイダでKeeperを認証するユーザーの場合、Keeper SSO Connectソフトウェアはユーザー環境でホストされます。SSO Connectソフトウェアは、ユーザーのマスターパスワードを生成し、管理します。 生成されたマスターパスワードは、データキーなどのユーザーが所有するその他の鍵を復号する鍵を取得するために、ストレッチング回数を10万回に設定されたPBKDF2で処理されます。

SSO代替マスターパスワード

通常、エンタープライズSSOログイン (SAML 2.0) を使用してKeeperボルトにログインしているユーザーは、「代替マスターパスワード」を使用して、Keeperウェブボルト、ブラウザ拡張機能やKeeperコマンダーにもログインできます。この機能を利用するには、Keeper管理者がロールポリシーで有効にしてから、ユーザーが設定する必要があります。この機能を有効にすると、SSOが有効にされてユーザーはマスターパスワードでオフラインアクセスすることも可能になります。

この機能は、次のような複数の理由からユーザーに役立つことがあります。

  • オフラインモードでボルトにログインするための要件

  • SSO IDプロバイダが利用できない場合のボルトへのログイン機能

  • KeeperコマンダーCLI (コマンドラインインターフェース) による認証

PBKDF2は、ストレッチング回数が10万回に設定され、代替マスターパスワードから鍵を取得するために使用されます。 鍵のハッシュ値で認証を行い、その鍵でユーザーのデータキーをデバイス上でローカルに復号します。 SSOマスターパスワードの詳細については、こちらのリンクをご参照ください。

生体認証

KeeperはWindows Hello、Touch ID、Face ID、Android 生体認証をネイティブでサポートしています。通常、マスターパスワードまたはエンタープライズSSOログイン (SAML 2.0) を使用してKeeperボルトにログインしているユーザーは、生体認証を使用してデバイスにログインすることもできます。生体認証はKeeper管理者がロールポリシーで有効にする必要があります。この機能を有効にすると、マスターパスワードのユーザーとSSOが有効にされているユーザーの両方が、生体認証でオフラインアクセスすることも可能になります。

デバイスで生体認証ログインが有効になっている場合、鍵はローカルでランダムに生成され、デバイスのセキュアエンクレーブ (例 Keychain) に保存されます。 ユーザーのデータキーは生体認証鍵で暗号化されます。 生体認証に成功すると、鍵が取得され、ユーザーは自分のボルトを復号することができます。

Keeperはユーザーの生体認証データの保管や処理は行いません。 Keeperはオペレーティングシステムの既存の生体認証機能と統合され、ユーザーを認証し、デバイスのセキュアエンクレーブで保護された暗号鍵を取得します。

保存データの暗号化

ユーザーの新規作成

  • パスワードベースの認証では、ユーザーはアカウントプロファイルを作成する際に「マスターパスワード」を選択する必要があります。また、FIDO2 WebAuthn、TOTP、Duo Security、RSA SecurID、SMS、SmartWatchを使用した第二要素認証を設定することもできます。

  • ユーザーがKeeperクラウドSSOコネクトを介して認証されている場合、256ビットの楕円曲線 (EC secp256r1) 秘密鍵が生成され、各デバイスにローカルで保存されます。 EC秘密鍵はデータキーを復号するために使用され、データキーはユーザーのボルトを復号します。 この暗号化モデルでは、マスターパスワードは使用されません。

  • ユーザーがKeeperオンプレミスSSOコネクト (SAML 2.0 IDプロバイダとの統合) を介して認証された場合、マスターパスワードとAES-256キーはSSO Connectソフトウェア (オンプレミスでエンタープライズ顧客によってホストされ、運営されている) によって自動生成されます。

  • ECデバイスの秘密鍵は、直接的にボルトデータの暗号化や復号化には使用されません。 IDプロバイダによる認証が成功すると、ボルトデータの復号に (保管されていない) 別の鍵が使用されます。 ローカルデバイスの秘密鍵をオフラインで抽出しても、ユーザーのボルトは復号化できません。

  • マスターパスワードは、ストレッチング回数が最低百万回に設定されたパスワード方式の鍵生成関数 (PBKDF2) を使用して、クライアントデバイスの暗号鍵を取得されます。

  • クライアント・デバイス上では、256ビットのAES「データ鍵」と「クライアント鍵」、およびユーザーとチーム間でレコードを共有するための「ユーザーEC秘密鍵/公開鍵ペア」が生成されます。(古い共有レコードとの互換性のため、2048ビットRSA秘密鍵/公開鍵ペアも生成されます)。

新規ユーザー登録暗号化モデル

データストレージ

  • 「データキー」は、Cloud Security Vaultに同期されるデータを暗号化するために使用されます。マスターパスワード方式の認証の場合、「データキー」はマスターパスワードから取得される「マスターパスワード鍵」で暗号化され、この暗号文はCloud Security Vaultに保存されます。 SSOクラウドベースの認証では、ローカルの (secp256r1) 秘密鍵を使用してデータキーを復号します。 データキーは、ユーザーのボルトを復号化します。

  • 「クライアント鍵」は、ユーザーのデバイスにローカルで保管されているデータを暗号化するために使用されます。「クライアント鍵」は「データキー」で暗号化され、この暗号文はCloud Security Vaultに保存されます。マスターパスワード方式の認証の場合、「クライアント鍵」はマスターパスワードから取得される「マスターパスワード鍵」で暗号化され、この暗号文はオフラインで使用するためにCloud Securityボルトに保存されます。 オフラインモードは、エンタープライズ管理者が強制適用ポリシーを通して管理できます。

  • オフラインで保管されたボルトデータは、ランダムに生成された256ビットの「クライアント鍵」でAES-GCM暗号化され、最大10万回のストレッチング回数とランダムソルトを使用したPBKDF2-HMAC-SHA512で保護されます。ソルトとストレッチング回数はローカルに保存されます。ユーザーが「マスターパスワード」を入力すると、ソルトと反復回数を使用した鍵が取得され、「クライアント鍵」の復号を実行します。次に「クライアント鍵」を使用して、保存されたレコードキャッシュを復号します。

  • 「デバイスEC公開鍵」はCloud Security Vaultに直接格納されます。

  • 「デバイスEC秘密鍵」はデバイス上にローカルに保存され、デバイスの外に出ることはありません。これはクラウドSSO認証モデルに使用されます。

  • 「ユーザーEC公開鍵」は、Cloud Security Vaultに直接保存されます。

  • 「ユーザーEC秘密鍵」は「データキー」で暗号化され、暗号文はCloud Security Vaultに保存されます。

  • 作成された各レコード (例 ウェブサイトのパスワードやファイル) に対して、256ビットのAES「レコード鍵」がクライアントデバイス上で生成されます。「レコード鍵」は、レコード内容の暗号化および復号化に使用されます。「レコード鍵」はユーザーの「データキー」で暗号化され、その暗号文はCloud Security Vaultに保存されます。また、レコード鍵とレコードデータは「クライアント鍵」で暗号化され、その暗号文はデバイスにローカルで保存されます。

マスターパスワードでログイン

  • ユーザーが (マスターパスワードで) デバイスにログインすると、最初にマスターパスワードから取得した鍵からクライアント鍵を復号します。

  • クライアント鍵は、デバイスにローカルで保存されたすべてのデータを復号するために使用されます。

  • ローカルでアンラップされたデータキー、または認証の成功時にCloud Security Vaultから取得されたデータキーは、ユーザーのマスターパスワードから取得した鍵で復号化されます。

  • レコード鍵の暗号文は、Cloud Security Vaultから同期され、ユーザーのデータキーを使用してローカルで復号化されます。共有フォルダ鍵は、各フォルダのそれぞれの共有フォルダ鍵で復号化されます。レコードの内容は、各レコードのそれぞれのレコード鍵で復号化されます。レコード鍵とレコードの内容は、クライアント鍵で暗号化され、ローカルに保存されます。

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

共有

  • Keeperレコードを他のユーザーと共有するために、KeeperはまずCloud Security Vaultからユーザーの楕円曲線公開鍵を要求します。

  • 各レコードのレコード鍵は受信者の楕円曲線公開鍵で暗号化され、Cloud Security Vaultを介してユーザーのKeeperボルトに同期されます。

  • 暗号化された共有レコードの受信者は、楕円曲線秘密鍵を使用してレコード鍵を復号化します。 最適化のため、レコード鍵はユーザーのデータキーで再暗号化され、暗号文は受信者のCloud Security Vaultに保存されます。

  • 後続のレコード取得では、受信者はデータキーを使用してレコード鍵を復号化し、次にレコード鍵を使用してレコード内容を復号化します。

  • Keeper の従来の「一般」レコードタイプとの互換性を維持するために、2048ビットRSA秘密/公開鍵ペアも利用されることに注意してください。

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

乱数ジェネレータ

Keeperクライアントデバイスのすべての暗号化関数では、安全な乱数ジェネレータが使用されます。例えば、Keeperウェブボルトやブラウザ拡張機能のようなウェブベースのアプリケーションでは、Web Crypto APIのgetRandomValuesメソッドが使用されます。iOSでは、SecRandomCopyBytesメソッドが使用されます。Androidでは、SecureRandomが使用されます。

送信中の暗号化

Keeper Cloud Security Vaultは、クライアントデバイスによる認証を通して検証されるAPIによって保護されています。クライアントは、ログイン時にセッショントークンを取得し、API呼び出しごとにそのトークンを送信します。セッショントークンはサーバー上で追跡されます。ログインは、マスターパスワード、セッションの再開、またはSAML 2.0 SSO認証のいずれかによって実行されます。

マスターパスワードを使用する際に、クライアントデバイスは、PBKDF2-HMAC-SHA256を1,000,000 回反復し、128ビットのランダムソルトを使用して256ビットの「認証鍵」を導出します。SHA-256を使用して認証鍵をハッシュ化することで「認証ハッシュ」が生成されます。ログインするには、認証ハッシュをCloud Security Vaultに保存されている認証ハッシュと比較します。ログイン後、セッショントークンはサーバー上で生成され、後続のAPIリクエストとして使用するためにクライアントデバイスに送信されます。クライアントからサーバーへの通信を継続して使用できるようにするには、セッションをアクティブにする必要があります。

KSIは、256ビットおよび128ビットのTLS (1.3と1.2) をサポートし、クライアントアプリケーションとKSIのクラウドベースのストレージ間ですべてのデータ転送を暗号化します。 KSIでは、SHA2アルゴリズムを使用して、Digicertによって署名されたTLS証明書を展開します。SHA2アルゴリズムは、民間認証局によって現在提供されている最も安全な署名アルゴリズムです。SHA2は、より広く使用されているSHA1よりもはるかに安全です。SHA1には、アルゴリズムで特定された数学的な弱点があるため、悪用される可能性があります。SHA2は、攻撃者がウェブサイトを偽装するために使用できる可能性のある偽造証明書の発行を防ぐうえで役立ちます。 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クライアントデバイスは、不正なデジタル証明書を使用した攻撃者によるなりすましを防止するセキュリティメカニズムであるKey Pinningを実装しています。

二要素認証

ユーザーのアカウントへの不正アクセスを防止するために、Keeperでは二要素認証も提供しています。二要素認証とは、3つの認証要素 (知識要素、所有要素、生体要素) のうち、2つ以上を必要とする認証方法です。二要素認証に関する詳細は、こちらのリンクをご参照ください。 Keeperは、ユーザーが知っているもの (パスワード) と所有しているもの (持っている携帯電話) を使用して、マスターパスワードやデバイスが侵害された場合に追加のセキュリティをユーザーに提供します。これを行うために、TOTP (時間ベースのワンタイムパスワード) を生成します。 Keeperは、暗号化された乱数生成器を使用して、10バイトの秘密鍵を生成します。このコードは約1分間有効で、SMS、Duo Security、RSA SecurID、TOTPアプリケーション、Google Authenticator、Keeper DNA対応ウェアラブルデバイスなどでユーザーに送信されます。 モバイルデバイスでGoogle AuthenticatorまたはTOTPアプリケーションを使用する場合、Keeperサーバーは秘密鍵を含むQRコードを内部で生成しますが、それが第三者に伝達されることはありません。ユーザーが二要素認証を無効にして、再度有効にするたびに、新しい秘密鍵が生成されます。 二要素認証を有効にするには、Keeperウェブアプリ、デスクトップアプリ、またはモバイルアプリの設定画面にアクセスします。Keeperビジネスユーザーは、Keeper管理コンソールのロール強制機能から、二要素認証とサポートされている二要素認証方式の使用を任意で強制することができます。

パスキーとFIDO2 WebAuthnセキュリティキー

Keeperでは、第2の要素として、YubiKeyやGoogle TitanキーなどのFIDO2に準拠したWebAuthnとU2Fハードウェアベースのセキュリティキーデバイスに対応しています。セキュリティキーは、ユーザーに6桁のコードを手動で入力するように要求しなくても、二要素認証を実行できる便利で安全な方法を提供します。

ユーザーのボルトに複数のセキュリティキーを設定できます。セキュリティキーデバイスに対応していないプラットフォームでは、ユーザーは他の設定済みの二要素認証方法に戻すことができます。

セキュリティキーとその他の二要素認証方法を設定するには、Keeperアプリケーションの[設定]画面にアクセスします。

BreachWatch

Keeperは、Amazon AWS上でBreachWatchと呼ばれるの自己完結型のマネージドサービスアーキテクチャを運用しています。BreachWatchはKeeperバックエンドAPIや保存されているユーザーデータから物理的に分離されています。

BreachWatchサーバーでは、物理的なハードウェアセキュリティモジュール (HSM) を使用して、ダークウェブのデータ漏洩から得た数十億もの一意のパスワードを処理、ハッシュ化、保管しています。 このような数十億のパスワードのそれぞれが、Keeperのサーバー上でHMAC_SHA512ハッシュ方式を使用して処理され、エクスポートできない鍵を使用してハードウェアセキュリティモジュールでハッシュ化されます。

Keeperのエンドユーザークライアントデバイスでは、BreachWatchが有効化されると、保存されている個々のパスワードに基づいてHMAC_SHA512ハッシュが生成されて、サーバーに送信されます。 サーバー上では、エクスポートできない鍵を使用するハードウェアセキュリティモジュール (HSM) を介して、HMAC_SHA512を使用した2つ目のハッシュが作成されます。 これらのハッシュを比較して、パスワードが漏洩したかどうかを判断します。

BreachWatchのバックエンドアーキテクチャは、データ漏洩の規模に関わらず、漏洩したパスワードとユーザーのボルトにある実際のパスワードとの相関を防ぐように構築されています。 漏洩したパスワードの検出に使用されるハッシュは、物理的なハードウェアセキュリティモジュールを活用して、ハッシュがオンラインでのみ実行されるようにしており、BreachWatchデータに対するブルートフォース攻撃の脅威を防ぎます。

以下のシステム図は、全体的なデータフロー、暗号化、BreachWatchのハッシュ処理ワークフローの概要を示しています。

BreachWatch暗号化モデル

要約

  • パスワードはHMAC_512で2回ハッシュ化されます。1回は「ペッパー」を使用してクライアントデバイスでハッシュ化され、もう1回はエクスポート不可能な鍵を使用するハードウェアセキュリティモジュールを使用してAmazon AWS CloudHSMでハッシュ化されます。

  • HMAC_512を使用するのは、強力なハッシュ関数と秘密鍵 (エクスポート不可能) を活用するためです。従って、ハッシュに対するオフライン攻撃は実行不可能になります。

  • 「メッセージ認証コード」 (MAC) は暗号化ハッシュ関数の結果を使用します。これは、ハッシュ関数の使用を拡張する方法です。その結果は、メッセージだけでなく、秘密鍵である可能性のある第2の入力にも依存します。

クラウドSSOコネクトによるSAML 2.0認証

KeeperクラウドSSOコネクトは、完全なクラウド環境で標準的なSAML 2.0プロトコルを使用するサードパーティのIDプロバイダ (IdP) 経由の認証と併せて、ユーザーを認証し、ゼロ知識で暗号化されたボルトに保管されたデータを復号化する方法をKeeperエンタープライズユーザーに提供します。

この実装では、ユーザーは、お使いのSSO IDプロバイダを介して認証を行い、デバイス上でボルトの暗号文を復号化することができます。各デバイスは、独自のEC (楕円曲線) 公開鍵/秘密鍵のペアと暗号化されたデータキーを所有します。 各ユーザーは独自のデータキーを所有します。新しいデバイスにサインインするには、ユーザーは既存のデバイスを利用して承認を行うか、特権を持つ管理者が新しいデバイスを承認する必要があります。

この新機能の重要性は、ユーザーがKeeperクラウドに保存されている暗号化された鍵を使用して、自分のボルトを復号できることにあります。 Keeperクラウドはユーザーのデバイス上でデータキーを復号することができないため、ゼロ知識が維持されます。ユーザーのデータキー (DK) はデバイスの秘密鍵 (DPRIV) で復号化され、デバイス暗号化データキー (DEDK) は、指定されたIDプロバイダ (例 Okta、Azure、AD FS、Google Workspace、Duo、Ping、JumpCloudなど) による認証に成功した時点でユーザーに提供されます。

クラウドSSOコネクトデータフロー

クラウドSSOコネクトの暗号化モデル

最初のデバイスフロー (新規ユーザーのオンボーディング)

  1. データキー、共有キーペア、デバイスEC秘密/公開鍵ペアが生成されます。

  2. データキーはデバイスのEC公開鍵で暗号化され、クラウド (DEDK) に保存されます。データキーはフォルダーキーとレコードキーを復号化します。

  3. ユーザーはIDプロバイダ (IdP) を使用してログインします。

  4. IdPログイン後、署名されたSAMLアサーションがKeeperによって検証されます。 ボルトが作成され、ユーザーがオンボードされます。

既存のデバイスのフロー

  1. ユーザーはIDプロバイダ (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) がユーザーに送信されます。

デバイスの承認

  1. デバイス承認は、知識がなくてもユーザーのデータキーを新しいデバイスに安全に配信するメカニズムです。

  2. ユーザーは、新しいデバイス公開鍵を使用してデータキーを暗号化することで、デバイスを承認できます。

  3. 管理者は、管理コンソール、コマンダー、または自動承認システムからデバイスを承認できます。

  4. 管理者はユーザーのデータキーを復号化し、新しいデバイスの公開鍵を使用してデータキーを再暗号化します。

  5. オートメーターサービスは、顧客のインフラストラクチャ上で自動デバイス承認を実行できます。

  6. オートメーターサービスは SAML署名を確認し、データキーをアンラップし、新しいデバイス公開鍵を使用してデータキーを暗号化します。

オートメーターサービスの詳細については、こちらのページをご覧ください。

SSO暗号化モデルの大型.svg版

クラウドSSOコネクトのデバイスレベルのセキュリティ

クラウドSSOコネクトのユーザーの場合、各デバイスに楕円曲線の秘密鍵が生成され、ローカルに保存されます。Chromiumベースのウェブブラウザの場合、Keeperボルトは、ローカルデバイスの楕円曲線秘密鍵 (DPRIV) をエクスポートできないCryptoKeyとして保管します。 iOSおよびMacデバイスでは、鍵はデバイスのキーチェーンに保存されます。 Androidデバイスでは、鍵はAndroid Keystoreで暗号化され、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オートメーターサービスの詳細については、こちらのページをご参照ください。

デバイスの承認方法

KeeperクラウドSSOコネクトでは、複数のデバイス承認方法に対応しています。

  1. Keeperプッシュ

  2. Keeper管理コンソールからの管理者承認

  3. コマンダー自動化ツールによる管理者承認

  4. Azure機能による自動管理者承認

  5. Keeperオートメーターを使用した自動承認 (推奨)

SSOクラウドデバイスの承認の詳細についてはこちらのページをご覧ください。

SSOアーキテクチャ

以下は、Keeper SSOコネクトのシステムアーキテクチャ図です。

SSOコネクトのセキュリティアーキテクチャ

アカウント復元

Keeperは、ランダムに生成された24単語のリカバリーフレーズを使用してアカウントを復元します。 マスターパスワードを忘れた場合に、リカバリーフレーズを使用してKeeperボルトへのアクセスを取り戻すことができます。

Keeperは、業界標準のBIP39ワードリストを使用してリカバリーフレーズを実装します。BIP39ワード リストは、256ビットのエントロピーを持つ暗号化キーを生成するために使用される 2048語のセットです。 BIP39リストの各単語は、読みやすさを向上させ、復元プロセスでエラーが発生しにくくするために慎重に選択されています。

リカバリーフレーズでのアカウントの復元は、256ビットAES-GCMキーで暗号化されたユーザーのデータ鍵の2番目のコピーを保存することによって機能します。 この鍵は、基礎となるハッシュアルゴリズムとして HMAC_SHA512 を使用したHKDFを使用し、BIP39リストでランダムに選択された24個の単語から導出されます。

ボルトの復元を完了するには、ユーザーは次のことを行う必要があります。

  • メール認証コードを入力してください。

  • 二要素認証を行います (アカウントで有効になっている場合)

  • リカバリーフレーズをデバイス上でローカルに入力します

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

シークレットマネージャー暗号化モデル

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シークレットマネージャーに関するセキュリティの詳細については、こちらのページをご参照ください。

シークレットマネージャーの詳細については、こちらのページをご参照ください。

ワンタイム共有暗号化モデル

ワンタイム共有

Keeperの「ワンタイム共有」を使用すると、Keeperアカウントを作成しなくても、期限付きで安全にレコード (パスワード、秘密、文書、その他の機密情報など) を受信者に共有できます。ワンタイム共有に実装された暗号化モデルは、クラウドインフラストラクチャを保護するためのゼロ知識およびゼロトラストプラットフォームである、Keeperシークレットマネージャーと同じ技術を採用しています。

  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シークレットマネージャーのゼロ知識プロトコルを使用して、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はボルトおよびリモートブラウザ分離セッションへのアクセスをこの高度な認証方法で保護します。

アカウント移管ポリシーの暗号化

アカウント移管ポリシーをロールに対して有効にすると、ロール強制適用ポリシーの公開鍵と秘密鍵のペアが管理コンソール上でローカルに生成されます。エンドユーザーのデータキー (強制が適用されるロールのユーザーの場合) は、ユーザーがボルトにサインインする際に、ロール強制適用ポリシーの公開鍵で暗号化されます。ロール強制の秘密鍵は、管理者の公開鍵で暗号化されます。 従って、ボルトを移管する必要がある場合に、管理者はロール強制の秘密鍵を復号化することができます。

ボルトの移管を実行するには、Keeper管理者はまずユーザーのアカウントをロックする必要があります。それから、ボルトが移管できるようになり、移管直後にユーザーのアカウントが削除されます。これにより、秘密裏に操作が行われないようにします。移管を実行する際には、まずロール強制の秘密鍵をアンラップしてから、ユーザーのデータキーをアンラップすることで、ユーザーのデータキーを取得します。データキーは、レコード鍵、チーム鍵、フォルダ鍵のアンラップに使用されます。

すべての暗号化はクライアント側の管理コンソール内で実行されるため、共有または移管される情報をKeeperが復号できるということは一切ありません。また、ユーザーのクライアントデータキーが共有されることもありません。従って、ユーザーのデバイスにキャッシュされたデータは、ユーザーのマスターパスワードがなければ復号できません。チーム、共有フォルダ、直接共有から削除されたユーザーは、そのチーム、共有フォルダ、レコードから新しいデータを受け取ることはありません。レコード、フォルダ、チームの鍵は、トランザクション中に管理者に洩れますが、それらの鍵を基となるレコードやフォルダのデータにアクセスするために使用することはできません。

いくつかの異なる管理者特権が階層ツリーの一部に割り当てられている場合があり、その特権ロールのメンバーは、KSI側のKeeper管理コンソールで操作を実行することができます。

アカウント移管ポリシーの詳細については、こちらのページをご参照ください。 

緊急アクセス (デジタル遺産)

Keeperの個人向け製品は、緊急時や死亡時にボルトへのアクセスを許可するために、最大5件の緊急連絡先を追加する機能に対応しています。指定された待機時間が経過すると、緊急連絡先に指定されている人はユーザーのボルトにアクセスできるようになります。ボルトの共有プロセスはゼロ知識であり、ユーザーのマスターパスワードは直接共有されることはありせん。元のユーザーによって設定された待機時間が経過した時点で、緊急連絡先と256ビットAES鍵を共有するために、2048ビットRSA暗号化が使用されます。そのため、緊急連絡先には、招待を受け入れるためのKeeperアカウント (および公開鍵と秘密鍵のペア) が必要です。

デジタル遺産のサポートは、個人レベルのアカウントのみを対象にしています。

モバイル用アプリ

Keeperのモバイルアプリにはトラッカーは含まれていません。 すべてのモバイルアプリは、KeeperのサードパーティテスターとBugcrowdバグ報奨金プログラムによる脆弱性テストを受けています。

Exodus Privacyは、ユーザー追跡を実行するアプリケーションを監視する組織です。 KeeperのAndroidアプリケーションは以下のとおりです。

https://reports.exodus-privacy.eu.org/en/reports/com.callpod.android_apps.keeper/latest/#trackers

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

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

ブラウザ拡張機能のセキュリティ

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およびCybertestと協力して、ソースコードレベルの分析を含む、ブラウザ拡張プラットフォームの脆弱性テストを継続的に実施しています。

プライバシーと権限

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 GroupCybertestなどのサイバーセキュリティ企業と協力して、サードパーティの自動入力に特化した侵入テストを定期的に実施しています。

コンプライアンスレポート

Keeperコンプライアンスレポートは、Keeperのゼロ知識暗号化モデルに準拠しています。ここでは、暗号化の観点からその仕組みを説明します。エンタープライズエンドユーザーがボルトにログインすると、タイプ (Type)、タイトル (Title)、およびURLフィールドがエンタープライズ楕円曲線公開鍵で暗号化されます。「監査データ」と呼ばれるこのデータは、ユーザーのデバイス上にローカルで暗号化され、Keeperクラウドに保存されます。監査データは、時間の経過とともにエンドユーザーデバイスによって継続的に更新されます。

Keeper管理者は、マスターパスワードまたはシングルサインオンを使用して管理コンソールにログインします。ログインに成功すると、管理者はAES 256 Enterprise Tree Keyと呼ばれる鍵を復号化し、エンタープライズ楕円曲線秘密鍵を復号化します。管理者は、コンプライアンスレポートを実行する権限を持っている場合、権限が付与されているノード内の任意のユーザーに対してレポートを実行できます。

暗号化された監査データは管理コンソールに送信されるので、管理者はエンタープライズ楕円曲線秘密鍵を使用して監査データをローカルでデバイス上に復号化できます。レポートの内容はローカルでユーザーインタフェースに表示され、CSV、JSONまたはPDF形式にエクスポートできます。 指定されたKeeper管理者だけが、管理者権限を付与されたノードのコンプライアンスレポートデータを取得して復号化できます。

コンプライアンスレポートの詳細については、こちらのページをご参照ください。

取得済みの米国特許

特許番号
要約

安全なクラウドベースのシングルサインオン接続を提供するシステムおよび方法であり、ゼロ知識アーキテクチャを持つセキュリティサービスプロバイダを使用します。

ゼロ知識ボルトアーキテクチャでシングルサインオン接続を提供するためのシステムおよび方法です。

パスワードに関する識別可能な情報をサービスプロバイダや外部の第三者に開示せずに、ゼロ知識ボルト内の漏洩したパスワードの存在の有無を検出する方法です。

ゼロ知識ボルトアーキテクチャでチャットメッセージを提供するためのシステムおよび方法です。

アカウント番号およびパスワードを保護するための方法および装置です。

現在の地理的位置に関連するファイルを選択して表示するための装置です。

ウェブサイトおよびアプリケーションにログイン資格証明を自動入力することで、モバイルコンピューティングデバイスからの迅速なログインを円滑にする方法です。

ユーザー定義のID検証システム。

脆弱性レポートおよびバグ報奨金プログラム

Keeper Securityは、潜在的なセキュリティ課題に関して責任ある開示を行うという業界のベストプラクティスに取り組んでいます。お客様のセキュリティとプライバシーを真剣に受け止め、KSIのお客様のプライバシーと個人情報の保護に努めます。KSIの使命は、世界で最も安全で革新的なセキュリティアプリを構築することであり、セキュリティ研究者で構成される世界的規模のコミュニティによるバグレポートは、KSIの製品とサービスのセキュリティを確保するうえでの貴重な要素であると考えています。

ユーザーを安全に保つことは、組織としての価値の中核です。KSIは誠実な研究者の情報を尊重し、サイバーセキュリティコミュニティとの継続的な関係がセキュリティとプライバシーを確保し、インターネットをより安全な場所にすることに役立つと信じています。これには、責任あるセキュリティテストとセキュリティ脆弱性の開示を奨励することが含まれます。

ガイドライン

Keeperの脆弱性開示ポリシーには、誠実な研究者と連携する際に期待されることとKSIに期待できることが提示されています。

セキュリティテストやレポートがこのポリシーのガイドライン内で行われる場合、KSIは以下を行います。

  • コンピュータ不正行為防止法に基づいて、認定されたものと見なします。

  • デジタルミレニアム著作権法 (DMCA) の適用除外であると見なします。また、セキュリティやテクノロジーの規制を回避したことを理由に訴訟を起こすことはありません。

  • 合法的なものと見なし、このプログラムに関連するいかなる法的措置も遂行または支持することはありません。

  • 問題を迅速に把握し、解決するために連携します。

  • 最初に問題を報告し、KSIがその問題に基づいてコードまたは設定を変更した場合は、その貢献を公式に認めます。

このポリシーのガイドラインおよび対象範囲に一致した方法でテストが実施されているかどうか懸念が生じた場合や確信が持てない場合は、続行する前にsecurity@keepersecurity.comに連絡してください。

誠実なセキュリティテストと発見された脆弱性の開示を推奨するために、次のことをお願いします。

  • プライバシーの侵害、ユーザーの操作性の低下、本番システムや企業システムの停止、データの破壊を回避します。

  • 以下に示された範囲内においてのみ調査を実施し、範囲外となる制度や活動に配慮します。

  • テスト中にユーザーデータが検出された場合は、直ちにsecurity@keepersecurity.comに連絡してください。

  • 脆弱性の発見を公表する前に、報告された問題を分析、確認、解決する十分な期間をKSIに与えます。

レポートの送信

KeeperはKSIの脆弱性開示プログラムを管理するために、Bugcrowdと提携しています。

bugcrowd

[https: //bugcrowd.com/keepersecurity]からレポートを送信してください。

ペネトレーションテスト

Keeperは、NCC GroupCybertestや独立したセキュリティ研究者などの専門家と協力して、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の詳細は、こちらをご参照ください。

Q. 二要素認証攻撃からはどのように保護するのですか?

A. Keeperでは承認されていないデバイスのログインを許可していません。(メール認証、Keeper Push、または二要素認証コードの入力のいずれかから) デバイスが承認されると、ユーザーに二要素認証のプロンプトが表示されます。二要素認証に10回失敗すると、失敗するたびにアカウントが指数関数的にロックされます。

Q. 列挙攻撃からはどのように保護するのですか?

A. ログインAPI V3により、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のアカウント移管ポリシーを使用する、アカウントの回復のためのゼロ知識方式が提供されています。 アカウント移管ポリシーについては、こちらのページをご参照ください。

Q. Keeperがゼロナレッジであるなら、どのようにして新しいデバイスでボルトにアクセスできますか?

A. 最初のデバイスでは、各ユーザーに固有の256ビットAES「データキー」が生成されます。消費者およびマスターパスワードでログインするユーザーの場合、選択したマスターパスワードを使用して、1,000,000回のPBKDF2を経てキーが導出され、このキーがローカルでデータキーを暗号化および復号化するために使用されます。

Keeperクラウドでは、このデータキーの暗号化されたバージョンを保存します。新しいデバイスでログインし、マスターパスワードを入力すると、ローカルでキーが導出され、ハッシュ化され、クラウドとの認証に使用されます。認証が成功し (デバイス検証と2FAのステップを通過した後)、暗号化された暗号文がデバイスに送信され、その後、マスターパスワードから導出されたキーを使用してデバイスで暗号文を復号化します。これによりデータキーが生成され、ローカルでボルトの復号化に使用されます。

マスターパスワードを変更した場合、新しいマスターパスワードから導出されたキーがAES-256データキーを暗号化します。その結果得られた暗号化されたキーは再びクラウドに保存されます。マスターパスワードは決してデバイスから外部に送信されることはありません。

SSO (シングルサインオン) でログインするユーザーは、上記のクラウドSSOの項目に記載された異なるプロセスに従います。

暗号鍵の大きさの比較

このセクションでは、KeeperのAES-256暗号化方式 (マスターパスワード認証を使用) とECC-256の強度 (Keeper SSO ConnectによるSSO認証を使用する場合) について詳しく説明します。

AES 128bまたは256bの鍵をブルートフォースするのに必要な時間は?

対称暗号化には、KeeperはAES-256を使用しています。Advanced Encryption Standard (AES) は、擬似ランダム順列であると仮定されます。PRP/PRF切り替えのレンマにより、これは鍵の回復がブルートフォース鍵の列挙を必要とすると仮定します。

仮定

  • 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) を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

経験的な調査によると、人間が使用する平均的なパスワードは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/resources.html

クラウドSSOコネクトのセキュリティモデル https: //docs.keeper.io/sso-connect-cloud/security-and-user-flow さらにご質問や資料のご要望がございましたら、security@keepersecurity.com まで電子メールでお問い合わせください。

脆弱性情報開示プログラム

Keeper Securityは、潜在的なセキュリティ課題に関して責任ある開示を行うという業界のベストプラクティスに取り組んでいます。お客様のセキュリティとプライバシーを真剣に受け止め、KSIのお客様のプライバシーと個人情報の保護に努めます。KSIの使命は、世界で最も安全で革新的なセキュリティアプリを構築することであり、セキュリティ研究者で構成される世界的規模のコミュニティによるバグレポートは、KSIの製品とサービスのセキュリティを確保するうえでの貴重な要素であると考えています。 ユーザーを安全に保つことは、組織としての価値の中核です。KSIは誠実な研究者の情報を尊重し、研究者のコミュニティとの継続的な関係がセキュリティとプライバシーを確保し、インターネットをより安全な場所にすることに役立つと信じています。これには、責任あるセキュリティテストとセキュリティ脆弱性の開示を奨励することが含まれます。

ガイドライン

Keeperの脆弱性開示ポリシーには、研究者と連携する際に期待されることと、KSIに期待できることが提示されています。

セキュリティテストやレポートがこのポリシーのガイドライン内で行われる場合、KSIは以下を行います。

  • コンピュータ不正行為防止法に基づいて、認定されたものと見なします。

  • デジタルミレニアム著作権法 (DMCA) の適用除外であると見なします。また、セキュリティやテクノロジーの規制を回避したことを理由に訴訟を起こすことはありません。

  • 合法的なものと見なし、このプログラムに関連するいかなる法的措置も遂行または支持することはありません。

  • 問題を迅速に把握し、解決するために連携します。

  • 最初に問題を報告し、KSIがその問題に基づいてコードまたは設定を変更した場合は、その貢献を公式に認めます。

このポリシーのガイドラインおよび対象範囲に一致した方法でテストが実施されているかどうか懸念が生じた場合や確信が持てない場合は、続行する前にsecurity@keepersecurity.comに連絡してください。

誠実なセキュリティテストと発見された脆弱性の開示を推奨するために、次のことをお願いします。

  • プライバシーの侵害、ユーザーの操作性の低下、本番システムや企業システムの停止、データの破壊を回避します。

  • 以下に示された範囲内においてのみ調査を実施し、範囲外となる制度や活動に配慮します。

  • テスト中にユーザーデータが検出された場合は、直ちにsecurity@keepersecurity.comに連絡してください。

  • 脆弱性の発見を公表する前に、報告された問題を分析、確認、解決する十分な期間をKSIに与えます。

レポートの送信

KeeperはKSIの脆弱性開示プログラムを管理するために、Bugcrowdと提携しています。[https: //bugcrowd.com/keepersecurity]からレポートを送信してください。

Last updated