• Document: Joint Interpretation Library
  • Size: 48.88 KB
  • Uploaded: 2019-01-13 03:16:55
  • Status: Successfully converted


Some snippets from your converted document:

Joint Interpretation Library Security Architecture requirements (ADV_ARC) for smart cards and similar devices Document purpose: provide requirements to developers and guidance to evaluators to fulfill the Security Architecture requirements of CC V3 ADV_ARC family. Version 2.0 January 2012 Security Architecture requirements (ADV_ARC) Joint Interpretation Library This page is intentionally left blank Page 2/11 Version 2.0 January 2012 Joint Interpretation Library Security Architecture requirements (ADV_ARC) Table of contents Contents 1 Introduction .............................................................................................. 4 1.1 Objective of the document ......................................................................... 4 1.2 Scope of Security Architecture................................................................... 4 2 General Aspects of Content and Presentation...................................... 5 3 Level of description in ADV_ARC........................................................... 6 4 Security domains ..................................................................................... 7 5 Secure start-up......................................................................................... 8 6 Self-protection.......................................................................................... 8 7 Non-bypassability .................................................................................. 10 7.1 TSF always invoked................................................................................. 10 7.2 Side channel ............................................................................................ 10 January 2012 Version 2.0 Page 3/11 Security Architecture requirements (ADV_ARC) Joint Interpretation Library 1 Introduction 1.1 Objective of the document The current document provides requirements for the developer and guidance for the evaluator on how to apply the assurance requirements of the family ADV_ARC to the Technical Domain of smart cards & similar devices. The developer documentation provided to fulfil the ADV_ARC family is denoted as “ARC document” in the text. The smart card technology requires special interpretation because it combines security integrated circuits, operating systems and applications to high secure devices. Therefore, this document is intended to provide mandatory interpretation for the application of the ADV_ARC family. It is addressed to both developers of security integrated circuits and developers of composite products, consisting of a hardware platform and embedded software. The embedded software can be organised in different ways (native software, closed operating systems with one or more applications, open software platforms and more). The expected assurance level is EAL4 (augmented by at least AVA_VAN.5) or higher. The mandatory interpretation defines what kind of information the ARC document SHALL contain and in which level of detail this information SHALL be provided. It does not define mandatory tasks for the evaluator. However, the document also serves as a guideline for the evaluator: in order to have a clear agreement between evaluator and developer, it states which kind of developer information is mandatory and may also define which is not. An informative part is provided in the Appendix which contains examples for the type of information and level of detail to be provided in the ARC document. 1.2 Scope of Security Architecture The version 3 of Common Criteria (CC) introduces a new security assurance requirements (SAR) family Security Architecture (ADV_ARC). Its objective is described in paragraph 214 of CC part 3 as follows: “The objective of this family is for the developer to provide a description of the security architecture of the TSF. This will allow analysis of the information that, when coupled with the other evidence presented for the TSF, will confirm the TSF achieves the desired properties. The security architecture descriptions support the implicit claim that security analysis of the TOE can be achieved by examining the TSF; without a sound architecture, the entire TOE functionality would have to be examined.” A security architecture is a set of properties that the TSF exhibits; these properties include self- protection, domain separation, and non-bypassability. These properties are distinct from security functionality expressed by Part 2 SFRs because they largely have no directly observable interface at the TSF. Rather, they are p

Recently converted files (publicly available):