Mind the Gap: Formal Verification and the Common Criteria (Discussion Paper)

Abstract

It is a common belief that the rise of standardized software certification schemes like the Common Criteria (CC) would give a boost to formal verification, and that software certification may be a killer application for program verification. However, while formal models are indeed used throughout high-assurance certification, verification of the actual implementation is not required by the CC and largely neglected in certification practicedespite the great advances in program verification over the last decade.In this paper we discuss the gap between program verification and CC software certification, and we point out possible uses of code-level program verification in the CC certification process.

TPMScan: A wide-scale study of security-relevant properties of TPM 2.0 chips

“…The challenges that the CC certification faced were expressed already around 2004 by Hearn [Hea04] and eight years later by Murdoch et al [MBA12], who discuss why both CC and FIPS 140 fell short of their promise, pointing to the lack of transparency. Beckert et al [BGG10] highlight that formal verification of only the specification, but not the implementation, is required to achieve higher EALs. Many of the schemes' problems are also mentioned in a user study [HTAP18] of 29 users trained in the NIST cryptographic validation program.…”

Automatized high-level evaluation of security properties for RTL hardware designs

“…In [5] the gap in the software domain between source code verification and CC certification is discussed. However, there is also a long existing gap between analysis of hardware RTL descriptions and checking of high-level rules and specifications.…”

“…The translation consists of five steps: VHDL structure parsing (1 ), translation of VHDL processes into Control Flow Graphs (CFGs) (2 ), FSM identification inside the CFGs (3 ), FSM extraction (4 ), and conversion of these FSMs into the NuSMV input language (5 ). Finally, the NuSMV model representation can be used to check high-level assumptions about the expected behaviour of the system.…”

A Digital Security Certificate Framework for Services

“…It can be observed that several certification schemes are specific to a particular domain such as Mobile Security, Network Security and so on, while a few schemes such as Common Criteria (CC), Commercial Product Assurance (CPA), and First Level Security Certification (CSPN) are applicable across the different domains. Among these broadly applicable schemes, the CC is a widely recognized (Common Criteria, 2012a), used (Common Criteria, 2012b), multi-domain (Turner, 2009), partially descriptive certification scheme (Beckert, Bruns, & Grebing, 2010). Schemes such as CPA, CSPN have different criteria towards the certification but they result in certificates that are represented similar to the CC Scheme.…”

“…The CC scheme is primarily "claims" based as it allows product vendors to describe the security functional requirements (SFRs) that are met by the product and to prove that the set of SFRs are able to counter the threats identified for a Target of Evaluation. This information is captured in a document called "Security Target" (Common Criteria, 2012b) (CC-ST) which is often seen as the descriptive part of the CC certification (Beckert et al, 2010). The product vendor then specifies the set of Security Assurance Requirements (SARs) in order to provide a certain Evaluation Assurance Level.…”