EN 
DE Special features for embedded systems
Authors: Jaroslav Svacina, Nadja Menz, Thilo Ernst, Fraunhofer FOKUS
Contribution – Embedded Software Engineering Congress 2015
The digitalization of many areas of society is progressing at an enormous pace. Countless industries are increasingly relying on data digitalization, process automation, and the networking of individual components and systems. Alongside the corresponding advantages, however, this current development offers a wide range of new attack vectors which, if exploited correctly, can lead to enormous financial losses or personal injury. To increase confidence in security, software and hardware products can be certified according to ISO/IEC 15408 (Common Criteria). This article provides an overview of the certification of security products according to Common Criteria and specifically addresses some particular aspects in the context of embedded systems.
Introduction
The increasing digitalization and technological advancement of various sectors offers numerous advantages for end users. For example, it's now possible to control one's home with a smartphone, access internet services from a connected vehicle, or digitize medical treatment data and manage it securely within the healthcare telematics infrastructure. However, the use of new, complex, and interconnected technologies also presents additional potential for misuse due to new security vulnerabilities. The malicious exploitation of such vulnerabilities often leads to significant financial losses.
A high level of security and the corresponding trust in security products are therefore playing an increasingly important role in both the business and private sectors. The desire for trust in IT security products, in particular, presents customers with a significant challenge. Many customers are often unable to grasp what security functionality a product offers and to what extent it meets their desired security requirements. Furthermore, without an independent expert assessment, it is virtually impossible for customers to determine whether the stated mechanisms are implemented correctly. The Common Criteria (ISO/IEC 15408, Common Criteria for Information Technology Security Evaluation, or CC for short) [2] have established a standard for evaluating and testing the security functionalities of IT products according to tiered levels of trustworthiness.
The Common Criteria provide a means of specifying security requirements and a standardized methodology for evaluating and assessing implemented security functionalities. Under specific agreements, a Common Criteria IT security certificate is internationally recognized and allows for the comparison of the security characteristics of certified products. A CC certificate provides clear statements regarding the claimed security characteristics: correctness of the security functionality, effectiveness of the security functionality against attacks, analysis of potential vulnerabilities, and the corresponding depth of testing. Based on the security targets (ST) underlying the certificate, the purchaser of the certified product can understand the corresponding security functionality and decide to what extent this product is suitable from a security perspective for the intended purpose and operating environment.
Figure 1 (see PDFFigure 1 shows the history of the Common Criteria. The first criteria for the methodical evaluation of security in information technology were the Trusted Computer System Evaluation Criteria (TCSEC) of the US Department of Defense. During the same period, comparable criteria were developed in Great Britain, Germany, and France, which were then incorporated into the common European criteria in 1991, along with the TCSEC. With advancing globalization, the need arose for uniform and internationally recognized criteria, which were developed in the form of the Common Criteria. The CCs represent a further development and harmonization of the European ITSEC criteria, the US TCSEC/Federal Criteria, and the Canadian criteria (CTCPEC) [1].
CC certification landscape
The global goals of the Common Criteria member states are a common, standardized set of criteria for IT security products and an evaluation methodology that makes the results comparable. This comparability forms the basis for the mutual international recognition of the certificates.
Global cooperation takes place within the context of the Common Criteria Recognition Arrangement (CCRA) [4]. At this level, working groups promote the further development of the Common Criteria and the accompanying documents, as well as organizing and conducting the mutual review of the respective national certification schemes. Within the CCRA framework, some countries are authorized to issue certificates (e.g., Germany, France, USA), while others are only authorized to recognize certificates (e.g., Czech Republic, Israel). The CCRA includes certifications based on internationally agreed protection profiles (collaborative protection profiles, cPP) as well as certificates for trustworthiness components up to and including level EAL 2.
Furthermore, dedicated cooperation takes place at the European level based on the so-called SOGIS-MRA (Senior Official Group Information Systems Security – Mutual Recognition Agreement) [5]. In this context, the participating countries are also classified according to their role. On the one hand, there are countries that issue (and, of course, recognize) certificates, and on the other hand, countries that are only permitted to recognize certificates. This usually applies to certificates up to EAL level 4. In certain technical domains, certificates up to EAL 7 are mutually recognized within the SOGIS-MRA. Moreover, the SOGIS working groups are striving to promote the harmonization of the application of CC security criteria and the procedures in certification processes by means of so-called Joint Interpretation Library (JIL) documents. These interpretations are then usually incorporated into the CCRA and adopted by the relevant CCRA working group (CC Development Board) as so-called CC-supporting documents.
In each country, governmental or government-recognized institutions are responsible for Common Criteria certification. The corresponding processes and national characteristics are defined by the national certification schemes. In Germany, the Federal Office for Information Security (BSI) is responsible for the certification of products according to Common Criteria. The BSI oversees the evaluation process, ensuring comparability of the assessments and a high level of confidence in the results. The legal basis for conducting certification procedures is provided by the Certification Ordinance and the Federal Act on Strengthening the Security of Information Technology. Figure 2 (see PDF) shows the parties involved in the certification process in Germany, whereby the CertLab of Fraunhofer FOKUS is commissioned by the BSI if required.
The process begins when the product manufacturer submits a certification application to the BSI (Federal Office for Information Security). The BSI reviews the application for basic certifiability and, if successful, issues a certification ID. The evaluation (review of documentation, audit of relevant locations, independent correctness tests, and vulnerability analysis with penetration tests) is conducted by an independent testing body. This body must have been previously accredited by the BSI. The results of each aspect of the review are documented in test reports. The certification body (BSI) monitors the processes and ensures a standardized approach and the comparability of the test results. The certification body reserves the right to incorporate specific interpretations of the Common Criteria (CC) and additional security requirements, such as those concerning cryptographic algorithms and random number generators, into the certification. Finally, if the certification decision is positive, the test reports are approved, and the certificate is issued by the BSI.
After a manufacturer submits a certification application to the BSI (Federal Office for Information Security), the BSI, if necessary, commissions the CertLab at Fraunhofer FOKUS to oversee the audit process. A CertLab employee then handles a significant portion of the audit process on behalf of the BSI. However, the BSI retains full control of the process and, in particular, responsibility for the certification and the issued certificate at all times.
The Common Criteria do not address some aspects or leave room for interpretation. Therefore, national certification bodies and standardization bodies publish additional documents that clarify certain aspects or introduce entirely new concepts. At the CCRA and SOGIS levels, these are the CC Supporting Documents and JIL documents; at the national level, they are the Application Notes and Interpretations of the Scheme (AIS documents) [6].
Common Criteria at a glance
The Common Criteria aim to make the effectiveness and correctness of a product's security functionality verifiable in a comparable manner. Furthermore, CC certification makes the security mechanisms included and evaluated in the product transparent. There are several reasons for undergoing CC certification. In principle, any manufacturer can have their IT security products certified. A CC certificate increases customer trust and can therefore be used for marketing purposes. The evaluated security properties and functionalities (including the depth of testing) are documented in the product's security specifications after the evaluation. However, there are cases in which a customer or client requires a certain level of security functionality, and without a corresponding CC certificate, the product cannot be used for its intended purpose or successfully marketed. Examples include official documents (e.g., electronic passports) and components for the telematics infrastructure in healthcare. Here, the security functionality and the depth of testing are explicitly required (e.g., by the relevant federal authorities). In these situations, so-called Protection Profiles (PP) are used, which specify the requirements concretely and in a standardized manner. Therefore, if a manufacturer wants to place a product in such a market segment and have it certified, conformity of the safety specifications to the desired Protection Profile is required.
The Common Criteria V3.1R4 consist of four parts: Parts 1-3 (ISO/IEC 15408) [2] and CEM, the Common Methodology for Information Technology Security Evaluation (ISO/IEC 18045) [3]. Part 1 describes the philosophy and the CC concepts and defines the terminology. Furthermore, it specifies precisely how the security requirements and protection profiles are to be designed. It is not always necessary to evaluate an entire product. To delimit the security functionality to be evaluated, Part 1 of the CC introduces the concept of the "Target of Evaluation" (TOE). The evaluation therefore only encompasses precisely that security functionality which is within the context of the TOE and for which the appropriate security requirements have been established in the ST and/or PP. Only when the security requirements are coherent and consistent and the TOE is precisely defined can the actual evaluation begin.
Part 2 describes a catalog of Security Functional Requirements (SFRs) for the TOE. These requirements are to be used in the ST and PP. Certain parts of the requirements are unspecified and must be specified in detail no later than the ST. The requirements in Part 2 reflect generally recognized and accepted expert knowledge. Should the SFRs be insufficient in certain situations, they can be extended, or new SFRs can be defined according to a procedure specified in the CC. The SFRs are structured into classes and families with at least one component.
Part 3 describes a collection of Security Assurance Requirements (SARs). The SARs define requirements for the content of the verification documentation as well as the activities of manufacturers and evaluators necessary for the evaluation. Among other things, the SARs determine the scope and depth of the verification process. Therefore, these requirements must also be included in the ST/PP (Technical Specification/Provisioning Document). The structure is similar to that of the SFRs (Security Requirements). To simplify the handling of SARs and provide a clear metric for security assurance, security components are grouped into Evaluation Assurance Levels (EALs). With increasing evaluation levels, the verification effort and depth also increase.
Part 3 of the CC (Certification Certificate) describes, in the form of trustworthiness components, which content (documentation, tests, source code, etc.) is to be reviewed and what activities are generally expected of the developers and evaluators involved in the certification. The CEM (Certification Evaluation Management) refines the evaluators' activities and provides methodological guidance for their implementation. Only a standardized evaluation methodology enables the recognition of certificates under certain agreements. The AVA_VAN (Vulnerability Assessment) family serves as an example. Part 3 states that, within this family, a vulnerability analysis must be performed with varying scope and depth depending on the specific component. The CEM breaks down each component into individual, detailed work units (WUs) and provides methodological guidance.
For example, the attack potential for exploiting a potential vulnerability is classified (Basic, Enhanced-Basic, Moderate, and High). Furthermore, the CEM provides a mechanism for evaluating a potential vulnerability with regard to the attack potential required for its exploitation. Based on the analysis of potential vulnerabilities, the penetration tests performed, and the subsequent evaluation, it can be systematically determined which attackers with which attack potential the TOE can defend against. Due to the diversity of products, the CEM cannot provide information on specific attacks. However, within the framework of the SOGIS-MRA, specific attacks on particular product types are investigated in specific technical domains and published as supporting documents.
Special features of CC for embedded systems
Within the framework of the Common Compliance (CC), both software and hardware products are certified. Examples of purely software products include firewalls and desktop/server operating systems. A common hardware product type is the smartcard, which has high security requirements. This product type is used in a wide variety of applications. Due to the many domain-specific characteristics of the respective product types, so-called technical domains are defined within the SOGIS-MRA context. Currently, these are "Smartcards and Similar Devices" and "Hardware Devices with Security Boxes." Within these technical domains, specific interpretations of the CC, as well as other supporting documents, are issued for these areas, some of which must be considered during the corresponding CC certification process. The following section presents some of the specific characteristics of the "Smartcards and Similar Devices" technical domain.
Composite Evaluation
Security chips (the basis for smart card products) are typically used in conjunction with various operating systems and applications. If, as part of each certification process, the application, the operating system, and the hardware platform (security chip including firmware) were subjected to complete certification, the hardware platform would have to be re-evaluated every time. Therefore, a composite evaluation and certification approach is necessary. The CCs offer a composition mechanism in the form of the ACO trust class. This mechanism addresses a composite evaluation consisting of already certified components. However, this approach is not suitable for the smart card sector, as this technical domain requires the consideration of a non-certified application in combination with a certified platform. For this reason, the SOGIS partners have agreed on the "Composite Product Evaluation" approach [9]. Figure 3 (see PDF) compares the two approaches „ACO“ and „Composite Product Evaluation“.
The Composite Product Evaluation (TOE) approach enables the vertical integration of certified subsystems within the framework of overall system certification. The supporting documentation provides not only the general approach but also a concrete extension of the methodology. Many existing testing aspects have been expanded in this context (compatibility testing at the ST level, consideration of platform usage requirements, integration tests, etc.). To use a TOE as a platform for further certifications, an additional test report must be prepared as part of the platform certification: the Evaluation Technical Report for Composition. This document forms the basis for certifications building upon the already certified platform.
Calculation of the attack potential in the smartcard area
Smartcard products must typically withstand an attacker with high attack potential. The methodology described in the CEM for calculating the attack potential for successfully exploiting a potential vulnerability has proven inadequate in this technical domain. The JHAS group (JIL Hardware Attacks Subgroup) has therefore defined an approach adapted to this domain [8]. One of the main extensions is the separation of the attack phases. The "Identification" and "Exploitation" phases of an attack are considered and evaluated separately. The "Identification" phase refers to the effort required to discover an attack and demonstrate its feasibility. The "Exploitation" phase considers the effort required to actually execute the attack. Only by considering these phases together does a comprehensive view of the attack potential necessary for the attack be obtained. The calculation of the attack potential also incorporates the consideration of so-called "open samples" (product samples with restricted security mechanisms or known secrets).
Requirements for production and development sites
Regardless of the EAL level used for the certification of the smartcard product (usually EAL4 and higher), the following SAR components are typically also included (augmenting the EAL level): AVA_VAN.5 – resistance against attackers with high attack potential and ALC_DVS.2 – high security of development and production environments, suitable for certifications according to AVA_VAN.5.
For such certifications, the application of the document "Minimum Site Security Requirements" [7] is mandatory. This document describes the requirements for development and production sites. In addition to requirements for the documentation of evidence, it provides specific specifications regarding relevant aspects such as the organization of information and data security, asset management, personnel security, physical and environmental security, communication and operational processes, and access control management.
Reliability and sustainability of the certification
For users and customers, it is essential to know the extent to which they can actually trust assurances regarding a product's safety. The Common Criteria therefore aim to provide users with a level of evidence of product trustworthiness tailored to their specific safety requirements, depending on the EAL level. This evidence demonstrates the measures taken during the product's development and implementation to ensure its safety. This demonstrated trustworthiness is, of course, subject to various conditions. For example, users must always be able to verify that they are indeed holding the certified product (in the certified version). Manuals, datasheets, and other guidance documents are also evaluated within the framework of the Common Criteria. This ensures that users have access to all the necessary information to use the product correctly and, above all, without compromising safety (which they might otherwise inflict themselves).
The CCs also take into account the future development of certified products as well as the parallel evolution of threats and attack techniques. If security-relevant changes are made during product development, recertification becomes necessary. Similarly, a reassessment is conducted in the event of significant changes in the threat landscape. Manufacturers remain obligated to report any newly discovered attacks on certified products to the certification body. Furthermore, the validity period of a CC certificate is always limited.
For safety assessments, confidential manufacturer information is often required, which should not be made public. The confidentiality of such information is reliably ensured throughout the entire CC certification process: Only a small group of people at the certification authority and the testing laboratory have access to confidential product information. Particularly sensitive material is only briefly reviewed on-site at the manufacturer's premises.
The manufacturer also decides whether the certification report is published and what information it may contain. For safety requirements, there is the option of publishing a reduced form ("ST-light"). For certified platforms intended as the basis for subsequent composite evaluation, a reduced test report for use in the composition process can be prepared ("ETR for Composition"). This is a non-public document, but it is intended for distribution to those involved in the composition process.
Trends and current developments
Especially in the embedded systems sector, IT security is currently gaining in importance and will continue to do so in the near future. The emerging trend in various industries (automotive, eHealth, smart energy, and others) towards a shift in demand for trusted components can be effectively supported by Common Criteria certification. It is expected that this trend will become increasingly relevant for suppliers in the coming years. Therefore, it is all the more important to strengthen cooperation between the respective certification schemes and to continue pursuing a common international strategy. The evolution from national Protection Profiles to Collaborative Protection Profiles (cPPs) demonstrates the shared commitment of the nations within the CCRA to ensuring the continuous mutual recognition of certificates. The development of cPPs is driven by International Technical Communities (iTCs). The iTCs comprise all relevant stakeholders, such as product manufacturers, end users, certification bodies, and testing laboratories.
Summary
Certification according to Common Criteria ensures compliance with specific standards in the implementation of security functionalities and the use of cryptography in IT security products. While certification clearly requires a certain amount of effort, it establishes uniform security standards in the growing market for secure hardware and software products. The CC standards are an open framework that can be flexibly applied to a wide variety of use cases and cost/benefit scenarios and is continuously being developed. Participating countries, within the context of the CCRA and SOGIS agreements, are working both on specifying the CC for particular technical domains and on optimizing CC processes and evaluation activities. This ensures that current technological, organizational, and procedural developments are adequately reflected in the Common Criteria.
literature
[1] Eckert, Claudia: IT Security. Oldenburg, 2006
[2] Common Criteria for Information Technology Security Evaluation, Version 3.1, Rev. 4, September 2012.
Part 1: Introduction and general model / Part 2: Functional security components / Part 3: Assurance security components
[3] Common Methodology for Information Technology Security Evaluation, Version 3.1, Rev. 4, September 2012.
[4] About the Common Criteria (October 2015)
[5] SOGIS – Senior Officials Group Information Systems Security (October 2015)
[6] BSI: Application Notes and Interpretations (AIS) (October 2015)
[7] JIL: Minimum Site Security Requirements, Version 1.1 (for trial use), July 2013
[8] JIL: Application of Attack Potential to Smartcards, Version 2.9, January 2013
[9] JIL: Composite product evaluation for Smart Cards and similar devices, Version 1.4, August 2015
Our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here Regarding training courses/seminars/workshops and individual coaching sessions offered by MircoConsult on the topic Quality, Safety & Security.
Hhere You will also find training courses on software and contract law.
Training & coaching on the other topics in our portfolio can be found here. here.
Quality, Safety & Security – Expertise
Valuable expertise on the topics of quality, safety & security is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
