PKF AvantEdge

Tag: encryption

PCI-DSS Scope Understanding: Encryption

July 20, 2024 / / 0 Comments

Scoping is one of the first and main thing that we do the moment we get engaged, after the customary celebratory drinks. In all projects, scope is always key, moreso in auditing and consulting, in standards compliance, be it PCI, ISMS, NIST 800s, CSA or all the other compliances we end up doing. Without scope there is nothing. Or there is everything, if you are looking at it from the customer’s viewpoint. If boundaries are not set, then everything is in open season. Everything needs to be tested, prodded, penetrated, reviewed. While this is all good and all, projects are all bounded by cost, time and quality. Scope determines this.

In PCI, scoping became such a tremendously huge issue that the council deem it necessary to publish an entire supplemetary document called “Guidance for PCI DSS Scoping and Network Segmentation” back in December 2016. Now, here is a trivia for you, from someone who has been doing PCI for donkey years. Did you know that this isn’t even the first attempt at sorting out scope for PCI-DSS?

Back in 2012, there was a group Open Scoping Framework Group that published the extremely useful Open PCI-DSS Scoping Toolkit that we used for many years as guidance before the council amalgamated the information there into formal documentation. This was our go-to bible and a shout out to those brilliant folks at http://www.itrevolution.com for providing it, many of its original concepts retained when PCI council released their formal documentation on scope and eventually within the standards itself. YES, scoping is finally in the iteration of v4 and v4.0.1 for PCI-DSS in the first few pages, so that people will not get angry anymore.

Or will they?

We’re seeing a phenomenon more and more in the industry of what we term as scope creep. Ok fine, that’s not our word. It’s been in existence since the fall of Adam. Anyway, in PCI context, for no apparent reason some of our customers come back to us and state their consultants, or even QSAs insists on scope being included — for NO REASON except that it is MANDATORY for PCI-DSS. Now, I don’t want to say we have no skin in the game, but this is where I often end up arguing with even the QSAs we partner with. I tell them, “Look, our first job here is to help our customers. We minimize or optimize scope for them, reducing it to the most consumable portion possible, and if they want to do anything extra, let them decide on it. We’re not here to upsell Penetration testing. Or segmentation testing. Or Risk Assessment. Or ASV. Or Policies and Procedures. Or SIEM. Or SOC. Or Logging. Or a basket of guavas and durians.” Dang it, we are here to do one thing: get you PCI compliant and move on with our lives.

The trend we see now is that everything seems to be piled up to our clients to do this and to do that. In the words of one extremely frustrated customer: “Everytime we talk to this *** (name redacted), it seems they are trying to sell us something and getting something out of us, like we are some kind of golden goose.”

Now, obviously, if you are a QSA company and doing that:- STOP IT. Stop it. It’s not only naughty and bring disrepute to your other brethren in the industry, it’s frowned upon and considered against your QSA code! Look at the article here.

Now PCI scoping itself deserves a whole new series of articles but I just want to zoom down to a particular scoping scenario that we recently encountered. It’s in a merchant environment.

Now many of our merchants have either or both of these scopes: Card terminal to process card present at the stores and E-Commerce site. There is one particular customer with card terminal POI (point of interaction), or traditionally known as EDCs (Electronic Data capture). Basically this is where the customer comes, take out the physical card and dip/wave it to this device at the location of the stores. So yes, PCI is required for the merchant for the very fact that the stores have these devices that interact with cards. Now what happens after this?

Most EDCs have SIM based connectivity now, and it goes straight to the acquirer using ISO8583 messages. These are already encrypted on the terminal itself and routes through the telco network to the bank/acquirer for further processing. Other ways are through the store network, routing back to the headquarters and then out to the acquirer. There are reasons why this happens, of course, one would be the aggregation of stores to HQ allows more visibility on the transactions and analysis of traffic. The thing here is, the terminal messages are encrypted by the terminals, that the merchants do not have any access to the keys for decryption. This is important.

