Software Modularisation and the Common Criteria

Transcription

1 Software Modularisation and the Common Criteria A Smartcard Developer s Perspective Dr. Karsten Klohs Morpho, Riemekestraße 160, PADERBORN karsten.klohs@morpho.com 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 modularization 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 assurance 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 modularization of the security description of an operating system which might simplify the re-use of software components in different products and their evaluations. 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 decomposition 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

2 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 reused 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 solution without defining the details of the implementation. Thus, it defines what problem shall be solved but not how. Within a system you can identify internal and external interfaces. Consider the following 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 decomposition of sub-system B. One observation is that the question what is an external and what is an internal interface depends on the level of decomposition that is analysed. The interface 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 perspectives: it is provided by one component and required by one or many other compo-

3 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 answer to the second question is given by the design decision where to define the interface. Consider the following figure. Module 2 requires the service and module 1 provides the service defined by the interface. 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 independently 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 software. 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 interface 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 Common 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 single elementary modules remains unchanged under an evaluation. As a consequence, the evaluation evidence for a single module shall be re-usable in another system context 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

4 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 reused 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 dependent component shall adhere to the security guidance of the provided component. However, this approach does not support the precise identification of the security 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 security problems in a similar way. Thus, there is an upward dependency from the implemented 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 decomposition 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 security functionality and not with respect to the security problem solved by a concrete product. This is a kind of dependency inversion which aims at resolving the upward link between the system implementation and the security problem definition at the highest-level of abstraction. This way, the internal representation of the security architecture can remain stable if the system is used to target another security 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 interface definitions. The intent is to re-use the security definition of features and interfaces 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 evaluation and not to use the concept for a compositional evaluation approach. The reason 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

5 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 reevaluation and composite evaluation approaches in order to identify in which application scenarios they work fine. Re-evaluation is in particular useful for product maintenance 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 factor 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 connect certificates in a bottom-up way. Secondly, we take a very brief look at the problems 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 Smartcards 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 product 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 reevaluation can focus on verifying that the changed module 2 contributes to the im-

6 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 perspective of the red security functional requirement. It yielded the result that the collaboration of module 1 and module 2 correctly implemented this security requirement. However, the security properties defined by the interface between theses modules as well as the security properties of the interface to module three are not explicitly 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 maintenance of the same product. However, the evaluator may identify the impact of software 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 library 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 composition of high-level components. The general intent is to gain a formal CC certificate for each of the components which is then re-used for the evaluation of the dependent components as depicted in the following figure.

7 The important properties of this approach are the following: The approach is inherently bottom-up, i.e. the different evaluation approaches subsequently 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. Furthermore, 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 embedded 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 functionality 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

8 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 following and start with a very simple scenario. Assume that one specific product implemented 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 embedded software evaluation. The embedded software developer uses sound design principles 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) reevaluation to re-use at least the evidence about the stable parts of the embedded software. 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.

9 So what are the differences with respect to the successful IC-ES composite approach? 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 security interface of the HAL component has to be described in terms of security functional requirements and objectives for the environment which is in this case the embedded 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 abstraction of the underlying IO facilities or the basic memory management formulation 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.

10 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 certification 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 different 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 maintaining 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 intention 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

11 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 modification of interface. Thus, if the security implementation 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 assurance class is not sufficient to conduct composite evaluations at a high assurance 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.

12 Firstly, the class ACO_REL points out, that the implementation of security functionality 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 component 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 description of the security properties and the functional 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 assessment 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 considered 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 simplify the delta-analysis and the re-consideration of security functionality in other contexts. 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 smartcard 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 manipulation of stored data

13 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 interfaces. 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 fundamental 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 independently from the security problem. A problem independent description supports the reuse 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 properties 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 considered 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 decomposition approach of software modularisation where the developer also decomposes a high-level functionality into its elementary parts. The elementary parts of the security architecture description are security mechanisms and architectural countermeasures. A security mechanism is a concrete implementation of security functionality or an enforcement of architectural soundness. Provided 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 implementation should describe for each module the implemented security mechanisms which can then in turn be combined to higher-level security features depending on the concrete product under consideration. Architectural countermeasures cover design principles and implementation techniques that support and collaborate with security mechanisms. One example of such a

14 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 operating 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 decomposition which is considered, the notion of security services and security properties can vary. For example, a module in the crypto-library can offer random number generation 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 description of the security implementation 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 problems. Decompose these security features into security mechanisms which form the elementary building blocks of the security implementation. The security mechanisms should be formulated on a level of detail which supports the stand-alone implementation within a single module. This way, the security mechanisms shall become reusable 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 description 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 different security problems.

15 This approach is security mechanism centric and as such similarly useful for describing the implementation of security services offered to the user and to describe the implementation of security invariants and properties inherently enforced by the system. 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 promising. 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 complex scenarios than simple product maintenance is currently under investigation. In any case, an evolution of the modelling concepts is likely to become extremely important 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 highsecurity 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 developer 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 implementation with minimal impact on the security architecture of the system. The maintenance and compositional evaluation techniques currently applied to security 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 subcomponent 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. Therefore, the continuous evolution of the description model for the modularisation of security 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 discussions 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.

16 Bibliography /CC_P2/ Title: Identification: Version: Version 3.1 Revision 3 Date: July 2009 /CC_P3/ Title: Identification: Version: Version 3.1 Revision 3 Date: July 2009 Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components CCMB Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components CCMB /CCDB_COMP/ Title: Identification: Version: Version 1.0 Revision 1 Date: September 2007 /EXS_JIL_SARC1/ Title: Version: Version 2.0 Date: January 2012 /EXS_JIL_SARC2/ Title: Version: Version 2.0 Date: January 2012 Composite Product Evaluation for Smart Cards and Similar Devices CCDB Security Architecture Requirements for Smartcards and Similar Devices Security Architecture Requirements for Smartcards and Similar Devices Annex 1