Keeperの暗号化モデル
Keeperの暗号化とセキュリティモデルの詳細については、ブロック図、実装の詳細、その他のリソースと併せて以下に概説します。
Last updated
Keeperの暗号化とセキュリティモデルの詳細については、ブロック図、実装の詳細、その他のリソースと併せて以下に概説します。
Last updated
Keeperはゼロ知識セキュリティプロバイダです。ゼロ知識は、最高レベルのセキュリティとプライバシーを保証するシステムアーキテクチャです。データの暗号化と復号化は、必ずユーザーのデバイス上でローカルに実行されます。
Keeperの暗号化モデルは、次の構造に準拠しています。
各ボルトのレコードは、GCMモードでクライアント側で一意に生成された256ビットAES暗号化鍵によって暗号化されます。
各レコードレベルの鍵は、共有フォルダ内に含まれている場合、256ビットAES共有フォルダ鍵でラップされます。
ボルトユーザーの場合、レコード鍵とフォルダ鍵はデータキーと呼ばれる別のAES-256鍵で暗号化されます。
Secrets Managerユーザーの場合、レコード鍵とフォルダ鍵は256ビットAESアプリケーションキーで暗号化されます。
マスターパスワードでログインするユーザーの場合、データを復号化と暗号化するためのキーは、ユーザーのマスターパスワードから得られます。
SSOまたはパスワードレス技術でログインするユーザーは、デバイスレベルでデータの暗号化と復号化を行うために楕円曲線暗号方式が使用されます。
Keeperサーバーに送信されるすべての暗号化ペイロードは、中間者攻撃から保護するために、TLSに加えて256ビットAES送信キーによってさらにラップされます。送信キーはクライアントデバイスで生成され、サーバーのEC公開鍵を介してECIES暗号化を使用してサーバーに転送されます。
ユーザー間の秘密の共有では、楕円曲線暗号を使用して安全な鍵配布が行われます。
マルチレイヤー暗号化は、ユーザー、グループ、および管理者レベルでのアクセス管理を提供します。
データは、送信されてKeeper's Cloud Security Vaultに保存される前にユーザーのデバイス上でローカルに暗号化されます。データが別のデバイスと同期されている場合、データは他のデバイスで復号化されるまでは暗号化されたままになります。
Keeperは、世界で最も安全で、認証やテスト、監査を受けているパスワードセキュリティプラットフォームです。業界で唯一のSOC2およびISO 27001認定パスワード管理ソリューションであるほか、米国商務省のEUと米国間のプライバシーシールドプログラムのプライバシーシールドに準拠し、欧州委員会のデータ保護指令に対応しています。最も安全なレベルの暗号化を実装するだけでなく、安全なソフトウェアを開発し、世界で最も安全なサイバーセキュリティプラットフォームを提供し続けるために、継続的に第三者の監査を受けるという非常に厳格な社内慣行も遵守しています。
KeeperはEU一般データ保護規則 (GDPR) を遵守し、欧州連合のお客様のために、当社のビジネスプロセスと製品がコンプライアンスを維持し続けるように全力を尽くしています。
プライバシーポリシーは、こちらをご覧ください。
https://www.keepersecurity.com/privacypolicy.html
Keeperのデスクトップアプリケーション、ウェブアプリケーション、およびモバイルアプリケーションには、トラッキングを実行するトラッカーやサードパーティライブラリーは含まれていません。例えば、KeeperのAndroidアプリにトラッカーがインストールされていないという情報を確認するには、こちらのリンクをご確認ください。
Keeperは完全なSaaSプラットフォームであり、現在以下のAmazon AWSデータセンターでデータをホストしています。お客様は、希望した第一地域でKeeperテナントをホストできます。顧客データ (保存された暗号文）、およびプラットフォームへのアクセスは、特定の地域に限定されます。
米国 (US)
米国政府クラウド (US_GOV)
欧州 (EU)
オーストラリア (AU)
日本 (JP)
カナダ (CA)
Keeperは、FIPS 140-3で検証されている暗号化モジュールを使用して、政府および公共部門の厳しいセキュリティ要件に対応しています。Keeperの暗号化は、NIST CMVPによって認定され、認定サードパーティの研究所によってFIPS 140標準に対しても認証されています。
Keeperは、NIST CMVPで証明書#4743を取得しています https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3976
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をご参照ください。
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/をご覧ください。
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管理コンソールからの管理者承認
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クラウドでは、認証トークンは「ユーザー認証」キーで超暗号化されます。ユーザー認証キーはサーバーによってランダムに生成され、保存する前にハードウェアセキュリティモジュール (エクスポート不可能なキー) で暗号化されます。ユーザー認証キーは、ソルト、認証トークン、ユーザーの暗号化データ・キー、およびバイオメトリクスなどの代替認証方法のためのその他の認証関連フィールドを暗号化するために使用されます。
KeeperのSSOクラウド機能は、SAML 2.0 IDプロバイダに対する認証を提供しながら、ユーザーのボルトで完全なゼロ知識暗号化を維持します。 楕円曲線（secp256r1）秘密鍵ペアがデバイス上で生成されます。 ユーザーのデータキーはデバイスの秘密鍵で復号化され、指定されたIDプロバイダによる認証が成功すると、暗号化されたデータキーがユーザーに提供されます。
SAML 2.0 IDプロバイダでKeeperを認証するユーザーの場合、Keeper SSO Connectソフトウェアはユーザー環境でホストされます。SSO Connectソフトウェアは、ユーザーのマスターパスワードを生成し、管理します。 生成されたマスターパスワードは、データキーなどのユーザーが所有するその他の鍵を復号する鍵を取得するために、ストレッチング回数を10万回に設定されたPBKDF2で処理されます。
通常、エンタープライズ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管理コンソールのロール強制機能から、二要素認証とサポートされている二要素認証方式の使用を任意で強制することができます。
Keeperでは、第2の要素として、YubiKeyやGoogle TitanキーなどのFIDO2に準拠したWebAuthnとU2Fハードウェアベースのセキュリティキーデバイスに対応しています。セキュリティキーは、ユーザーに6桁のコードを手動で入力するように要求しなくても、二要素認証を実行できる便利で安全な方法を提供します。
ユーザーのボルトに複数のセキュリティキーを設定できます。セキュリティキーデバイスに対応していないプラットフォームでは、ユーザーは他の設定済みの二要素認証方法に戻すことができます。
セキュリティキーとその他の二要素認証方法を設定するには、Keeperアプリケーションの「設定 (Settings）」画面にアクセスします。
Keeperは、Amazon AWS上でBreachWatchと呼ばれるの自己完結型のマネージドサービスアーキテクチャを運用しています。BreachWatchはKeeperバックエンドAPIや保存されているユーザーデータから物理的に分離されています。
BreachWatchサーバーでは、物理的なハードウェアセキュリティモジュール (HSM) を使用して、ダークウェブのデータ漏洩から得た数十億もの一意のパスワードを処理、ハッシュ化、保管しています。 このような数十億のパスワードのそれぞれが、Keeperのサーバー上でHMAC_SHA512ハッシュ方式を使用して処理され、エクスポートできない鍵を使用してハードウェアセキュリティモジュールでハッシュ化されます。
Keeperのエンドユーザークライアントデバイスでは、BreachWatchが有効化されると、保存されている個々のパスワードに基づいてHMAC_SHA512ハッシュが生成されて、サーバーに送信されます。 サーバー上では、エクスポートできない鍵を使用するハードウェアセキュリティモジュール (HSM) を介して、HMAC_SHA512を使用した2つ目のハッシュが作成されます。 これらのハッシュを比較して、パスワードが漏洩したかどうかを判断します。
BreachWatchのバックエンドアーキテクチャは、データ漏洩の規模に関わらず、漏洩したパスワードとユーザーのボルトにある実際のパスワードとの相関を防ぐように構築されています。 漏洩したパスワードの検出に使用されるハッシュは、物理的なハードウェアセキュリティモジュールを活用して、ハッシュがオンラインでのみ実行されるようにしており、BreachWatchデータに対するブルートフォース攻撃の脅威を防ぎます。
以下のシステム図は、全体的なデータフロー、暗号化、BreachWatchのハッシュ処理ワークフローの概要を示しています。
要約
パスワードはHMAC_512で2回ハッシュ化されます。1回は「ペッパー」を使用してクライアントデバイスでハッシュ化され、もう1回はエクスポート不可能な鍵を使用するハードウェアセキュリティモジュールを使用してAmazon AWS CloudHSMでハッシュ化されます。
HMAC_512を使用するのは、強力なハッシュ関数と秘密鍵 (エクスポート不可能) を活用するためです。従って、ハッシュに対するオフライン攻撃は実行不可能になります。
「メッセージ認証コード」 (MAC) は暗号化ハッシュ関数の結果を使用します。これは、ハッシュ関数の使用を拡張する方法です。その結果は、メッセージだけでなく、秘密鍵である可能性のある第2の入力にも依存します。
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など) による認証に成功した時点でユーザーに提供されます。
データキー、共有キーペア、デバイスEC秘密/公開鍵ペアが生成されます。
データキーはデバイスのEC公開鍵で暗号化され、クラウド (DEDK) に保存されます。データキーはフォルダーキーとレコードキーを復号化します。
ユーザーはアイデンティティプロバイダー (IdP) を使用してログインします。
IdPログイン後、署名されたSAMLアサーションがKeeperによって検証されます。 ボルトが作成され、ユーザーがオンボードされます。
ユーザーはアイデンティティプロバイダー (IdP) を使用してログインします。
IdPログイン後、署名されたSAMLアサーションがKeeperによって検証されます。
Keeperは、デバイス暗号化データキー (DEDK) をユーザーに配信します。
データキーはデバイスのEC秘密鍵を使用して復号化されます。
データキーはフォルダーキーとレコードキーを復号化します。
レコードキーはレコードの内容を復号化します。
新しいデバイスごとに、EC秘密鍵と公開鍵のペアが生成されます。
ユーザーはアイデンティティプロバイダー (IdP) を使用してログインします。
IdPログイン後、署名されたSAMLアサーションがKeeperによって検証されます。
デバイスはKeeper Push、管理者承認、またはAutomatorサービスを通じて「承認」されます (*下記の「デバイスの承認」を参照)。
承認プロセスでは、データキーが新しいデバイスの公開鍵で暗号化されます。
デバイス暗号化データキー (DEDK) がユーザーに送信されます。
デバイス承認は、知識がなくてもユーザーのデータキーを新しいデバイスに安全に配信するメカニズムです。
ユーザーは、新しいデバイス公開鍵を使用してデータキーを暗号化することで、デバイスを承認できます。
管理者は、管理コンソール、コマンダー、または自動承認システムからデバイスを承認できます。
管理者はユーザーのデータキーを復号化し、新しいデバイスの公開鍵を使用してデータキーを再暗号化します。
Automatorサービスは、顧客のインフラストラクチャ上で自動デバイス承認を実行できます。
Automatorサービスは SAML署名を確認し、データキーをアンラップし、新しいデバイス公開鍵を使用してデータキーを暗号化します。
クラウド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 Connect暗号化モデルで説明されているように、簡単に設定でき、暗号鍵の管理にホスト型のソフトウェアは必要がないという利点があります。
Keeper SSO Connectのオンプレミス実装と比較すると、このモデルにおける唯一のワークフローに関する変更点は、ユーザーがアクティブなデバイスで新しいデバイスの承認を実行するか、Keeper管理者にデバイス承認の責任を委譲して承認する必要があるということになります。
KeeperクラウドSSOコネクトでは、複数のデバイス承認方法に対応しています。
Keeper Push
Keeper管理コンソールからの管理者承認
コマンダー自動化ツールによる管理者承認
Azure機能による自動管理者承認
Keeper Automatorを使用した自動承認 (**推奨)
Keeper SSO Connectのシステムアーキテクチャ図を次に示します。
Keeperは、ランダムに生成された24単語のリカバリーフレーズを使用してアカウントを回復します。 マスターパスワードを忘れた場合に、リカバリーフレーズを使用してKeeperボルトへのアクセスを取り戻すことができます。
Keeperは、業界標準のBIP39ワードリストを使用してリカバリーフレーズを実装します。BIP39ワード リストは、256ビットのエントロピーを持つ暗号化キーを生成するために使用される 2048語のセットです。 BIP39リストの各単語は、読みやすさを向上させ、回復プロセスでエラーが発生しにくくするために慎重に選択されています。
リカバリーフレーズでのアカウントの回復は、256ビットAES-GCMキーで暗号化されたユーザーのデータ鍵の2番目のコピーを保存することによって機能します。 この鍵は、基礎となるハッシュアルゴリズムとして HMAC_SHA512 を使用したHKDFを使用し、BIP39リストでランダムに選択された24個の単語から導出されます。
ボルトの回復を完了するには、ユーザーは次のことを行う必要があります。
メール認証コードを入力してください。
二要素認証を行います (アカウントで有効になっている場合)
リカバリーフレーズをデバイス上でローカルに入力します
Keeperシークレットマネージャーは、DevOps、ITセキュリティ、ソフトウェア開発チーム向けのゼロ知識プラットフォームであり、ソフトウェア開発と展開のライフサイクル全体を通じて機密情報を管理します。
シークレットマネージャーは、次の暗号化モデルに準拠しています。
秘密はデバイス上で暗号化および復号化されます (サーバー上ではありません）。
デバイスはプレーンテキスト (人間が読める) データを保存することはありません。
サーバーがプレーンテキストのデータを受信することはありません。
Keeperの従業員、サードパーティや仲介者が秘密を復号化することはできません。
秘密の暗号化や復号化をするための鍵は、クライアントデバイス上でユーザーが管理します。
各秘密は、GCMモードでクライアント側で一意に生成された256ビットAES暗号化鍵によって暗号化されます。
各レコードレベルの鍵は、共有フォルダ内に含まれている場合、共有フォルダ鍵によってラップされます。
クライアント側で生成された256ビットAESアプリケーションキーを使用して、共有フォルダおよびレコード鍵が復号化されます。レコード鍵は、個々の秘密を復号化します。
Keeperサーバーに送信されるすべての暗号化ペイロードは、中間者攻撃から保護するために、TLSに加えて256ビットAES送信キーでさらにラップされます。送信キーはクライアントデバイスで生成され、サーバーのEC公開鍵を介してECIES暗号化を使用してサーバーに転送されます。
ユーザー間の秘密の共有では、楕円曲線暗号を使用して安全な鍵配布が行われます。
マルチレイヤー暗号化は、ユーザー、グループ、および管理者レベルでのアクセスコントロールを提供します。
ユーザーボルト内で管理される秘密はセグメント化され、個々のレコードとフォルダへのアクセス権が付与されている定義済みのシークレットマネージャーデバイスに分離されます。
ボルトで、共有者はレコードオプション画面で「ワンタイム共有」をクリックして、ワンタイムアクセストークンを生成します。共有されるレコードの256ビットAESレコード鍵は、ワンタイムアクセストークンで暗号化され、この暗号化された値はKeeper Cloudに保存されます。
共有者は、単純なURLまたはQRコードを使用して、優先チャネルからワンタイムアクセストークンを受信者に送信します。アクセストークンを含むURL部分はURLの「フラグメント識別子」セクション内に保持され、Keeperのサーバーにネットワーク経由で送信されることはありません。そのため、ゼロ知識は保持され、Keeperはその情報にアクセスしたり、復号化したりすることはできません。
受信者はデバイスのブラウザでURLを開き、単一ページのボルトアプリケーションがデバイスにロードされます。ワンタイムアクセストークンは、ローカルのボルトアプリケーションに直接受け渡されます (サーバーには送信されません）。
URLを読み込むと、受信者のデバイスはクライアント側の楕円曲線公開鍵/秘密鍵のペアを生成し、秘密鍵はクライアントデバイスにローカルでブラウザのCryptoKeyストレージに保存されます。
初めて使用する際に、SDKライブラリはワンタイムアクセストークンのハッシュを使用して認証し、認証が成功すると、サーバーは暗号化されたレコード暗号文と暗号化されたレコード鍵で応答します。
クライアントはワンタイムアクセストークンを使用してレコード鍵を復号化し、レコードの内容はレコード鍵を使用して復号化されます。その後、レコード鍵は、クライアントデバイスのブラウザのCryptoKeyストレージ、またはその他の指定されているストレージの場所にローカルで保存されます。
サーバーでは、そのデバイス用に暗号化されたレコード鍵が削除されるため、ワンタイムアクセストークンは再使用できなくなります。それ以降は、クライアントのリクエストはクライアント秘密鍵で署名される必要があります。
同じデバイスでサーバーに後続のコールを送る際は、デバイスを一意に定義する識別子 (ワンタイムアクセストークンのハッシュ) とクライアント秘密鍵で署名されたリクエスト本文と一緒に送信されます。サーバーは、デバイスのクライアント公開鍵を使用して、特定のデバイス識別子に対するリクエストのECDSA署名をチェックします。Keeper Cloudはレコードのリクエストを処理し、認証が成功すると、サーバーは暗号化されたレコード暗号文をクライアントに返します。
レコードレベルの暗号化に加えて、クライアントデバイスはランダムに生成されたAES-256ビットの送信鍵を生成します。この鍵はKeeperクラウドAPIの公開鍵で暗号化されます。クライアントデバイスは、送信鍵を使用してサーバーからの応答を復号化し、レコード鍵を使用して暗号文応答ペイロードを復号化します。これにより、レコードの内容が復号化されます。
アカウント移管ポリシーをロールに対して有効にすると、ロール強制適用ポリシーの公開鍵と秘密鍵のペアが管理コンソール上でローカルに生成されます。エンドユーザーのデータキー (強制が適用されるロールのユーザーの場合) は、ユーザーがボルトにサインインする際に、ロール強制適用ポリシーの公開鍵で暗号化されます。ロール強制の秘密鍵は、管理者の公開鍵で暗号化されます。 従って、ボルトを移管する必要がある場合に、管理者はロール強制の秘密鍵を復号化することができます。
ボルトの移管を実行するには、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と協力して、ソースコードレベルの分析を含む、ブラウザ拡張プラットフォームの脆弱性テストを継続的に実施しています。
Keeperウェブボルトには、発信要求元を制限し、Keeperから明示的に発信されたスクリプトを除くすべてのスクリプト (インラインスクリプトおよびイベント処理HTML属性を含む) の実行を禁止する厳格なコンテンツセキュリティポリシーが実装されており、クロスサイトスクリプティング攻撃のほとんどのベクトルを低減または取り除きます。
Keeperドメイン名へのアクセスは、TLS v1.2を使用するHTTPSに制限され、HTTP Strict Transport Securityによって強制されます。これにより、さまざまなパケットスニフィング、データの改ざんや中間者攻撃が防止されます。
Keeperのブラウザ拡張内では、ページフレーム領域内からボルトにログインするようにKeeperがユーザーに求めることはありません。拡張機能へのログインは、ブラウザのブラウザ拡張 (Browser Extension) ツールバー領域で行います。ウェブブラウザからボルトにログインするには、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やCybertestなどのサイバーセキュリティ企業と協力して、サードパーティの自動入力に特化した侵入テストを定期的に実施しています。
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と提携しています。
[https: //bugcrowd.com/keepersecurity]からレポートを送信してください。
Keeperは、NCC Group、Cybertestや独立したセキュリティ研究者などの専門家と協力して、KSIのすべての製品とシステムに対してサードパーティの侵入テストと脆弱性テストを実施します。 レポートの概要は、要望に応じてエンタープライズユーザーに提供されます。
A. いいえ。KSIはゼロ知識であるため、ユーザーのデータを復号することはできません。
A. マスターパスワードは保存されません。また、マスターパスワードから取得する暗号鍵も保存されません。 ユーザーがマスターパスワードを入力すると、10万回の反復回数を持つPBKDF2と呼ばれるパスワード導出関数を使用して、リアルタイムで鍵が取得されます。この鍵で暗号文をアンラップしてデータキーを抽出してから、データキーでフォルダ鍵、レコード鍵、レコードデータをアンラップします。
A. KeeperはPBKDF2を100万回の繰り返しで使用しています。
A. 管理者が生体認証を有効にして許可した場合、AES-256の「生体認証鍵」がデバイス上でローカルに生成され、iOSキーチェーンに保存されます。ユーザーがFace IDまたはTouch ID認証を使用してオペレーティングシステムとの認証に成功すると、鍵はKeeperアプリケーションに提供され、保存されている暗号文をアンラップしてデータキーを取得するために使用されます。
KeeperはWindows Hello、Touch ID、Face ID、Android生体認証をネイティブでサポートしています。通常、マスターパスワードまたはエンタープライズSSOログイン (SAML 2.0) を使用してKeeperボルトにログインしているユーザーは、生体認証を使用してデバイスにログインすることもできます。生体認証はKeeper管理者がロールポリシーで有効にする必要があります。この機能を有効にすると、マスターパスワードのユーザーとSSOが有効にされているユーザーの両方が、生体認証でオフラインアクセスすることも可能になります。
A. Keeperはパスワードスタッフィングとパスワードブルートフォース攻撃に対して、複数の保護レイヤーを実装しています。承認されていないデバイスのログインは許可していません。承認されると、最初のステップは二要素認証です。二要素認証を通過した場合のみ、ユーザーはパスワードテストを試みることができます。パスワードの試行に10回失敗すると、アカウントは試行ごとに指数関数的にロックされます。Keeperの自己破壊メカニズムをローカルデバイスで有効にして、5回失敗した場合にローカルで保存されたデータを削除することもできます。ログインAPIの詳細は、こちらをご参照ください。
A. Keeperでは承認されていないデバイスのログインを許可していません。(メール認証、Keeper Push、または二要素認証コードの入力のいずれかから) デバイスが承認されると、ユーザーに二要素認証のプロンプトが表示されます。二要素認証に10回失敗すると、失敗するたびにアカウントが指数関数的にロックされます。
A. ログインAPI V3により、Keeperクラウドインフラストラクチャに対するユーザー列挙の防止において大きな進歩を遂げています。つまり、サーバーはユーザーのアカウントの存在の有無を開示しないということを意味します。信頼しているデバイスや既知のデバイス、またはIPからユーザーがログインしていない限り、列挙は拒否されます。
Keeperは複数の分離されたデータセンターを運営しており、データセンター間の列挙は拒否されているため、ユーザーが間違ったデータセンターからログインしようとすると、ラウンドトリップとメール認証を行わなければならない場合があります。 ウェブインターフェースから開示することはできないため、ログインとリダイレクトを伝えるためにメールが利用されます。
A. ユーザーがデバイスにログインすると、すべてのエンタープライズポリシーはKeeperクラウドからダウンロードされ、レコードレベルのフィルタリング、URLフィルタリング、パスワード固有ルールと処理を必要とするポリシーについては、デバイス上でローカルに処理されます。
A. アカウントの回復は、ユーザーが管理コンソールのロールポリシーセクションで無効にすることができます。これは、サードパーティのIDプロバイダを利用するSSOクラウドを使用している場合に必要になることがあります。 アカウント回復の仕組み (リカバリーフレーズ方式) は、ユーザーの24単語の回復フレーズから生成された256ビットAESキーで暗号化された、ユーザーのデータキーの2番目のコピーを保存することによって行われます。ボルトの回復を完了するには、データキーを復号化するために、ユーザーは1. メール認証コードを入力し、2. 二要素認証手順 (アカウントで有効になっている場合) を通過し、3. デバイス上でローカルにリカバリーフレーズを正確に入力する必要があり、次に、マスターパスワードのリセットをユーザーに許可します。お使いのアカウントの設定メニューで、アカウントリカバリーを有効にし、Keeperの二要素認証機能をオンにすることをお勧めします。 アカウントリカバリーを無効にし、「アカウント移管」管理機能に依存したいエンタープライズのお客様は、このポリシーを設定することが可能です。アカウント回復を無効にした場合、マスターパスワードを忘れたり、SSO IdPにアクセスできなくなった場合にユーザーを回復できる唯一の方法は、アカウント移管となることに注意してください。
A. ビジネスユーザーやエンタープライズユーザーには、Keeperのアカウント移管ポリシーを使用する、アカウントの回復のためのゼロ知識方式が提供されています。 アカウント移管ポリシーについては、こちらのリンク。
このセクションでは、KeeperのAES-256暗号化方式 (マスターパスワード認証を使用) とECC-256の強度 (Keeper SSO ConnectによるSSO認証を使用する場合) について詳しく説明します。
対称暗号化には、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は、これらの楕円曲線に対する最もよく知られた攻撃を考えると、128bの鍵の列挙しかできません。これはAES-128の半分の強度です。確かに、ECC-256に対する鍵の列挙攻撃は、AES-256に対する攻撃よりも容易であると思われます。しかし、AES-256とAES-128の性能差は無視できますが、ECC-256とECC-512の性能差は顕著で、一部のライブラリは残念ながら512b版の楕円曲線をサポートしていません。
前述の通り、AES-128とAES-256に対する鍵列挙攻撃は非現実的であり、AES-256の鍵列挙攻撃は、AES-128とAES-256に対する鍵列挙攻撃は非現実的です。しかし、性能が低下することはほとんどなく、AES-256はすべての開発ライブラリでサポートされているため、実装は簡単で標準的です。ECC-512の使用は、普遍的にサポートされておらず、性能上のペナルティが顕著であるため、困難です。
注目すべきは、ビットコインのブロックチェーンがECC-256を使用していることです。これにより、256b楕円曲線の強度に事実上3000億ドルの懸賞金がかけられています。
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]からレポートを送信してください。
サービスによる自動承認
による自動管理者承認
Automatorサービスの詳細については、をご覧ください。
SSOクラウドデバイスの承認の詳細についてはをご覧ください。
Keeperシークレットマネージャーに関するセキュリティの詳細については、をご参照ください。
シークレットマネージャーの詳細については、のドキュメントをご参照ください。
Keeperの「ワンタイム共有」を使用すると、Keeperアカウントを作成しなくても、期限付きで安全にレコード (パスワード、秘密、文書、その他の機密情報など) を受信者に共有できます。ワンタイム共有に実装された暗号化モデルは、クラウドインフラストラクチャを保護するためのゼロ知識およびゼロトラストプラットフォームである、と同じ技術を採用しています。
