Visa Encryption with Sql Server

[dmalhotr2001@yahoo.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/busines...y_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

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.

3. Truncation - I have no idea

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)


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???

:D

[Mike C#]

Re: Visa Encryption with Sql Server


<dmalhotr2001@y ahoo.comwrote in message
news:1168397631 .106000.311560@ i39g2000hsf.goo glegroups.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/busines...y_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.

[Laurentiu Cristofor [MSFT]]

Re: Visa Encryption with Sql Server

RSA is an asymmetric key algorithm - it is not meant for direct data
protection, so there is no point using it to protect SSNs.

Thanks

--
Laurentiu Cristofor [MSFT]
Software Development Engineer
SQL Server Engine

http://blogs.msdn.com/lcris/

This posting is provided "AS IS" with no warranties, and confers no rights.

"Mike C#" <xyz@xyz.comwro te in message
news:%OYoh.91$X a5.85@newsfe12. lga...

>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.
>
>

[Mike C#]

Re: Visa Encryption with Sql Server

Maybe that's the exact reason why they didn't specify he could use RSA in
the implementation docs...

Regardless, if they didn't specify RSA as an option he shouldn't use it.

YW

"Laurentiu Cristofor [MSFT]" <Laurentiu.Cris tofor@nospam.co mwrote in
message news:eu$eD%23ON HHA.1252@TK2MSF TNGP02.phx.gbl. ..

RSA is an asymmetric key algorithm - it is not meant for direct data
protection, so there is no point using it to protect SSNs.
>
Thanks
>
--
Laurentiu Cristofor [MSFT]
Software Development Engineer
SQL Server Engine

http://blogs.msdn.com/lcris/

>
This posting is provided "AS IS" with no warranties, and confers no
rights.
>
"Mike C#" <xyz@xyz.comwro te in message
news:%OYoh.91$X a5.85@newsfe12. lga...

>>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.
>>
>>

>
>