The Security Objectives for the Environment are summarized in the following table:
Name Source Refined?
OE.DEV_NOS - -
OE.DEL_NOS - -
OE.IC_ORG - -
OE.DLV_PROTECT - -
OE.DLV_DATA - -
OE.TEST_OPERATE - -
OE.USE_DIAG - -
OE.USE_KEYS - -
OE.NATIVE [JCSPP] no
OE.NO-DELETION [JCSPP] no
OE.NO-INSTALL [JCSPP] no
OE.VERIFICATION [JCSPP] no Table 5: Security Objectives for the environment
4.2.1 Security Objectives for the Environment not contained in [JCSPP]
4.2.1.1 Objectives on Phase 1
OE.DEV_NOS The Smart Card NOS shall be designed in a secure manner, by using exclusively software development tools (compilers assemblers, linkers, simulators, etc.) and software-hardware integration testing tools (emulators) that will result in the integrity of program and data.
The Native Operating System developer shall use established procedures to control storage and usage of the classified development tools and documentation, suitable to maintain the integrity and the confidentiality of the assets of the TOE.
It must be ensured that tools used for the generation of the TOE are only delivered and accessible to the parties authorized personnel. It must be ensured that confidential information on defined assets is only delivered to the parties authorized personnel on a need to know basis.
OE.DEL_NOS The Smart Card Native Operating System and related data must be delivered from the Smart Card Native Operating System developer (phase 1) to the IC designer through a trusted delivery and verification procedure that shall be able to maintain the integrity of the software and its confidentiality, if applicable.
Initialization Data shall be accessible only by authorized personnel (physical, personnel, organizational, technical procedures).
Samples used to run tests shall be accessible only by authorized personnel.
4.2.1.2 Objective on Phases 2 and 3
OE.IC_ORG Procedures dealing with physical, personnel, organizational, technical measures for the confidentiality and integrity, of Smart Card Native Operating System (e.g. source code mask and any associated documents) and IC Manufacturer proprietary information (tools, software, documentation, dice ...) shall exist and be applied in IC development and manufacturing.
Procedures shall exist to ensure the protection of IC sensitive information during exchange with the NOS developer.
4.2.1.3 Objectives on the TOE Delivery Process (Phases 3 to 7)
OE.DLV_PROTECT Procedures shall ensure protection of TOE material/information under delivery including the following objectives:
o Non-disclosure of any security relevant information, identification of the element under delivery,
o Meet confidentiality rules (confidentiality level, transmittal form, reception acknowledgement),
o Physical protection to prevent external damage, secure storage and handling procedures (including rejected TOE’s),
o Traceability of TOE during delivery including the following parameters: origin and shipment details reception, reception acknowledgement, location material/information.
Procedures shall ensure that corrective actions are taken in case of improper operation in the delivery process (including if applicable any non-conformance to the confidentiality convention) and highlight all non-conformance to this process.
Procedures shall ensure that people (shipping department, carrier, reception department) dealing with the procedure for delivery have got the required skill, training and knowledge to meet the procedure requirements and be able to act fully in accordance with the above expectations.
4.2.1.4 Objectives on Delivery to Phases 4, 5 and 6
OE.DLV_DATA The TOE sensitive Data and documentation must be delivered to either the IC packaging manufacturer, to the Card Manufacturer, or to the Personalizer through a trusted delivery and verification procedure that shall be able to maintain the integrity and confidentiality of the TOE sensitive Data.
4.2.1.5 Objectives on Phases 4 to 6
OE.TEST_OPERATE Appropriate functionality testing of the TOE shall be used in phases 4 to 6.
During all manufacturing and test operations, security procedures shall be used through phases 4, 5 and 6 to maintain confidentiality and integrity of the TOE manufacturing and test data.
4.2.1.6 Objectives on Phase 7
OE.USE_DIAG Secure TOE communication protocols shall be supported and used by the environment.
OE.USE_KEYS During the TOE usage, the terminal or system in interaction with the TOE, shall ensure the protection (integrity and confidentiality) of their own keys by operational means and/or procedures.
Application note:
Objectives for the TOE environment are usually not satisfied by the TOE Security Functional Requirements.
The TOE development and manufacturing environment (phases 1 to 3) is in the scope of this ST. These phases are under the TOE developer scope of control. Therefore, the objectives for the environment related to phase 1 to 3 are covered by Assurance measures, which are materialized by documents, process and procedures evaluated through the TOE evaluation process.
The `product usage phases` (phase 4 to 7) are not in the scope of the evaluation. During these phases, the TOE is no more under the developer control. In this environment, the TOE protects itself with its own Security functions. But some additional usage recommendation must also be followed in order to ensure that the TOE is correctly and securely handled, and that shall be not damaged or compromised.
This ST assumes (A.DLV_DATA, A.TEST_OPERATE, A.USE_DIAG, A.USE_KEYS) that users handle securely the TOE and related Objectives for the environment are defined (OE.DLV_DATA, OE.TEST_OPERATE, OE.USE_DIAG, OE.USE_KEYS)
4.2.2 Security Objectives for the Environment from [JCSPP]
OE.NATIVE Those parts of the APIs written in native code as well as any pre-issuance native application on the card shall be conformant with the TOE so as to ensure that security policies and objectives described herein are not violated. See #.NATIVE (p.36) for details.
Note: The Security Objectives from [JCSPP] for the environment OE.SCP.RECOVERY, OE.SCP.SUPPORT, and O.SCP.IC are listed as TOE security objectives for the TOE in section 4.1.2.5 as the Smart Card Platform belong to the TOE for this evaluation.
Note: The Security Objective from [JCSPP] for the environment OE.CARD-MANAGEMENT is listed as TOE security objective for the TOE in section 4.1.2.4 as the Card Manager belongs to the TOE for this evaluation.
OE.NO-DELETION No installed applets (or packages) shall be deleted from the card.
OE.NO-INSTALL There is no post-issuance installation of applets. Installation of applets is secure and shall occur only in a controlled environment in the pre-issuance phase.
The objectives OE.NO-INSTALL and OE.NO-DELETION have been included so as to describe procedures that shall contribute to ensure that the TOE will be used in a secure manner. Moreover, they have been defined in accordance with the environmental assumptions they uphold (actually, they are just a reformulation of the corresponding assumptions). The DELETION and NO-INSTALL (assumptions and objectives) constitute the explicit statement that the Minimal configuration corresponds to that of a closed card (no code can be loaded or deleted once the card has been issued). It is not evident that these objectives should be carried out by using IT means.
OE.VERIFICATION All the bytecodes shall be verified at least once, before the loading, before the installation or before the execution, depending on the card capabilities, in order to ensure that each bytecode is valid at execution time. See #.VERIFICATION (p.37) for details.