Now, what happened was that some QSAs have taken into their mind that because the traffic is routed through the HQ environment, the HQ gets pulled into scope. And therefore , this particular traffic must be properly segmented and then segmentation PT needs to be performed. This could potentially lead to a lot of issues, especially if your HQ environment is populated with a lot of different segments – it could constitute multiple, tiring, tedious testing by the merchant team….or it could constitute a profitable service done by your ‘service providers’ (Again, if these service providers happen to be your QSA, you can see where the question of upsell and independence come from).

Now here’s the crux. We hear these merchants telling us, oh, their consultant or QSA say that it’s mandatory for segmentation PT to occur in this HQ environment. The reasoning is that there is card data flowing through it. Regardless whether it is encrypted or not, as long as there is card data, IT IS IN SCOPE. Segmentation PT MUST BE DONE.

But. Is it though?

The whole point of segmentation PT is that it demarcates out of scope to in-scope. By insisting to have segmentation PT done, is to concede that there is an IN-SCOPE segment or environment in the HQ. The smug QSA nods, as he sagely says, “Well, as QSAs, we are the judge, jury and executioner. I say there is an in scope, regardless of encryption.”

So, we look at the PCI SSC and the standards, and let’s see. QSAs will point to page 14 of PCI-DSS v4.0 standards under “Encrypted Cardholder Data and Impact on PCI DSS Scope”.

Encryption alone is generally insufficient to render the cardholder data out of scope for PCI DSS and does not remove the need for PCI DSS in that environment.

PCI-DSS v4.0.1 by a SMILING QSA RUBBING PALMS TOGETHER

Let’s read further this wonderful excerpt:

The entity’s environment is still in scope for PCI DSS due to the presence of cardholder data. For example, for a merchant card-present environment, there is physical access to the payment cards to complete a transaction and
there may also be paper reports or receipts with cardholder data. Similarly, in merchant card-not-present environments, such as mailorder/telephone-order and e-commerce, payment card details are provided via channels that need to be evaluated and protected according to PCI DSS.

So far, correct. We agree to this. Exactly like what was mentioned, PCI is in scope. The question here is, will the HQ gets pulled in scope just for transmitting encrypted card data from the POIs?

Let’s look at what causes an environment with card encryption to be in scope (reading further down the paragraph)

a) Systems performing encryption and/or decryption of cardholder data, and systems performing key management functions,

b) Encrypted cardholder data that is not isolated from the encryption and decryption and key management processes,

c) Encrypted cardholder data that is present on a system or media that also contains the decryption key,

d) Encrypted cardholder data that is present in the same environment as the decryption key,

e) Encrypted cardholder data that is accessible to an entity that also has access to the decryption key.

So let’s look at the HQ scope. Does it cover the following 5 criteria for in-scope PCI-DSS dealing with encrypted card data? There is no decryption or encryption process done. The encrypted cardholder data is isolated from the key management processes. The merchant has no access or anything to do with the decryption key.

So now you see the drift. Moving down the paragraph, we find noted that when an entity receives and/or stores only data encrypted by another entity, and where they do not have the ability to decrypt the data, they may be able to consider the encrypted data out of scope if certain conditions are met. This is because responsibility for the data generally remains with the entity, or entities, with the ability to decrypt the data or impact the security of the
encrypted data.

In other words: Encrypted cardholder data (CHD) is out of scope if the entity being assessed for PCI cannot decrypt the encrypted card data.

So now back to the question, if this is so, then why does the merchant still need PCI? Well, because it’s already provisioned above: For example, for a merchant card-present environment, there is physical access to the payment cards to complete a transaction and there may also be paper reports or receipts with cardholder data.

So therefore, stores are always in scope. The question we have here is, if the HQ or any other areas are pulled in scope simply for transmitting encrypted CHD as a passthrough to the acquirer. In many way, this is similar to why PCI considered telco lines as out of scope. They simply provide the highway where all these encrypted messages travel on.

Now, of course, the QSA is right about one thing. They do have the final say, because they can still insist on customers doing the segment PT even if its not needed by the standard. They can impose their own risk-based requirements. They can insist the clients do a full application pentest or ASV over all IPs not related to PCI. They can insist on clients getting a pink elephant to dance in a tutu in order to pass PCI. It’s up to them. But guess what?

