支払いを受け付けるモバイルアプリを構築しています。ユーザは、CCの詳細を入力し、支払い情報は、HTTPSを介して小売業者のPOSシステムに提出される。 POSは支払いを直接処理し、実際のクレジットカード情報を必要とするため、カードを保管するStripeのようなサービスを使用することはできず、支払いを処理するためのトークンを返すことはできません。iOS/Androidのクレジットカード情報をPCIに準拠して保存する方法
アプリの性質上、ユーザーは定期的に支払いを行うため、利便性のためにCC情報を保存したいと考えています。ただし、これは定期的な請求ではなく、ユーザは自由に取引を開始します。そこで私は、サーバー上で一元CCを維持する必要はありませんし、私はこの方法を使用して各ユーザーのデバイス上の個々のカードを保存検討している：
- CC番号&有効期限
- を使用して、AES256を使用して暗号化収集支払いを行うためのキーとしてCVC（CVC保存されていない）
- その後のiOSキーチェーン（またはAndroid向けと同等）で暗号化されたデータを保存
- 、（a）のデータはキーチェーンから取り出し、そして
- （Bさ）ユーザはCC情報を解読するためにCVCを入力する必要があります
ユーザーがCVCを知っていれば、おそらくカードを持っている可能性があるので、デバイスをハッキングする必要はありません。
暗号化については、RNCryptor libの使用を検討しています。その主な特徴の1つは、暗号化と認証のために、共通のパスワードを2つの256ビット鍵の暗号的に「ランダムな」バイトシーケンスに自動的に変換することです。鍵の伸張は、PBKDF2の10kラウンドを通して実行されます。実装の詳細は、リンクではありますが、簡単に言えば：PBKDF2
- AES-256暗号化
- CBCモード
- パスワードハッシュHMAC
の質問：
わずか3 CVC桁とRNCryptorのキー・ストレッチの実装を播種した場合、私は判断することがよく十分な数学を理解していないが、統計学的にランダムに十分なキーを生成します。私は、RNCryptorが安全を保つために必要なパスワードの仕様に関する文書を見つけることができませんでした。それについてのいかなる考えも認められるでしょう。このLIBを使用すると、このように簡単です：
// Encryption
NSData *data = ...
NSString *password = @"Secret password";
NSData *ciphertext = [RNCryptor encryptData:data password:password];
// Decryption
NSError *error = nil;
NSData *plaintext = [RNCryptor decryptData:ciphertext password:password error:&error];
if (error != nil) {
NSLog(@"ERROR:%@", error);
return
}
// ...
AES256のiOSキーチェーン（またはドロイド同等）の暗号化 CC情報なしデバイスロックパスコードが有効になっていない場合、それは問題ではないのstorying？私の考えは、情報はすでにAES256で暗号化されていますが、キーチェーンの暗号化がなくてもデバイスに保存できますか？
多くのCC番号が格納されている中央サーバがない場合、PCI準拠のセクションはこの場合に関係しますか？私は、PCIの仕様を読んでみましたが、ドキュメントには、迷路をナビゲートするために:(
少なくとも、iDeviceにパスコードが有効になっていることを確認する必要があります。 – zaph
Aes256は256ビットのキーを必要としますが、cvcコードは10ビットの情報しか含んでいません。もし、cvcコードをキーとして使用するならば、無理矢理、これは即座に破られるだけでなく、その過程でcvcコードも漏れるでしょう。 –
これはApplePayがiOS側のものではありませんか？ – Bobson