Combine Secure 3DES Encryption with ability to count occurence of known plaintext - how to accomodate both aims?

From: Andy (a_at_b.com)
Date: 01/19/05 

Date: Wed, 19 Jan 2005 16:27:58 +1300

Hi,

This isn't a terribly scientific question, but as a non expert using
cryptographioc products, I have ended up with what may be conflicting
requirements that need to be reconciled.

OVERVIEW

A database of credit card transactions is maintained. Every new transaction
has the transaction details including credit card number stored in a
database column. before writing to the column containing CC number, it is
encrypted using 3DES via a Hardware Security Processor (HSP).

The 3DES Encrypt/Decrypt command is used to encrypt the plaintext CC number
against a secret key encrypted against the HSP Master File Key.

I can instruct the HSP to encrypt the data using an IV that is randomly
generated by the HSP for every encryption and then store the encrypted
value and the IV (returned encrypted under the Atalla Master Key) for later
decryption (if the card needs to be refunded or transaction completed in a
two stage sales operation for example).

This would appear to be entirely satisfactory from an encryption viewpoint
as it provides separation of key from database (HSP is needed as well as
data) and the random IV protects against a known plaintext attack as even
if the attacker (insider?) was to choose a known credit card number as a
target, the IV would be unpredictable for each row and therefore credit
card.

PROBLEM:

We also need to be able to programmatically count within (say within a 14
day period) how many times a given credit card number has been used. The
reason is to perform velocity checking ; Eg: a phishing attack whereby an
attacker uses the same credit card number over and over varying expiry date
until an approval is received - the attacker now has a valid card number and
expiry date. The program should be able to block further attempts when a
specified threshold (eg 5 attempts with 48 hours) is reached. If we used a
null IV for every encryption, we would be able to encrypt the current
transactions CC number and then search preceding transactions for matching
encrypted values. If we use the random IV (to protect against known
plaintext attack by attacker with database access), then this velocity
checking doesn't work unless we decrypt each and every transaction again -
too expensive in terms of processor load.

An alternative is to leave the random IV for maximum security and to add a
new column with a one way SHA1 hash and use this to search for transactions
using the "same" card number, but we wouldn't be able to use salt for the
SHA-1 so would this make a new vulnerability?An insider attacker would then
be able to use the matching SHA-1 hashes for a known plaintext to determine
which encrypted columns had the same data.

Would an expert be able to venture an opinion?

1) Use 3DES with null IV for every option.
2) Add a SHA1 hash of the plaintext CC number (no salt) and search on that.

Relevant Pages

  • Re: Strongest encryption algorithm
    ... attacks have a complexity, the algorithm where the lowest complexity attack ... Before you can define the strengh of a cryptosystem by its complexity ... in this case it is incorrect to assume that the attacker can ... encrypt test messeges with the same key as the data was encrypted with. ...
    (sci.crypt)
  • Re: Encryption newbie - Same length encrypted result
    ... >the credit card fields to allow for longer encrypted cc numbers. ... >Currently the CC field can hold 20 characters. ... I want to encrypt any ... Use a block cipher with a 20 character block length. ...
    (sci.crypt)
  • Re: Needle in a haystack--or is this just stupid?
    ... I plan to encrypt them on disk with a symmetric ... However now suppose I'm worried that an attacker may simply ... >> disk I stored thousands of encrypted dummy files, ... adaptive chosen plaintext since once they steal my disk I'm not going ...
    (sci.crypt)
  • Re: PCI Compliance - Encryption of all non-console administrative access.
    ... security people wanting just that - encrypt "data at rest" in ... be able to generate fraudulent transactions. ... http://www.garlic.com/~lynn/aadsm27.htm#47 If your CSO lacks an MBA, fire one of you ...
    (bit.listserv.ibm-main)
  • Re: Strongest encryption algorithm
    ... encrypt test messeges with the same key as the data was encrypted with. ... The best that attacker can hope for is to encrypt a messege of his ... This requires a source of entropy during encryption, ... you have no clue about cryptography at all. ...
    (sci.crypt)