Magic SSO V4.5 Security Target v1.3 2 / 86 < Revision History > Version Date Content / Author v1.0 2024-03-04 First Issue / Dream Security Co.,Ltd. ID Security Technology Lab v1.1 2024-05-10 Correct Error / Dream Security Co.,Ltd. ID Security Technology Lab v1.2 2024-06-24 EOR-01 Reflections / Dream Security Co.,Ltd. ID Security Technology Lab v1.3 2024-07-19 Update / Dream Security Co.,Ltd. ID Security Technology Lab 3 / 86 < Table of Contents > 1 Security Target introduction.............................................................................................................................................6 1.1 Security Target Reference........................................................................................................................................6 1.2 TOE Reference ..............................................................................................................................................................6 1.3 TOE overview ................................................................................................................................................................7 1.3.1 Single Sign On overview ...............................................................................................................................7 1.3.2 TOE Type and scope........................................................................................................................................7 1.3.3 TOE usage and major security features..................................................................................................7 1.3.4 Non-TOE and TOE operational environment.................................................................................... 10 1.4 TOE description......................................................................................................................................................... 13 1.4.1 Physical scope of the TOE.......................................................................................................................... 13 1.4.2 Logical scope of the TOE ........................................................................................................................... 14 1.5 Terms and definitions............................................................................................................................................. 21 1.6 Conventions................................................................................................................................................................ 27 2 Conformance claim........................................................................................................................................................... 28 2.1 CC, PP and security requirements package conformance.................................................................... 28 2.2 Conformance claim rationale ............................................................................................................................. 28 2.3 Conformance way with the protection profile........................................................................................... 31 3 Security objectives............................................................................................................................................................. 32 3.1 Security objectives for the operational environment.............................................................................. 32 4 Extended components definition............................................................................................................................... 34 4.1 Cryptographic support (FCS).............................................................................................................................. 34 4.1.1 Random Bit Generation............................................................................................................................... 34 4.1.1.1 FCS_RGB.1 Random bit generation .......................................................................................... 34 4.2 Identification & authentication (FIA) .............................................................................................................. 34 4.2.1 TOE Internal mutual authentication ...................................................................................................... 34 4.2.1.1 FIA_IMA.1 TOE Internal mutual authentication................................................................... 35 4.2.2 Specification of Secrets ............................................................................................................................... 35 4.2.2.1 FIA_SOS.3 Destruction of Secrets .............................................................................................. 36 4.3 Security Management (FMT) .............................................................................................................................. 36 4.3.1 ID and password............................................................................................................................................. 36 4.3.1.1 FMT_PWD.1 Management of ID password ........................................................................... 37 4.4 Production of the TSF (FPT)................................................................................................................................ 38 4.4.1 Protection of stored TSF data .................................................................................................................. 38 4.4.1.1 FPT_PST.1 Basic protection of stored TSF data ................................................................... 38 5 Security requirements...................................................................................................................................................... 40 5.1 Security functional requirements...................................................................................................................... 40 5.1.1 Security audit (FAU)....................................................................................................................................... 41 4 / 86 5.1.1.1 FAU_ARP.1 Security alarms............................................................................................................ 41 5.1.1.2 FAU_GEN.1 Audit data generation............................................................................................ 42 5.1.1.3 FAU_SAA.1 Potential violation analysis ................................................................................... 44 5.1.1.4 FAU_SAR.1 Audit review................................................................................................................. 44 5.1.1.5 FAU_SAR.3 Selectable audit review........................................................................................... 45 5.1.1.6 FAU_STG.3 Action in case of possible audit data loss..................................................... 45 5.1.1.7 FAU_STG.4 Prevention of audit data loss............................................................................... 45 5.1.2 Cryptographic support (FCS).................................................................................................................... 46 5.1.2.1 FCS_CKM.1 Cryptographic key generation ........................................................................... 46 5.1.2.2 FCS_CKM.2 Cryptographic key distribution.......................................................................... 46 5.1.2.3 FCS_CKM.4 Cryptographic key destruction .......................................................................... 47 5.1.2.4 FCS_COP.1 Cryptographic operation........................................................................................ 47 5.1.2.5 FCS_RBG.1 Random bit generation (extended) .................................................................. 49 5.1.3 Identification and authentication (FIA) ................................................................................................ 50 5.1.3.1 FIA_AFL.1(1) Authentication failure handling (administrator)....................................... 50 5.1.3.2 FIA_AFL.1(2) Authentication failure handling (end user) ................................................ 50 5.1.3.3 FIA_IMA.1 TOE internal mutual authentication (extended) ........................................... 50 5.1.3.4 FIA_SOS.1 Verification of secrets ............................................................................................... 51 5.1.3.5 FIA_SOS.2 Generation of secrets................................................................................................ 51 5.1.3.6 FIA_SOS.3 Destruction of secrets (extended)....................................................................... 52 5.1.3.7 FIA_UAU.2 User authentication before any action............................................................ 52 5.1.3.8 FIA_UAU.4(1) Single-use authentication mechanism (administrator) ....................... 52 5.1.3.9 FIA_UAU.4(2) Single-use authentication mechanism (end user)................................. 52 5.1.3.10 FIA_UAU.7 Protected authentication feedback ................................................................... 53 5.1.3.11 FIA_UID.2 User identification before any action................................................................. 53 5.1.4 Security management (FMT)..................................................................................................................... 54 5.1.4.1 FMT_MOF.1 Management of security functions behavior............................................. 54 5.1.4.2 FMT_MTD.1 Management of TSF data.................................................................................... 54 5.1.4.3 FMT_PWD.1 Management of ID and password (extended).......................................... 55 5.1.4.4 FMT_SMF.1 Specification of management functions ....................................................... 55 5.1.4.5 FMT_SMR.1 Security roles............................................................................................................. 56 5.1.5 Protection of the TSF (FPT)........................................................................................................................ 57 5.1.5.1 FPT_ITT.1 Basic internal TSF data transfer protection ...................................................... 57 5.1.5.2 FPT_PST.1 Basic protection of stored TSF data (extended) ........................................... 57 5.1.5.3 FPT_RCV.1 Manual Recovery........................................................................................................ 57 5.1.5.4 FPT_TST.1 TSF testing...................................................................................................................... 57 5.1.6 TOE access (FTA)............................................................................................................................................. 59 5.1.6.1 FTA_MCS.2 Per user attribute limitation on multiple concurrent sessions ............ 59 5 / 86 5.1.6.2 FTA_SSL.3 Termination of a session by TSF .......................................................................... 59 5.1.6.3 FTA_TSE.1 TOE session establishment ..................................................................................... 59 5.2 Security assurance requirements...................................................................................................................... 60 5.2.1 Security Target evaluation.......................................................................................................................... 60 5.2.1.1 ASE_INT.1 Security Target evaluation ...................................................................................... 60 5.2.1.2 ASE_CCL.1 Conformance claims................................................................................................. 61 5.2.1.3 ASE_OBJ.1 Security objectives for the operational environment ............................... 62 5.2.1.4 ASE_ECD.1 Extended components definition....................................................................... 62 5.2.1.5 ASE_REQ.1 Stated security requirements............................................................................... 63 5.2.1.6 ASE_TSS.1 TOE summary specification ................................................................................... 64 5.2.2 Development.................................................................................................................................................... 64 5.2.2.1 ADV_FSP.1 Security-enforcing functional specification................................................... 64 5.2.3 Guidance documents ................................................................................................................................... 65 5.2.3.1 AGD_OPE.1 Operational user guidance.................................................................................. 65 5.2.3.2 AGD_PRE.1 Preparative procedures.......................................................................................... 66 5.2.4 Life-cycle support .......................................................................................................................................... 66 5.2.4.1 ALC_CMC.1 Labelling of the TOE .............................................................................................. 66 5.2.4.2 ALC_CMS.1 TOE CM coverage.................................................................................................... 67 5.2.5 Tests ................................................................................................................................................................. 67 5.2.5.1 ATE_FUN.1 Functional testing..................................................................................................... 67 5.2.5.2 ATE_IND.1 Independent testing: conformance................................................................... 68 5.2.6 Vulnerability assessment............................................................................................................................. 68 5.2.6.1 AVA_VAN.1 Vulnerability survey................................................................................................ 68 5.3 Security requirements rationale ........................................................................................................................ 70 5.3.1 Dependency of the SFRs ............................................................................................................................ 70 5.3.2 Dependency rationale of security assurance requirements ....................................................... 72 6 TOE summary specification........................................................................................................................................... 73 6.1 Security audit............................................................................................................................................................. 74 6.2 Cryptographic support.......................................................................................................................................... 77 6.3 Identification and authentication ..................................................................................................................... 80 6.4 Security management............................................................................................................................................ 82 6.5 Protection of the TSF ............................................................................................................................................. 84 6.6 TOE access................................................................................................................................................................... 86 6 / 86 1 Security Target introduction 1.1 Security Target Reference Classification Contents Title Magic SSO V4.5 Security Target Version v1.3 Developer Dream Security Co.,Ltd. ID Security Technology Lab Date 2024-07-19 Evaluation Criteria Common Criteria for Information Technology Security Evaluation Common Criteria version CC V3.1 r5 Evaluation Assurance Level EAL1+(ATE_FUN.1) Keywords Single Sign On, SSO 1.2 TOE Reference Classification Contents TOE Identification Magic SSO V4.5 Detailed Version v4.5.0.1 Component SSO Server Magic SSO V4.5 Server v4.5.0.1 : magicsso-server-4.5.0.1.tar SSO Agent Magic SSO V4.5 Agent v4.5.0.1 : magicsso-agent-4.5.0.1.tar Guidance’s Magic SSO V4.5 Operational Guidance v1.3 : Magic_SSO_V4.5-OPE-v1.3.pdf Magic SSO V4.5 Installation Guide v1.3 : Magic_SSO_V4.5-PRE-v1.3.pdf Developer Dream Security Co.,Ltd. ID Security Technology Lab 7 / 86 1.3 TOE overview 1.3.1 Single Sign On overview Magic SSO V4.5 (hereinafter referred to as ‘TOE’) is used to enable the user to access various business systems and use the service through a single user login without additional login action. The TOE performs user identification and authentication, authentication token(hereinafter referred to as “token”) issue and validity verification according to the user authentication policy. 1.3.2 TOE Type and scope TOE is provided as software. The TOE is composed of the server that processes user login, manages the authentication token, and sets the policy(hereinafter referred to as ‘SSO Server’) and the agent that is installed in each business system performs the function of authentication token issue and verification(hereinafter referred to as ‘SSO Agent’). The TOE uses the following validated cryptographic modules whose safety and implementation conformity are verified through KCMVP (Korea Cryptographic Module Validation Program). Encryption module name Validation number Developer Validation date MagicJCrypto V3.0.0 CM-200-2026.12 Dream Security Co.,Ltd. 2021-12-31 1.3.3 TOE usage and major security features The TOE performs user identification and authentication functions through a DBMS that stores general user information, enabling the provision of services to various business systems with a single login (Single Sign-On) without requiring additional login actions. The TOE provides TSF protection functions such as a security audit function that records and manages major events as audit data when running security functions and management functions, data protection within TSF-controlled storage, and TSF self-testing. In addition, processing authentication failures, identification and authentication functions such as mutual authentication between TOE components, cryptographic support functions such as encryption key management and cryptographic operation for issuing authentication tokens, security management functions for managing security functions and environment settings, and TOE access functions for managing access sessions of authorized administrators. Additionally, the authentication token provides confidentiality and integrity, and the TOE execution code provides integrity. 8 / 86 The end user identification and authentication procedures of the TOE are shown in [Figure 1]. The detailed procedures are divided into the initial authentication phase using the end user ID and password and the authentication token-based authentication phase that accesses the business system using the authentication token issued during the initial authentication procedure. [Figure 1] End user identification and authentication procedure Firstly, the initial authentication phase is as follows. The end user accesses the business system and enters the ID, password and the SSO Agent receives a login verification request to the SSO Server, which in turn checks the authorized user status. Upon receiving the login verification request, the SSO Server issues an authentication token if the login verification result is valid after performing login verification using end user information stored in the DBMS. The issued token is passed to the SSO Agent. If the authentication token is verified and valid, The SSO Agent transfers an issued token to the user. Second, authentication token-based authentication steps are as follows. The authentication token- based authentication phase is performed only when has been normally issued in the initial authentication phase. The end user sends an authentication token-based authentication request to the SSO Agent installed in the business system, receiving the authentication request, the SSO Agent sends an authentication token verification request to the SSO Server. The SSO Server that receives the authentication token verification request performs the stored authentication token 9 / 86 verification and delivers the authentication token to the SSO Agent when the verification result is valid. The SSO Agent that receives the authentication token verifies the authentication token and passes it to the end user if it is valid. Authentication phase Example of operation procedure Initial authentication (A) Login request ⟶ (B) Login verification request ⟶ (C) Login verification request to server ⟶ (D) Login verification & Token issuance ⟶ (E) Forward Token via web browser ⟶ (F) Forward Token to agent ⟶ (G) Forward Token to end-user Token-based authentication (1) Token-based authentication request ⟶ (2) Forward Token-based authentication request ⟶ (3) Forward Token-based authentication request to server ⟶ (4) Token verification ⟶ (5) Forward Token via web browser ⟶ (6) Forward Token to agent ⟶ (7) Forward Token to end-user In addition, the subject that issue, store, and verify authentication tokens are as follows. - Authentication token issuance subject: SSO Server - Authentication token storage location: SSO Server, SSO Agent, user PC (web browser) - Authentication token verification subject: SSO Server 10 / 86 1.3.4 Non-TOE and TOE operational environment Figure 2 shows the TOE operational environment. TOE operational environment and consists of an SSO Server and an SSO Agent. SSO Server provides login verification, authentication token issue and management, and policy setting. SSO Server is mounted on Web Application Server and operates as a single web application. The SSO Agent performs normal user login verification requests, authentication token issuance, and verification request functions to the SSO Server and verifies the authentication token received from the SSO Server. SSO Agent is installed in each business system web application server in the form of library file API. Wrapper is used for compatibility with various business systems and Wrapper is excluded from the scope of the TOE. [Figure 2] TOE operational environment An administrator PC operational environment on which Chrome web browser that supports HTTPS (Hypertext Transfer Protocol over Secure Socket Layer) is required for an administrator to access the SSO Server and perform security management functions such as SSO Server configuration, status check and audit log search. 11 / 86 ■ DBMS(Oracle) SSO Server and Oracle, a relational database management system, are interlinked for the purpose of the management of authentication and policy information. ■ Mail Server A mail server is used as an external entity necessary for the operation of the TOE. The mail server is utilized to notify an authorized administrator via email in case of failed administrator authentication or possible audit data loss. Any hardware in which the TOE is installed is non-TOE. The requirements for non-TOE hardware/software that is mandatory for the operation of the product but does not fall under the scope of the TOE are as follows. Since the SSO Server and SSO Agent are Java-based web applications, they require Java and Web Application Server (WAS) among the software items. TOE Classification Item Minimum Specification SSO Server H/W CPU Intel Dual Core 2 GHz or higher Memory 8 GB or more HDD Space required for installation of TOE : 100 GB or more NIC Ethernet 100/1000 Mbps * 1 Port or more S/W OS Ubuntu 20.04 (Kernel 5.15.0) 64 bit Java OpenJDK 1.8.0_412 WAS Apache Tomcat 9.0.91 DBMS Oracle 11g(11.2.0.2.0) SSO Agent H/W CPU Intel Dual Core 2 GHz or higher Memory 8 GB or more HDD Space required for installation of TOE : 100 GB or more NIC Ethernet 100/1000 Mbps * 1 Port or more S/W OS Ubuntu 20.04 (Kernel 5.15.0) 64 bit Java OpenJDK 1.8.0_412 WAS Apache Tomcat 9.0.91 12 / 86 The requirements for the administrator PC operating environment connecting to the SSO Server are as follows. Classification Item Minimum Specification Admin PC S/W Browser Chrome 126.0 The 3rd -party software used in the operating environment required for TOE operation is as follows. 3rd -party Software Usage OpenJDK 1.8.0_412 Since the TOE is a Java-based web application, it requires a Java Development Kit (JDK). Apache Tomcat 9.0.91 The SSO Server Web Application Server (WAS) for security management and UI provision, and the SSO Agent requires Web Application Server (WAS) for business system integration. Oracle 11g(11.2.0.2.0) The SSO Server requires a DBMS to manage the storage of authentication, policy setting information, and audit data. 13 / 86 1.4 TOE description This chapter describes the physical scope and the logical scope of the TOE. 1.4.1 Physical scope of the TOE The TOE consists of SSO Server, SSO Agent, an operational guidance (Magic SSO V4.5 Operational Guidance v1.3, Magic_SSO_V4.5-OPE-v1.3.pdf) and an installation guide (Magic V4.5 Installation Guide v1.3, Magic_SSO_V4.5-PRE-v1.3.pdf). The SSO Server is Magic SSO V4.5 Server v4.5.0.1 that verifies end user login, manages authentication tokens and establishes policies. The SSO Agent is Magic SSO V4.5 Agent v4.5.0.1 that performs the function of requesting the verification of end user login to the SSO Server and requesting authentication token issuance. Any hardware and software in which the TOE is installed shall not fall under the scope of the TOE. [Figure 3] Physical scope of the TOE Magic SSO V4.5 product includes SSO Server and SSO Agent, which are the software developed by Dream Security Co.,Ltd., together with the operational guidance and the installation guide procedure documents. 14 / 86 Classification Type Distribution type SSO Server S/W to install in management server (CD distribution) Magic SSO V4.5 Server v4.5.0.1 : magicsso-server-4.5.0.1.tar SSO Agent S/W to install in business system (CD distribution) Magic SSO V4.5 Agent v4.5.0.1 : magicsso-agent-4.5.0.1.tar Guideline Operational Guidance, Installation Guide (CD distribution) Magic SSO V4.5 Operational Guidance v1.3 : Magic_SSO_V4.5-OPE-v1.3.pdf Magic SSO V4.5 Installation Guide v1.3 : Magic_SSO_V4.5-PRE-v1.3.pdf 1.4.2 Logical scope of the TOE [Figure 4] Logical scope of the TOE 1) SSO Server ■ Security audit The SSO Server generates audit data on security-relevant events to trace the responsibility for behaviors related to the security. Audit data generated by the SSO Server record the date and time of an event, the type of an event, subject identity and an outcome (success or failure) of an 15 / 86 event. All the audit data are stored in DBMS. An authorized administrator can review the audit data through the administrator screen and can search the audit data according to the date and time of an event, the type of an event and an outcome of an event. In addition to the super administrator, monitoring administrators authorized for audit viewing can view the audit data. In case the audit data storage reaches a certain threshold defined by the administrator, a warning email will be sent to the administrator. Also, in case the audit storage is full, audited events are ignored and a warning message is sent to the administrator via email. In addition, the following potential violations are analyzed, and a warning message is sent to the administrator via email. - Authentication failure event: authentication attempts made by an end user/administrator fail consecutively for a specific number of times defined by the administrator - Audit event on integrity violation - Event on failed self-test of the validated cryptographic module ■ TOE Access The TOE performs per user attribute limitation on concurrent sessions, management of TSF- initiated sessions and TOE session establishment to manage access by the end users and administrators. The maximum number of concurrent sessions of management access by an administrator that belong to the same administrator is limited to one. Also, the concurrent establishment of management access session and local access session that belong to the same administrator is prohibited. The TOE blocks new access if an administrator makes management access in one terminal and then tries to log in with the same account or the same privilege in a different terminal. An access session by an administrator/end user is terminated after a specified period of end user inactivity (default value: 10 minutes). As to management access by an administrator, any access by IPs, other than access IPs configurable by an administrator (default value: 2 IPs), is denied. ■ Cryptographic Support The TOE manages the security functions for generation, distribution and destruction of cryptographic key necessary for cryptographic operation, cryptographic operation and random number generation. For an algorithm applied here, MagicJCrypto V3.0.0, which is a validated cryptographic module, is used. 16 / 86 The SSO Server uses a random bit generator (HASH_DRBG(SHA-256)) in generating a symmetric key necessary for encrypting authentication information sent to the SSO Agent and encrypting/decrypting authentication tokens. The SSO Server performs encryption/decryption by using a symmetric key encryption algorithm (SEED/CBC 128 bits) in encrypting authentication information sent to the SSO Agent and encrypting/decrypting authentication tokens. The SSO Server destroys a symmetric key that was used for encrypting authentication information sent to the SSO Agent and encrypting/decrypting authentication tokens by overwriting it with ‘0’ (0x30). The SSO Server, when sending a cryptographic key for authentication information sent to the SSO Agent, uses a public key algorithm (RSAES (SHA-256)) to encrypt with a SSO Agent public key and distribute it. The SSO Server uses a digital signature algorithm (RSA-PSS (SHA-256)) in generating digital signature of authentication information sent to the SSO Agent and verifying digital signature of authentication information received by the SSO Agent. A random bit generator (HASH_DRBG (SHA-256)) is used for generating necessary random bits in generating symmetric key and password salts. A message authentication code algorithm (HMAC (SHA-256)) is used for the integrity verification of the TOE module. ■ Identification and Authentication The TOE identifies an administrator based on ID during identification and authentication attempts and performs administrator authentication before any behavior. The information provided through the GUI for identification/authentication of an administrator is ID and password, based on which an administrator is identified/authenticated. In case administrator authentication attempts fail consecutively for a specified number of times defined by an administrator (default value: 5 times), the authentication function becomes inactivated and access is denied for a specified period for authentication delay defined by an administrator (default value: 5 minutes). Passwords for authentication are masked with * and only the cause information of authentication failure is provided. Thus, in case of failed identification and authentication, feedback on reasons for the failure is not provided. 17 / 86 An administrator password shall be generated in accordance with the password rules. Once identification and authentication are completed, the administrator can manage the security functions. If identification and authentication of an end user are initially completed, an authentication token is generated with single-use login authentication information on the authenticated user and time stamps. Afterwards, upon authentication request based on the authentication token of the end user, the integrity verification that compares the end user’s authentication token with the authentication token hash managed on the SSO Server is conducted. Also, the token verification in the validity verification that compares the authentication token expirations is performed. For the destruction of the authentication token, the authentication token managed on the SSO Server is overwritten with “0” value and then destroyed. Upon login request from an end user and upon token-based authentication request, duplication check is performed to compare Request ID in the authentication request information with Request ID managed on the SSO Server to prevent the reuse. TOE internal mutual authentication is performed through the protocol implemented by Dream Security Co.,Ltd.. ■ Protection of the TSF The TOE offers the confidentiality and the integrity for the communication of inter-TOE components by performing cryptographic communication through the cryptographic module. For the protection of the TSF data, the information on end user/administrator’s authentication, TOE integrity verification, SSO Server and SSO Agent and so forth is encrypted, stored and managed in the DBMS. Authentication tokens are loaded in SSO Server sessions in an end user’s browser and are destroyed immediately after the use. The SSO Server runs self-tests during the initial start-up and periodically during normal operation to check the process status to ensure that it is in a safe condition and the security function works normally. It also performs integrity monitoring of TSF data and TSF executable codes subject to the integrity verification. ■ Security Management The SSO Server provides the function that enables an authorized administrator to manage security 18 / 86 roles, policies, end user information and audit information through the security management interface. An authorized administrator can change an administrator’s or an end user’s password through the security management interface and verifies the validity of the password values in accordance with the password policy when creating or changing an end user’s or an authorized administrator’s password. When an authorized administrator accesses the security management interface for the first time, it shall be enforced that the administrator changes the password. An audit administrator shall change the password upon access after the password is reset by an authorized administrator. - Security Role Management: The function of the administrator role management is provided. The administrator role is classified into super administrator and monitoring administrator. A super administrator is authorized for policy management, end user information management and audit information management while a monitoring administrator is authorized for the monitoring of the TOE and audit information viewing. - Security Policy Management: It provides authentication policy management functions. Set general user authentication policies such as password validity setting, duplicate login prevention setting, and session inactivity time setting. Set the storage capacity threshold and self-module verification cycle of audit information. Set the mail information of the mail server address and mail notification information. - End User Information Management: It provides the function of handling unlocking of an end user account that has been locked. - Audit Information Management: It provides the function of viewing audit information based on a search period, types of audit events and outcomes. 2) SSO Agent ■ Security Audit The SSO Agent generates audit data on security-relevant events to trace the responsibility for behaviors related to the security. Audit data generated by the SSO Server record the date and time of an event, the type of an event, subject identity and an outcome (success or failure) of an event. All the audit data are transmitted to the SSO Server. ■ TOE Access 19 / 86 Following identification and authentication of an end user, a session is terminated after a specified period of inactivity (default value: 10 minutes). Afterwards, identification and authentication are performed through re-authentication. ■ Cryptographic Support The TOE manages the security functions for generation, distribution and destruction of cryptographic key necessary for cryptographic operation, cryptographic operation and random number generation. For an algorithm applied here, MagicJCrypto V3.0.0, which is a validated cryptographic module, is used. The SSO Agent uses a random bit generator (HASH_DRBG(SHA-256)) in generating a symmetric key necessary for encrypting authentication information sent to the SSO Server and encrypting/decrypting authentication tokens. The SSO Agent performs encryption/decryption by using a symmetric key encryption algorithm (SEED/CBC 128 bits) in encrypting authentication information sent to the SSO Server. The SSO Agent destroys a symmetric key that was used for encrypting authentication information sent to the SSO Server tokens by overwriting it with ‘0’ (0x30). The SSO Agent, when sending a cryptographic key for authentication information sent to the SSO Server, uses a public key algorithm (RSAES (SHA-256)) to encrypt with a SSO Server public key and distribute it. The SSO Agent uses a digital signature algorithm (RSA-PSS (SHA-256)) in generating digital signature of authentication information sent to the SSO Server and verifying digital signature of authentication information received by the SSO Server. A random bit generator (HASH_DRBG (SHA-256)) is used for generating necessary random bits in generating a symmetric key. A message authentication code algorithm (HMAC (SHA-256)) is used for the integrity verification of the TOE module. ■ Identification and Authentication The TOE identifies an end user based on ID during the initial identification and authentication attempts and performs end user authentication before any behavior. The information provided through GUI for identification/authentication of an end user is ID and password, based on which 20 / 86 an end user is identified/authenticated. In case end user authentication attempts fail consecutively for a specified number of times defined by an administrator (default value: 5 times), the authentication function becomes inactivated and access is denied until the administrator unlocks the end user account. Passwords for authentication are masked with * and only the cause information of authentication failure is provided. Thus, in case of failed identification and authentication, feedback on reasons for the failure is not provided. If identification and authentication of an end user are initially completed, identification and authentication through an authentication token are performed upon token-based request. For the destruction of the authentication token, the authentication token managed on the SSO Server is overwritten with “0” value and then destroyed. Upon login request from an end user and upon token-based authentication request, duplication check is performed to compare Request ID in the authentication request information with Request ID managed on the SSO Server to prevent the reuse. TOE internal mutual authentication is performed through the protocol implemented by Dream Security Co.,Ltd. ■ Protection of the TSF The TOE offers the confidentiality and the integrity for the communication of inter-TOE components by performing cryptographic communication through the cryptographic module. For the protection of the TSF data, the information on end user/administrator’s authentication, TOE integrity verification, SSO Server and SSO Agent and so forth is encrypted, stored and managed in the DBMS. Authentication tokens are loaded in SSO Server sessions in an end user’s browser and are destroyed immediately after the use. The SSO Agent runs self-tests during the initial start-up and periodically during normal operation to check the process status to ensure that it is in a safe condition and the security function works normally. It also performs integrity monitoring of TSF data and TSF executable codes subject to the integrity verification. 21 / 86 1.5 Terms and definitions Application Programming Interface (API) A set of software libraries that exist between the application layer and the platform system layer and facilitate the development of applications that run on the platform Approved cryptographic algorithm A cryptographic algorithm selected by Korean Cryptographic Module Validation Authority for block cipher, secure hash algorithm, message authentication code, random bit generation, key agreement, public key cipher, digital signatures cryptographic algorithms considering safety, reliability and interoperability Approved mode of operation The mode of cryptographic module using approved cryptographic algorithm Assets Entities that the owner of the TOE presumably places value upon Assignment The specification of an identified parameter in a component (of the CC) or requirement Attack potential Measure of the effort to be expended in attacking a TOE expressed as an attacker's expertise, resources and motivation Augmentation Addition of one or more requirement(s) to a package Authentication Data Information used to verify a user's claimed identity Authentication token Authentication data that authorized end-users use to access the business system Authorized Administrator Authorized user to securely operate and manage the TOE Authorized User The TOE user who may, in accordance with the SFRs, perform an operation 22 / 86 Business System An application server that authorized end-users access through ‘SSO’ Class Set of CC families that share a common focus Client Application program that can access the services of SSO Server or SSO Agent through network Component Smallest selectable set of elements on which requirements may be based Critical Security Parameters (CSP) Information related to security that can erode the security of the encryption module if exposed or changed (e.g., verification data such as secret key/private key, password, or Personal Identification Number) Database Management System (DBMS) A software system composed to configure and apply the database. Decryption The act that restoring the ciphertext into the plaintext using the decryption key Dependency Relationship between components such that if a requirement based on the depending component is included in a PP, ST or package, a requirement based on the component that is depended upon must normally also be included in the PP, ST or package Element Indivisible statement of a security need Encryption The act that converting the plaintext into the ciphertext using the encryption key Endpoint Where TOE components such as agents and clients are installed and operated without further sub-interworking entities 23 / 86 End-user Users of the TOE who want to use the business system, not the administrators of the TOE Evaluation Assurance Level (EAL) Set of assurance requirements drawn from CC Part 3, representing a point on the CC predefined assurance scale, that form an assurance package External Entity Human or IT entity possibly interacting with the TOE from outside of the TOE boundary Family Set of components that share a similar goal but differ in emphasis or rigor Identity Representation uniquely identifying entities (e.g. user, process or disk) within the context of the TOE Iteration Use of the same component to express two or more distinct requirements Korea Cryptographic Module Validation Program (KCMVP) A system to validate the security and implementation conformance of cryptographic modules used for protection of important but not classified information among the data communicated through the information and communication network of the government and public institutions Local access Connection established between administrator and TOE via console port Management access The access to the TOE by using the HTTPS, SSH, TLS, etc to manage the TOE by administrator, remotely Management Console Applications that provide administrators with graphical interfaces (GUI), command-based interfaces (CLI), and so on to provide system management and settings Manual recovery 24 / 86 Recovery via an update server, etc. run by the user or by user intervention Monitoring administrator As An authorized user who operates and manages the TOE securely, Only the audit log can be viewed among the security management functions Object Passive entity in the TOE containing or receiving information and on which subjects perform operations Operation(on a component of the CC) Modification or repetition of a component. Allowed operations on components are assignment, iteration, refinement and selection Operation(on a subject) Specific type of action performed by a subject on an object Private Key A cryptographic key which is used in an asymmetric cryptographic algorithm and is uniquely associated with an entity (the subject using the private key), not to be disclosed Protection Profile (PP) Implementation-independent statement of security needs for a TOE type Public Key A cryptographic key which is used in an asymmetric cryptographic algorithm and is associated with a unique entity (the subject using the public key), it can be disclosed Public Key(asymmetric) cryptographic algorithm A cryptographic algorithm that uses a pair of public and private key Public Security Parameters (PSP) security related public information whose modification can compromise the security of a cryptographic module Random bit generator (RBG) A device or algorithm that outputs a binary sequence that is statistically independent and is not biased. The RBG used for cryptographic application generally generates 0- and 1-bit string, and 25 / 86 the sequence can be combined into a random bit block. The RBG is classified into the deterministic and non-deterministic type. The deterministic type RBG is composed of an algorithm that generates bit strings from the initial value called a “seed key,” and the non-deterministic type RBG produces output that depends on the unpredictable physical source Refinement Addition of details to a component Role Predefined set of rules on permissible interactions between a user and the TOE Secret Key The cryptographic key which is used in symmetric cryptographic algorithm and is associated with one or more entity, it is not allowed to release Secure Sockets Layer (SSL) This is a security protocol proposed by Netscape to ensure confidentiality, integrity and security over a computer network Security Policy Document Document uploaded to the list of the validated cryptographic module with the module’s name and specifying the summary for the cryptographic algorithms and operational environments of the TOE Security Target (ST) Implementation-dependent statement of security needs for a specific identified TOE Selection Specification of one or more items from a list in a component Self-test Pre-operational or conditional test executed by the cryptographic module Sensitive Security Parameters (SSP) Critical security parameters (CSP) and public security parameters (PSP) Subject Active entity in the TOE that performs operations on objects 26 / 86 Super administrator As an authorized user who operates and manages the TOE securely, it can perform all security management functions Symmetric cryptographic technique Encryption scheme that uses the same secret key in mode of encryption and decryption, also known as secret key cryptographic technique Target of Evaluation (TOE) Set of software, firmware and/or hardware possibly accompanied by guidance Threat Agent Entity that can adversely act on assets TOE Security Functionality (TSF) Combined functionality of all hardware, software, and firmware of a TOE that must be relied upon for the correct enforcement of the SFRs Transport Layer Security (TLS) This is a cryptographic protocol between a SSL-based server and a client and is described in RFC 2246 TSF Data Data for the operation of the TOE upon which the enforcement of the SFR relies User Refer to "External entity“, authorized administrator and authorized end-user in the TOE Validated Cryptographic Module A cryptographic module that is validated and given a validation number by validation authority Wrapper Interfaces for interconnection between the TOE and various types of business systems or authentication systems 27 / 86 1.6 Conventions The notation, formatting and conventions used in this PP are consistent with the Common Criteria for Information Technology Security Evaluation. The CC allows several operations to be performed for functional requirements: iteration, assignment, selection and refinement. Each operation is used in this PP. Iteration Iteration is used when a component is repeated with varying operations. The result of iteration is marked with an iteration number in parenthesis following the component identifier, i.e., denoted as (iteration No.). Assignment This is used to assign specific values to unspecified parameters (e.g., password length). The result of assignment is indicated in square brackets like [ assignment value ]. Selection This is used to select one or more options provided by the CC in stating a requirement. The result of selection is shown as underlined and italicized. Refinement This is used to add details and thus further restrict a requirement. The result of refinement is shown in bold text. 28 / 86 2 Conformance claim 2.1 CC, PP and security requirements package conformance The Common Criteria and the Protection Profile, and the security requirements package that this ST and the TOE conform to are as follows: Classification Compliance CC Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5 - Common Criteria for Information Technology Security Evaluation. Part 1: Introduction and General Model, Version 3.1, Revision 5 (CCMB-2017-04-001, April 2017) - Common Criteria for Information Technology Security Evaluation. Part 2: Security Functional Components, Version 3.1, Revision 5 (CCMB-2017-04-002, April 2017) - Common Criteria for Information Technology Security Evaluation. Part 3: Security Assurance Components, Version 3.1, Revision 5 (CCMB-2017-04-003, April 2017) CC Part2 Extended : FCS_RBG.1, FIA_IMA.1, FIA_SOS.3, FMT_PWD.1, FPT_PST.1 CC Part3 Conformant PP National Protection Profile for Single Sign On V3.0 (2023-04-27) Security requirements package Augmented : EAL1 augmented (ATE_FUN.1) 2.2 Conformance claim rationale This ST strictly conforms to the “National Protection Profile for Single Sign-On V3.0” adopting the TOE type, security objectives and security requirements in the same way as the PP. Classificatio n PP ST Rationale TOE Type Single sign on Single sign on Same as PP Operational environment OE.Physical control OE.Physical control Same as PP OE.Trusted admin OE.Trusted admin Same as PP OE.Log backup OE.Log backup Same as PP 29 / 86 OE.Operation system reinforcement OE.Operation system reinforcement Same as PP OE.Secure development OE.Secure development Same as PP - OE.Time stamp More restrictive than the PP - Although the PP does not include security problem definitions and security requirements regarding time stamps used in audit records, this ST additionally identifies the assumptions that secure time stamps received from the TOE operational environment are used. Therefore, it is more restrictive than the PP - OE.DBMS More restrictive than the PP - Although the PP does not include security problem definitions and security requirements regarding the DBMS where audit data are recorded, this ST additionally identifies the assumptions that the DBMS safely stores and protects audit data generated in the TOE. Therefore, it is more restrictive than the PP - OE.Management Access More restrictive than the PP - Although the PP does not include security problem definitions and security requirements regarding authorized administrator TOE access, this ST additionally identifies assumption that authorized administrator TOE access is securely managed, which is more restrictive than PP Security functional requirements FAU_ARP.1 FAU_ARP.1 Same as PP FAU_GEN.1 FAU_GEN.1 Same as PP FAU_SAA.1 FAU_SAA.1 Same as PP 30 / 86 FAU_SAR.1 FAU_SAR.1 Same as PP FAU_SAR.3 FAU_SAR.3 Same as PP FAU_STG.3 FAU_STG.3 Same as PP FAU_STG.4 FAU_STG.4 Same as PP FCS_CKM.1 FCS_CKM.1 Same as PP FCS_CKM.2 FCS_CKM.2 Same as PP FCS_CKM.4 FCS_CKM.4 Same as PP FCS_COP.1 FCS_COP.1 Same as PP FCS_RBG.1 FCS_RBG.1 Same as PP FIA_AFL.1 FIA_AFL.1(1) Authentication failure handling in the PP is divided into that of an administrator and that of an end user to perform the iteration operation. Since the users of the TOE consist of the administrators and the end users, this ST conforms to the security requirements equivalent to those in the PP FIA_AFL.1(2) FIA_IMA.1 FIA_IMA.1 Same as PP FIA_SOS.1 FIA_SOS.1 Same as PP FIA_SOS.2 FIA_SOS.2 Same as PP FIA_SOS.3 FIA_SOS.3 Same as PP FIA_UAU.2 FIA_UAU.2 Same as PP FIA_UAU.4 FIA_UAU.4(1) Same as PP FIA_UAU.4(2) Same as PP FIA_UAU.7 FIA_UAU.7 Same as PP FIA_UID.2 FIA_UID.2 Same as PP FMT_MOF.1 FMT_MOF.1 Same as PP FMT_MTD.1 FMT_MTD.1 Same as PP FMT_PWD.1 FMT_PWD.1 Same as PP FMT_SMF.1 FMT_SMF.1 Same as PP FMT_SMR.1 FMT_SMR.1 Same as PP FPT_ITT.1 FPT_ITT.1 Same as PP FPT_PST.1 FPT_PST.1 Same as PP FPT_RCV.1 FPT_RCV.1 Same as PP FPT_TST.1 FPT_TST.1 Same as PP FTA_MCS.2 FTA_MCS.2 Same as PP 31 / 86 FTA_SSL.3 FTA_SSL.3 Same as PP FTA_TSE.1(1) FTA_TSE.1 Same as PP Warranty requirements ADV_FSP.1 ADV_FSP.1 Same as PP AGD_OPE.1 AGD_OPE.1 Same as PP AGD_PRE.1 AGD_PRE.1 Same as PP ALC_CMC.1 ALC_CMC.1 Same as PP ALC_CMS.1 ALC_CMS.1 Same as PP ASE_CCL.1 ASE_CCL.1 Same as PP ASE_ECD.1 ASE_ECD.1 Same as PP ASE_INT.1 ASE_INT.1 Same as PP ASE_OBJ.1 ASE_OBJ.1 Same as PP ASE_REQ.1 ASE_REQ.1 Same as PP ASE_TSS.1 ASE_TSS.1 Same as PP ATE_FUN.1 ATE_FUN.1 Same as PP ATE_IND.1 ATE_IND.1 Same as PP AVA_VAN.1 AVA_VAN.1 Same as PP 2.3 Conformance way with the protection profile This security target adheres to “strict protection profile conformance”. 32 / 86 3 Security objectives 3.1 Security objectives for the operational environment The followings are the security objectives handled by technical and procedural method supported from operational environment to provide the TOE security functionality accurately. OE. PHYSICAL_CONTROL The place where SSO Agent and SSO Server among the TOE components are installed and operated shall be equipped with access control and protection facilities so that only authorized administrator can access. OE. TRUSTED_ADMIN The authorized administrator of the TOE shall be non-malicious users, have appropriately trained for the TOE management functions and accurately fulfill the duties in accordance with administrator guidance. OE. LOG_BACKUP The authorized administrator shall periodically check a spare space of audit data storage in case of the audit data loss and carries out the audit data backup (external log server or separate storage device, etc.) to prevent audit data loss. OE. OPERATION_SYSTEM_REINF ORCEMENT The authorized administrator of the TOE shall ensure the reliability and security of the operating system by performing the reinforcement on the latest vulnerabilities of the operating system in which the TOE is installed and operated. OE. SECURE_DEVELOPMENT The developer who uses the TOE to interoperate with the user identification and authentication function in the operational environment of the business system shall ensure that the security functions of the TOE are securely applied in accordance with the requirements of the manual provided with the TOE. OE.TIME_STAMP The TOE shall receive reliable time stamps from the operating environment and accurately record audit data related to the operation of the TOE. 33 / 86 OE.DBMS The TOE shall receive reliable DBMS from the operational environment, store audit data related to the operation of the TOE and protect the audit data from unauthorized deletion or modification. OE.Management Access The confidentiality and integrity of data transmitted for communication between the web browser of the manager's PC and the web server, which is the operating environment of the management server, must be guaranteed. 34 / 86 4 Extended components definition 4.1 Cryptographic support (FCS) 4.1.1 Random Bit Generation Family Behavior This family defines requirements for the TSF to provide the capability that generates random bits required for TOE cryptographic operation. Component leveling FCS_RBG.1 random bit generation, requires TSF to provide the capability that generates random bits required for TOE cryptographic operation. Management: FCS_RBG.1 There are no management activities foreseen Audit: FCS_RBG.1 There are no auditable events foreseen 4.1.1.1 FCS_RGB.1 Random bit generation Hierarchical to No other components Dependencies No dependencies FCS_RBG.1.1 The TSF shall generate random bits required to generate an cryptographic key using the specified random bit generator that meets the following [assignment: list of standards]. 4.2 Identification & authentication (FIA) 4.2.1 TOE Internal mutual authentication Family Behavior FCS_RBG Random bit generation 1 C S_ R B G 난 수 생 성 35 / 86 This family defines requirements for mechanisms that enforce defined quality metrics on provided secrets and generate secrets to satisfy the defined metric Component leveling FIA_IMA.1 TOE Internal mutual authentication requires that the TSF provides mutual authentication function between TOE components in the process of user identification and authentication Management: FIA_IMA.1 There are no management activities foreseen Audit: FIA_IMA.1 The following actions are recommended to record if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimum: Success and failure of mutual authentication 4.2.1.1 FIA_IMA.1 TOE Internal mutual authentication Hierarchical to No other components Dependencies No dependencies FIA_IMA.1 The TSF shall perform mutual authentication between [assignment: different parts of TOE] using the [assignment: authentication protocol] that meets the following [assignment: list of standards] 4.2.2 Specification of Secrets Family Behavior This family defines requirements for mechanisms that enforce defined quality metrics on provided secrets and generate secrets to satisfy the defined metric FIA_IMA.1 TOE Internal mutual authentication 1 C S_ R B G 난 수 생 성 36 / 86 Component leveling The specification of secrets family in CC Part 2 is composed of 2 components. It is now composed of three components, since this PP adds one more component as below ※ The description on two components included in CC Part 2 is omitted FIA_SOS.3 Destruction of secrets requires, that the secret information be destroyed according to the specified destruction method, which can be based on the assigned standard Management: FIA_SOS.3 There are no management activities foreseen Audit: FIA_SOS.3 The following actions are recommended to record if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimum : Success and failure of the activity 4.2.2.1 FIA_SOS.3 Destruction of Secrets Hierarchical to No other components Dependencies FIA_SOS.2 TSF Generation of secrets FIA_SOS.3.1 The TSF shall destroy secrets in accordance with a specified secrets destruction method [assignment: secret destruction method] that meets the following: [assignment: list of standards] 4.3 Security Management (FMT) 4.3.1 ID and password Family Behavior FIA_SOS Specification of Secrets 2 C S_ R B G 난 수 생 성 1 C S_ R B G 난 수 생 성 3 C S_ R B G 난 수 생 성 37 / 86 This family defines the capability that is required to control ID and password management used in the TOE, and set or modify ID and/or password by authorized users Component leveling FMT_PWD.1 ID and password management, requires that the TSF provides the management function of ID and password Management: FMT_PWD.1 The following actions could be considered for the management functions in FMT: a) Management of ID and password configuration rules Audit: FMT_PWD.1 The following actions are recommended to record if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimum: All changes of the password 4.3.1.1 FMT_PWD.1 Management of ID password Hierarchical to No other components Dependencies FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_PWD.1.1 The TSF shall restrict the ability to manage the password of [assignment: list of functions ] to [assignment: the authorized identified roles] 1. [assignment: password combination rules and/or length] 2. [assignment: other management such as management of special characters unusable for password, etc.] FMT_PWD.1.2 The TSF shall restrict the ability to manage the ID of [assignment: list of functions] to [assignment: the authorized identified roles] 1. [assignment: ID combination rules and/or length] 2. [assignment: other management such as management of special characters FMT_PWD ID and password 1 C S_ R B G 난 수 생 성 38 / 86 unusable for ID, etc.] FMT_PWD.1.3 The TSF shall provide the capability for [selection, choose one of: setting ID and password when installing, setting password when installing, changing the ID and password when the authorized administrator accesses for the first time, changing the password when the authorized administrator accesses for the first time] 4.4 Production of the TSF (FPT) 4.4.1 Protection of stored TSF data Family Behavior This family defines rules to protect TSF data stored within containers controlled by the TSF from the unauthorized modification or disclosure. Component leveling FPT_PST.1 Basic protection of stored TSF data, requires the protection of TSF data stored in containers controlled by the TSF Management: FPT_PST.1 There are no management activities foreseen Audit: FPT_PST.1 There are no auditable events foreseen 4.4.1.1 FPT_PST.1 Basic protection of stored TSF data Hierarchical to No other components Dependencies No dependencies FPT_PST.1.1 The TSF shall protect [assignment: TSF data] stored in containers controlled by the TSF from the unauthorized [selection: disclosure, modification] FPT_PST Protection of stored TSF data 1 C S_ R B G 난 수 생 성 39 / 86 40 / 86 5 Security requirements In this section specify security functional requirements and assurance requirements that must be satisfied by the TOE. 5.1 Security functional requirements The security functional requirements defined in this ST are derived from the relevant security functional components in CC Part 2 to satisfy the security objectives identified in Chapter 3. [Table 1] below summarizes the security functional components used in this ST. [Table 1] Security functional requirements Security functional class Security functional component Security audit (FAU) FAU_ARP.1 Security alarms FAU_GEN.1 Audit data generation FAU_SAA.1 Potential violation analysis FAU_SAR.1 Audit review FAU_SAR.3 Selectable audit review FAU_STG.3 Action in case of possible audit data loss FAU_STG.4 Prevention of audit data loss Cryptographic support (FCS) FCS_CKM.1 Cryptographic key generation FCS_CKM.2 Cryptographic key distribution FCS_CKM.4 Cryptographic key destruction FCS_COP.1 Cryptographic operation FCS_RBG.1(extended) Random bit generation Identification and authentication (FIA) FIA_AFL.1(1) Authentication failure handling(administrator) FIA_AFL.1(2) Authentication failure handling(end-user) FIA_IMA.1(extended) TOE Internal mutual authentication FIA_SOS.1 Verification of secrets FIA_SOS.2 TSF Generation of secrets FIA_SOS.3(extended) Destruction of secrets FIA_UAU.2 Authenticated the user before all behavior FIA_UAU.4(1) Single-use authentication mechanisms(administrator) FIA_UAU.4(2) Single-use authentication mechanisms(End-user) FIA_UAU.7 Protected authentication feedback FIA_UID.2 Identification the user before all behavior Security management (FMT) FMT_MOF.1 Management of security functions behavior FMT_MTD.1 Management of TSF data FMT_PWD.1(extended) Management of ID and password 41 / 86 FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles Protection of the TSF (FPT) FPT_ITT.1 Basic internal TSF data transfer protection FPT_PST.1(extended) Basic protection of stored TSF data FPT_RCV.1 Manual Recovery FPT_TST.1 TSF testing TOE access (FTA) FTA_MCS.2 Per user attribute limitation on multiple concurrent sessions FTA_SSL.3 Locking or termination of interactive session FTA_TSE.1 TOE session establishment 5.1.1 Security audit (FAU) 5.1.1.1 FAU_ARP.1 Security alarms Hierarchical to No other components Dependencies FAU_SAA.1 Potential violation analysis FAU_ARP.1.1 The TSF shall take [ refer to “actions” in [Table 2] list of actions against security violations ] upon detection of a potential security violation. [Table 2] List of actions against security violations Security functional component Security violation Action FIA_AFL.1(1) - In case administrator authentication attempts fail consecutively for a defined number of times (default value: 5 times) - Inactivate the authentication function for a defined period (default value: 5 minutes) - Send a warning message email to the authorized administrator FIA_AFL.1(2) - In case end user authentication attempts fail consecutively for a defined number of times (default value: 5 times) - Inactivate the authentication function until the authorized administrator unlock the account FPT_TST.1 Self-test when TSF is driven - In case a self-test of the validated cryptographic module fails - In case the integrity verification fails - In case the process validation fails Periodic self-examination - Inactivate the authentication function until the authorized administrator unlock the account - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator 42 / 86 - In case a self-test of the validated cryptographic module fails - In case the integrity verification fails - In case the process validation fails Self-test by administrator - In case a self-test of the validated cryptographic module fails - In case the integrity verification fails - In case the process validation fails - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator FAU_STG.3 - In case the audit trail exceeds the threshold (default value: 90%) - Send a warning message email to the authorized administrator FAU_STG.4 - In case the audit trail is full - Ignore an audited event - Send a warning message email to the authorized administrator 5.1.1.2 FAU_GEN.1 Audit data generation Hierarchical to No other components Dependencies FPT_STM.1 Reliable time stamps FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shutdown of the audit functions; b) All auditable events for the not specified level of audit; and c) [ Refer to the “auditable events” in [Table 3] Audit events ] FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST [ Refer to the contents of “additional audit information” in [Table 3] Audit events ] [Table 3] Auditable events Security functional Auditable event Additional audit 43 / 86 component information FAU_ARP.1 Actions taken due to potential security violations FAU_SAA.1 Enabling and disabling of any of the analysis mechanisms, Automated responses performed by the tool FAU_STG.3 Actions taken due to exceeding of a threshold FAU_STG.4 Actions taken due to the audit storage failure FCS_CKM.1 Success and failure of the activity FCS_CKM.2 Success and failure of the activity (applied only to the distribution of a key related to encryption/decryption of TSF data) FCS_CKM.4 Success and failure of the activity (applied only to the destruction of a key related to encryption/decryption of TSF data) FCS_COP.1 Success and failure of cryptographic operation, and the type of cryptographic operation (applied only to items related to issuance, storage, verification and deletion of authentication token) FIA_AFL.1(1) The reaching of the threshold for the unsuccessful authentication attempts and the actions taken and the subsequent, if appropriate, restoration to the normal state FIA_AFL.1(2) The reaching of the threshold for the unsuccessful authentication attempts and the actions taken and the subsequent, if appropriate, restoration to the normal state FIA_SOS.2 Rejection by the TSF of any tested secret FIA_SOS.3(extended) Success and failure of the activity (applied only to destruction of SSO authentication token) FIA_UAU.2 All use of the user authentication mechanism FIA_UAU.4(1) Single-use authentication mechanism(Admin) FIA_UAU.4(2) Single-use authentication mechanism(end user) FIA_UID.2 All use of the user identification mechanism FMT_MOF.1 All modifications in the behavior of the functions in the TSF FMT_MTD.1 All modifications to the values of TSF data Modified values of TSF data FMT_PWD.1(extended) All changes of the password FMT_SMF.1 Use of management functions FMT_SMR.1 Modifications to the user group of rules divided FPT_TST.1 Execution of the TSF self-tests and the results of the tests The validated cryptographic module 44 / 86 self-test failure data, Modified TSF data or execution code in case of integrity violation, The process validation failure data FTA_MCS.2 Denial of a new session based on the limitation of multiple concurrent sessions FTA_SSL.3 Locking or termination of interactive sessions FTA_TSE.1 Denial of a session establishment due to the session establishment mechanism All attempts at establishment of a user session 5.1.1.3 FAU_SAA.1 Potential violation analysis Hierarchical to No other components Dependencies FAU_GEN.1 Audit data generation FAU_SAA.1.1 The TSF shall be able to apply a set of rules in monitoring the audited events and based upon these rules indicate a potential violation of the enforcement of the SFRs. FAU_SAA.1.2 The TSF shall enforce the following rules for monitoring audited events: a) Accumulation or combination of [ Failed authentication attempt threshold reach audit event in FIA_AFL.1(1), Failed authentication attempt threshold reach audit event in FIA_AFL.1(2), Self-test failure event of the validated cryptographic module, Integrity verification failure event, Process verification failure event in FPT_TST.1, Audit trail capacity exceeding the threshold among auditable events in FAU_STG.3, Full audit trail event among auditable events in FAU_STG.4 ] known to indicate a potential security violation; b) [ None ] 5.1.1.4 FAU_SAR.1 Audit review Hierarchical to No other components Dependencies FAU_GEN.1 Audit data generation FAU_SAR.1.1 The TSF shall provide the [ authorized administrator ] with the capability to read [ all the audit data ] from the audit records. 45 / 86 FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the authorized administrator to interpret the information. 5.1.1.5 FAU_SAR.3 Selectable audit review Hierarchical to No other components Dependencies FAU_SAR.1 Audit review FAU_SAR.3.1 The TSF shall provide the ability to apply [ sorting in the descending order based on the time and date of events ] of audit data based on [ the time and date of an event AND event type AND event outcome ]. 5.1.1.6 FAU_STG.3 Action in case of possible audit data loss Hierarchical to No other components Dependencies FAU_STG.1 Protected audit trail storage FAU_STG.3.1 The TSF shall [ Notification to the authorized administrator, [N/A] ] if the audit trail exceeds [ the percentage of the used storage more than the total audit trail storage (50-90% range that can be defined by the authorized administrator, default value of exceeding the threshold: 90%) ]. 5.1.1.7 FAU_STG.4 Prevention of audit data loss Hierarchical to No other components Dependencies FAU_STG.1 Protected audit trail storage FAU_STG.4.1 The TSF shall ignore audited events and [ send a warning email to the authorized administrator ] if the audit trail is full. 46 / 86 5.1.2 Cryptographic support (FCS) 5.1.2.1 FCS_CKM.1 Cryptographic key generation Hierarchical to No other components Dependencies [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [ “Cryptographic algorithm” in [Table 4] List of cryptographic key generation standards ] and specified cryptographic key size [ “Cryptographic key size” in [Table 4] List of cryptographic key generation standards ] that meet the following [ “Reference standard” in [Table 4] List of cryptographic key generation standards ]. [Table 4] List of cryptographic key generation standards Usage Cryptographic algorithm Cryptographic key size Reference standard KEK (Key Encrypt Key) PBKDF2 (SHA-256) 128 bit TTAK.KO-12.0334 DEK (Data Encrypt Key) HASH_DRBG (SHA-256) 128 bit ISO/IEC 18031 Authentication token encrypting/decrypting key HASH_DRBG (SHA-256) 128 bit ISO/IEC 18031 Transmission information encrypting/decrypting key HASH_DRBG (SHA-256) 128 bit ISO/IEC 18031 Server Certificate Public / Private Key Pair for Cryptography RSA Public key 2048 bit ISO/IEC 18033-2 Server Certificate Public / Private key pair for Signing RSA Public key 2048 bit ISO/IEC 18033-2 5.1.2.2 FCS_CKM.2 Cryptographic key distribution Hierarchical to No other components Dependencies [FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2 Import of user data with security attributes or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [ “Cryptographic key distribution method” in [Table 5] List of cryptographic key distribution standards ] that meets the following [ “Reference standard” in [Table 5] List of cryptographic key distribution 47 / 86 standards ]. [Table 5] List of cryptographic key distribution standards Usage Cryptographic algorithm Cryptographic key size Reference standard Public key cryptography RSAES (SHA-256) Public key 2048 bits ISO/IEC 18033-2 Cryptographic key distribution method - Distribution by encrypting an encryption key for the information transmitted between the SSO Server and the SSO Agent with the public key of the other server 5.1.2.3 FCS_CKM.4 Cryptographic key destruction Hierarchical to No other components Dependencies [FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2 Import of user data with security attributes or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [ “Method” in [Table 6] List of cryptographic key destruction ] that meets the following [ “Usage” in [Table 6] List of cryptographic key destruction ]. [Table 6] List of cryptographic key destruction Usage Method Cryptographic key size Reference standard Cryptographic key destruction Overwriting with '0' (0x30) - - 암호키 파기 기능 - Destruction of a symmetric key used for KEK (Key Encrypt Key) - Destruction of a symmetric key used for DEK (Data Encrypt Key) - Destruction of a symmetric key used for encryption of authentication tokens - Destruction of a symmetric key used for encryption of the information transmitted between the SSO Server and the SSO Agent 5.1.2.4 FCS_COP.1 Cryptographic operation Hierarchical to No other components Dependencies [FDP_ITC.1 Import of user data without security attributes or FDP_ITC.2 Import of user data with security attributes or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction 48 / 86 FCS_COP.1.1 The TSF shall perform [ “Function of cryptographic operation” in [Table 7] List of cryptographic operation standards ] in accordance with a specified cryptographic algorithm [ “Cryptographic algorithm” in [Table 7] List of cryptographic operation standards ] and cryptographic key sizes [ “Cryptographic key size” in [Table 7] List of cryptographic operation standards ] that meet the following [ “Reference standard” in [Table 7] List of cryptographic operation standards ]. [Table 7] List of cryptographic operation standards Usage Cryptographic algorithm Cryptographic key size Reference standard KEK Generation, Message authentication code HMAC (SHA-256) 256 bits ISO/IEC 9797-2 Function of cryptographic operation - Generation of a symmetric key used for KEK (Key Encrypt Key) - Integrity verification of the TOE Usage Cryptographic algorithm Cryptographic key size Reference standard Hash SHA-256 - ISO/IEC 10118-3 Function of cryptographic operation - Integrity verification of authentication tokens - Integrity verification of TSF data - Encryption of administrator and end user passwords Usage Cryptographic algorithm Cryptographic key size Reference standard Block cipher (symmetric key cryptography) SEED/CBC 128 bits TTAS.KO-12.0004/R1 Function of cryptographic operation - Encryption/decryption of DEK (Data Encrypt Key) - Encryption/decryption of TSF data - Encryption/decryption of authentication tokens - Encryption/decryption of the information transmitted between the SSO Server and the SSO Agent Usage Cryptographic algorithm Cryptographic key size Reference standard Public key cryptography RSAES (SHA-256) Public key 2048 bits ISO/IEC 18033-2 Function of cryptographic operation - Encryption of a symmetric key used for encryption of authentication tokens - Encryption of a symmetric key used for encryption of the information transmitted between the SSO sever and the SSO Agent Usage Cryptographic algorithm Cryptographic key size Reference standard Digital signature RSA-PSS (SHA-256) Public key 2048 bits ISO/IEC 14888-2 49 / 86 Function of cryptographic operation - Digital signature/verification of the information transmitted between the SSO Server and the SSO Agent 5.1.2.5 FCS_RBG.1 Random bit generation (extended) Hierarchical to No other components Dependencies No dependencies FCS_RBG.1.1 The TSF shall generate random bits required to generate a cryptographic key using the specified random bit generator that meets the following [ “Reference standard” in [Table 8] List of random bit generation standards ]. [Table 8] List of random bit generation standards Usage Cryptographic algorithm Cryptographic key size Reference standard Random bit generation HASH_DRBG (SHA-256) - ISO/IEC 18031 50 / 86 5.1.3 Identification and authentication (FIA) 5.1.3.1 FIA_AFL.1(1) Authentication failure handling (administrator) Hierarchical to No other components Dependencies FIA_UAU.1 Timing of authentication FIA_AFL.1.1 The TSF shall detect when [5], a positive number within [1 to 5] that can be configured by the administrator unsuccessful authentication attempts occur related to [ authentication attempt in the TOE by the authorized administrator ]. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the TSF shall [ inactivate the relevant administrator’s authentication function for the period configurable by the authorized administrator (positive integer number between 5 and 10, default value: 5 minutes), send a warning email to the authorized administrator ]. 5.1.3.2 FIA_AFL.1(2) Authentication failure handling (end user) Hierarchical to No other components Dependencies FIA_UAU.1 Timing of authentication FIA_AFL.1.1 The TSF shall detect when [5], a positive number within [1 to 5] that can be configured by the administrator unsuccessful authentication attempts occur related to [ authentication attempt in the TOE by the end user ]. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met, the TSF shall [ inactivate the authentication function of the relevant end user so that the user cannot log in any longer until the administrator unlocks ]. 5.1.3.3 FIA_IMA.1 TOE internal mutual authentication (extended) Hierarchical to No other components Dependencies No dependencies FIA_IMA.1.1 The TSF shall perform mutual authentication through [ the authentication protocol implemented by Dream Security Co.,Ltd. (digital signature using the validated cryptographic module, verification) ] that meets [ None ] between [ the SSO Server and the SSO Agent ]. 51 / 86 5.1.3.4 FIA_SOS.1 Verification of secrets Hierarchical to No other components Dependencies No dependencies FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [ [Table 9] Password security criteria ]. [Table 9] Password security criteria Criteria valid Issues 9 ~ 16 digits length English alphabet lowercase letters, English alphabet uppercase letters, numbers, special characters(!, @, #, $, %, ^, *, +, =, -) Include at least one each prohibited item Do not set the same password as the user account (ID) Do not enter consecutive repetitions of the same characters and numbers Prohibiting sequential input of consecutive letters or numbers on the keyboard Do not reuse the previously used password 5.1.3.5 FIA_SOS.2 Generation of secrets Hierarchical to No other components Dependencies No dependencies FIA_SOS.2.1 The TSF shall provide a mechanism to generate an authentication token that meets [ the acceptable standard defined below ]. [ a) Subject that generates an authentication token: SSO Server b) Authentication token components: User ID, user name, authentication time (time stamp), Validity of certification, previous login IP, previous login time, current login IP, current login time, Log in check cycle, session inactivity period, password failure allowed, password expiration date, password expiration warning, password change number of days, Login Type, integrity value c) Cryptographic algorithm of an authentication token: Refer to the algorithm in [Table 7] List of cryptographic operation standards d) Integrity algorithm of an authentication token: Refer to the algorithm in [Table 9] List of cryptographic operation standards ] 52 / 86 FIA_SOS.2.2 The TSF shall be able to enforce the use of TSF-generated authentication tokens for [ Single Sign On of end user ]. 5.1.3.6 FIA_SOS.3 Destruction of secrets (extended) Hierarchical to No other components Dependencies FIA_SOS.2 Generation of secrets FIA_SOS.3.1 The TSF shall destroy authentication tokens in accordance with a specified authentication token destruction method [ overwrite 3 times with “0” value ] that meets the following [ None ]. 5.1.3.7 FIA_UAU.2 User authentication before any action Hierarchical to FIA_UAU.1 Timing of authentication Dependencies FIA_UID.1 Timing of identification FIA_UAU.2.1 The TSF shall require the user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of the user. 5.1.3.8 FIA_UAU.4(1) Single-use authentication mechanism (administrator) Hierarchical to No other components Dependencies No dependencies FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to [ password-based authentication mechanism ]. 5.1.3.9 FIA_UAU.4(2) Single-use authentication mechanism (end user) Hierarchical to No other components Dependencies No dependencies FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to [ password-based authentication mechanism, authentication token-based authentication mechanism ]. 53 / 86 5.1.3.10 FIA_UAU.7 Protected authentication feedback Hierarchical to No other components Dependencies FIA_UAU.1 Timing of authentication FIA_UAU.7.1 The TSF shall provide only [ the following list of feedback ] to the user while the authentication is in progress. [ a) Passwords being entered are masked (character “●”) b) In case of failed authentication, feedback on the reason for the failure is not provided but feedback is provided with the statement, “authentication failed” ] 5.1.3.11 FIA_UID.2 User identification before any action Hierarchical to FIA_UID.1 Identification Dependencies No dependencies FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. 54 / 86 5.1.4 Security management (FMT) 5.1.4.1 FMT_MOF.1 Management of security functions behavior Hierarchical to No other components Dependencies FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MOF.1.1 The TSF shall restrict the ability to conduct management actions of the functions in [ “List of functions” in [Table 10] List of security functions behavior ] to the [ authorized administrator ]. [Table 10] List of security functions behavior List of functions Management behavior Authorized administrator Audit information viewing Determine behaviors Super administrator, monitoring administrator Module verification in real time Determine, modify behaviors Super administrator Audit information setting Determine, modify behaviors Super administrator Mail notification setting Determine, modify behaviors Super administrator Agent management Determine, modify behaviors Super administrator User management Determine, modify behaviors Super administrator User policy establishment Determine, modify behaviors Super administrator User unlocking Determine, modify behaviors Super administrator Administrator management Determine, modify behaviors Super administrator Administrator policy establishment Determine, modify behaviors Super administrator Administrator password change Determine, modify behaviors Super administrator, monitoring administrator Version information viewing Determine behaviors Super administrator, monitoring administrator 5.1.4.2 FMT_MTD.1 Management of TSF data Hierarchical to No other components Dependencies FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_MTD.1.1 The TSF shall restrict the ability to manage [ “List of data” in [Table 11] List of TSF data] to [ the authorized administrator ]. [Table 11] List of TSF data List of data Management Authorized administrator Audit information Query Super administrator, 55 / 86 monitoring administrator Audit storage capacity threshold Query, modify Super administrator Cycle of integrity verification of cryptographic module and SSO module Query, modify Super administrator Mail server information Query, modify Super administrator Mail sending information Query, modify Super administrator Agent information Query, modify Super administrator User information Query, modify Super administrator User policy information Query, modify Super administrator Administrator information Query, modify Super administrator Administrator policy establishment Query, modify Super administrator 5.1.4.3 FMT_PWD.1 Management of ID and password (extended) Hierarchical to No other components Dependencies FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles FMT_PWD.1.1 The TSF shall restrict the ability to manage [ None ] to the [ authorized administrator ]. 1. [ None ] 2. [ None ] FMT_PWD.1.2 The TSF shall restrict the ability to manage ID of [ None ] to the [ authorized administrator ]. 1. [ None ] 2. [ None ] FMT_PWD.1.3 The TSF shall provide the capability for changing the password when the authorized administrator accesses for the for the first time. 5.1.4.4 FMT_SMF.1 Specification of management functions Hierarchical to No other components Dependencies No dependencies FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [ list of management functions to be provided by the TSF ] 56 / 86 [ a) List of security functions specified in FMT_MOF.1 b) List of TSF data management specified in FMT_MTD.1 c) List of functions specified in FMT_PWD.1 ] 5.1.4.5 FMT_SMR.1 Security roles Hierarchical to No other components Dependencies FIA_UID.1 Timing of identification FMT_SMR.1.1 The TSF shall maintain the roles [ the following authorized roles ]. [ a) Roles of super administrator Audit information viewing Module verification in real time Audit information setting Mail notification setting User unlocking User policy establishment Administrator management Administrator policy establishment Administrator password change Version information b) Roles of monitoring administrator Audit information viewing Administrator password change Version information ] FMT_SMR.1.2 The TSF shall be able to associate users with roles defined in FMT_SMR.1.1. 57 / 86 5.1.5 Protection of the TSF (FPT) 5.1.5.1 FPT_ITT.1 Basic internal TSF data transfer protection Hierarchical to No other components Dependencies No dependencies FPT_ITT.1.1 The TSF shall protect TSF data from disclosure, modification when it is transmitted between separate parts of the TOE. 5.1.5.2 FPT_PST.1 Basic protection of stored TSF data (extended) Hierarchical to No other components Dependencies No dependencies FPT_PST.1.1 The TSF shall protect [ the following TSF data ] stored in the containers controlled by the TSF from unauthorized disclosure, modification. [ a) Administrator and end user password b) Authentication token c) Cryptographic key d) DBMS account information e) Server certificate password f) Policy establishment information g) Configuration information ] 5.1.5.3 FPT_RCV.1 Manual Recovery Hierarchical to No other components Dependencies AGD_OPE.1 User Operation Manual FPT_RCV.1.1 [ Agent's settings, executable file modification ], the TSF must be in a management mode that provides the function to return the TOE to a safe state. 5.1.5.4 FPT_TST.1 TSF testing Hierarchical to No other components Dependencies No dependencies 58 / 86 FPT_TST.1.1 The TSF shall run a suite of self-tests during initial start-up, periodically during normal operation, upon request of authorized administrators to demonstrate the correct operation of the TSF. FPT_TST.1.2 The TSF shall provide authorized administrators with the capability to verify the integrity of TSF data. FPT_TST.1.3 The TSF shall provide authorized administrators with the capability to verify the integrity of TSF. 59 / 86 5.1.6 TOE access (FTA) 5.1.6.1 FTA_MCS.2 Per user attribute limitation on multiple concurrent sessions Hierarchical to FTA_MCS.1 Basic limitation on multiple concurrent sessions Dependencies FIA_UID.1 Timing of identification FTA_MCS.2.1 The TSF shall restrict the maximum number of concurrent sessions that belong to the same user according to the rules [ Limit the maximum number of concurrent sessions for the same user and users with the same privileges to 1, [Unlimited number of concurrent sessions for monitoring administrators with the same privileges] ]. FTA_MCS.2.2 The TSF shall enforce, by default, a limit of [ 1 ] session per user. 5.1.6.2 FTA_SSL.3 Termination of a session by TSF Hierarchical to No other components Dependencies No dependencies FTA_SSL.3.1 The TSF shall terminate an interactive session after [ the period of user inactivity (administrator configurable positive integer between 3 and 10, default value: 10 minutes) ]. 5.1.6.3 FTA_TSE.1 TOE session establishment Hierarchical to No other components Dependencies No dependencies FTA_TSE.1.1 The TSF shall be able to deny administrator’s management access session establishment based on [ access IP, [whether to activate the management access session of the same account and administrator account with the same privilege] ]. 60 / 86 5.2 Security assurance requirements Security assurance requirements of this ST are composed of assurance components in CC Part 3 and the evaluation assurance level is EAL1+. [Table 12] below summarizes assurance components. [Table 12] Assurance requirements Assurance class Assurance component Security Target evaluation ASE_INT.1 ST introduction ASE_CCL.1 Conformance claims ASE_OBJ.1 Security objectives for the operational environment ASE_ECD.1 Extended components definition ASE_REQ.1 Stated security requirements ASE_TSS.1 TOE summary specification Development ADV_FSP.1 Basic functional specification Guidance documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures Life-cycle support ALC_CMC.1 Labelling of the TOE ALC_CMS.1 TOE configuration management coverage Tests ATE_FUN.1 Functional testing ATE_IND.1 Independent testing: conformance Vulnerability assessment AVA_VAN.1 Vulnerability survey 5.2.1 Security Target evaluation 5.2.1.1 ASE_INT.1 Security Target evaluation Dependencies: No dependencies Developer action elements ASE_INT.1.1D The developer shall provide a ST introduction. Content and presentation elements ASE_INT.1.1C The ST introduction shall contain a ST reference, a TOE reference, a TOE overview and a TOE description. ASE_INT.1.2C The ST reference shall uniquely identify the ST. ASE_INT.1.3C The TOE reference shall uniquely identify the TOE. ASE_INT.1.4C The TOE overview shall summarize the usage and major security features of the TOE. ASE_INT.1.5C The TOE overview shall identify the TOE type. 61 / 86 ASE_INT.1.6C The TOE overview shall identify any non-TOE hardware/software/firmware required by the TOE. ASE_INT.1.7C The TOE description shall describe the physical scope of the TOE. ASE_INT.1.8C The TOE description shall describe the logical scope of the TOE. Evaluator action elements ASE_INT.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ASE_INT.1.2E The evaluator shall confirm that the TOE reference, the TOE overview and the TOE description are consistent with each other. 5.2.1.2 ASE_CCL.1 Conformance claims Dependencies: ASE_INT.1 ST introduction ASE_ECD.1 Extended components definition ASE_REQ.1 Stated security requirements Developer action elements ASE_CCL.1.1D The developer shall provide a conformance claim. ASE_CCL.1.2D The developer shall provide a conformance claim rationale. Content and presentation elements ASE_CCL.1.1C The conformance claim shall contain a CC conformance claim that identifies the version of the CC to which the ST and the TOE claim conformance. ASE_CCL.1.2C The CC conformance claim shall describe the conformance of the ST to CC Part 2 as either CC Part 2 conformant or CC Part 2 extended. ASE_CCL.1.3C The CC conformance claim shall describe the conformance of the ST to CC Part 3 as either CC Part 3 conformant or CC Part 3 extended. ASE_CCL.1.4C The CC conformance claim shall be consistent with the extended components definition. ASE_CCL.1.5C The conformance claim shall identify all PPs and security requirement packages to which the ST claims conformance. ASE_CCL.1.6C The conformance claim shall describe any conformance of the ST to a package as either package-conformant or package-augmented. ASE_CCL.1.7C The conformance claim rationale shall demonstrate that the TOE type is 62 / 86 consistent with the TOE type in the PPs for which conformance is being claimed. ASE_CCL.1.8C The conformance claim rationale shall demonstrate that the statement of the security problem definition is consistent with the statement of the security problem definition in the PPs for which conformance is being claimed. ASE_CCL.1.9C The conformance claim rationale shall demonstrate that the statement of security objectives is consistent with the statement of security objectives in the PPs for which conformance is being claimed. ASE_CCL.1.10C The conformance claim rationale shall demonstrate that the statement of security requirements is consistent with the statement of security requirements in the PPs for which conformance is being claimed. Evaluator action elements ASE_CCL.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.2.1.3 ASE_OBJ.1 Security objectives for the operational environment Dependencies: No dependencies Developer action elements ASE_OBJ.1D The developer shall provide a statement of security objectives. Content and presentation elements ASE_OBJ.1C The statement of security objectives shall describe the security objectives for the operational environment. Evaluator action elements ASE_OBJ.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation evidence. 5.2.1.4 ASE_ECD.1 Extended components definition Dependencies: No dependencies Developer action elements ASE_ECD.1.1D The developer shall provide a statement of security requirements. ASE_ECD.1.2D The developer shall provide an extended components definition. Content and presentation elements 63 / 86 ASE_ECD.1.1C The statement of security requirements shall identify all extended security requirements. ASE_ECD.1.2C The extended components definition shall define an extended component for each extended security requirement. ASE_ECD.1.3C The extended components definition shall describe how each extended component is related to the existing CC components, families, and classes. ASE_ECD.1.4C The extended components definition shall use the existing CC components, families, classes, and methodology as a model for presentation. ASE_ECD.1.5C The extended components shall consist of measurable and objective elements such that conformance or nonconformance to these elements can be demonstrated. Evaluator action elements ASE_ECD.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ASE_ECD.1.2E The evaluator shall confirm that no extended component can be clearly expressed using existing components. 5.2.1.5 ASE_REQ.1 Stated security requirements 종속관계 : ASE_ECD.1 Extended components definition Developer action elements ASE_REQ.1.1D The developer shall provide a statement of security requirements. ASE_REQ.1.2D The developer shall provide a security requirements rationale. Content and presentation elements ASE_REQ.1.1C The statement of security requirements shall describe the SFRs and the SARs. ASE_REQ.1.2C All subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs shall be defined. ASE_REQ.1.3C The statement of security requirements shall identify all operations on the security requirements. ASE_REQ.1.4C All operations shall be performed correctly. ASE_REQ.1.5C Each dependency of the security requirements shall either be satisfied, or the security requirements rationale shall justify the dependency not being satisfied. 64 / 86 ASE_REQ.1.6C The statement of security requirements shall be internally consistent. Evaluator action elements ASE_REQ.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.2.1.6 ASE_TSS.1 TOE summary specification Dependencies: ASE_INT.1 ST introduction ASE_REQ.1 Stated security requirements ADV_FSP.1 Basic functional specification Developer action elements ASE_TSS.1.1D The developer shall provide a TOE summary specification. Content and presentation elements ASE_TSS.1.1C The TOE summary specification shall describe how the TOE meets each SFR. Evaluator action elements ASE_TSS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ASE_TSS.1.2E The evaluator shall confirm that the TOE summary specification is consistent with the TOE overview and the TOE description. 5.2.2 Development 5.2.2.1 ADV_FSP.1 Security-enforcing functional specification Dependencies: No dependencies Developer action elements ADV_FSP.1.1D The developer shall provide a functional specification. ADV_FSP.1.2D The developer shall provide a tracing from the functional specification to the SFRs. Content and presentation elements ADV_FSP.1.1C The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI. ADV_FSP.1.2C The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI. 65 / 86 ADV_FSP.1.3C The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering. ADV_FSP.1.4C The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. Evaluator action elements ADV_FSP.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_FSP.2.2E The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. 5.2.3 Guidance documents 5.2.3.1 AGD_OPE.1 Operational user guidance Dependencies: ADV_FSP.1 Basic functional specification Developer action elements AGD_OPE.1.1D The developer shall provide operational user guidance. Content and presentation elements AGD_OPE.1.1C The operational user guidance shall describe, for each user role, the user- accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings AGD_OPE.1.2C The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner. AGD_OPE.1.3C The operational user guidance shall describe, for each user role, the available functions and interfaces, particularly all security parameters under the control of the user, indicating secure values as appropriate. AGD_OPE.1.4C The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. AGD_OPE.1.5C The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation. AGD_OPE.1.6C The operational user guidance shall, for each user role, describe the security 66 / 86 measures to be followed to fulfil the security objectives for the operational environment as described in the ST. AGD_OPE.1.7C The operational user guidance shall be clear and reasonable. Evaluator action elements AGD_OPE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.2.3.2 AGD_PRE.1 Preparative procedures Dependencies: No dependencies Developer action elements AGD_PRE.1.1D The developer shall provide the TOE including its preparative procedures. Content and presentation elements AGD_PRE.1.1C The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures. AGD_PRE.1.2C The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST. Evaluator action elements AGD_PRE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AGD_PRE.1.2E The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation. 5.2.4 Life-cycle support 5.2.4.1 ALC_CMC.1 Labelling of the TOE Dependencies: ALC_CMS.1 TOE CM coverage Developer action elements ALC_CMC.1.1D The developer shall provide the TOE and a reference for the TOE. Content and presentation elements 67 / 86 ALC_CMC.1.1C The TOE shall be labelled with its unique reference. Evaluator action elements ALC_CMC.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.2.4.2 ALC_CMS.1 TOE CM coverage Dependencies: No dependencies Developer action elements ALC_CMS.1.1D The developer shall provide a configuration list for the TOE. Content and presentation elements ALC_CMS.1.1C The configuration list shall include the followings: the TOE itself; and the evaluation evidence required by the SARs. ALC_CMS.1.2C The configuration list shall uniquely identify the configuration items. Evaluator action elements ALC_CMS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.2.5 Tests 5.2.5.1 ATE_FUN.1 Functional testing Dependencies: ATE_COV.1 Evidence of coverage Developer action elements ATE_FUN.1.1D The developer shall test the TSF and document the results. ATE_FUN.1.2D The developer shall provide test documentation. Content and presentation elements ATE_FUN.1.1C The test documentation shall consist of test plans, expected test results and actual test results. ATE_FUN.1.2C The test plans shall identify the tests to be performed and describe the scenarios for performing each test. These scenarios shall include any ordering dependencies on the results of other tests. ATE_FUN.1.3C The expected test results shall show the anticipated outputs from a successful 68 / 86 execution of the tests. ATE_FUN.1.4C The actual test results shall be consistent with the expected test results. Evaluator action elements ATE_FUN.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 5.2.5.2 ATE_IND.1 Independent testing: conformance Dependencies: ADV_FSP.1 Basic functional specification AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures Developer action elements ATE_IND.1.1D The developer shall provide the TOE for testing. Content and presentation elements ATE_IND.1.1C The TOE shall be suitable for testing. Evaluator action elements ATE_IND.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_IND.1.2E The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. 5.2.6 Vulnerability assessment 5.2.6.1 AVA_VAN.1 Vulnerability survey Dependencies: ADV_FSP.1 Basic functional specification AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures Developer action elements AVA_VAN.1.1D The developer shall provide the TOE for testing. Content and presentation elements AVA_VAN.1.1C The TOE shall be suitable for testing. Evaluator action elements AVA_VAN.1.1E The evaluator shall confirm that the information provided meets all 69 / 86 requirements for content and preparation of evidence. AVA_VAN.1.2E The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE. AVA_VAN.1.3E The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker processing Basic attack potential. 70 / 86 5.3 Security requirements rationale Security requirements rationale demonstrates that the SFRs described are suitable to satisfy the security objectives and consequently, appropriate to address the security problem. 5.3.1 Dependency of the SFRs The following table shows dependency of security functional requirements. [Table 13] Dependency rationale No. Security functional requirements dependency Reference standard 1 FAU_ARP.1 FAU_SAA.1 3 2 FAU_GEN.1 FPT_STM.1 OE.Time Stamp 3 FAU_SAA.1 FAU_GEN.1 2 4 FAU_SAR.1 FAU_GEN.1 2 5 FAU_SAR.3 FAU_SAR.1 4 6 FAU_STG.3 FAU_STG.1 OE.DBMS 7 FAU_STG.4 FAU_STG.1 OE.DBMS 8 FCS_CKM.1 FCS_CKM.2 or FCS_COP.1 9, 11 FCS_CKM.4 10 9 FCS_CKM.2 FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 8 FCS_CKM.4 10 10 FCS_CKM.4 FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 8 11 FCS_COP.1 FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1 8 FCS_CKM.4 10 12 FCS_RBG.1 - - 13 FIA_AFL.1(1) FIA_UAU.1 19 14 FIA_AFL.1(2) FIA_UAU.1 19 15 FIA_IMA.1 - - 16 FIA_SOS.1 - - 17 FIA_SOS.2 - - 18 FIA_SOS.3 FIA_SOS.2 17 19 FIA_UAU.2 FIA_UID.1 23 20 FIA_UAU.4(1) - - 21 FIA_UAU.4(2) - - 22 FIA_UAU.7 FIA_UAU.1 19 23 FIA_UID.2 - - 24 FMT_MOF.1 FMT_SMF.1 27 71 / 86 FMT_SMR.1 28 25 FMT_MTD.1 FMT_SMF.1 27 FMT_SMR.1 28 26 FMT_PWD.1 FMT_SMF.1 27 FMT_SMR.1 28 27 FMT_SMF.1 - - 28 FMT_SMR.1 FIA_UID.1 23 29 FPT_ITT.1 - - 30 FPT_PST.1 - - 31 FPT_RCV.1 AGD_OPE.1 - 32 FPT_TST.1 - - 33 FTA_MCS.2 FIA_UID.1 23 34 FTA_SSL.3 - - 35 FTA_TSE.1 - - FAU_GEN.1 has a dependency on FPT_STM.1. However, the TOE uses reliable time stamps provided in the TOE operational environment and accurately records audit data related to the operation of the TOE. Thus, the dependency of FAU_GEN.1 is satisfied by OE. Time Stamp, which is the security objective for the operational environment, on behalf of FPT_STM.1. FAU_STG.3 and FAU_STG.4 have a dependency on FAU_STG.1. However, the TOE uses reliable DBMS provided in the TOE operational environment to store audit data related to the operation of the TOE and ensures that audit data are protected from unauthorized deletion or modification. Thus, the dependency of FAU_STG.3 and FAU_STG.4 is satisfied by OE.DBMS, which is the security objective for the operational environment, on behalf of FAU_STG.1. FIA_AFL.1(1) has a dependency on FIA_UAU.1, which is satisfied by FIA_UAU.2 hierarchical to FIA_UAU.1. FIA_AFL.1(2) has a dependency on FIA_UAU.1, which is satisfied by FIA_UAU.2 hierarchical to FIA_UAU.1. FIA_UAU.2 has a dependency on FIA_UID.1, which is satisfied by FIA_UID.2 hierarchical to FIA_UID.1. FIA_UAU.7 has a dependency on FIA_UAU.1, which is satisfied by FIA_UAU.2 hierarchical to FIA_UAU.1. FMT_SMR.1 has a dependency on FIA_UID.1, which is satisfied by FIA_UID.2 hierarchical to FIA_UID.1. 72 / 86 FTA_MCS.2 has a dependency on FIA_UID.1, which is satisfied by FIA_UID.2 hierarchical to FIA_UID.1. FTA_SSL.3 has a dependency on AGD_OPE.1. 5.3.2 Dependency rationale of security assurance requirements As the dependency of EAL1 assurance package provided in the CC is already satisfied, the rationale is omitted herein. The augmented SAR ATE_FUN.1 has a dependency on ATE_COV.1. ATE_FUN.1 has been augmented to ensure that the developer performs tests on test items correctly and documents them in the test documentation. However, ATE_COV.1 is not included in this ST since it is deemed not necessarily required to include ATE_COV.1 that presents the consistency between test items and TSFI. 73 / 86 6 TOE summary specification This chapter summarizes security functionality required by the TOE. The table below is the list of security functions specified in the TOE summary specification. [Table 14] Security functional requirements Security functional class Security functional component Security audit (FAU) FAU_ARP.1 Security alarms FAU_GEN.1 Audit data generation FAU_SAA.1 Potential violation analysis FAU_SAR.1 Audit review FAU_SAR.3 Selectable audit review FAU_STG.3 Action in case of possible audit data loss FAU_STG.4 Prevention of audit data loss Cryptographic support (FCS) FCS_CKM.1 Cryptographic key generation FCS_CKM.2 Cryptographic key distribution FCS_CKM.4 Cryptographic key destruction FCS_COP.1 Cryptographic operation FCS_RBG.1(extended) Random bit generation Identification and authentication (FIA) FIA_AFL.1(1) Authentication failure handling(administrator) FIA_AFL.1(2) Authentication failure handling(end-user) FIA_IMA.1(extended) TOE Internal mutual authentication FIA_SOS.1 Verification of secrets FIA_SOS.2 TSF Generation of secrets FIA_SOS.3(extended) Destruction of secrets FIA_UAU.2 Authenticated the user before all behavior FIA_UAU.4(1) Single-use authentication mechanisms(administrator) FIA_UAU.4(2) Single-use authentication mechanisms(End-user) FIA_UAU.7 Protected authentication feedback FIA_UID.2 Identification the user before all behavior Security management (FMT) FMT_MOF.1 Management of security functions behavior FMT_MTD.1 Management of TSF data FMT_PWD.1(extended) Management of ID and password FMT_SMF.1 Specification of management functions FMT_SMR.1 Security roles Protection of the TSF (FPT) FPT_ITT.1 Basic internal TSF data transfer protection FPT_PST.1(extended) Basic protection of stored TSF data FPT_RCV.1 Manual Recovery 74 / 86 FPT_TST.1 TSF testing TOE access (FTA) FTA_MCS.2 Per user attribute limitation on multiple concurrent sessions FTA_SSL.3 Locking or termination of interactive session FTA_TSE.1 TOE session establishment 6.1 Security audit All the audit data generated during the operation of the TOE are collected by and stored in the SSO Server. As to auditable events of the TOE, audit data are generated regarding the start-up and the termination of the audit function, and “auditable events” and “additional audit information” in [Table 15] Auditable events. [Table 15] Auditable events Security functional component Auditable event Additional audit information FAU_ARP.1 Actions taken due to potential security violations FAU_SAA.1 Enabling and disabling of any of the analysis mechanisms, Automated responses performed by the tool FAU_STG.3 Actions taken due to exceeding of a threshold FAU_STG.4 Actions taken due to the audit storage failure FCS_CKM.1 Success and failure of the activity FCS_CKM.2 Success and failure of the activity (applied only to the distribution of a key related to encryption/decryption of TSF data) FCS_CKM.4 Success and failure of the activity (applied only to the destruction of a key related to encryption/decryption of TSF data) FCS_COP.1 Success and failure of cryptographic operation, and the type of cryptographic operation (applied only to items related to issuance, storage, verification and deletion of authentication token) FIA_AFL.1(1) The reaching of the threshold for the unsuccessful authentication attempts and the actions taken and the subsequent, if appropriate, restoration to the normal state FIA_AFL.1(2) The reaching of the threshold for the unsuccessful 75 / 86 authentication attempts and the actions taken and the subsequent, if appropriate, restoration to the normal state FIA_SOS.2 Rejection by the TSF of any tested secret FIA_SOS.3(extended) Success and failure of the activity (applied only to destruction of SSO authentication token) FIA_UAU.2 All use of the user authentication mechanism FIA_UAU.4(1) Single-use authentication mechanism(Admin) FIA_UAU.4(2) Single-use authentication mechanism(end user) FIA_UID.2 All use of the user identification mechanism FMT_MOF.1 All modifications in the behavior of the functions in the TSF FMT_MTD.1 All modifications to the values of TSF data Modified values of TSF data FMT_PWD.1(extended) All changes of the password FMT_SMF.1 Use of management functions FMT_SMR.1 Modifications to the user group of rules divided FPT_TST.1 Execution of the TSF self-tests and the results of the tests The validated cryptographic module self-test failure data, Modified TSF data or execution code in case of integrity violation, The process validation failure data FTA_MCS.2 Denial of a new session based on the limitation of multiple concurrent sessions FTA_SSL.3 Locking or termination of interactive sessions FTA_TSE.1 Denial of a session establishment due to the session establishment mechanism All attempts at establishment of a user session Audit data generated by the TOE record the date and time of an event, the type of an event, subject identity, an outcome (success or failure) of an event and further details. The authorized administrator can review the audit data through the Web UI (Audit Information>Audit information View menu) and search the audit data according to the date and time of an event, the type of an event and an outcome of an event. Search results of the audit data are sorted and displayed in the descending order based on the time and date of events. The function of modifying/deleting the audit data is not provided. 76 / 86 If the storage where the audit data are stored exceeds the threshold defined by the administrator (define an integer number between 50 and 90, default value: 90, unit: %), a warning message is sent to the administrator via email. Also, if the audit data storage is full, the audited event data are ignored and a warning message is sent to the administrator via email. Furthermore, a “security violation” in [Table 16] Actions against security violations below is detected and an “action” in [Table 16] Actions against security violations below is performed. [Table 16] Actions against security violations Security functional component Security violation Action FIA_AFL.1(1) - In case administrator authentication attempts fail consecutively for a defined number of times (default value: 5 times) - Inactivate the authentication function for a defined period (default value: 5 minutes) - Send a warning message email to the authorized administrator FIA_AFL.1(2) - In case end user authentication attempts fail consecutively for a defined number of times (default value: 5 times) - Inactivate the authentication function until the authorized administrator unlock the account FPT_TST.1 Self-test when TSF is driven - In case a self-test of the validated cryptographic module fails - In case the integrity verification fails - In case the process validation fails Periodic self-examination - In case a self-test of the validated cryptographic module fails - In case the integrity verification fails - In case the process validation fails Self-test by administrator - In case a self-test of the validated cryptographic module fails - In case the integrity verification fails - Inactivate the authentication function until the authorized administrator unlock the account - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator - Send a warning message email to the authorized administrator 77 / 86 - In case the process validation fails - Send a warning message email to the authorized administrator FAU_STG.3 - In case the audit trail exceeds the threshold (default value: 90%) - Send a warning message email to the authorized administrator FAU_STG.4 - In case the audit trail is full - Ignore an audited event - Send a warning message email to the authorized administrator Relevant SFR : FAU_ARP.1, FAU_GEN.1, FAU_SAA.1, FAU_SAR.1, FAU_SAR.3, FAU_STG.3, FAU_STG.4 6.2 Cryptographic support The TOE uses [Table 17] TOE use a validated cryptographic module. The TOE generates/distributes cryptographic keys and performs cryptographic operations in accordance with a cryptographic algorithm and a cryptographic key size specified in [Table 18] List of Cryptographic Algorithm Standards. In addition, it generates random bits required to generate a cryptographic key using a specified random bit generator that meets [Table 18] List of TOE cryptographic algorithm standards. [Table 17] TOE use a validated cryptographic module Encryption module name Validation number Developer Validation date MagicJCrypto V3.0.0 CM-200-2026.12 Dream Security Co.,Ltd. 2021-12-31 [Table 18] TOE List of Cryptographic Algorithms Standards Classification Cryptographic algorithm Encryption key length Reference standard Random bit generation HASH_DRBG (SHA-256) - ISO/IEC 18031 Secure hash algorithm SHA-256 - ISO/IEC 10118-3 Message authentication code HMAC (SHA-256) 256 bit ISO/IEC 9797-2 Symmetric Key Cipher SEED/CBC 128 bit TTAS.KO-12.0004/R1 Public key cipher RSAES (SHA-256) Public key 2048 bit ISO/IEC 18033-2 Digital signatures RSA-PSS (SHA-256) Public key 2048 bit ISO/IEC 14888-2 The TOE generates a cryptographic key when performing “the function of cryptographic key generation” in the following [Table 19] List of Cryptographic Key Generation Standards and generates a cryptographic key in accordance with “cryptographic algorithm” and “cryptographic key size” specified in [Table 19] List of cryptographic key generation standards. 78 / 86 [Table 19] List of Cryptographic Key Generation Standards Usage Cryptographic algorithm Cryptographic key size Reference standard KEK (Key Encrypt Key) PBKDF2 (SHA-256) 128 bit TTAK.KO-12.0334 DEK (Data Encrypt Key) HASH_DRBG (SHA-256) 128 bit ISO/IEC 18031 Authentication token encrypting/decrypting key HASH_DRBG (SHA-256) 128 bit ISO/IEC 18031 Transmission information encrypting/decrypting key HASH_DRBG (SHA-256) 128 bit ISO/IEC 18031 Server Certificate Public / Private Key Pair for Cryptography RSA Public key 2048 bit ISO/IEC 18033-2 Server Certificate Public / Private key pair for Signing RSA Public key 2048 bit ISO/IEC 18033-2 The TOE generates random bits in accordance with the “reference standard” in the following [Table 20] List of random bit generation standards, and generates random bits required to generate a cryptographic key. [Table 20] Random Bit Generation Standard List Usage Cryptographic algorithm Cryptographic key size Reference standard Random bit generation HASH_DRBG (SHA-256) - ISO/IEC 18031 The TOE distributes a cryptographic key when performing “the function of cryptographic key distribution” in the following [Table 21] List of cryptographic key distribution standards and distributes a cryptographic key in accordance with the “reference standard” specified in [Table 21] List of cryptographic key distribution standards. [Table 21] List of cryptographic key distribution standards Usage Cryptographic algorithm Cryptographic key size Reference standard Public key cryptography RSAES (SHA-256) Public key 2048 bits ISO/IEC 18033-2 Cryptographic key distribution method - Distribution by encrypting an encryption key for the information transmitted between the SSO Server and the SSO Agent with the public key of the other server The TOE destroys a cryptographic key when performing “the function of cryptographic key 79 / 86 destruction” in the following [Table 22] List of cryptographic key destruction standards and destroys a cryptographic key in accordance with the “reference standard” specified in [Table 22] List of cryptographic key destruction standards [Table 22] List of cryptographic key destruction standards Usage Method Cryptographic key size Reference standard Cryptographic key destruction Overwrite 3 times with '0' (0x30) - - Function of cryptographic key destruction - Destruction of a symmetric key used for KEK (Key Encrypt Key) (upon the termination of the TOE) - Destruction of a symmetric key used for DEK (Data Encrypt Key) (upon the termination of the TOE) - Destruction of a symmetric key used for encryption of authentication tokens (upon end user logout) - Destruction of a symmetric key used for encryption of the information transmitted between the SSO Server and the SSO Agent (upon the completion of the encrypted transmission, upon the completion of the decryption after the reception) The TOE performs cryptographic operations for a symmetric key when performing “the function of cryptographic operation” in the following [Table 23] List of cryptographic operation standards for symmetric key, and performs cryptographic operations for a symmetric key in accordance with “cryptographic algorithm” and “cryptographic key size” specified in [Table 23] List of cryptographic operation standards for symmetric key. [Table 23] List of cryptographic operation standards Usage Cryptographic algorithm Cryptographic key size Reference standard KEK Generation, Message authentication code HMAC (SHA-256) 256 bits ISO/IEC 9797-2 Function of cryptographic operation - Generation of a symmetric key used for KEK (Key Encrypt Key) - Integrity verification of the TOE Usage Cryptographic algorithm Cryptographic key size Reference standard Hash SHA-256 - ISO/IEC 10118-3 Function of cryptographic operation - Integrity verification of authentication tokens - Integrity verification of TSF data - Encryption of administrator and end user passwords Usage Cryptographic algorithm Cryptographic key size Reference standard 80 / 86 Block cipher (symmetric key cryptography) SEED/CBC 128 bits TTAS.KO-12.0004/R1 Function of cryptographic operation - Encryption/decryption of DEK (Data Encrypt Key) - Encryption/decryption of TSF data - Encryption/decryption of authentication tokens - Encryption/decryption of the information transmitted between the SSO Server and the SSO Agent Usage Cryptographic algorithm Cryptographic key size Reference standard Public key cryptography RSAES (SHA-256) Public key 2048 bits ISO/IEC 18033-2 Function of cryptographic operation - Encryption of a symmetric key used for encryption of authentication tokens - Encryption of a symmetric key used for encryption of the information transmitted between the SSO sever and the SSO Agent Usage Cryptographic algorithm Cryptographic key size Reference standard Digital signature RSA-PSS (SHA-256) Public key 2048 bits ISO/IEC 14888-2 Function of cryptographic operation - Digital signature/verification of the information transmitted between the SSO Server and the SSO Agent Relevant SFR : FCS_CKM.1, FCS_CKM.2, FCS_CKM.4, FCS_COP.1, FCS_RBG.1 6.3 Identification and authentication The TOE performs mutual authentication for the mutual authentication between the SSO Server and the SSO Agent by using a server certificate as specified in [Table 24] Mutual authentication mechanism. [Table 24] Mutual authentication mechanism Classification Cryptographic algorithm Cryptographic key size Reference standard Digital signature/verification RSA-PSS (SHA-256) Public key 2048 bits ISO/IEC 14888-2 Mutual authentication mechanism - When transmitting authentication request information from the SSO Agent to the SSO Server a) The SSO Agent generates a digital signature with the private key of the SSO Agent b) The SSO Server verifies the digital signature with the public key of the SSO Agent - When transmitting authentication information from the SSO Server to the SSO Agent a) The SSO Server generates a digital signature with the private key of the SSO Server b) The SSO Agent verifies the digital signature with the public key of the SSO Server 81 / 86 In TOE, user identification and authentication are performed at once. Information provided through the screen GUI for user identification/authentication is an ID and password, and user identification/authentication is performed using this information. Any action that a user can perform before being identified/authenticated is mutual authentication between the SSO Server and the SSO Agent. After the last successful authentication of the administrator, if authentication attempts fail consecutively for a specified number of times defined by the administrator (default value: 5 times), the TOE inactivates the authentication function and access is denied for a specified period for authentication delay defined by the administrator (default value: 5 minutes). Then, a warning email is sent to the authorized administrator. After the last successful authentication of the end user, if authentication attempts fail consecutively for a specified number of times defined by the administrator (default value: 5 times), the TOE inactivates the authentication function and access is denied until the administrator unlocks the account. TOE provides a mechanism in which password information satisfies the password security criteria in [Table 25] when the administrator creates/changing the password and changes the password of the general user. [Table 25] Password security criteria Criteria valid Issues 9 ~ 16 digits length English alphabet lowercase letters, English alphabet uppercase letters, numbers, special characters(!, @, #, $, %, ^, *, +, =, -) Include at least one each prohibited item Do not set the same password as the user account (ID) Do not enter consecutive repetitions of the same characters and numbers Prohibiting sequential input of consecutive letters or numbers on the keyboard Do not reuse the previously used password After the end user is successfully identified/authenticated, the TOE provides a mechanism to generate an authentication token that meets the following standard. When generating an authentication token, server time information that indicates the uniqueness is encrypted. - Subject that generates an authentication token: SSO Server - Authentication token components: User ID, user name, authentication time (time stamp), Validity of certification, previous login IP, previous login 82 / 86 time, current login IP, current login time, Log in check cycle, session inactivity period, password failure allowed, password expiration date, password expiration warning, password change number of days, Login Type, integrity value - Cryptographic algorithm of an authentication token: Refer to the algorithm in [Table 23] List of cryptographic operation standards - Integrity algorithm of an authentication token: Refer to the algorithm in [Table 23] List of cryptographic operation standards The TOE uses a validated cryptographic module whose security and implementation conformance have been confirmed by the Korea Cryptographic Module Validation Program (KCMVP). - Cryptographic module name : MagicJCrypto V3.0.0 - Verification Number : CM-200-2026.12 - Verification date : 2021-12-31 The TOE destroys an authentication token loaded in the memory upon the termination of the end user session. It destroys an authentication token by overwrite 3 times it with “0”. The TOE prevents the reuse of authentication data related to the access session information of the authorized administrator, as well as the reuse of authentication data related to the information on the access session and authentication token generation of the end user. The TOE provides the following feedback while the administrator/end user authentication is in progress. - Secrets (passwords) being entered are masked (character “●”) - In case of failed authentication, feedback on the reason for the failure is not provided but feedback is provided with the statement, “authentication failed” Relevant SFR : FIA_AFL.1(1), FIA_AFL.1(2), FIA_IMA.1, FIA_SOS.1, FIA_SOS.2, FIA_SOS.3, FIA_UAU.2, FIA_UAU.4(1), FIA_UAU.4(2), FIA_UAU.7, FIA_UID.2 6.4 Security management The TOE provides the authorized administrator with the following [Table 26] List of security functions behavior and [Table 27] List of TSF data. The authorized super administrator can manage 83 / 86 all security functions and the TOE restricts the management function of the authorized monitoring administrator to the monitoring of audit information. [Table 26] List of security functions behavior List of functions Management behavior Authorized administrator Audit information viewing Determine behaviors Super administrator, monitoring administrator Module verification in real time Determine, modify behaviors Super administrator Audit information setting Determine, modify behaviors Super administrator Mail notification setting Determine, modify behaviors Super administrator Agent management Determine, modify behaviors Super administrator User management Determine, modify behaviors Super administrator User policy establishment Determine, modify behaviors Super administrator User unlocking Determine, modify behaviors Super administrator Administrator management Determine, modify behaviors Super administrator Administrator policy establishment Determine, modify behaviors Super administrator Administrator password change Determine, modify behaviors Super administrator, monitoring administrator Version information viewing Determine behaviors Super administrator, monitoring administrator [Table 27] List of TSF data List of data Management Authorized administrator Audit information Query Super administrator, monitoring administrator Audit storage capacity threshold Query, modify Super administrator Cycle of integrity verification of cryptographic module and SSO module Query, modify Super administrator Mail server information Query, modify Super administrator Mail sending information Query, modify Super administrator Agent information Query, modify Super administrator User information Query, modify Super administrator User policy information Query, modify Super administrator Administrator information Query, modify Super administrator Administrator policy establishment Query, modify Super administrator The TOE provides the function of password change when the authorized administrator accesses for the first time, and the password rules are shown in [Table 25] Password security criteria. Only the authorized administrator is authorized to generate and change IDs and passwords of the administrator and end users. 84 / 86 Relevant SFR : FMT_MOF.1, FMT_MTD.1, FMT_PWD.1, FMT_SMF.1, FMT_SMR.1 6.5 Protection of the TSF The cryptographic communication of the TOE in transmitting data between the SSO Server and the SSO Agent is as follows: a) A symmetric key for data encryption is generated (algorithm: SEED/CBC/128) and the data are encrypted. b) The generated symmetric key is encrypted with the counterpart’s public key (algorithm: RSAES (SHA-256)) and transmitted together with the encrypted data. c) The counterpart uses the private key to decrypt the encrypted symmetric key (algorithm: RSAES (SHA-256)) and decrypts the transmitted data with the symmetric key (algorithm: SEED/CBC/128). The TSF data stored in the TOE are encrypted with “cryptographic key” and “cryptographic algorithm” in the following [Table 28] TSF data protection method, thereby being protected from unauthorized disclosure and modification. A derived key used in the TOE is derived by the password-based key derivation method. The derivation method generates a key by using the password-based key derivation function 2 (PBKDF2) defined in PKCS#5. [Table 28] How to protect TSF data Component Encryption Target Encryption Key Encryption algorithm Storage location SSO Server Master Key (DEK) Derived Key (KEK) SEED/CBC/128 File Certification Private Key Password Master Key (DEK) SEED/CBC/128 File DBMS Account Information Master Key (DEK) SEED/CBC/128 File Administrator Password - SHA-256 DBMS End-user Password - SHA-256 DBMS Authentication Token Generated Encryption Key SEED/CBC/128 Memory Certification Information Generated Encryption Key SEED/CBC/128 Memory Policy Setting Information Master Key (DEK) SEED/CBC/128 DBMS Preferences Information Master Key (DEK) SEED/CBC/128 File Transmission Information Encryption Symmetric Key Public Key RSAES(SHA-256) Memory Authentication Token Public Key RSAES(SHA-256) Memory 85 / 86 Encryption Symmetric Key SSO Agent Master Key (DEK) Derived Key (KEK) SEED/CBC/128 File Certification Private Key Password Master Key (DEK) SEED/CBC/128 File Authentication Token Generated Encryption Key SEED/CBC/128 Memory Certification Request Information Generated Encryption Key SEED/CBC/128 Memory Preferences Information Master Key (DEK) SEED/CBC/128 File Transmission Information Encryption Symmetric Key Public Key RSAES(SHA-256) Memory Authentication Token Encryption Symmetric Key Public Key RSAES(SHA-256) Memory The SSO Server is periodically (Choose what time every hour, what time every day, and what day of every month. Default value: 8 o'clock every day) and provides a self-test function upon request of the administrator. Since TOE is installed and operated on the Web Application Server, the self- test is judged by the presence or absence of a process in the Web Application Server. If the self- test fails, a warning message email is sent to the administrator. The SSO Server provides integrity verification function at the time of start-up, periodically (Choose what time every hour, what time every day, and what day of every month. Default value: 8 o'clock every day) during regular operation, and upon request of the administrator, the integrity verification targets include a password module, a TOE execution code, and a TOE configuration file. Integrity verification is performed by the TSF integrity test method in [Table 29] TSF Integrity Testing Method below, and a warning message email is sent to the administrator when integrity verification fails. The SSO Agent provides the self-test function when started, periodically (Choose what time every hour, what time every day, and what day of every month. Default value: 8 o'clock every day) during regular operation, and upon request of the administrator. Since TOE is installed and operated on the Web Application Server, the self-test is judged by the presence or absence of a process in the Web Application Server. If the self-test fails, a warning message email is sent to the administrator. In addition, if the self-test fails, the administrator can manually recover using the file backed up when installing the TSF. The SSO agent provides integrity verification function at start-up, periodically (Choose what time every hour, what time every day, and what day of every month. Default value: 8 o'clock every day) during regular operation, upon request of the administrator, and integrity verification targets 86 / 86 include a password module, a TOE execution code, and a TOE configuration file. Integrity verification is performed by the TSF integrity test method in [Table 29] TSF Integrity Testing Method below, and a warning message email is sent to the administrator when integrity verification fails. [Table 29] TSF Integrity Testing Method Component Integrity Verification Target Test algorithm Reference standard SSO Server Validated cryptographic modules Self-test - Executable code HMAC (SHA-256) ISO/IEC 9797-2 Configuration file HMAC (SHA-256) ISO/IEC 9797-2 SSO Agent Validated cryptographic modules Self-test - Executable code HMAC (SHA-256) ISO/IEC 9797-2 Configuration file HMAC (SHA-256) ISO/IEC 9797-2 Relevant SFR : FPT_ITT.1, FPT_PST.1, FPT_RCV.1, FPT_TST.1 6.6 TOE access The TOE limits the maximum number of simultaneous sessions for users with the same authority to 1, and blocks new access if the user or login again with the same authority on another terminal after access from one terminal. The TOE prohibits simultaneous session connection between a management access session and a local access session for the same administrator. Administrator management access denies access other than the administrator-configurable access IP (a positive number between 2 and 99, default value: 2). The administrator's access session ends after the administrator inactivity period (a positive number between 3 and 10 that can be configured by the administrator, default value: 10 minutes). The access session of the end user ends after the user inactivity period (a positive number between 3 and 10 that can be configured by the administrator, default value: 10 minutes). Relevant SFR : FTA_MCS.2, FTA_SSL.3, FTA_TSE.1