It’s also up to the customer to change or have another opinion on this. There are plenty of QSAs about. And once more, not all QSAs are created equal as explored in our article here.  Here we debunk common myths like whether having a local QSA makes any difference or not (it doesn’t), and whether all QSAs interpret PCI the same way (they don’t) and how important independence and conflict of interest should play a role, especially in scoping and working for the best interest of the customer, and not peddling services.

So, if you want to have a go with us, or at least just get an opinion on your PCI scope, drop a message to pcidss@pkfmalaysia.com and we will get back to you and sort out your scoping questions!


PCI-DSS V4.0 Deep Dive 2: Keyed Cryptographic Hashing

May 20, 2024 / / 0 Comments

As we delve into the intricacies of the PCI-DSS v4.0 standard, it’s crucial to understand the significance of each requirement and its impact on safeguarding sensitive cardholder data. For this article, we’ll be focusing on Requirement 3.5.1.1, which revolves around the use of keyed cryptographic hashing for protecting Primary Account Numbers (PANs).


Requirement 3.5.1.1 states that “Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.”

Firstly, like everything else from interpreting history to interpreting your wife’s nuanced tone when she says, “It’s fine.”, everything needs a little contextualization. Luckily for us, PCI has placed some explanation for us to jumpstart the discussion.

A hashing function that incorporates a randomly generated secret key to provide brute force attack resistance and secret authentication integrity.
Appropriate keyed cryptographic hashing algorithms include but are not limited to: HMAC, CMAC, and GMAC, with an effective cryptographic strength of at least 128-bits (NIST SP 800-131Ar2).
Refer to the following for more information about HMAC, CMAC, and GMAC, respectively: NIST SP 800-107r1, NIST SP 800-38B, and NIST SP 800-38D).
See NIST SP 800-107 (Revision 1): Recommendation for Applications Using Approved Hash Algorithms §5.3.

Definition of Keyed Cryptographic Hash, PCI Glossary

So that’s a lot of MACs.

Let’s break it down. The requirements has 3 areas of importance, which we have helpfully underlined.

Keyed Cryptographic Hashes

The requirement mandates the use of keyed cryptographic hashes to render PANs unreadable. A keyed hash basically takes the entire PAN and combines it with a secret key to produce a unique, fixed-size output that is practically impossible to reverse-engineer without knowing the key. This way, even if an attacker gains access to the hashed PAN, they won’t be able to derive the original PAN without the secret key.

In 3.2.1, this was not stated and therefore the assumption that a simple hash was sufficient. Let’s listen to what this old obsolete standard says: “It is recommended, but not currently a requirement, that an additional, random input value be added to the cardholder data prior to hashing to reduce the feasibility of an attacker comparing the data against (and deriving the PAN from) tables of precomputed hash values.”

That aged like milk. Basically they are talking about salt. The goal of salting is to protect against dictionary attacks or attacks using a rainbow table. If no secret salt is used, or if the salt has not been sufficiently protected, the corresponding data, for example the PAN, can be read from the attacker’s previously calculated dictionaries or rainbow tables. So in short, salts are good for the world. Except for Salt Bae. He’s no good.

Salting creates slow hashing, which is the point. So that it takes a few billion years for brute force to be successful. How different is salting from keyed hashes? For one, salts are generally known. Sometimes they are even stored together with the hash in the database. So if let’s say, that’s compromised, Salt is known. I suppose, you can say “Live by the salt, die by the salt.” Ha!

Keyed Crypto Hashes mean there is a secret key. And before you go and jump off the building, there are already existing algorithms out there (The MAC brothers) that has previously been used — primarily, to my knowledge — for message integrity checks. In fact, the MAC here means Message Authentication Code to check integrity and authenticity. Unlike the salt, it ISN’T known, or at least not unprotected. So even if the database is compromised, they can’t get the key, because it’s protected (through encryption, later on to explain).

Now, why the change from normal hash, with recommended Salt, to hash with secret key?

