Software Modularisation and the Common Criteria
A Smartcard Developer’s Perspective
Dr. Karsten Klohs
Morpho, Riemekestraße 160, 33106 PADERBORN
Abstract. The Common Criteria (CC) establishes assurance into a specific product by considering a precisely defined product configuration as target of evaluation. In contrast, software development techniques strive for modulariza-tion to support the re-use or the exchangeability of components. We investigate the classical re-use approaches in the CC - like the re-evaluation approach, the composite evaluation of security ICs and embedded software and the CC assur-ance class ACO - and analyse what challenges remain from the perspective of a Smartcard OS development. One key observation is that the re-use of software components usually takes place on a lower-level software design. Interestingly, the newest version of JIL document on security architecture requirements for smartcards and similar devices establishes a first starting point for the modu-larization of the security description of an operating system which might sim-plify the re-use of software components in different products and their evalua-tions. The idea is to describe the security interface and the security mechanisms implemented by a component independently from a concrete security problem, so that this description can be re-used in several evaluations.
Keywords. Common Criteria, Smartcard, Modularisation
1
Introduction
One key concept of software development is the modularisation of software i.e. the decomposition of the whole software system into system elements, subsystems, and modules. The names for these structures can differ from one developer to another but the general approach is always the same. We stick to the terminology of the Common Criteria in the sense that subsystems and modules form the intermediate and final levels of decomposition. We also use the term component if the level of decomposi-tion is not relevant.
The primary aims of the software modularisation are the following:
• if a large complex problem is broken down into pieces then it is possible to solve each of the sub-problems in isolation and to distribute the development activities on different teams
• if the other modules are not aware about the concrete implementation of a solution in one of the modules then it is possible to exchange the implementation without impact on the remaining parts of the system
• once a sub-problem is solved within a single module it is possible to re-use the module in another problem context where the same sub-problem has to be solved. Thus, a good system design strives for the definition of modules which can be re-used or exchanged easily.
The definition of interfaces is vital for the modularisation of software. An interface describes which sub-problem a module has to solve so that the solution can be used by other modules to fulfil their tasks. It describes the properties of the intended solu-tion without defining the details of the implementasolu-tion. Thus, it defines what problem shall be solved but not how.
Within a system you can identify internal and external interfaces. Consider the fol-lowing abstract system that decomposes into two sub-systems A and B. Furthermore, the decomposition of the sub-system A is shown, while we abstract from the decom-position of sub-system B.
One observation is that the question what is an external and what is an internal in-terface depends on the level of decomposition that is analysed. The inin-terface between module 1 and module 2 is an external interface of module 2 but confined within the sub-system A. Similarly the interface between module 2 and the sub-system B is an external interface of the sub-system A but an internal interface of the whole system, while module 1 provides an interface to the external world.
A second observation is that each interface can be seen from two different perspec-tives: it is provided by one component and required by one or many other
compo-nents. There is a subtle difference between the question which module provides and requires an interface and the question which module depends on the other. The an-swer to the second question is given by the design decision where to define the inter-face. Consider the following figure.
Module 2 requires the service and module 1 provides the service defined by the in-terface. If the interface is defined in the context of module 1 then module 2 depends on module 1. This is the usual case, because it is quite natural to define a service in-dependently from the usage environment. In contrast, if the interface is defined in the context of module 2 then the dependency is inverted. This dependency inversion is a key technique to avoid upward dependencies in the software design. Consider the start-up phase of a security IC: After power-on the security IC firstly initialises the memory and all hardware elements before he transfers control to the embedded soft-ware. This is achieved by a well defined interface in this case the jump to a specific memory address but the implementation of this interface has to be provided by the embedded software. Obviously, the security IC is responsible for defining this inter-face because otherwise the IC becomes dependent on the embedded software. Such kinds of interfaces are also sometimes called call-backs or hooks.
How does these elementary principles of software modularisation relate to a Com-mon Criteria evaluation? First of all, the primary aim of the software development to structure the system in a way which simplifies the re-use and exchangeability of sin-gle elementary modules remains unchanged under an evaluation. As a consequence, the evaluation evidence for a single module shall be re-usable in another system con-text and the security assessment of the rest of the system should remain stable if one module implementation is replaced by another.
We have observed that the definition of interfaces is vital to support a proper modularisation of a system. Interestingly, the CC already defines a framework for the definition of “security properties of interfaces”: Security Functional Requirements (SFRs) can be used to express and model the security services which a system shall
provide. Secondly, objectives for the environment (OEs) can express the requirements that have to be fulfilled by collaborating components.
However, the attempt to apply SFRs and OEs to model the provided and required security interface of software modules in way that the security assessment can be re-used leads to the following fundamental challenges.
• The primary intent of the objectives for the environment is to model organisational and other high-level requirements and not software interfaces. A simple way to use them for at least establishing the link to software interfaces is to claim that “a de-pendent component shall adhere to the security guidance of the provided compo-nent”. However, this approach does not support the precise identification of the se-curity interfaces of the providing component.
• Security Functional Requirements define the security problem a system shall fulfil. The software developer’s aim is to re-use the same system for solving many secu-rity problems in a similar way. Thus, there is an upward dependency from the im-plemented system to the problem describing SFRs which results in a reassessment of similar implementation if it is used to solve different problems.
• Finally, the most critical challenge is that the SFR model does not support the de-composition into smaller bricks which is the primary aim of software interfaces. In particular, it is more convenient to model the security properties of a low-level module interface much closer to the software interface which is responsible for the implementation.
Therefore, this paper suggests defining a model for security properties of software components which exhibits the following properties.
• Describe the security properties of the components based on the implemented secu-rity functionality and not with respect to the secusecu-rity problem solved by a concrete product. This is a kind of dependency inversion which aims at resolving the up-ward link between the system implementation and the security problem definition at the highest-level of abstraction. This way, the internal representation of the secu-rity architecture can remain stable if the system is used to target another secusecu-rity problem.
• The model shall support the decomposition of large scale security features into smaller security mechanisms which in turn are defined close to the software inter-face definitions. The intent is to re-use the security definition of features and inter-faces of those components which remain stable and to allow for the exchange of security implementation without modification of the security architecture of the system provided that the security properties of the interface remain stable.
• The aim is to support the security assessment of a system within a security evalua-tion and not to use the concept for a compositional evaluation approach. The rea-son for this that re-use of modules takes place on the lowest level of decomposition while each compositional evaluation always exhibits some process overhead. A chip-card operating system can easily decompose into say 50 modules – but you want for sure not to run 50 evaluation processes in parallel. However, if 48 of the
50 modules remain stable you want to benefit from their security assessment even if the set of SFRs have completely changed, because the system targets a different security problem.
The paper investigates the following topics. Firstly, we review the existing re-evaluation and composite re-evaluation approaches in order to identify in which applica-tion scenarios they work fine. Re-evaluaapplica-tion is in particular useful for product main-tenance i.e. if a successor version solves the same security problem but with limited changes in the implementation. Composite evaluation is useful if it is possible to fac-tor out a large component which a standardised and stable interface. It is in particular useful if one vendor supplies the base component to many other vendors and to con-nect certificates in a bottom-up way. Secondly, we take a very brief look at the prob-lems addressed by the ACO class to get a first impression about the issues arising in a composition. Finally, a review of the JIL document “Security Architecture for Smart-cards and Similar Devices” will show that the notion of Security Features, Security Mechanisms, Security Services, and Security Properties can serve as a first starting point for the security description model described above.
2
Maintenance and Re-Evaluation: The Delta-Analysis
Approach
The certificate maintenance or re-evaluation approach works fine if the new prod-uct contains comparatively few changes and if it addresses the same security problem. The following figure shows an abstracted software iteration where only the module 2 has been updated. The tracing of the security functional requirement which defines the security problem is depicted by red boxes.
In this case module 1 and module 3 do not have to be reconsidered and the re-evaluation can focus on verifying that the changed module 2 contributes to the
im-plementation of the SFR in the same way than the original one. The situation can become less convenient if the new product targets a different security problem as depicted on the left-hand side of the following figure.
The original security assessment of the module 1 had been conducted from the per-spective of the “red” security functional requirement. It yielded the result that the collaboration of module 1 and module 2 correctly implemented this security require-ment. However, the security properties defined by the interface between theses mod-ules as well as the security properties of the interface to module three are not explic-itly expressed. Therefore, it is more difficult to re-use parts of the security assessment of the previous evaluation for tracing the “blue” security functional requirement.
Therefore, the idea is to use an explicit security description of the implementation of the whole system to support the tracing of arbitrary SFRs as depicted by the yellow triangles on the right-hand side of the figure. The differing SFRs still have to be traced which makes the second situation in general more complex than a simple main-tenance of the same product. However, the evaluator may identify the impact of soft-ware changes on the security implementation of the system more quickly if all the security properties of the system have been explicitly defined and reviewed.
3
Composite Evaluation of a Security IC with Dedicated and
Embedded Software
The composite evaluation of a security IC with dedicated software like a crypto li-brary and with some embedded software like a secure chip card operating system is the prime example how the common criteria methodology can be applied to the com-position of high-level components. The general intent is to gain a formal CC certifi-cate for each of the components which is then re-used for the evaluation of the de-pendent components as depicted in the following figure.
The important properties of this approach are the following:
• The approach is inherently bottom-up, i.e. the different evaluation approaches sub-sequently extend the scope of the evaluation.
• The “provided security interface” of each component is formulated in terms of SFRs, so that the composition approach fits to the evaluation methodology. Fur-thermore, the interfaces of a security IC and of a crypto library are comparatively stable and well standardized.
• The treatment of the “required security interfaces” is more subtle: usually they are formulated in terms of general objectives for the environment (OEs) like “the em-bedded software follows the security guidance of the IC”.
We will now elaborate a little bit more on these properties in order to determine how this approach relates to software modularisation techniques.
3.1 Analysis of the Bottom-Up Certification
The bottom-up approach has the advantage that it is possible to build security func-tionality in the upper layers directly upon the security services provided by the lower layer. This approach is very convenient for the developers of the base components
because they can make their base component available in a certified configuration to a wide range of dependent components.
Interestingly, this approach is not widely extended to embedded software though it would be an interesting option. We want to identify the reasons for that in the follow-ing and start with a very simple scenario. Assume that one specific product imple-mented by a piece of embedded software shall be made available on two different security ICs.
In this case the porting to the new platform is usually covered by a second embed-ded software evaluation. The embedembed-ded software developer uses sound design princi-ples and factors out a hardware abstraction layer (HAL) in order to provide a common interface to the rest of the embedded software as depicted in the following figure.
As a consequence, it is possible to perform the second evaluation as a (delta) re-evaluation to re-use at least the evidence about the stable parts of the embedded soft-ware.
Interestingly, the approach to extend the bottom-up approach to the HAL-layer(s) and to execute the two product evaluations as composite evaluations is not taken by embedded software developers. This is the case, even though such an approach can have additional benefits to the embedded software developer if she hosts two different products on the same HAL-implementation as depicted in the next figure.
So what are the differences with respect to the successful IC-ES composite ap-proach?
Firstly, the separate consideration of the HAL layer from the rest of the embedded software does not reduce but increase the number of certification processes to be maintained by the software developer. The additional formal overhead of factoring out a “HAL evaluation” is significant. An additional security target has to formalise the security properties of the HAL component, and additional composite activities have to be conducted to connect the evaluation processes to each other.
However, there are also other more technical issues of the approach. Firstly, the se-curity interface of the HAL component has to be described in terms of sese-curity func-tional requirements and objectives for the environment which is in this case the em-bedded software. Of course, this has also been done for the underlying crypto library and the security IC but obviously works best if the structure of interface fits well to the SFRs defined in part 2 of the Common Criteria /CC_P2/. This is the case for the abstraction of crypto primitives but for additional HAL functionality like the abstrac-tion of the underlying IO facilities or the basic memory management formulaabstrac-tion efforts are required.
There are also some technical challenges in the design of the HAL. An inherent property of smartcard embedded software development is that the software structures have to be as small and as efficient as possible due to the limited resources of the chip. Therefore, the embedded software developer strives to design the HAL layer in a way that it can be “tailored to the mission”.
There are two different sub-aspects that induce challenges for the evaluation. Firstly, an optimal solution for integrating the HAL into a second product ES_B may be achieved by a slight modification of the separation of responsibilities between the HAL and the remaining ES – i.e. a modification of parts of the interface. This restricts the re-usability of the HAL a little bit but this can be acceptable in comparison to the gain in performance or memory consumption. However, even minor changes in the HAL component would trigger maintenance or re-evaluation if the HAL is evaluated stand-alone which in turn increases the process overhead. Of course, tailoring the interface is feasible only if the two collaborating components are supplied by the same vendor – in the IC-ES composition scenario the embedded software developer has to take the security IC and its libraries as is. Thus, we conclude that advantages of re-use significantly depend on the stability of interfaces.
The second sub-aspect is not related to optimisation but to differing requirements. If some hardware dependent functionality is required for the embedded product A but not for the embedded product B then a good design of the supportive HAL would supply configuration options that add, remove, or adopt functionality. This in turn increases the probability of changes in implementation of the HAL which lead to a more complex reassessment if the modified is used in a second product.
3.2 Conclusions for Modular Software
The discussion in the previous section showed that a bottom-up composite certifi-cation approach works comparatively fine, if
• the interfaces between the two component are stable which is for example likely if standard functionality is implemented or if the components are supplied by differ-ent vendors
• it is easy to describe the security properties of the interface in terms of SFRs which is the case for cryptographic functionality but becomes more complex for arbitrary software interfaces.
On the other hand, an embedded software developer strives for a balance between the reusability of components and an optimal integration of sub-components into the system. This in turn leads to minor but continuous evolution of interfaces and to a design which supports configurability.
As a consequence, the more natural way for a software developer to re-use parts of her security implementation is the following:
• focus the re-use activities on the support of the delta analysis instead of maintain-ing several full-fledged certification tracks
• describe the security properties of the interface between different components on a level of granularity which is as close as possible to the software interface. The in-tention here is to re-use the assessment of the stable software elements so that the re-assessment can focus on the changing parts.
• additionally, the direct link of the security property description to the software modules simplifies the handling of various configurations. The software developer
can formulate the security properties of the superset of all module variants and then re-use this description for a specific configuration of a newly evaluated product. We will not dig into the details of the difficulties to certify a highly configurable product in the following even though this is also a very interesting topic.
A very evident idea to achieve this goal is to formulate the security aspects of the implementation with the same techniques that are used to structure the software. The software developer decomposes the software into modules and defines interfaces between those modules in a way which support the re-use of modules in different contexts and the simple exchangeability of an implementation without the modifica-tion of interface. Thus, if the security implementamodifica-tion is also described in terms of security interfaces and the security properties of modules then this description should at least simplify the security assessment of the unchanged parts of the system. The following chapters elaborate more on this general idea.
4
Assurance Class ACO
Even though the CC supporting document on the “Composite Evaluation for Smartcards and Similar Devices” /CCDB_COMP/ correctly points out that this assur-ance class is not sufficient to conduct composite evaluations at a “high” assurassur-ance level it is still worthwhile to take a brief look onto the issues addressed by the ACO class in /CC_P3/ because it provides first insights in the challenges which arise if two components are combined with each other. Consider the following figure taken from /CC_P3/ p.175 which shows the different kinds of dependencies between a dependent component A and a base-component B.
Firstly, the class ACO_REL points out, that the implementation of security func-tionality in the dependent component may rely on the services supplied by the base component. In order to support the assessment if the base component fits the need of the dependent component, the service requirements of the dependent component shall be explicitly stated. This is the similar to describing the required interfaces of a com-ponent and should be taken into account when describing the security interfaces of a component.
Secondly, the figure shows that the services that the dependent component depends upon may not necessarily be in the scope of the TSFI of the base component. This can happen if the security problem targeted by the base component has not taken into account the specific usage scenario of the dependent component. To deal with this situation the ACO_DEV class requires additional implementation evidence about the non-TSF interfaces of the base component. Obviously, these can be taken from the ADV_TDS evidence of the base component. This is a hint, that a combined descrip-tion of the security properties and the funcdescrip-tional properties is worthwhile to increase the potential to re-use the description in other contexts.
Additionally, the ACO class also mandates additional testing and vulnerability as-sessment of the composed TOE. This is not surprising from the software development point of view because it appears to be an incarnation of the usual problem that even after intensive component testing additional integration tests are necessary to ensure that the composition did not yield to subtle problems in the combined system state.
All in all the ACO class already addresses some of the issues which have to be taken into account if an already assessed component shall be coupled with another component with only limited knowledge about the base component. As such, it can act as a useful input for understanding the analysis needs when some software module shall either be re-used or exchanged in some evaluation. The idea is to take most of the issues addressed in different composition models into account when establishing the description of security implementation of a system. This is not mandatory because the evaluator has access to all necessary information if the composed TOE is consid-ered as a whole. However, strategies like explicitly formulating the required interfaces and provide input for security assessments at the level of all modules can help to sim-plify the delta-analysis and the re-consideration of security functionality in other con-texts.
5
JIL Document on Security Architecture Requirements
The primary target of the JIL document on Security Architecture Requirements for Smartcards and Similar Devices is to provide guidance for identifying the central security properties a smart card device has to enforce. Due to that fact that a smart-card is build to operate in a hostile environment where an attacker has physical access to the TOE these properties are:
─ self-protection even under massive perturbation of the execution code and manipu-lation of stored data
─ non-bypassablity in particular the obfuscation of so called side-channels like the power consumption or electromagnetic emanation which can leak information about secret data.
─ Secure-startup i.e. the secure initialisation of the security functionality from a down-state which may be induced either by sudden power-cut of or the transition to power-safe modes.
The increasing market demand for open, expandable platforms as defined e.g. by Global Platform and Java, adds the security property of a strong domain separation mechanism, which provides a secure execution environment to different applications sharing the system resources.
These security properties are specific because the do not exhibit observable inter-faces. They are confined within the system and react usually in case of an external attack and not in normal operation mode. Therefore, they cannot be traced easily via the functional product interface like normal SFRs and as such shall be described by the developer evidence of the ADV_ARC part.
The informative annex of the security architecture document /EXS_JIL_SARC2/ suggests a terminology of security features, security mechanisms, security services, and security properties to describe the security architecture of the system as shown in the following overview. Interestingly this terminology covers several of the funda-mental needs for the description of the modularisation of security implementations.
A security function is a description what TOE does in order to meet one or more SFRs. This notion is strongly related to the observation of this paper that it is more natural for the developer to describe the implemented security functionality independ-ently from the security problem. A problem independent description supports the re-use of already existing components in other problem contexts which is one of the key goals of a modular design also.
A security feature denotes a combination of security functions and security proper-ties implemented to advert an attack. The term primarily originates in the observation that a combination of functionality and inherent properties of software has to be con-sidered to understand how a security feature is designed. However, it also indicates that there is a need of different levels of description. This is similar to the decomposi-tion approach of software modularisadecomposi-tion where the developer also decomposes a high-level functionality into its elementary parts.
The elementary parts of the security architecture description are security mecha-nisms and architectural countermeasures. A security mechanism is a concrete imple-mentation of security functionality or an enforcement of architectural soundness. Pro-vided that the developer encapsulates such elementary building blocks in modules, the notion of security mechanisms can prove to be a valuable starting point for modelling the security implementation of a system. The description of the security implementa-tion should describe for each module the implemented security mechanisms which can then in turn be combined to higher-level security features depending on the con-crete product under consideration.
Architectural countermeasures cover design principles and implementation tech-niques that support and collaborate with security mechanisms. One example of such a
measure is a strict layering of the operating system architecture e.g. by abstracting the hardware interface in a hardware abstraction layer. The fact that the rest of the operat-ing system interacts via this interface with the hardware only and that the HAL can internally enforce hardware specific security requirements minimises the risk that some operating system mechanism can unintentionally interfere with the security critical hardware management. A second example of an architectural countermeasure is the structured use of execution flow protection mechanisms throughout the whole software. The difference to security mechanisms is that the architectural measures cannot be directly assigned to a single implementing module.
To summarise the modelling approach suggested by the JIL security architecture document appears to be capable to support the modular description of the security implementation of a system in a generic way.
The other notions of security service and security properties can be interpreted from the perspective of exposed interfaces on different layers of decomposition. The term security service emphasises that the service offers some security implementation to an entity in the external world. Such an entity can be a user but also some other sub-system of the TOE e.g. the interface of a dedicated crypto library or a hardware abstraction layer. In any case, a security service is visible at an exposed interface.
A security property is some invariant enforced by a component on which a user of the module can rely upon. Such invariants are confined within a component and not visible at the component’s external interface. Depending on the level of decomposi-tion which is considered, the nodecomposi-tion of security services and security properties can vary. For example, a module in the crypto-library can offer random number genera-tion to the rest of the system as a security service. Other components of the system may use this service for execution randomisation which in turn helps to enforce the non-bypassability property of the system by obfuscating side-channels. On this higher-level of abstraction the underlying security service is no longer directly offered via an exposed interface but contributes to security implementation confined within the system.
These observations give rise to the following developer’s approach to the descrip-tion of the security implementadescrip-tion and design of a system:
• Design the security architecture in terms of generic security features which can be used to fulfil a wide range of security functional requirements of security prob-lems.
• Decompose these security features into security mechanisms which form the ele-mentary building blocks of the security implementation. The security mechanisms should be formulated on a level of detail which supports the stand-alone implemen-tation within a single module. This way, the security mechanisms shall become re-usable and exchangeable.
• Describe how different security mechanisms and other design concepts collaborate to advert attacks i.e. what high-level functionality they shall support. This descrip-tion is driven by the security mechanisms so what is implemented in the software and can as such be re-used at least partially if two software derivates target differ-ent security problems.
This approach is security mechanism centric and as such similarly useful for de-scribing the implementation of security services offered to the user and to describe the implementation of security invariants and properties inherently enforced by the sys-tem. Even though the intent of the security architecture document is to focus on the inherent security properties of the system, it is more natural from the developer’s perspective to describe the collaboration of all security mechanisms in the same way.
First results form discussions with Morpho development teams are quite promis-ing. The focus on the security implementation of the system and in particular the close link to the modular structure of the system components simplifies the discussions between security architects and the developers. The question in how far the approach supports and simplifies the re-use of security implementation evidence on more com-plex scenarios than simple product maintenance is currently under investigation. In any case, an evolution of the modelling concepts is likely to become extremely impor-tant in the future once the dramatically decreasing product availability times which are one of the primary advantages of flash technology will be exploited on the high-security smartcard market.
6
Conclusion and Acknowledgements
This paper reviewed the software modularisation techniques and Common Criteria techniques to deal with software maintenance and software composition. The devel-oper would like to focus the description of security functionality on the implemented mechanisms enforced by the elementary modules in order to support the re-use of modules in another product or to simplify the exchange or improvement of implemen-tation with minimal impact on the security architecture of the system.
The maintenance and compositional evaluation techniques currently applied to se-curity evaluation in the field of Smartcards and similar devices work especially fine if a product is modified only by adjusting some of its modules or if a larger sub-component can be factored out which provides a stable interface to the rest of the system.
However, the flexibility of the upcoming flash technology is likely to raise the need for more fine-grained re-use and an intense tailoring of modular software. There-fore, the continuous evolution of the description model for the modularisation of secu-rity implementation can become a key challenge for a Smartcard developer in the future.
I’d like to thank the colleagues of the ISCI Working Group I on Methodology and Best Practices for Smart Security Device Evaluation for all the informative discus-sions about security architecture and the members of the Secure e-Documents R&D of Morpho for their valuable feed-back from the developer’s perspective.
Bibliography
/CC_P2/Title: Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components Identification: CCMB-2009-07-002
Version: Version 3.1 Revision 3
Date: July 2009
/CC_P3/
Title: Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components Identification: CCMB-2009-07-003
Version: Version 3.1 Revision 3
Date: July 2009
/CCDB_COMP/
Title: Composite Product Evaluation for Smart Cards and Simi-lar Devices
Identification: CCDB-2007-09-001 Version: Version 1.0 Revision 1
Date: September 2007
/EXS_JIL_SARC1/
Title: Security Architecture Requirements for Smartcards and Similar Devices
Version: Version 2.0
Date: January 2012
/EXS_JIL_SARC2/
Title: Security Architecture Requirements for Smartcards and Similar Devices – Annex 1
Version: Version 2.0
