Sensitive Auth Data?

[ASL]

Previous discussions in this forum have confirmed that if card holder data is encrypted with a key and stored in a db site and the db site does not have the key, then the data in the db site is considered to be "not" card holder data.

Lets extend this concept to sensitive auth data.

The sensitive data (the whole of Track2) is encrypted in an HSM with an AES256 key, the key is destroyed and the encrypted data is persisted to db. Lets assume the db is offsite from the HSM site.
Is the db holding sensitive auth data? Lets remember, the track2 cannot be recovered, retrieved or extracted in any way at the db site.
Is the HSM site compliant with PCI DSS as it is not holding any data and no longer has the key that was used to encrypt the data?
View both sites a one entity, is this entity compliant given the sensitive auth data cannot be recovered, retrieved or extracted in any way?

If either the db or the HSM site is non compliant, then IMHO this is a bit of a hypocritical stance to take. You can't seperate out concepts because of the name or type of the data, either it is not the original data or it is the original data, regardless of what the original content was.

[jbhall56]

Previous discussions in this forum have confirmed that if card holder data is encrypted with a key and stored in a db site and the db site does not have the key, then the data in the db site is considered to be "not" card holder data.

I'm not sure where you got this idea, but it is not true. Encrypted data is ALWAYS cardholder data (CHD). The only way it is not considered CHD is when it is either (a) truncated or masked, OR (b) it is one-way hashed. Encryption implies decryption, which means that it can be turned back into readable data, therefore it is always considered CHD. The storage of the key away from the DB in question is just a 'best practice' to ensure the encrypted data cannot be readily decrypted.

Lets extend this concept to sensitive auth data.

The sensitive data (the whole of Track2) is encrypted in an HSM with an AES256 key, the key is destroyed and the encrypted data is persisted to db. Lets assume the db is offsite from the HSM site.
Is the db holding sensitive auth data? Lets remember, the track2 cannot be recovered, retrieved or extracted in any way at the db site.
Is the HSM site compliant with PCI DSS as it is not holding any data and no longer has the key that was used to encrypt the data?
View both sites a one entity, is this entity compliant given the sensitive auth data cannot be recovered, retrieved or extracted in any way?

While I would agree with the concept of your premise, according to requirement 3.2.1, "Do not store the full contents of any track from the magnetic stripe ..." That means that you CANNOT store any track data REGARDLESS of how secure you think you might have made it. There are NO EXCEPTIONS to this rule. Trust me, others have tried and been rejected. 3.2.1 is the ONLY requirement that cannot be met by compensating controls, you MUST comply with 3.2.1 exactly as written.

[ASL]

I'm not sure where you got this idea, but it is not true. Encrypted data is ALWAYS cardholder data (CHD). The only way it is not considered CHD is when it is either (a) truncated or masked, OR (b) it is one-way hashed. Encryption implies decryption, which means that it can be turned back into readable data, therefore it is always considered CHD. The storage of the key away from the DB in question is just a 'best practice' to ensure the encrypted data cannot be readily decrypted.
.

I refer to the comment from CMARK in the recent forum discussion titled "Is this PAN data?"
< In the same vein a solution where data was encrypted with assymetric crypto using a public key retained on the server and the private key was retained by the merchant off the network was determined by the card brands to not be cardholder data. There were some pretty strict caveats around the solution (key had to be generated off the network, data had to be downloaded before decrypted, etc.etc._) but it demonstrates a similar concept. >

and similar concepts are peppered throughout this forum and others. By the above comment, the card brands have already made a ruling on some system that does exactly this with CHD.

So, encrypted data is NOT always CHD. If the key is not available at the db site, then the data is not whatever the original was. Truncated, masked or one way hash is not the only way to protect CHD.

Therefore take it to the next step and apply other data types to this concept.

[andrewj]

The problem appears to be that you are asking half questions, that and looking for authoritative answers. What is the point of encrypting data with a (random, symmetric, well controlled) key that you immediately destroy?

Clearly there is none.

