Encryption requirements for PANs in databases

[Patrick]

Hello,
I'm working in the UK where PCI compliance is not yet mandated but we are starting to firm up our software in readiness. We have limited knowledge of PCI:DSS and I was looking for a couple of pointers.

For our main retail product we use a database to store transaction details including the PAN and expiry date and from this we need to generate a submission file for the banks as well as reports for the retailer.

1: If the PAN is encrypted, do we need to encrypt the expiry date as well (we don't store the service code or card holder name so they're not a problem)?

2: I intend to use a password based encryptor using DES-EDE2 and HMAC/SHA-1. Is this strong enough encryption?

3: If so is there a minimum length for the password?

4: Section 3.6 of the standards talk about secure key storage, revocation of keys etc. Is the password a key? I was intending to hardcode the pass phrase in the dlls that required access to the PAN. Would that be acceptable?

5: I was planning to use PAN masking on reports for low level users but allow administrators to see the whole PAN. Can retailer reports include the full PAN if use of the reports is properly audited?

Thanks in advance for your help,
Patrick

[lyalc]

Here goes one view on the sketchy details you provided:
1. Yes
2. The encryption sounds Ok if you meant 3DES in EDE mode, but the key management processes is going to be a big hassle. See 3.5, 3.6. For example, how would you implement split knowledge or strong/random key generation with a single password used for the key?
3. See above first.
4. Hardcoding the password or "seed" for the key is not PCI compliant. It means the key is on the same disk, as well as present in every system backup -> why bother with encryption in the first place?

5. It depends on the overall lifecycle of the reports, and the actual business need to see the whole PAN in the report. Unless its essential for reconciliation purposes, I'd suggest you mask PANs in the report. If the PAN can't be masked, then get input from you friendly local QSA to avoid rework.

Why wouldn't something like the key generation processes in PGP or OpenSSL, and StrongKey (all Open Source) be suitable for an internally developed solution?
Or buy FIPS140 complaint/like commercial products.

Crypto is far too easy to get wrong, so I strongly suggest you use something thats already be reviewed, tested and widley accepted.

[Patrick]

Thanks for your quick reply Iyalc. Sorry for being sketchy but didn't want to bore you all with too much detail. Looks like I was a bit (LOT) naive on my first day looking at this! Thanks for the pointer to StrongKey; I was kind of ignoring the whole of section 3.6 before because I was out of my depth and had no chance of implementing it myself. Going to have alook at PGP and OpenSSL now to see how they'll fit in.

We will get a QSA involved eventually but at the moment I'm working very much on my own (as I said PCI isn't mandated here yet so there's no money from customers yet either) so any other pointers or advice will be very gratefully received.

Thanks again.

[admin]

You do not need to encrypt the expiration date.

[apm]

Patrick,

You say that PCI is not yet mandated in the UK but it is. PCI DSS compliance is required by the card schemes everywhere, the question is where are they enforcing compliance.

If you talk to any of the major acquirers in the UK they will not give you a new acquiring contract unless you are PCI DSS compliant. Our acquirers have told us that if we are not compliant by June 30th, 2007 they will be fined by MasterCard and pass the fines on to us. They have also stated that if we can not demonstrate progress in our PCI DSS compliance project by April (no problem for us) then Visa will fine them and they will pass on the fines.

In fact, PCI DSS COmpliance has been required (but pathetically enforced) since September 2004.

So I suggest you check with your acquirer and get them to verify if they tell you anything different. If they are adamant that you don't have to be compliant yet then I would be very interested in knowing which acquirer you are talking to!!!

[WeWontLoseItIPromise]

I am trying to solve PCI compliance issues at a medium sized merchant that conducts business entirely by card-not-present transactions on a recuring basis and hence stores PANs on internal billing systems.

The 2 billing systems are provided by vendors who are both global players in this particular market space with substantial client bases.

Each of these vendors claims PCI compliance. Where that regards encryption of PANs in databases they have in general used symetric or asymetric keys stored outside the database to encrypt PAN columns in their databases. While this does "encrypt" I think they key management, storage in particular, is not quite what the PCI DSS authors had in mind.