The problem is with card numbers. Those dang card numbers, which is so different from let’s say passwords. Unlike passwords, where it could really be random, credit card numbers are NOT random. They are unique, but they are far from random. You see, a credit card consist of:

  1. The bank identification number (BIN) or issuer identification number (IIN): The first six digits is the issuer id. You can go https://www.bindb.com/bin-list
  2. The account number: The number between the BIN and the check digit (the last digit) is six to nine digits long and is used to identify the individual account number.
  3. The check digit: The last digit, added to validate the authenticity of the credit card number. This is by using the Luhn algorithm.

The thing about Luhn is that it is used to validate primary account numbers. I am not going into details, as other people have done so and will do a much better job in explaining this. But the short of it is that, if I have the BIN, and I have the Luhn and I have, let’s say 3 more numbers of the account number, then you get the picture. The Luhn digit is the result of the luhn algorithm applying to all the previous numbers (right first to left), which you already known, if it’s truncated! You would already know 9 digits (first six, last three, the last being the final luhn result). It’s likely still going to take a lot of effort, but the predictable way credit cards are structured actually provides less fields to be guessed. As scary as it may sound, hashes can be possibly reversed. Well, not ‘reversed’ per se but ‘reconstructed’ through guesswork and bruteforce.

While salt adds complexity and make it slower, salts aren’t secret, remember, so eventually that can still be broken. A Key however is secret. Remember the data encryption key, key encryption keys? Well, hashing now requires the same treatment as encryption in that sense that these keys need to be encrypted.

The other important bit of this requirement is the requirement emphasizes that the entire PAN must be hashed. This is important because hashing only a portion of the PAN would still leave some sensitive information exposed. By hashing the entire PAN, we ensure that no part of it remains in plain text, adding an extra layer of protection.

Lastly, the requirement stresses the importance of proper key management processes and procedures, as outlined in Requirements 3.6 and 3.7. This means that the secret keys used for hashing must be securely generated, stored, and managed throughout their lifecycle. Weak key management can undermine the entire purpose of keyed hashing, so it’s crucial to get this right.

What does this mean?

It means, like a lot of new requirements in v4.0: more work.

It is, in its heart, a concept of defense-in-depth. Requirement 3.5.1.1 serves as a secondary line of defense against unauthorized access to stored PANs. Even if an attacker manages to exploit a vulnerability or misconfiguration in an entity’s primary access control system and accesses the database, the keyed cryptographic hashing of PANs acts as an additional barrier, preventing the attacker from obtaining the actual PANs, unless they manage to compromise the key.

By implementing a secondary, independent control system for managing cryptographic keys and decryption processes, entities can ensure that a failure in the primary access control system doesn’t automatically lead to a breach of PAN confidentiality. For instance, instead of storing the PANs in plain text, a website employs a keyed hashing algorithm, such as HMAC-SHA256, to render the PANs unreadable. Each PAN is combined with a unique, randomly generated secret key before being hashed, and the resulting hash values are stored in the website’s database.

Final note: It’s important to note that Requirement 3.5.1.1 applies to all instances of stored PANs, whether in primary storage (databases, flat files) or non-primary storage (backups, audit logs, exception logs). This means that entities must ensure that keyed cryptographic hashing is implemented consistently across all storage locations, leaving no room for gaps in protection.

However, the requirement does make an exception for temporary files containing cleartext PANs during the encryption and decryption process. This is a practical consideration, as it allows entities to temporarily work with unencrypted PANs while performing necessary operations, as long as the temporary files are properly secured and promptly removed after use.

If you have any questions or need assistance in navigating the complexities of PCI-DSS v4.0, don’t hesitate to reach out to us at avantedge@pkfmalaysia.com. Our team of experienced professionals is here to help you every step of the way, ensuring that your organization stays secure, compliant, and ahead of the curve in the ever-evolving landscape of data security.

PCI-DSS and Vendors

June 20, 2020 / / 0 Comments

One of the things that advisors and consultants do, as part of our journey to get our clients to comply to PCI-DSS is the inevitable (and unenviable) task of dealing with vendors. A vendor can be classified as anyone or any company that is selling a service or a product to our client, that directly or indirectly relates or affect their PCI-DSS compliance. Examples include firewall vendors, encryption technology vendors, HSM vendors, server vendors, Virtual solution vendors, SIEM vendors, SOC providers, call center solution vendors, telemarketing services, hosting providers, cloud providers and the list goes on. Having dealt with hundreds of vendors over the course of the decade we have come across all kinds: some are understanding, some are hostile, some are dismissive, some are helpful and the list goes on.

