Editing Common Criteria (section)

===Criticisms===
In August 2007, [[Government Computing News|''Government Computing News'' (GCN)]] columnist William Jackson critically examined Common Criteria methodology and its US implementation by the Common Criteria Evaluation and Validation Scheme (CCEVS).<ref>[http://gcn.com/articles/2007/08/10/under-attack.aspx Under Attack: Common Criteria has loads of critics, but is it getting a bum rap] {{webarchive|url=https://web.archive.org/web/20210423134739/http://gcn.com/articles/2007/08/10/under-attack.aspx |date=2021-04-23}} Government Computer News, retrieved 2007-12-14</ref> In the column executives from the security industry, researchers, and representatives from the National Information Assurance Partnership (NIAP) were interviewed. Objections outlined in the article include:

* Evaluation is a costly process (often measured in hundreds of thousands of US dollars) – and the vendor's return on that investment is not necessarily a more secure product.
* Evaluation focuses primarily on assessing the evaluation documentation, not on the actual security, technical correctness or merits of the product itself. For U.S. evaluations, only at EAL5 and higher do experts from the National Security Agency participate in the analysis; and only at EAL7 is full source code analysis required.
* The effort and time necessary to prepare evaluation evidence and other evaluation-related documentation is so cumbersome that by the time the work is completed, the product in evaluation is generally obsolete.
* Industry input, including that from organizations such as the [[Common Criteria Vendor's Forum]], generally has little impact on the process as a whole.

In a 2006 research paper, computer specialist David A. Wheeler suggested that the Common Criteria process discriminates against [[free and open-source software]] (FOSS)-centric organizations and development models.<ref>{{cite web |url=https://dwheeler.com/essays/oss_software_assurance.pdf |title=Free-Libre / Open Source Software (FLOSS) and Software Assurance / Software Security |first=David |last=Wheeler |date=2006-12-11 |access-date=2023-12-30}}</ref> Common Criteria assurance requirements tend to be inspired by the traditional [[Waterfall model|waterfall]] software development methodology. In contrast, much FOSS software is produced using modern [[Agile software development|agile]] paradigms. Although some have argued that both paradigms do not align well,<ref>{{cite book |last1=Wäyrynen |first1=J. |last2=Bodén |first2=M. |last3=Boström |first3=G. |title=Extreme Programming and Agile Methods - XP/Agile Universe 2004 |chapter=Security Engineering and eXtreme Programming: An Impossible Marriage? |series=Lecture Notes in Computer Science |date=2004 |volume=3134 |pages=117–128 |doi=10.1007/978-3-540-27777-4_12|isbn=978-3-540-22839-4 }}</ref> others have attempted to reconcile both paradigms.<ref>{{cite web |last1=Beznosov |first1=Konstantin |last2=Kruchten |first2=Philippe |url=http://lersse-dl.ece.ubc.ca/record/87 |title=Towards Agile Security Assurance |date=2005-10-16 |access-date=2023-12-30}}</ref> Political scientist [[Jan Kallberg]] raised concerns over the lack of control over the actual production of the products once they are certified, the absence of a permanently staffed organizational body that monitors compliance, and the idea that the trust in the Common Criteria IT-security certifications will be maintained across geopolitical boundaries.<ref>{{cite web |url=https://personal.utdallas.edu/~bxt043000/Publications/Technical-Reports/UTDCS-13-12.pdf |title=Common Criteria meets Realpolitik - Trust, Alliances, and Potential Betrayal |access-date=2023-12-30 |last=Kallberg |first=Jan |date=2012-08-01}}</ref>

In 2017, the [[ROCA vulnerability]] was found in a list of Common Criteria certified smart card products. The vulnerability highlighted several shortcomings of Common Criteria certification scheme:<ref name=parsovs_phd>{{cite thesis |type=PhD |first=Arnis |last=Parsovs |date=2021-03-03 |title=Estonian Electronic Identity Card and its Security Challenges |publisher=University of Tartu |url=https://dspace.ut.ee/items/559b9004-2aca-414d-8788-f0b8cedffb2d |language=et |pages=141–143 |access-date=2023-12-30}}</ref>
* The vulnerability resided in a homegrown RSA key generation algorithm that has not been published and analyzed by the cryptanalysis community. However, the [[Common Criteria Testing Laboratory|testing laboratory]] TÜV Informationstechnik GmbH (TÜViT) in Germany approved its use and the certification body [[Federal Office for Information Security|BSI]] in Germany issued Common Criteria certificates for the vulnerable products. The Security Target of the evaluated product claimed that RSA keys are generated according to the standard algorithm. In response to this vulnerability, [[Federal Office for Information Security|BSI]] now plans to improve transparency by requiring that the certification report at least specifies if the implemented proprietary cryptography is not exactly conformant to a recommended standard. [[Federal Office for Information Security|BSI]] does not plan on requiring the proprietary algorithm to be published in any way.
* Even though the certification bodies are now aware that the security claims specified in the Common Criteria certificates do not hold anymore, neither [[Agence nationale de la sécurité des systèmes d'information|ANSSI]] nor [[Federal Office for Information Security|BSI]] have revoked the corresponding certificates. According to [[Federal Office for Information Security|BSI]], a certificate can only be withdrawn when it was issued under misconception, e.g., when it turns out that wrong evidence was submitted. After a certificate is issued, it must be presumed that the validity of the certificate decreases over time by improved and new attacks being discovered. Certification bodies can issue maintenance reports and even perform a re-certification of the product. These activities, however, have to be initiated and sponsored by the vendor.
* While several Common Criteria certified products have been affected by the ROCA flaw, vendors' responses in the context of certification have been different. For some products a maintenance report was issued, which states that only RSA keys with a length of 3072 and 3584 bits have a security level of at least 100 bits, while for some products the maintenance report does not mention that the change to the TOE affects certified cryptographic security functionality, but concludes that the change is at the level of guidance documentation and has no effect on assurance.
* According to [[Federal Office for Information Security|BSI]], the users of the certified end products should have been informed of the [[ROCA vulnerability]] by the vendors. This information, however, did not reach in a timely manner the Estonian authorities who had deployed the vulnerable product on more than 750,000 [[Estonian identity card]]s.