In both cases I have asked the vendors to consider improvements; one of whom so far has come to the table with a clear intent to make improvements for us. This vendor has quite reasonably asked what I would like them to implement to improve my confidence in their compliance status.

I am struggling to give them an answer.

If I ask for FIPS140/HSM level practices, they will probably object based on that pricing out most of their clients from using their product. We probably can't afford or properly manage it ourselves, let alone expect them to implement it properly.

I asked a local friendly QSA whether FIPS140/HSM practices are required; they answered that the requirement, while alluded to in the DSS, was clarified in the QSA training. They said that FIPS140/HSM not necessary and that row/column level encryption is adequate using modern database functionality. Unfortunately it was not made much clearer than that and there is a lot more to the problem.

If the PCI council expect all merchants to reach FIPS140 practices and use a HSM, they will probably get 10% compliance in reality. If they clearly mandate less rigorous practices, based on functionality that is built into mainstream databases, then they will probably get 90% compliance and a huge improvement in over risk reduction.

Problem is; I don't know what is good enough and even the willing vendors don't know what they should be aiming for. Do any readers have guidance on this?

Take for example MSSQL2005 - it has built in row/column encryption capabilities based on a key heirachy which leverages a not perfect but pretty decent OS provided secure key storage function. When combined with strong authentication and least-priv access to decryption capabilities, this is a big step forward over "roll-your-own" encryption & key-management built for each application.

Discussion & suggestions greatly appreciated.

[lyalc]

Database/column encryption is generally 'good enough' for PCI, provided the key management aspects are also addressed.
Fips/HSM approaches are not esential but good recomemendations where its affordable.
For instance, SQL 2005 stored the keys on the same system/media, which seems to conflict with 3.4.1 and 3.5.

Also, SQL queries have to reference the key (as far as I am told), meaning a chnage to queries.

Oracle 10g separates out key management, and applies the same key to a column, thus not change to queries. To me, this seems a cleaner and preferrable option, along with supporting split key/dual control.
I'm not sure of MySQL or PostGresSQL.

With SQL 2005, I think there is a need for Smartcards and readers, to meet the split knowledge aspect. Maybe Dual Control can only be acheived by locking the server up, and having 1 person control the cabinet key, another administer SQL.

[Patrick]

An alternative to HSMs are Trusted Platform Modules (TPMs - https://www.trustedcomputinggroup.org/home). The intention is to include a chip on motherbaords (http://www.intel.com/design/motherbd/rh/index.htm) as standard where they provide secure storage for keys.

As a software developer working on PCI:DSS I'm looking at using symmetric keys for PAN encryption (DEKs) that are themsleves stored encrypted by another key (KEK) in the standard file system. The KEK can remain in either a TPM or HSM depending on the customers requirements/facilities and potentially be escrowed to another server encrypted by a public key from that server (along with all the encrypted DEKs).

Hope that helps some wewon't.

PS: if anyone can see holes in the above scheme, please let me know :)
Thanks,
Patrick

[lyalc]

We're getting well off the orignal thread here, but TPMs may have some issues.
In the event the KEK is bound to the TPM, then migrating key storage keys to anonther server, or retaining them for long term retrieval or 'old' data may be problematic.

Using another server to escrow/manage the KEKs seems to just duplicate having a HSM for the key management purpose.

Developing your own code for split knowledge and 'n of m' key export/import schemes isn't always trivial or a good use of time.

Lyal

[WeWontLoseItIPromise]

For instance, SQL 2005 stored the keys on the same system/media, which seems to conflict with 3.4.1 and 3.5.

3.4.1 specifically applies to "disk level encryption" so should not affect keys used to encrypt data in a database. Did you mean to list a different point number?

[fatal]

The UK is absolutely required to be PCI DSS compliant and they are getting just as much pressure as my US customers are.

http://www.visaeurope.com/aboutvisa/security/ais/requirements.jsp

[mdahn]

You do not need to encrypt the expiration date.

I would also note a recent post on the blog: Encryption for PCI Compliance (http://pcianswers.com/2007/05/01/encryption-for-pci-compliance/)