Posted by Mike C# on 01/10/07 03:08

<dmalhotr2001@yahoo.com> wrote in message
news:1168397631.106000.311560@i39g2000hsf.googlegroups.com...
>I was wondering whether anyone ever dealt with encryption that are visa
> compliant with credit card numbers:
>
> On 3.4 of this document
> (http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf)
>
>
> It states the encryption:
>
> 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
>
>
> 1. One way hashes cannot be decrypted so this won't work

Question - for what reason do you need to encrypt and decrypt credit card #s
and SSNs? What kind of searches are you planning on doing that one-way
hashes won't work? Are you planning on running reports on all SSNs that
begin with "990" for instance, or all credit card #s that start with "8096"?

> 2. Triple DES works however we will need to encrypt SSN. Triple DES
> doesn't encrypt 2 values the same way, so we cannot use it as an
> index key that we wanted to. The decrypted value comes out the same
> however the encrypted values are always different. We can't do table
> scans for a SSN look up.

All encryption methods (via SQL Server 2005 T-SQL) salt the encrypted data
with a random IV. So no two encryptions of the same value should have the
same encrypted representation. You can create a pseudo-index on SSN by
storing a hash of the SSN in one column and storing the encrypted version in
another column. This will work for exact match searches (i.e., looking for
one exact SSN; WHERE ssn = 'xxx-xx-xxxx'), but not for range searches like
WHERE ssn < 'xxx-xx-xxxx'. You can also use a MAC code as described here:
http://blogs.msdn.com/raulga/archive/2006/03/11/549754.aspx

> 3. Truncation - I have no idea

You know, like the last 4 - 5 digits of the credit card. Question: do you
really absolutely have to store the entire credit card number? Many
businesses store just the last 4 - 5 digits and an authorization code.

> 4. Index token or PAD seems like one way encryption and never can be
> decrypted (not sure what this is for if it can't be decrypted)

Hashes and so on are useful for specific exact searches. For instance, if a
person calls in and you ask "what's your SSN?" Then you type it in, hash
it, and search for the hashed value in the table. No need to decrypt or
recover the plaintext of the stored SSN's. Again, just have to ask, but do
you absolutely *need* to store the entire SSN?

> So how do I get this to work?? It doesn't say RSA is compliant either.
> If you think RSA is okay, where does it EXPLICITLY say that on this
> document???

Sorry, not going to review the document, but if they don't give RSA as an
option, then don't use RSA.

[Back to original message]