The TOE is a mobile device based on Android 7.0 with modifications made to increase the level of security provided to end users and enterprises. The TOE is intended to be used as part of an enterprise messaging solution providing mobile staff with enterprise connectivity.
\r\nThe TOE includes a Common Criteria mode (or “CC mode”) that an administrator can invoke through the use of an MDM or through a dedicated administrative application (see the Guidance for instructions to obtain the application). The TOE must meet the following prerequisites in order for an administrator to transition the TOE to CC mode.
\r\n· Require a screen lock password (swipe, PIN, pattern, or facial recognition screen locks are not allowed).
\r\n· The maximum password failure retry policy should be less than or equal to ten.
\r\n· Device encryption must be enabled or a screen lock password required to decrypt data on boot.
\r\n· Revocation checking must be enabled.
\r\n· External storage must be encrypted.
\r\n· Password (non-container) recovery policy must not be enabled.
\r\nWhen CC mode has been enabled, the TOE behaves as follows.
\r\n· The TOE sets the system wide Android CC mode property to “Enabled” if all the prerequisites have been met.
\r\n· The TOE performs secure boot integrity checking of the kernel and key system executables.
\r\n· The TOE prevents loading of custom firmware/kernels and requires all updates occur through FOTA (Samsung’s Firmware Over The Air firmware update method)
\r\n· The TOE uses CAVP approved cryptographic ciphers when joining and communicating with wireless networks.
\r\n· The TOE utilizes CAVP approved cryptographic ciphers for TLS.
\r\n· The TOE ensures FOTA updates utilize 2048-bit PKCS #1 RSA-PSS formatted signatures (with SHA-512 hashing).
\r\nThe TOE includes a containerization capability, KNOX Workspace, which is part of the KNOX platform. This container 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 a KNOX Workspace container created (and to create a KNOX Workspace container, one must purchase an additional license). Thus, the evaluation includes several KNOX-specific claims that apply to a KNOX Workspace container when created.
","evaluation_configuration":"\r\n\r\nThe evaluated configuration consists of the following devices:
\r\n| \r\n Device Name \r\n | \r\n\r\n Model | \r\n\r\n \r\n Chipset \r\n | \r\n\r\n Android | \r\n\r\n Kernel Version \r\n | \r\n\r\n Build Number \r\n | \r\n
| \r\n Galaxy S8 (Qualcomm) \r\n | \r\n\r\n SM-G950 \r\n | \r\n\r\n MSM8998 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 4.4.16 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S8 (System LSI) \r\n | \r\n\r\n SM-G950 \r\n | \r\n\r\n Exynos 8895 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 4.4.13 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S8 + (Qualcomm) \r\n | \r\n\r\n SM-G955 \r\n | \r\n\r\n MSM8998 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 4.4.16 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S8 + (System LSI) \r\n | \r\n\r\n SM-G955 \r\n | \r\n\r\n Exynos 8895 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 4.4.13 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S8 Active \r\n | \r\n\r\n SM-G892 \r\n | \r\n\r\n MSM8998 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 4.4.16 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n \r\n Galaxy Tab S3 \r\n | \r\n\r\n SM-T820 \r\n | \r\n\r\n MSM8996 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.18.31 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n SM-T825 \r\n | \r\n\r\n MSM8996 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.18.31 \r\n | \r\n\r\n NRD90M \r\n | \r\n|
| \r\n SM-T827 \r\n | \r\n\r\n MSM8996 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.18.31 \r\n | \r\n\r\n NRD90M \r\n | \r\n|
| \r\n Galaxy S7 (Qualcomm) \r\n | \r\n\r\n SM-G930 \r\n | \r\n\r\n MSM8996 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.18.31 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S7 (System LSI) \r\n | \r\n\r\n SM-G930 \r\n | \r\n\r\n Exynos 8890 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.18.14 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S7 Edge (Qualcomm) \r\n | \r\n\r\n SM-G935 \r\n | \r\n\r\n MSM8996 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.18.31 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S7 Edge (System LSI) \r\n | \r\n\r\n SM-G935 \r\n | \r\n\r\n Exynos 8890 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.18.14 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S7 Active \r\n | \r\n\r\n SM-G891 \r\n | \r\n\r\n MSM8996 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.18.31 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S6 Edge+ \r\n | \r\n\r\n SM-G928 \r\n | \r\n\r\n Exynos 7420 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.10.61 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy Note 5 \r\n | \r\n\r\n SM-N920 \r\n | \r\n\r\n Exynos 7420 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.10.61 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S6 \r\n | \r\n\r\n SM-G920 \r\n | \r\n\r\n Exynos 7420 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.10.61 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S6 Edge \r\n | \r\n\r\n SM-G925 \r\n | \r\n\r\n Exynos 7420 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.10.61 \r\n | \r\n\r\n NRD90M \r\n | \r\n
| \r\n Galaxy S6 Active \r\n | \r\n\r\n SM-G890 \r\n | \r\n\r\n Exynos 7420 \r\n | \r\n\r\n 7.0 \r\n | \r\n\r\n 3.10.61 \r\n | \r\n\r\n NRD90M \r\n | \r\n
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 4, September 2012. 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 4, July 2012. The product, when delivered and configured as identified in the Samsung Android 7 on Galaxy Devices Guidance documentation, Version 3.0, June 1, 2017 document, satisfies all of the security functional requirements stated in the Samsung Electronics Co., Ltd. Samsung Galaxy Devices on Android 7 (MDFPP30/WLANCEP10) Security Target, Version 0.3, May 30, 2017. The project underwent CCEVS Validator review. The evaluation was completed in June 2017. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report (report number CCEVS-VR-VID10809-2017) prepared by CCEVS.
\r\n","environmental_strengths":"\r\n\r\nThe logical boundaries of the Samsung Galaxy Devices on Android 7 (MDFPP30) are realized in the security functions that it implements. Each of these security functions is summarized below.
\r\nSecurity Audit - The TOE is designed to be able to generate 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 - The TOE includes a cryptographic library with CAVP certified algorithms for a wide range of cryptographic functions including: 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, IPsec, and HTTPS and also 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 - The TOE is designed to control access to system services by hosted applications, including protection of the Trust Anchor Database. Additionally, the TOE is designed to protect user and other sensitive data using encryption so that even if a device is physically lost, the data remains protected. The functionality provided by a KNOX Workspace container enhances the security of user data by providing an additional layer of separation between apps and data while the device is in use.
\r\nIdentification and authentication - The 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. Also, 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 and 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 cases characters, numbers, and special characters and passwords between 4 and 16 characters are supported.
\r\nThe TOE can also serve as an 802.1X supplicant and can use X509v3 and validate certificates for EAP-TLS, TLS and IPsec exchanges.
\r\nSecurity management - The TOE provides all the interfaces necessary to manage the security functions 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 - The TOE implements a number of features designed 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 is also designed to protect itself from modification by applications as well as to isolate 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 of the 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 - The 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 - The TOE supports the use of 802.11-2012, 802.1X, EAP-TLS, TLS and IPsec to secure communications channels between itself and other trusted network devices.
","features":[]}