Abstract
This paper presents a methodology for creating security targets that are compliant with two or more protection profiles. In our case, we are developing a hardware based Java Card™ implementation of Global Platform’s cross-industry standard for reconfigurable smart cards (called Open Platform). We have four protection profiles to contend with: Open Platform Protection Profile (OP3), Java Card System Protection Profile (JCSPP), Secure Silicon Vendors Group Protection Profile (SSVG-PP) and the Smart Card Security Users Group Smart Card Protection Profile (SCSUG-SCPP).Despite the Common Criteria’s common language for expressing security function requirements (SFRs), we have found that even if all four protection profiles ask for the same SFR, in some cases the TOE requires a single TOE security function (TSF), whereas in others it requires multiple TSFs. Moreover, demonstration of compliance against free-form descriptions of threats, assumptions and other Common Criteria paraphernalia – some of which may be identical, others overlapping and still others superficially similar but actually divergent – presents even more difficulty to the security target author. Our methodology overcomes these problems by mapping the SFRs and other requirements onto a hierarchically-layered security architecture that has the property that each layer inherits the security properties of the lower layers. This paper should be of prime interest to security target authors who have the task of complying with two or more PPs, particularly in the smart card arena.