However, if you encrypt any data with a random, 256 bit AES key that never exists outside of a TRSM, and you destroy the key immediately afterwards, then you have effectively produced a random mapping of the data from the pre-image space of the track data to the image space of the output cryptogram. It is totally and irreversibly unrecoverable, and if the data is stored in a block of 128 bits (ie a single AES block - not necessarily possible for full track data) it in fact provides 'perfect secrecy', which is to say that all possible pre-images are equally likely to have produced the ciphertext, and therefore the true pre-image cannot be determined from any other possible pre-image. Eg the cipher text could be decrypted into all possible track 2 values, providing different possible values of the key that was used.

At this point, when the key is erased, it ceases to be track data and becomes random data.

Of course, this assumes that the key is truly random and contains 256 bits of entropy (hard to impossible, depending on your faith in things like FIPS Special Publication 800-22); that it is completely zeroised after use, and no information on its use is leaked through any side channels that are not completely plugged in the HSM; that you can somehow pack the data into 128 bits; and that it only ever exists within the TRSM of the HSM.

The above pre-requisites make this system no use to anyone. Once you start maintaining the key for any length of time, problems creep in that change the answer to this question. So, we need more information.

[ASL]

Although the idea may seem useless, it's the concept I'm thinking of. From just two replies we have two totally different viewpoints about what the data is if the key is destroyed (putting aside issues about randomisation, zeroing, key length, key device etc).

Rulings should be based upon logical foundations, and hopefully qualified opinions are also. The fact is that some QSA's, and the card brands, now view certain data sets as not CHD, even though the dataset originated from CHD. Saying this isn't so just does not fit with the current situation today.

Once one accepts the logic that CHD can be turned into non CHD by some process, where does this lead to?

Lets look at current concepts. Given that the sensitive data we are talking about in a Track2 dataset is the Discretionary Data field and the LRC(everything else in Track2 is allowed to be stored), what if the DD and LRC was truncated? Is it still the same data? Obviously not if it was truncated to nothing but what if one digit remained, or two or three (say out of ten)? At what stage does non data turn back into original data and vice versa?
This is where it gets into a very grey area. The effort and cost of recovery seems to me to be the next primary consideration eg the breaking of a POS terminal, 6 weeks and 250k.

[lyalc]

True, it is well accepted that CHD can be transformed into 'not CHD'. Examples are hashing or similar one-way functions, truncation etc, so there is nothing new in this thread so far.

Nothing so far indicates track 2 can be stored, ever.

Encryption implies decryption is possible. In the event that the auditor is aso a crypto expert and willing to assess the complete HSM functionality as part of the whole PCI solution (not the common "there's a HSM therefore crypto is done Ok" approach), then the conceptual approach outlined may be accepted - in some cases.

Remember, each QSA is expected to be 'reasonable' as in would another QSA come to a similar conclusion - we put our accreditation and reputations on the line for every PIC requirement assessed as 'compliant'.

I'd suggest getting detailed assessment outcomes from a QSA on specifics, not the generalisations here. There are too many nuances involved in the original hypothetical situation, let alone the subsequent 'what ifs'.

If you are looking for guidance on producing a PCI-compliant product, then get a QPASP invovled and have the result PABP/PA DSS certified. I suspect the hypothetical may be too site specfic, however, for PABP to be a real option.

[andrewj]

There has always been an accepted method of turning CHD into non-CHD; deletion. The process you describe (encryption with a random key that is instantly destroyed, and never exists outside of a TRSM) is merely another (more complex way) of achieving such deletion. It should not be confused with any other process that does not achieve the deletion of the data, such as truncation.

Put another way, the initial question was essentially philosophical - one hand clapping the fall of an unheard tree, and all that. It has no logical base, or implementation. Moving away from such philosophy brings the question into the real world where things are still black and white (not grey).

Storage of track data post authorisation is not permitted.

[jbhall56]

At the end of the day, someone has to stand up and ask the real question here. Why are you going through all of this effort to destroy the data in the first place?

