Chain of trust for installation & update files

PA DSS requires vendors to ensure that the chain of trust is maintained for all installation and update files. These are primarily laid out in 7.2.a – 7.2.e of the PA-DSS 2 requirements. What this means is that customers should be able to verify that the files that they install/update are actually from you (authentication) and that they have not been modified (integrity).

This is something that trips up a lot of payment application vendors. Most payment application vendors post the software installation files on a website and have customers download them. This method is used by other software vendors too. A few times, vendors will also upload an HMAC (check-sum) of the file so that customers can verify that the files have not been modified.

Let’s say a hacker is able to break into the vendors download site, replace the original application installation/update files and also replace the HMAC to reflect the new file(s). When a customer downloads the files(s) and verifies the HMAC, it will check out, even though it is not the correct file. This is exactly what happened to WordPress in 2007 when a hacker replaced the installation package with one that had backdoor code in one of the files in the package.

So, how do we authenticate the files (to ensure that they come from the vendor) and also verify that the integrity (to ensure that the files have not been modified by anyone else)? The easiest way would be digitally sign the files. Digital signatures serve will server both our purposes. The signature reliably authenticates that the files come from the vendor. They also contain a hash value that will not be valid if the files have been modified.

When customers downloads a signed installation/update package, they can check the digital signature and be sure that they are valid files. Requirement 7.2.e (PA DSS v2) requires QSAs to replace the update files with arbitrary files and then verify that the update was not installed. This will require an automated way for the application to check that the patch was valid before being applied. One of the ways this can be accomplished is by checking the digital signature and verifying that it is valid before applying the update or patch.

Sometimes, vendors will say that their customers do not download the software themselves, but that the vendors’ personnel login remotely (that is a separate discussion in itself) and install the software and updates. In this case, the Implementation Guide must list the steps for verifying the integrity of the software on the target system. This can be a manual verification of a digital signature or a hash.

Please note that previously, I was informed by the QA personnel at the PCI SSC that the digital signature must be verified automatically by the application before the patch/update is installed. But I have now been told by James Barrow, Director of QA Programs, PCI SSC, that a manual verification by personnel is acceptable.