Too much trust in Common Criteria and FIPS 140-2?

Last week I attended PacSec in Tokyo, Japan. This is one of the three SecWest conferences every year, the largest being CanSecWest in Vancouver.
One of the interesting talks to me was Jussipekka Leiwo’s talk on “An analysis of authentication vulnerabilities in CC and FIPS 140-2 certified USB tokens”. In it he describes a loophole in the process of both certifications regarding USB tokens. In the example he provided, two well known USB keys that were found to be CC and FIPS 140-2 compliant were reviewed and found not to be compliant; but the issue was that they were not the same versions that were approved as well as that which was reviewed. There was also a lot of concern raised about the lack of relationship between the documenter and the developer of products going for CC and FIPS 140-2 compliance.
While these are of grave concern for anyone relying on this certification for the protection of information, it made me wonder about an even larger problem with version verification. What stops me from designing a knock-off product with the exact same version as your CC and FIPS 140-2 product? How do you verify you’re using the correct one?
Self verification is built into the higher level security standards, but not at this level. So it makes me wonder, what level of trust should we be placing on Common Criteria and FIPS 140-2 if those intimately involved in the process are highlighting such systematic process flaws?