CC の詳細を格納するために使用しているモデルは次のとおりです。これはどれほど安全に見えますか?
すべての情報は公開鍵暗号化を使用して暗号化され、鍵ペアはユーザーに依存します (サーバー上で生成され、秘密鍵はデータベース上でハッシュされているユーザーのパスワードを使用して対称暗号化されます) したがって、基本的に最初の実行時に、ユーザーは自分のSSL 接続を介したパスワードであり、パスワードはソルトを追加して使用され、MD5 ハッシュを生成します。また、パスワードは秘密鍵の暗号化にも使用され、秘密鍵はサーバーに保存されます。ユーザーが支払いをしたいとき、彼は自分のパスワードを送ります。パスワードは秘密鍵を復号化し、秘密鍵は CC の詳細を復号化し、CC の詳細が請求されます。
ユーザーのパスワードが秘密鍵を保護するのに十分安全である場合、秘密鍵をスキップしてパスワードを (適切な鍵導出アルゴリズムを介して) 使用してクレジット カード番号を暗号化しませんか? 不必要な複雑さは、セキュリティを確実に改善しません。
このスキームは、公開鍵を何にも使用していません。これは、非対称アルゴリズムがここでは不適切であることを示しています。
これにより、クレジット カードのセキュリティがユーザーのパスワードの強度に結び付けられます。パスワードの強度はユーザーごとに異なり、一般的には弱いものです。独自の対称暗号化キーを作成し、それを安全に保管してから、CBC、CTR、IV などの頭字語を含む、専門家が発明した一連の複雑なことを行うことをお勧めします。
カード番号と秘密鍵ファイルを一緒に保存するかどうかはわかりません。ユーザーパスワードを使用して秘密鍵ファイルを暗号化するだけで、暗号化された秘密鍵ファイルが利用可能な場合、辞書スタイルの攻撃への扉が開かれているように見えます。
かなり遅くなる可能性のある公開鍵暗号を使用する理由がわかりません。また、ユーザーごとに1つのキーペアのモデルは拡張できない場合があります（ファイルの数、公開キー操作のパラメーターを生成できますか）。あなたは虐待的な振る舞いをしているかもしれないことに注意してください-盗まれたカードのリストが良いかどうかをチェックする人々。
独自のマスターシークレットを追加し、キースケジュールを組み合わせて導出することにより、ユーザーが不在の場合でもカード番号の使用を防ぐことができます。一般に、ユーザーが不在の場合はカード番号を使用する必要があるため、ほとんどの加盟店はこの厳格な要件に従うことができません。
ユーザー固有のキーが必要な場合（そして毎回異なるIVを使用する必要がある場合）、openssl EVP_BytesToKeyルートに移動し、暗号化キーとivが派生するマスターシークレットを使用して毎回異なるソルトを渡すことができます（およびユーザーごとに異なります）。
最後に、支払い手段の使用は、説明されているようにユーザーパスワードだけで保護されます。一部のユーザーは弱いパスワードを選択します。したがって、追加のプルーフを使用して、カードがユーザーのものであることを確認することをお勧めします。これは、友好的な不正のチャージバックと戦い、実際の不正のチャージバックを低く抑えることができるため、自分のためのものです。
公開鍵が使用されない場合、非対称暗号化を行う意味がないというエリクソンに同意します。
いつものように、ここでの問題は鍵管理の問題です。この不安は、データを復号化する鍵を安全に隠す方法がわからないことから生じます。
可能かどうかはわかりませんが、余裕がある場合は、ハードウェア セキュリティ モジュールを購入して、HSM でキーを管理できるようにするか、HSM マスター キーを使用してすべての顧客 (秘密) キーを暗号化してください。
できない場合は、「マスター」キーを保存するのに適した場所を見つける必要があります。たとえば、Windows ストアが考えられます (可能であれば)。ただし、Windowsストアがどれほど安全かはよくわかりません。
Payment Card Industryies の「Payment Application DSS」を参照してください。 https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml
いくつかの決定を下すのに役立つ場合があります。