The TOE is a mobile device based on Android 13 with a built-in IPsec VPN client and modifications made to increase the level of security provided to end users and enterprises. The TOE is intended for use as part of an enterprise mobility solution providing mobile staff with enterprise connectivity.
\r\nThe TOE includes a Common Criteria mode (or “CC mode”) that an administrator can invoke using an MDM. The TOE must meet the following prerequisites in order for an administrator to transition the TOE to and remain in the CC configuration.
\r\n· Require a boot and device lock password (swipe, PIN, pattern, accessibility (direction), screen locks are not allowed). Acceptable biometrics vary with the device for the device lock.
\r\n· The maximum password failure retry policy should be less than or equal to 30.
\r\n· A screen lock password required to decrypt data on boot.
\r\n· Revocation checking must be enabled.
\r\n· Security and audit logging must be enabled.
\r\n· External storage must be encrypted.
\r\n· Developer debugging must be disabled.
\r\n· When CC mode has been enabled, the TOE behaves as follows:
\r\no The TOE sets the system wide Android CC mode property to be enabled.
\r\no The TOE prevents loading of custom firmware/kernels and requires all updates occur through FOTA.
\r\no The TOE utilizes ACVP/CAVP approved cryptographic ciphers for TLS.
\r\nThe TOE includes the ability to create separate profiles part of the Knox Platform. A profile provides a way to segment applications and data into two separate areas on the device, such as a personal area and a work area, each with its own separate apps, data and security policies. For this effort, the TOE was evaluated both without and with profiles created. Thus, the evaluation includes several Knox-specific claims that apply when these profiles are created.
\r\nThere are different models of the TOE, the Samsung Galaxy Devices on Android 13, and these models differ in their internal components (as described in the table below). All devices are A64 architecture.
","evaluation_configuration":"The model numbers of the mobile devices used during evaluation testing are as follows:
\r\n| \r\n\r\n | \r\n\r\n\r\n | \r\n\r\n SoC \r\n | \r\n\r\n Arch \r\n | \r\n\r\n Kernel \r\n | \r\n\r\n Build Number \r\n | \r\n
| \r\n Galaxy Z Flip5 5G \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 8 Gen 2 (SM8550) \r\n | \r\n\r\n ARMv8 \r\n | \r\n\r\n 5.15 \r\n | \r\n\r\n TP1A.220624.014 \r\n | \r\n
| \r\n Galaxy A52 5G \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 750G (SM7225) \r\n | \r\n\r\n ARMv8 \r\n | \r\n\r\n 4.19 \r\n | \r\n\r\n TP1A.220624.014 \r\n | \r\n
| \r\n Galaxy A71 5G \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 765 \r\n | \r\n\r\n ARMv8 \r\n | \r\n\r\n 4.19 \r\n | \r\n\r\n TP1A.220624.014 \r\n | \r\n
| \r\n Galaxy Tab Active3 \r\n | \r\n\r\n Samsung \r\n | \r\n\r\n Exynos 9810 \r\n | \r\n\r\n ARMv8 \r\n | \r\n\r\n 4.9 \r\n | \r\n\r\n SP1A.210812.016 \r\n | \r\n
| \r\n Galaxy S23 FE \r\n | \r\n\r\n Samsung \r\n | \r\n\r\n Exynos 2200 \r\n | \r\n\r\n ARMv8 \r\n | \r\n\r\n 5.10 \r\n | \r\n\r\n SP1A.210812.016 \r\n | \r\n
| \r\n Galaxy S23 FE \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 8 Gen 1 (SM8450) \r\n | \r\n\r\n ARMv8 \r\n | \r\n\r\n 5.10 \r\n | \r\n\r\n SP1A.210812.016 \r\n | \r\n
In addition to the evaluated devices, the following are claimed as equivalent:
\r\n| \r\n Evaluated Device \r\n | \r\n\r\n SoC \r\n | \r\n\r\n Equivalent Devices \r\n | \r\n\r\n Differences \r\n | \r\n
| \r\n Galaxy Z Flip5 5G \r\n | \r\n\r\n Snapdragon 8 Gen 2 \r\n | \r\n\r\n Galaxy Z Fold5 5G \r\n | \r\n\r\n Z Fold5 > Z Flip5 in terms of display size \r\n | \r\n
| \r\n Galaxy Tab S9 Ultra \r\n | \r\n\r\n Tab S9 devices are tablets (no voice calling) with S Pen \r\n | \r\n||
| \r\n Galaxy Tab S9+ \r\n | \r\n\r\n Tab S9 Ultra > Tab S9+ > Tab S9 in terms of display size \r\n | \r\n||
| \r\n Galaxy Tab S9 \r\n | \r\n\r\n All Tab S9 has under screen image fingerprint sensor \r\n | \r\n||
| \r\n Galaxy A52 5G \r\n | \r\n\r\n Snapdragon 750 \r\n | \r\n\r\n Galaxy A42 5G \r\n | \r\n\r\n A52 5G > A42 5G screen resolution & RAM \r\n | \r\n
| \r\n Galaxy A71 5G \r\n | \r\n\r\n Snapdragon 765 \r\n | \r\n\r\n Galaxy A51 5G \r\n | \r\n\r\n A71 5G > A51 5G in terms of display size \r\n | \r\n
| \r\n Galaxy Tab Active3 \r\n | \r\n\r\n Exynos 9810 \r\n | \r\n\r\n N/A \r\n | \r\n\r\n T577 & T575 tablets have 5G \r\n | \r\n
| \r\n T570 tablets only have Wi-Fi \r\n | \r\n|||
| \r\n Galaxy S23 FE \r\n | \r\n\r\n Exynos 2200 \r\n | \r\n\r\n N/A \r\n | \r\n\r\n |
| \r\n Galaxy S23 FE \r\n | \r\n\r\n Snapdragon 8 Gen 1 (SM8450) \r\n | \r\n\r\n N/A \r\n | \r\n\r\n \r\n | \r\n
Equivalent Devices
\r\nEquivalent devices are claimed as equivalent with a note about the differences between the evaluated device (first column) and the equivalent models (noted in the third column with the differences in the fourth column). Equivalence in this table is determined by the use of identical processors, kernel and build number, and is not made across processor types. If a device may be released with different processors around the world, a version of the device with each processor will be tested, and equivalence will be claimed specifically to similar devices utilizing the same processor.
\r\nThe Differences column in the table denotes the differences between the evaluated device and those listed in the Equivalent column (which typically contains multiple different derivative devices), and are not meant to line up with the devices listed in the Equivalent column itself. Except in the case of a different Wi-Fi radios or biometric sensors (in which case the radio or biometric is tested on a different device and so always verified as part of the evaluation), any differences between the evaluated device and claimed equivalent devices are outside the requirements of the evaluation requirements, such as screen size/type/resolution, battery size, position of ports. In general, the devices include a final letter or number at the end of the name that denotes that the device is for a specific carrier or region (for example, U = US Carrier build and F = International, which were used during the evaluation).
\r\nFor each device, there are specific models that are validated. This table lists the specific carrier models that have the validated configuration (covering both evaluated and equivalent devices).
\r\n| \r\n Device Name \r\n | \r\n\r\n Chipset Vendor \r\n | \r\n\r\n Chipset Name \r\n | \r\n\r\n Base Model Number \r\n | \r\n\r\n Carrier Models \r\n | \r\n
| \r\n Galaxy Z Fold5 5G \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 8 Gen 2 (SM8550) \r\n | \r\n\r\n SM-F946 \r\n | \r\n\r\n W, B, N, U1, U \r\n | \r\n
| \r\n Galaxy Z Flip5 5G \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 8 Gen 2 (SM8550) \r\n | \r\n\r\n SM-F731 \r\n | \r\n\r\n W, B, C, N, U1, U \r\n | \r\n
| \r\n Galaxy A51 5G \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 765G (SM7250) \r\n | \r\n\r\n SM-A516 \r\n | \r\n\r\n V, SC54A*, SCG07* \r\n | \r\n
| \r\n Galaxy A71 5G \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 765G (SM7250) \r\n | \r\n\r\n SM-A716 \r\n | \r\n\r\n U1, U, V \r\n | \r\n
| \r\n Galaxy A52 5G \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 750G (SM7225) \r\n | \r\n\r\n SM-A526 \r\n | \r\n\r\n W, B, U1, U, SC-53B \r\n | \r\n
| \r\n Galaxy Tab S9 Ultra \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 8 Gen 2 (SM8550) \r\n | \r\n\r\n SM-X916 \r\n | \r\n\r\n B, N \r\n | \r\n
| \r\n SM-X900 \r\n | \r\n\r\n None \r\n | \r\n|||
| \r\n Galaxy Tab S9+ \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 8 Gen 2 (SM8550) \r\n | \r\n\r\n SM-X818 \r\n | \r\n\r\n U \r\n | \r\n
| \r\n SM-X816 \r\n | \r\n\r\n B, N, E \r\n | \r\n|||
| \r\n SM-X810 \r\n | \r\n\r\n None \r\n | \r\n|||
| \r\n Galaxy Tab S9 \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 8 Gen 2 (SM8550) \r\n | \r\n\r\n SM-X716 \r\n | \r\n\r\n B, N \r\n | \r\n
| \r\n SM-X710 \r\n | \r\n\r\n None \r\n | \r\n|||
| \r\n Galaxy Tab Active3 \r\n | \r\n\r\n Samsung \r\n | \r\n\r\n Exynos 9810 \r\n | \r\n\r\n SM-T577 \r\n | \r\n\r\n U \r\n | \r\n
| \r\n SM-T575 \r\n | \r\n\r\n N, None \r\n | \r\n|||
| \r\n SM-T570 \r\n | \r\n\r\n None \r\n | \r\n|||
| \r\n Galaxy A42 5G \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 750G (SM7225) \r\n | \r\n\r\n SM-A426 \r\n | \r\n\r\n B, N, U1, U \r\n | \r\n
| \r\n SM-S426 \r\n | \r\n\r\n DL \r\n | \r\n|||
| \r\n Galaxy S23 FE \r\n | \r\n\r\n Samsung \r\n | \r\n\r\n Exynos 2200 \r\n | \r\n\r\n SM-S711 \r\n | \r\n\r\n B \r\n | \r\n
| \r\n Galaxy S23 FE \r\n | \r\n\r\n Qualcomm \r\n | \r\n\r\n Snapdragon 8 Gen 1 (SM8450) \r\n | \r\n\r\n SM-S711 \r\n | \r\n\r\n W, U1, U \r\n | \r\n
Carrier Models
","security_evaluation_summary":"The evaluation was carried out in accordance to the Common Criteria Evaluation and Validation Scheme (CCEVS) requirements and guidance. The evaluation demonstrated that the TOE meets the security requirements contained in the Security Target. The criteria against which the TOE was judged are described in the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5, April 2017. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 5, April 2017. The product, when delivered and configured as identified in the Samsung Android 13 on Galaxy Devices Administrator Guide, Version 9.0.2, October 16, 2023 document, satisfies all of the security functional requirements stated in the Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 13 – Fall Security Target, Version 0.4, October 23, 2023. The project underwent CCEVS Validator review. The evaluation was completed in October 2023. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report (report number CCEVS-VR-VID11410-2023) prepared by CCEVS.
","environmental_strengths":"The logical boundaries of the Samsung Galaxy Devices on Android 13 - Fall are realized in the security functions that it implements. Each of these security functions is summarized below.
\r\nSecurity audit:
\r\nThe TOE generates logs for a range of security relevant events. The TOE stores the logs locally so they can be accessed by an administrator or they can be exported to an MDM.
\r\nCryptographic support:
\r\nThe TOE includes multiple cryptographic libraries with ACVP certified algorithms for a wide range of cryptographic functions including the following: asymmetric key generation and establishment, symmetric key generation, encryption/decryption, cryptographic hashing and keyed-hash message authentication. These functions are supported with suitable random bit generation, key derivation, salt generation, initialization vector generation, secure key storage, and key and protected data destruction. These primitive cryptographic functions are used to implement security protocols such as TLS, EAP-TLS, IPsec, and HTTPS and to encrypt the media (including the generation and protection of data and key encryption keys) used by the TOE. Many of these cryptographic functions are also accessible as services to applications running on the TOE.
\r\nUser data protection:
\r\nThe TOE controls access to system services by hosted applications, including protection of the Trust Anchor Database. Additionally, the TOE protects user and other sensitive data using encryption so that even if a device is physically lost, the data remains protected. The functionality provided by work profiles and Knox Separated Apps enhance the security of user data by providing an additional layer of separation between different categories of apps and data while the device is in use. The TOE ensures that residual information is protected from potential reuse in accessible objects such as network packets.
\r\nIdentification and authentication:
\r\nThe TOE supports a number of features related to identification and authentication. From a user perspective, except for making phone calls to an emergency number, a password or Biometric Authentication Factor (BAF) must be correctly entered to unlock the TOE. In addition, even when the TOE is unlocked the password must be re-entered to change the password or re-enroll the biometric template. Passwords are obscured when entered so they cannot be read from the TOE's display, the frequency of entering passwords is limited and when a configured number of failures occurs, the TOE will be wiped to protect its contents. Passwords can be constructed using upper and lower case characters, numbers, and special characters and passwords between 4 and 16 characters are supported. The TOE can also be configured to utilize a biometric authentication factor (fingerprints), to unlock the device (Note: This only works after the primary authentication method, password, has been entered after the device powers on).
\r\nThe TOE can also serve as an 802.1X supplicant and can use X.509v3 and validate certificates for EAP-TLS, TLS and IPsec exchanges. The TOE can also act as a client or server in an authenticated Bluetooth pairing.
\r\nSecurity management:
\r\nThe TOE provides all the interfaces necessary to manage the security functions (including the VPN client) identified throughout this Security Target as well as other functions commonly found in mobile devices. Many of the available functions are available to users of the TOE while many are restricted to administrators operating through a Mobile Device Management solution once the TOE has been enrolled. Once the TOE has been enrolled and then un-enrolled, it removes all MDM policies and disables CC mode.
\r\nProtection of the TSF:
\r\nThe TOE implements a number of features to protect itself to ensure the reliability and integrity of its security features. It protects particularly sensitive data such as cryptographic keys so that they are not accessible or exportable. It also provides its own timing mechanism to ensure that reliable time information is available (e.g., for log accountability). It enforces read, write, and execute memory page protections, uses address space layout randomization, and stack-based buffer overflow protections to minimize the potential to exploit application flaws. It also protects itself from modification by applications as well as isolates the address spaces of applications from one another to protect those applications.
\r\nThe TOE includes functions to perform self-tests and software/firmware integrity checking so that it might detect when it is failing or may be corrupt. If any self-tests fail, the TOE will not go into an operational mode. It also includes mechanisms (i.e., verification of the digital signature of each new image) so that the TOE itself can be updated while ensuring that the updates will not introduce malicious or other unexpected changes in the TOE. Digital signature checking also extends to verifying applications prior to their installation.
\r\nTOE access:
\r\nThe TOE can be locked, obscuring its display, by the user or after a configured interval of inactivity. The TOE also has the capability to display an advisory message (banner) when users unlock the TOE for use.
\r\nThe TOE is also able to attempt to connect to wireless networks as configured.
\r\nTrusted path/channels:
\r\nThe TOE supports the use of 802.11-2012, 802.1X, EAP-TLS, TLS, HTTPS and IPsec to secure communications channels between itself and other trusted network devices.
","features":[]}