But there is always a common denominator in vendors: They all start by justifying why their product or service is:

a) Not relevant to PCI-DSS compliance (because they don’t store card data, usually)

b) Why their product is PCI acceptable (but it’s really not, or when we have questions on certain aspects of it)

It always begins with these two start points and it can then branch off into a myriad of different plots, twists, turns and endings, very much like a prolonged Korean drama.

With this in mind, we recently had an interesting call with one of such vendor, who basically runs a fairly important PCI subsystem for one of our clients. The problem was that their logs and console had two things that we sometimes find: the combination of truncated and hashed values of a credit card information, grouped together.

Now, just a very quick recap:

a) Truncated card data – This is where you see parts of the card replaced by XXXX characters (or any character) where the full card number is not STORED. Now it must be noted that TRUNCATED and MASKED are treated differently, although oftentimes confused and used interchangeably. When we say something is MASKED, it generally means the PAN (Primary account number) is stored in full but not displayed in full on the console/application etc. This applies sometimes to call centers or outsourced services where full PAN is not required for back office operations but for reconciliation or references. TRUNCATED here means even in storage, the full PAN is not present.

b) Hashed Card Data – Hashing means its a one-way transformation of card data into a hash value with no way to reverse it (Unlike encryption). If we use a SHA-256 hash algorithm on a PAN, you get a fixed result. Fraud management systems may store this hash PAN in order to identify transactions by that particular card (after hashing), and not worry about the actual card data being stored. It’s like hashing of passwords where the actual password isn’t known.

It’s to be noted, when done properly, these two instances of data may even be considered entirely out of scope of PCI-DSS. The problem here is when you have both of these stored together and correlated together, it renders the data protection weaker than just having one control available. This is probably where the concept usually gets lost on clients implementing these controls, as we have seen many times before – for example, tokenized information being stored together with truncated values.

Even PCI-DSS itself states clearly in the standard item 3.4 in the Note, that “Where hashed and truncated versions of the same PAN are present in an entity’s environment, additional controls must be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.”

To clarify, it doesn’t mean that it CANNOT be done, but additional controls must be in place. A further look at this is found in the Tokenization Product Security Guidelines Supplementary document:

IT 1A-3.b: Verify that the coexistence of a truncated PAN and a token does not provide a statistical advantage greater than the probably of correctly guessing the PAN based on the truncated value alone.

Further on:

…then the vendor provides documentation to validate the security strength (see Annex C – Minimum Key Sizes and Equivalent Key Strengths for Cryptographic Primitives) for each respective mechanism. The vendor should provide a truncated PAN and irreversible token sample for each.

And furthermore in Tokenization_Guidelines_Info_Supplement.pdf:

Note: If a token is generated as a result of using a hash function, then it is relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of the PAN. Where hashed and truncated versions of the same PAN are present in the environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN.

So in short, at anytime we see there are hashed values and truncated value together, we need to validated further on the controls. A good writeup is found here at another blog which summarises the issues surrounding this.

However, as our call with this particular vendor continued on, he demonstrated just how vendors should or should NOT approach PCI-DSS compliance, which sort of inspired this post:

A) DON’T place yourself as the topical expert in PCI-DSS: Don’t. Not because you are not, but because you are representing a product or a service, so you always view certain things through a lense you have been trained on. I know, because I was with vendors for many years and most of our consultants are from vendor backgrounds. He immediately started by stating, he is extremely well verse with section 3.4 of PCI-DSS (which basically talks about the 4 options of protecting card holder data stored), and that he has gone through this conversation many times with consultants. This immediately sends the QSA red flags, once the vendor starts moving away from what they know (their product) to what they may think they know but generally may not (PCI-DSS), and in general we don’t want to put the auditor on defence once vendors sound defensive. It should be collaborative. DO state clearly that we are subject matter experts in our own field and we are open to discussions.