You obviously have the capability to modify your code, so why go through all of the hoops that have been discussed in this thread? Just avoid storing the data in the first place. This seems a LOT simpler to me than developing some Rube Goldberg method of securing data that you obviously have no future use for since you will be obscuring it. You'll save storage space and make your software less complex.

[cmark]

The comment related to encrypted data not always being CHD came directly from me and is indeed accurate. I have worked with both of the largest card brands on this concept. There are several solutions that employ DUKPT, PGP and other technologies that render the data as 'non data' when implemented correctly. There is theory and then there is practice. While encrypted data can be unencrypted, without the key, and with the appropriate algorythm etc. etc., it approaches mathematical impossibility to compromise the data. It is not simply the technology but the application that must be considered.

With regard to sensitive authentication data, this is a common debate. We all know that without the PAN the CVV data is really meaningless data. That being said, it simply poses to great of a risk for the PCI SSC/Card Brands to make a statement that suggests that this data can be retained if PAN etc. is not. It is a violation of not only the PCI DSS but the card brand's operating regulations to retain this data. It is not needed after the initial authorization response and as such cannot be retained. That being said, should a company decide to pull the CVC data out and encrypt nobody would likely be the wiser but it would still be a violation.

[ASL]

That being said, it simply poses to great of a risk for the PCI SSC/Card Brands to make a statement that suggests that this data can be retained if PAN etc. is not. It is a violation of not only the PCI DSS but the card brand's operating regulations to retain this data.

I refer to PCI DSS "If a PAN is not stored, processed or transmitted, PCI DSS requirements do not apply".

I'm a database provider, I receive data that contains the DD, it is encrypted, I cannot read it. I store this data. I never know or see whatever key was used for the encryption process.
I do not have the PAN. I never see, store, process or transmit the PAN. Therefore does PCI DSS, or PABP or PA or anything else apply to me and if so then please reconcile this position to the above statement.

[cmark]

If you receive cardholderdata from a client, it is your client's responsibility to ensure compliance with the PCI DSS. This means ensuring their service providers support their compliance.

This is the same argument that hosting providers (I used to work for one and this was my argument.) use which would be to say "...hey I just provide ping, power and pipe. I don't really care if my client puts a body in the cage. It is not my responsibility."

This is indeed true but if my client tells me that I am receiving PCI data and must comply, then my lack of support will simply cause my client to be out of compliance. They have a business decision to make in that case. Use the vendor that will not support compilance or go somewhere else that will support compliance.

If someone is sending your organization the track data (minus the PAN), technically they are in violation of the PCI DSS and operating regulations (even if encrypted) unless they have a legitimate need for such data (on the issuing side, for example). Will anyone every find out? Likely not. Will there ever be a compromise in which the data is discovered through a CPP investigation? Unlikely. Will they ever be declared 'non compliant'? doubful. If you are simply providing database services to your client and they are sending you encrypted data and it contains prohibited data, shame on them as it is their data. If it does not have PAN, then technically they are in violation of the PCI DSS but it does not mean that you now have to comply.

If your clients send you cardholder data (ignore the sensitive auth. discussion for a minutes) you are a service provider and specifically a MasterCard DSE. You then have an obligation to register and comply with the PCI DSS. If all you see is an encrypted data stream and you do not have the key to decrypt, in all honesty, my position would be that your client needs to ensure that they are not sending you prohibited data. If you do not have the key to decrypt the data, then it is a risk decision for your client and I would say that you are not in a position to have to comply.

The discussion is whether you have cardholder data or not. My position would be that you have data that puts your clients in violation of the card brand rules but that you do not have cardholder data and thus you do not have PCI DSS requirements. (you may have other services you provide but I am using the simplest approach here)

It really comes down to intent, recognition and responsibility. If I am renting a storage shed, that storage shed owner is not responsible if I put a body in the shed. If however, my neighbor comes over and offers to store dead bodies for me in his basement, then he is liable as he knowingly supported said retention. Same applies to you. You are storing data that is not technically cardholder data. It is still a violation of your client to retain. Likely nobody will every be the wiser but I don't see it being a PCI DSS issue for you.