Comments on: Encrypting sensitive data http://jpos.org/blog/2006/03/encrypting-sensitive-data/ jPOS rants, propaganda and some useful stuff. Sat, 24 Jul 2010 23:35:09 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: apr http://jpos.org/blog/2006/03/encrypting-sensitive-data/comment-page-1/#comment-89 apr Sun, 12 Mar 2006 14:55:31 +0000 http://jpos.org/blog/?p=21#comment-89 While reviewing use cases for the proposed scheme, I found that it has flaw when dealing with stand-in situations, where you need to SAF a message. You don't have access to the acquirer's encryption service at that time. I thought we could use an hybrid approach, local encryption until you transmit the transaction and get the acquirer-generated cryptogram. But this is actually not required if we use PKI. So the proposed scheme seems good to me for local encryption where you need to protect customer information. When you can use a remote encryption service, PKI is the way to go. You just need to encrypt using your acquirer's public key. While reviewing use cases for the proposed scheme, I found that it has flaw when dealing with stand-in situations, where you need to SAF a message. You don’t have access to the acquirer’s encryption service at that time.

I thought we could use an hybrid approach, local encryption until you transmit the transaction and get the acquirer-generated cryptogram. But this is actually not required if we use PKI.

So the proposed scheme seems good to me for local encryption where you need to protect customer information. When you can use a remote encryption service, PKI is the way to go. You just need to encrypt using your acquirer’s public key.

]]> By: Andy Orrock http://jpos.org/blog/2006/03/encrypting-sensitive-data/comment-page-1/#comment-88 Andy Orrock Sun, 12 Mar 2006 05:51:30 +0000 http://jpos.org/blog/?p=21#comment-88 jPOS readers and users will be interested to note that a good applicability for Alejandro's proposed approach is for adherence to Visa's CISP program. For auditing purposes and network compliance, applications connected to the Visa network (either directly or through a payment gateway like FDR, Fifth Third, NPC, etc.) must adhere to Visa’s Cardholder Information Security Program (“CISP”), which dictates acceptable practices in regards to the protection of cardholder data for official information, refer to http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html. The specific requirements at issue here are those related to cardholder data – these are discussed in bullets 3.3 and 3.4 of Visa’s Payment Card Industry (“PCI”) PCI Security Audit (see embedded PDF as hyperlink in Visa page referenced above). Those requirements read: 3.3 Mask account numbers when displayed (the first six and last four digits are the maximum number of digits to be displayed). Note that this does not apply to those employees and other parties with a specific need to see full credit card numbers. 3.4 Render sensitive cardholder data unreadable anywhere it is stored, (including data on portable media, in logs, and data received from or stored by wireless networks) by using any of the following approaches: • One-way hashes (hashed indexes) such as SHA-1 • Truncation • Index tokens and PADs, with the PADs being securely stored • Strong cryptography, such as Triple-DES 128-bit or AES 256-bit with associated key management processes and procedures. jPOS readers and users will be interested to note that a good applicability for Alejandro’s proposed approach is for adherence to Visa’s CISP program.

For auditing purposes and network compliance, applications connected to the Visa network (either directly or through a payment gateway like FDR, Fifth Third, NPC, etc.) must adhere to Visa’s Cardholder Information Security Program (“CISP”), which dictates acceptable practices in regards to the protection of cardholder data for official information, refer to http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html. The specific requirements at issue here are those related to cardholder data – these are discussed in bullets 3.3 and 3.4 of Visa’s Payment Card Industry (“PCI”) PCI Security Audit (see embedded PDF as hyperlink in Visa page referenced above). Those requirements read:

3.3 Mask account numbers when displayed (the first six and last four digits are the maximum number of digits to be displayed).

Note that this does not apply to those employees and other parties with a specific need to see full credit card numbers.

3.4 Render sensitive cardholder data unreadable anywhere it is stored, (including data on portable media, in logs, and data received from or stored by wireless networks) by using any of the following approaches:

• One-way hashes (hashed indexes) such as SHA-1

• Truncation

• Index tokens and PADs, with the PADs being securely stored

• Strong cryptography, such as Triple-DES 128-bit or AES 256-bit with associated key management processes and procedures.

]]>