B) DON’T recover by going ‘technical’: In his eagerness to demonstrate his opinion on PCI, he insisted that we all should know what 3.4 is about. Concerning the four controls stated in PCI-DSS (token, truncation, hashing, encryption), he claimed that their product is superior to what we are used to because his product has implemented 3 out of 4 of these controls (hashing, truncation and encryption) and he claims this makes it even more compliant to PCI-DSS. At this point, someone is going to call you out, which is what we did reluctantly as we were all staring at each other quizzically. We had to emphasize we really can’t bring this to the auditor or justify this to our client who was also on the call, as this is an absolute misinterpretation of PCI-DSS, no matter what angle you spin. PCI never told us to implement as many of these options as possible. In fact, clearly stating if more than one of these are introduced, extra care must be taken in terms of controls that these cannot be correlated back to the PAN. We told him this was a clear misinterpretation to which his response was going into a long discourse of where we consultants were always ‘harping’ on impractical suggestions of security and where we always think it’s easy to crack hashes just because we know a little bit about ‘rainbow tables’. We call this “going technical”. As Herman Melville, the dude that wrote Moby Dick puts it:

“A man of true Science uses but few hard words and those only when none others will serve his purpose; whereas the smatterer in Science… thinks that by mouthing hard words he understands hard things”. – Dude that wrote Moby Dick.

Our job is really to uncomplicate things and not to make it sound MORE complicated, because there may always be someone in the room (or video conference) who knows a little more than what they let on.

DO avoid jargonizing the entire conversation as it is very awkward for everyone, especially for those who really know the subject. DO allow input from others and see from the point of view of the standard, whether you agree or disagree or not and keep in mind the goal is common: to make our client compliant.


C) DO find a solution together. As a vendor, we must remember, the team is with the client. The consultant is (usually) with the client. So its the same team. A good consultant will always want vendors to work together. We always try to work out an understanding if vendors cannot implement certain things, then let’s see what we can work on, and we can then talk to the the QSA and reason things out. Compensating controls etc. So the solution needs to be together, and finally, after all those awkward moments of mansplaining everything to us, we just went: “OK, let’s move on, these are the limitations, let’s see where the solution is.” And after around 5 minutes or so, we had a workaround sorted out. Done. No need to fuss. So next step is to get this workaround passed by the auditor for this round and if not, then we are back again to discuss, if yes, then done, everyone is moving out to other issues. Time is of essence, and the last thing we need is each of us trying to show the size of our brains to each other.

D) Don’t namedrop and look for shorter ways to resolve issues. One of the weirdest thing that was said in the conversation after all our solution discussion was when the vendor said that he knew who the QSA was and he dropped a few names and said, just tell the QSA it’s so and so, and we’ve worked together and he will understand. Firstly, it doesn’t work like that. Namedropping doesn’t allow you to pass PCI. Secondly, no matter how long you have worked with someone, remember, another guy in the room may know that someone longer than you. We’ve been working with the QSA since the day they were not even in the country and for a decade, so we know everyone there. If namedropping was going to pass PCI, we would be passing PCI to every Tom, Dick, Harry and Sally around the world. No, it doesn’t work that way, we need to resolve the issues.

So there you have it. This may sound like a rant, but the end of the conversation was actually somewhat amicable. Firstly, I was genuinely appreciative of the time he gave us. Some vendors don’t even get to the table to talk and the fact that he did, I really think its a good step forward and made our jobs easier. Secondly, we did find the workaround together and that he was willing to even agree to a workaround, that’s a hard battle won. Countless vendors have stood their ground and stubbornly refused to budge even when PCI non-compliance was screaming at their faces. Thirdly, I think, after all the “wayang“, I believe he actually truly believed in helping our client and really thought that his product was actually compliant in all aspects. Of course, his delivery was awkward, but the intention was never to make life difficult for everyone, but to be of assistance.

At the end, the experience was a positive one, given how many discussions with vendors go south. We knew more of their solution, we worked out a solution together and more importantly, we think this will pass PCI for our client. So everyone wins. In this case, the Korean Drama ended well!

For more information on PCI-DSS, drop us a line at pcidss@pkfmalaysia.com and we will get back to you immediately! Stay safe!

© 2024 PKF AvantEdge

— Up ↑