4

メンバーシップの詳細とクレジットカードの詳細を保存するように設計されたソリューションを開発しています。可能な限りPCIDSSに準拠しようとしています。これまでの私のデザインは次のとおりです。

PAN=プライマリアカウント番号==クレジットカードの長い番号

  • サーバーAはリモートサーバーです。すべてのメンバーシップの詳細（名前、住所など）を保存し、保存されているPANごとに個別のキーAを提供します
  • サーバーBはローカルサーバーであり、実際には暗号化されたPANとキーBを保持し、復号化を行います。

PANを取得するには、クライアントは両方のサーバーで認証する必要があり、サーバーAにそれぞれのキーAを要求してから、キーAをサーバーBに渡します。これにより、PANがクライアントに返されます（認証が成功した場合）。サーバーAは、キーAをサーバーBの公開鍵でのみ暗号化します。これは、事前に暗号化されているためです。サーバーBはおそらく最初にソルトを送信する必要がありますが、暗号化する必要はないと思います

上記に関しては、実装（つまりコーディング）の詳細についてはまだ考えていませんが、ソリューションはJavaのCajoフレームワーク（RMIのラッパー）を使用しているため、サーバーは相互に通信します（現在、メンバーシップの詳細は転送されます）この上）。

クライアントではなくサーバーBに復号化を実行させたい理由は、サーバーではおそらく同じくらい悪いのに、復号化キーがクライアントのRAMに入るのを恐れているからです...

誰かが上記のデザインに何か問題があるのを見ることができますか？上記を変更する必要があるかどうかは関係ありません。

ありがとう

jtnire

4

3 に答える 3

6

序文として、これを開発し、PCIコンプライアンスを実行するという悪夢があります。これらのカードの詳細を保存できる決済サービスプロバイダーを使用したり、トークンIDを使用してアドホックな承認/決済を実行したりするなどの代替案を検討することは間違いなく価値があります（「ダイヤルアップクレジットカードマシン」を介してキー入力するのではありません）。あなたが説明した）

そのアドバイスを無視してPCIルートを選択した場合は、少なくともPCI承認のQualified Security Assesor（QSA）をできるだけ早く関与させて、思いついた設計を承認してください。PCIは、「できる限り準拠しようとする」べきものではありません。残念ながら、それはすべてか無かです。

ただし、これに取り組む1つの方法は、ボックスAでキーサービングアプリケーションを実行することです。このアプリケーションでは、2つの「キー管理」キーを入力する必要があります。これらのキーを一緒にするとマスターキーが形成されます。マスターキーはRAMにのみ保存され、ディスクに保持されることはありません。

アプリケーションはキー暗号化キーを生成します。キー暗号化キーはボックスAに保存され、マスターキーによって暗号化されます。KEKは自動的に生成されます（ユーザーが入力するものではありません）。KEKは、マスターキーによって暗号化されたボックスAのディスクに永続化できます。

カードの詳細はボックスBに保存されます。このボックスには、カードの詳細の対称暗号化を実行するために使用されるデータ暗号化キーも保存されます。DEK自体は暗号化された形式で保存され、ボックスAのKeyEncryptingKeyで暗号化されます。

暗号化/復号化を実行するアプリケーションはボックスBにあり、KEKを要求する前にボックスAに対して自身を認証する必要があります。次に、KEKを使用してDEKを復号化し、暗号化/復号化を実行できます。

于 2010-03-24T13:04:53.443 に答える
1

サーバー A がハッキングされた場合 - これは、基本的にすべてのクレジット カードをクリア テキストで取得できることを意味しますか? 次に、すべてのクレジットカードにアクセスするために必要なすべての個々のキー情報にアクセスできます。

于 2010-03-24T11:04:29.843 に答える
0

クレジット カード情報の保存方法に関するBytemark ブログエントリを読むことに興味があるかもしれません。

要点は、カード情報を保持しているサーバーが番号を漏らさないことです。許可されている操作は、「新しいカードの追加」、「既存のカードの更新または削除」、および「カードへのチャージ」です。サーバーは支払い処理業者自体に接続します。

于 2010-03-24T11:23:42.000 に答える